Pemantauan dan Telemetri (Membangun Real-World Cloud Apps dengan Azure)

oleh Rick Anderson, Tom Dykstra

Unduh Fix It Project atau Unduh E-book

E-book Building Real World Cloud Apps dengan Azure didasarkan pada presentasi yang dikembangkan oleh Scott Guthrie. Ini menjelaskan 13 pola dan praktik yang dapat membantu Anda berhasil mengembangkan aplikasi web untuk cloud. Untuk informasi tentang e-book, lihat bab pertama.

Banyak orang mengandalkan pelanggan untuk memberi tahu mereka ketika aplikasi mereka tidak berfungsi. Itu bukan praktik terbaik di mana saja, dan terutama tidak di cloud. Tidak ada jaminan pemberitahuan cepat, dan ketika Anda mendapatkan pemberitahuan, Anda sering mendapatkan data minimal atau menyesatkan tentang apa yang terjadi. Dengan sistem telemetri dan pengelogan yang baik, Anda dapat mengetahui apa yang terjadi dengan aplikasi Anda, dan ketika terjadi kesalahan, Anda segera mengetahui dan memiliki informasi pemecahan masalah yang bermanfaat untuk dikerjakan.

Membeli atau menyewa solusi telemetri

Catatan

Artikel ini ditulis sebelum Application Insights dirilis. Application Insights adalah pendekatan yang disukai untuk solusi telemetri di Azure. Lihat Menyiapkan Application Insights untuk situs web ASP.NET Anda untuk informasi selengkapnya.

Salah satu hal yang hebat tentang lingkungan cloud adalah sangat mudah untuk membeli atau menyewa cara Anda untuk menang. Telemetri adalah contohnya. Tanpa banyak usaha Anda bisa mendapatkan sistem telemetri yang benar-benar baik dan berjalan, sangat hemat biaya. Ada banyak mitra hebat yang berintegrasi dengan Azure, dan beberapa di antaranya memiliki tingkat gratis - sehingga Anda bisa mendapatkan telemetri dasar tanpa hasil. Berikut adalah beberapa yang saat ini tersedia di Azure:

• New Relic
• AppDinamics
• Dynatrace

Microsoft System Center juga menyertakan fitur pemantauan.

Kita akan dengan cepat menelusuri pengaturan New Relic untuk menunjukkan betapa mudahnya menggunakan sistem telemetri.

Di portal manajemen Azure, daftar untuk layanan. Klik Baru, lalu klik Simpan. Kotak dialog Pilih Add-on muncul. Gulir ke bawah dan klik New Relic.

Klik panah kanan dan pilih tingkat layanan yang Anda inginkan. Untuk demo ini kita akan menggunakan tingkat gratis.

Klik panah kanan, konfirmasi "pembelian", dan New Relic sekarang muncul sebagai Add-on di portal.

Klik Info Koneksi, dan salin kunci lisensi.

Buka tab Konfigurasi untuk aplikasi web Anda di portal, atur Pemantauan Performa ke Add-On, dan atur daftar drop-down Pilih Add-On ke New Relic. Lalu klik Simpan.

Di Visual Studio, instal paket New Relic NuGet di aplikasi Anda.

Sebarkan aplikasi ke Azure dan mulai gunakan. Buat beberapa tugas Fix It untuk menyediakan beberapa aktivitas bagi New Relic untuk dipantau.

Lalu kembali ke halaman New Relic di tab Add-on portal dan klik Kelola. Portal mengirimkan Anda ke portal manajemen New Relic, menggunakan akses menyeluruh untuk autentikasi sehingga Anda tidak perlu memasukkan kredensial Anda lagi. Halaman Gambaran Umum menyajikan berbagai statistik performa. (Klik gambar untuk melihat halaman gambaran umum ukuran penuh.)

Berikut adalah beberapa statistik yang dapat Anda lihat:

• Waktu respons rata-rata pada waktu yang berbeda dalam sehari.

  

• Tarif throughput (dalam permintaan per menit) pada waktu yang berbeda dalam sehari.

  

• Waktu CPU server yang dihabiskan untuk menangani permintaan HTTP yang berbeda.

  

• Waktu CPU yang dihabiskan di berbagai bagian kode aplikasi:

  

• Statistik performa historis.

  

• Panggilan ke layanan eksternal seperti layanan Blob dan statistik tentang seberapa andal dan responsif layanan tersebut.

  

  

  

• Informasi tentang dari mana di dunia atau dari mana lalu lintas aplikasi web AS berasal.

  

Anda juga dapat menyiapkan laporan dan peristiwa. Misalnya, Anda dapat mengatakan kapan saja Anda mulai melihat kesalahan, mengirim email ke staf dukungan pemberitahuan untuk masalah tersebut.

New Relic hanyalah salah satu contoh sistem telemetri; Anda juga bisa mendapatkan semua ini dari layanan lain. Keindahan cloud adalah bahwa tanpa harus menulis kode apa pun, dan untuk biaya minimal atau tanpa biaya, Anda tiba-tiba bisa mendapatkan lebih banyak informasi tentang bagaimana aplikasi Anda digunakan dan apa yang sebenarnya dialami pelanggan Anda.

Log untuk wawasan

Paket telemetri adalah langkah pertama yang baik, tetapi Anda masih harus melengkapi kode Anda sendiri. Layanan telemetri memberi tahu Anda ketika ada masalah dan memberi tahu Anda apa yang dialami pelanggan, tetapi mungkin tidak memberi Anda banyak wawasan tentang apa yang terjadi dalam kode Anda.

Anda tidak ingin harus melakukan remote ke server produksi untuk melihat apa yang dilakukan aplikasi Anda. Itu mungkin praktis ketika Anda memiliki satu server, tetapi bagaimana dengan ketika Anda telah menskalakan ke ratusan server dan Anda tidak tahu mana yang Anda butuhkan untuk jarak jauh? Pengelogan Anda harus memberikan informasi yang cukup bahwa Anda tidak perlu jarak jauh ke server produksi untuk menganalisis dan men-debug masalah. Anda harus mencatat informasi yang cukup sehingga Anda dapat mengisolasi masalah hanya melalui log.

Masuk produksi

Banyak orang mengaktifkan pelacakan dalam produksi hanya ketika ada masalah dan mereka ingin men-debug. Ini dapat memperkenalkan penundaan substansial antara waktu Anda mengetahui masalah dan waktu Anda mendapatkan informasi pemecahan masalah yang berguna tentang hal itu. Dan informasi yang Anda dapatkan mungkin tidak berguna untuk kesalahan terputus-terputus.

Apa yang kami rekomendasikan di lingkungan cloud di mana penyimpanan murah adalah Anda selalu membiarkan masuk dalam produksi. Dengan begitu ketika kesalahan terjadi, Anda sudah mencatatnya, dan Anda memiliki data historis yang dapat membantu Anda menganalisis masalah yang berkembang dari waktu ke waktu atau terjadi secara teratur pada waktu yang berbeda. Anda dapat mengotomatiskan proses pembersihan untuk menghapus log lama, tetapi Anda mungkin menemukan bahwa lebih mahal untuk menyiapkan proses seperti itu daripada menyimpan log.

Pengeluaran pengelogan tambahan sepele dibandingkan dengan jumlah waktu pemecahan masalah dan uang yang dapat Anda hemat dengan memiliki semua informasi yang Anda butuhkan sudah tersedia ketika terjadi kesalahan. Kemudian ketika seseorang memberi tahu Anda bahwa mereka memiliki kesalahan acak sekitar pukul 8:00 tadi malam, tetapi mereka tidak ingat kesalahannya, Anda dapat dengan mudah mencari tahu apa masalahnya.

Selama kurang dari $ 4 sebulan Anda dapat menyimpan 50 gigabyte log di tangan, dan dampak performa pengelogan sepele selama Anda mengingat satu hal - untuk menghindari penyempitan performa, pastikan pustaka pengelogan Anda tidak sinkron.

Membedakan log yang menginformasikan dari log yang memerlukan tindakan

Log dimaksudkan untuk INFORM (Saya ingin Anda mengetahui sesuatu) atau ACT (saya ingin Anda melakukan sesuatu). Berhati-hatilah untuk hanya menulis log ACT untuk masalah yang benar-benar mengharuskan seseorang atau proses otomatis untuk mengambil tindakan. Terlalu banyak log ACT akan menciptakan kebisingan, membutuhkan terlalu banyak pekerjaan untuk menyaring semuanya untuk menemukan masalah asli. Dan jika log ACT Anda secara otomatis memicu beberapa tindakan seperti mengirim email ke staf pendukung, hindari membiarkan ribuan tindakan tersebut dipicu oleh satu masalah.

Dalam pelacakan .NET System.Diagnostics, log dapat ditetapkan tingkat Kesalahan, Peringatan, Info, dan Debug/Verbose. Anda dapat membedakan ACT dari log INFORM dengan mempertahankan tingkat Kesalahan untuk log ACT dan menggunakan tingkat yang lebih rendah untuk log INFORM.

Mengonfigurasi tingkat pengelogan pada durasi

Meskipun ada baiknya untuk selalu masuk dalam produksi, praktik terbaik lainnya adalah menerapkan kerangka kerja pengelogan yang memungkinkan Anda menyesuaikan pada run-time tingkat detail yang Anda catat, tanpa menyebarkan ulang atau memulai ulang aplikasi Anda. Misalnya saat Anda menggunakan fasilitas pelacakan di System.Diagnostics Anda dapat membuat log Kesalahan, Peringatan, Info, dan Debug/Verbose. Kami sarankan Anda selalu mencatat log Kesalahan, Peringatan, dan Info dalam produksi, dan Anda mungkin ingin dapat menambahkan pengelogan Debug/Verbose secara dinamis untuk pemecahan masalah berdasarkan kasus per kasus.

Web Apps di Azure App Service memiliki dukungan bawaan untuk menulis System.Diagnostics log ke sistem file, penyimpanan Tabel, atau penyimpanan Blob. Anda dapat memilih tingkat pengelogan yang berbeda untuk setiap tujuan penyimpanan, dan Anda dapat mengubah tingkat pengelogan dengan cepat tanpa memulai ulang aplikasi Anda. Dukungan penyimpanan Blob memudahkan untuk menjalankan pekerjaan analisis HDInsight pada log aplikasi Anda, karena HDInsight tahu cara bekerja dengan penyimpanan Blob secara langsung.

Pengecualian Log

Jangan hanya menempatkan pengecualian. ToString() dalam kode pengelogan Anda. Itu meninggalkan informasi kontekstual. Dalam kasus kesalahan SQL, itu meninggalkan nomor kesalahan SQL. Untuk semua pengecualian, sertakan informasi konteks, pengecualian itu sendiri, dan pengecualian dalam untuk memastikan bahwa Anda menyediakan semua yang akan diperlukan untuk pemecahan masalah. Misalnya, informasi konteks mungkin menyertakan nama server, pengidentifikasi transaksi, dan nama pengguna (tetapi bukan kata sandi atau rahasia apa pun!).

Jika Anda mengandalkan setiap pengembang untuk melakukan hal yang benar dengan pengelogan pengecualian, beberapa di antaranya tidak akan. Untuk memastikan bahwa itu dilakukan dengan cara yang benar setiap saat, bangun penanganan pengecualian langsung ke antarmuka pencatat Anda: teruskan objek pengecualian itu sendiri ke kelas pencatat dan catat data pengecualian dengan benar di kelas pencatat.

Mencatat panggilan ke layanan

Kami sangat menyarankan Agar Anda menulis log setiap kali aplikasi Anda memanggil layanan, baik itu ke database atau REST API atau layanan eksternal apa pun. Sertakan dalam log Anda tidak hanya indikasi keberhasilan atau kegagalan tetapi berapa lama setiap permintaan berlangsung. Di lingkungan cloud, Anda akan sering melihat masalah yang terkait dengan perlambatan daripada menyelesaikan pemadaman. Sesuatu yang biasanya membutuhkan waktu 10 milidetik mungkin tiba-tiba mulai mengambil satu detik. Ketika seseorang memberi tahu Anda bahwa aplikasi Anda lambat, Anda ingin dapat melihat New Relic atau layanan telemetri apa pun yang Anda miliki dan memvalidasi pengalaman mereka, dan kemudian Anda ingin dapat melihat adalah log Anda sendiri untuk menyelami detail mengapa lambat.

Menggunakan antarmuka ILogger

Apa yang kami sarankan lakukan ketika Anda membuat aplikasi produksi adalah membuat antarmuka ILogger sederhana dan menempelkan beberapa metode di dalamnya. Ini memudahkan untuk mengubah implementasi pengelogan nanti dan tidak harus melalui semua kode Anda untuk melakukannya. Kita bisa menggunakan kelas di System.Diagnostics.Trace seluruh aplikasi Fix It, tetapi sebaliknya kita menggunakannya di bawah sampul di kelas pengelogan yang mengimplementasikan ILogger, dan kita melakukan panggilan metode ILogger di seluruh aplikasi.

Dengan begitu, jika Anda ingin membuat pengelogan Anda lebih kaya, Anda dapat mengganti System.Diagnostics.Trace dengan mekanisme pengelogan apa pun yang Anda inginkan. Misalnya, seiring bertambahnya aplikasi, Anda mungkin memutuskan bahwa Anda ingin menggunakan paket pengelogan yang lebih komprehensif seperti NLog atau Blok Aplikasi Pengelogan Pustaka Perusahaan. (Log4Net adalah kerangka kerja pengelogan populer lainnya tetapi tidak melakukan pengelogan asinkron.)

Salah satu alasan yang mungkin untuk menggunakan kerangka kerja seperti NLog adalah untuk memfasilitasi membagi output pengelogan menjadi penyimpanan data volume tinggi dan bernilai tinggi terpisah. Itu membantu Anda menyimpan data INFORM dalam volume besar yang tidak perlu Anda jalankan dengan cepat, sambil mempertahankan akses cepat ke data ACT.

Pengelogan Semantik

Untuk cara yang relatif baru untuk melakukan pengelogan yang dapat menghasilkan informasi diagnostik yang lebih berguna, lihat Blok Aplikasi Pengelogan Semantik Pustaka Perusahaan (SLAB). SLAB menggunakan dukungan Event Tracing for Windows (ETW) dan EventSource di .NET 4.5 untuk memungkinkan Anda membuat log yang lebih terstruktur dan dapat dikueri. Anda menentukan metode yang berbeda untuk setiap jenis peristiwa yang Anda catat, yang memungkinkan Anda menyesuaikan informasi yang Anda tulis. Misalnya, untuk mencatat kesalahan SQL Database Anda mungkin memanggil LogSQLDatabaseError metode . Untuk pengecualian semacam itu, Anda tahu bagian kunci informasi adalah nomor kesalahan, sehingga Anda dapat menyertakan parameter nomor kesalahan dalam tanda tangan metode dan merekam nomor kesalahan sebagai bidang terpisah dalam catatan log yang Anda tulis. Karena angka tersebut berada di bidang terpisah, Anda dapat dengan lebih mudah dan andal mendapatkan laporan berdasarkan nomor kesalahan SQL daripada yang Anda bisa jika Anda hanya menggabungkan nomor kesalahan menjadi string pesan.

Pengelogan di aplikasi Fix It

Antarmuka ILogger

Berikut adalah antarmuka ILogger di aplikasi Fix It.

public interface ILogger
{
    void Information(string message);
    void Information(string fmt, params object[] vars);
    void Information(Exception exception, string fmt, params object[] vars);

    void Warning(string message);
    void Warning(string fmt, params object[] vars);
    void Warning(Exception exception, string fmt, params object[] vars);

    void Error(string message);
    void Error(string fmt, params object[] vars);
    void Error(Exception exception, string fmt, params object[] vars);

    void TraceApi(string componentName, string method, TimeSpan timespan);
    void TraceApi(string componentName, string method, TimeSpan timespan, string properties);
    void TraceApi(string componentName, string method, TimeSpan timespan, string fmt, params object[] vars);
}

Metode ini memungkinkan Anda menulis log pada empat tingkat yang sama yang didukung oleh System.Diagnostics. Metode TraceApi adalah untuk mencatat panggilan layanan eksternal dengan informasi tentang latensi. Anda juga dapat menambahkan sekumpulan metode untuk tingkat Debug/Verbose.

Implementasi Pencatat antarmuka ILogger

Implementasi antarmukanya sangat sederhana. Ini pada dasarnya hanya memanggil ke metode System.Diagnostics standar. Cuplikan berikut menunjukkan ketiga metode Informasi dan satu sama lain.

public class Logger : ILogger
{
    public void Information(string message)
    {
        Trace.TraceInformation(message);
    }

    public void Information(string fmt, params object[] vars)
    {
        Trace.TraceInformation(fmt, vars);
    }

    public void Information(Exception exception, string fmt, params object[] vars)
    {
        var msg = String.Format(fmt, vars);
        Trace.TraceInformation(string.Format(fmt, vars) + ";Exception Details={0}", exception.ToString());
    }

    public void Warning(string message)
    {
        Trace.TraceWarning(message);
    }

    public void Error(string message)
    {
        Trace.TraceError(message);
    }

    public void TraceApi(string componentName, string method, TimeSpan timespan, string properties)
    {
        string message = String.Concat("component:", componentName, ";method:", method, ";timespan:", timespan.ToString(), ";properties:", properties);
        Trace.TraceInformation(message);
    }
}

Memanggil metode ILogger

Setiap kali kode di aplikasi Fix It menangkap pengecualian, ia memanggil metode ILogger untuk mencatat detail pengecualian. Dan setiap kali melakukan panggilan ke database, Blob service, atau REST API, ia memulai stopwatch sebelum panggilan, menghentikan stopwatch saat layanan kembali, dan mencatat waktu yang berlalu bersama dengan informasi tentang keberhasilan atau kegagalan.

Perhatikan bahwa pesan log menyertakan nama kelas dan nama metode. Ini adalah praktik yang baik untuk memastikan bahwa pesan log mengidentifikasi bagian apa dari kode aplikasi yang menulisnya.

public class FixItTaskRepository : IFixItTaskRepository
{
    private MyFixItContext db = new MyFixItContext();
    private ILogger log = null;

    public FixItTaskRepository(ILogger logger)
    {
        log = logger;
    }

    public async Task<FixItTask> FindTaskByIdAsync(int id)
    {
        FixItTask fixItTask = null;
        Stopwatch timespan = Stopwatch.StartNew();

        try
        {
            fixItTask = await db.FixItTasks.FindAsync(id);
            
            timespan.Stop();
            log.TraceApi("SQL Database", "FixItTaskRepository.FindTaskByIdAsync", timespan.Elapsed, "id={0}", id);
        }
        catch(Exception e)
        {
            log.Error(e, "Error in FixItTaskRepository.FindTaskByIdAsynx(id={0})", id);
        }

        return fixItTask;
    }

Jadi sekarang untuk setiap kali aplikasi Fix It telah melakukan panggilan ke SQL Database, Anda dapat melihat panggilan, metode yang memanggilnya, dan persis berapa banyak waktu yang diperlukan.

Jika Anda menelusuri log, Anda dapat melihat bahwa waktu yang diambil panggilan database adalah variabel. Informasi tersebut dapat berguna: karena aplikasi mencatat semua ini, Anda dapat menganalisis tren historis dalam performa layanan database dari waktu ke waktu. Misalnya, layanan mungkin cepat sebagian besar waktu tetapi permintaan mungkin gagal atau respons mungkin melambat pada waktu-waktu tertentu dalam sehari.

Anda dapat melakukan hal yang sama untuk layanan Blob - untuk setiap kali aplikasi mengunggah file baru, ada log, dan Anda dapat melihat dengan tepat berapa lama waktu yang diperlukan untuk mengunggah setiap file.

Hanya beberapa baris kode tambahan untuk menulis setiap kali Anda memanggil layanan, dan sekarang setiap kali seseorang mengatakan mereka mengalami masalah, Anda tahu persis apa masalahnya, apakah itu kesalahan, atau bahkan jika itu hanya berjalan lambat. Anda dapat menentukan sumber masalah tanpa harus jarak jauh ke server atau mengaktifkan pengelogan setelah kesalahan terjadi dan berharap untuk membuatnya kembali.

Injeksi Dependensi di aplikasi Fix It

Anda mungkin bertanya-tanya bagaimana konstruktor repositori dalam contoh yang ditunjukkan di atas mendapatkan implementasi antarmuka pencatat:

public class FixItTaskRepository : IFixItTaskRepository
{
    private MyFixItContext db = new MyFixItContext();
    private ILogger log = null;

    public FixItTaskRepository(ILogger logger)
    {
        log = logger;
    }

Untuk menghubungkan antarmuka ke implementasi, aplikasi menggunakan injeksi dependensi (DI) dengan AutoFac. DI memungkinkan Anda menggunakan objek berdasarkan antarmuka di banyak tempat di seluruh kode Anda dan hanya perlu menentukan di satu tempat implementasi yang digunakan saat antarmuka dibuat. Ini memudahkan untuk mengubah implementasi: misalnya, Anda mungkin ingin mengganti pencatat System.Diagnostics dengan pencatat NLog. Atau untuk pengujian otomatis, Anda mungkin ingin mengganti versi tiruan pencatat.

Aplikasi Fix It menggunakan DI di semua repositori dan semua pengontrol. Konstruktor kelas pengontrol mendapatkan antarmuka ITaskRepository dengan cara yang sama seperti repositori mendapatkan antarmuka pencatat:

public class DashboardController : Controller
{
    private IFixItTaskRepository fixItRepository = null;

    public DashboardController(IFixItTaskRepository repository)
    {
        fixItRepository = repository;
    }

Aplikasi ini menggunakan pustaka AUTOFac DI untuk secara otomatis menyediakan instans TaskRepository dan Logger untuk konstruktor ini.

public class DependenciesConfig
{
    public static void RegisterDependencies()
    {
        var builder = new ContainerBuilder();

        builder.RegisterControllers(typeof(MvcApplication).Assembly);
        builder.RegisterType<Logger>().As<ILogger>().SingleInstance();

        builder.RegisterType<FixItTaskRepository>().As<IFixItTaskRepository>();
        builder.RegisterType<PhotoService>().As<IPhotoService>().SingleInstance();
        builder.RegisterType<FixItQueueManager>().As<IFixItQueueManager>();

        var container = builder.Build();
        DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
    }
}

Kode ini pada dasarnya mengatakan bahwa di mana saja konstruktor membutuhkan antarmuka ILogger , meneruskan instans kelas Logger , dan setiap kali membutuhkan antarmuka IFixItTaskRepository , meneruskan instans kelas FixItTaskRepository .

AutoFac adalah salah satu dari banyak kerangka kerja injeksi dependensi yang dapat Anda gunakan. Yang populer lainnya adalah Unity, yang direkomendasikan dan didukung oleh Pola dan Praktik Microsoft.

Dukungan pengelogan bawaan di Azure

Azure mendukung jenis pengelogan berikut untuk Web Apps di Azure App Service:

• Pelacakan System.Diagnostics (Anda dapat mengaktifkan dan menonaktifkan dan mengatur tingkat dengan cepat tanpa memulai ulang situs).
• Peristiwa Windows.
• Log IIS (HTTP/FREB).

Azure mendukung jenis pengelogan berikut di Cloud Services:

• Pelacakan System.Diagnostics.
• Penghitung performa.
• Peristiwa Windows.
• Log IIS (HTTP/FREB).
• Pemantauan direktori kustom.

Aplikasi Fix It menggunakan pelacakan System.Diagnostics. Yang perlu Anda lakukan untuk mengaktifkan pengelogan System.Diagnostics di aplikasi web adalah membalik sakelar di portal atau memanggil REST API. Di portal, klik tab Konfigurasi untuk situs Anda, dan gulir ke bawah untuk melihat bagian Diagnostik Aplikasi . Anda dapat mengaktifkan atau menonaktifkan pengelogan dan memilih tingkat pengelogan yang Anda inginkan. Anda dapat meminta Azure menulis log ke sistem file atau ke akun penyimpanan.

Setelah mengaktifkan pengelogan di Azure, Anda dapat melihat log di jendela Output Visual Studio saat dibuat.

Anda juga dapat menulis log ke akun penyimpanan Anda dan melihatnya dengan alat apa pun yang dapat mengakses layanan Azure Storage Table, seperti Server Explorer di Visual Studio atau Azure Storage Explorer.

Ringkasan

Sangat mudah untuk menerapkan sistem telemetri out-of-the-box, pengelogan instrumen dalam kode Anda sendiri, dan mengonfigurasi pengelogan di Azure. Dan ketika Anda memiliki masalah produksi, kombinasi sistem telemetri dan log kustom akan membantu Anda menyelesaikan masalah dengan cepat sebelum menjadi masalah besar bagi pelanggan Anda.

Di bab berikutnya kita akan melihat cara menangani kesalahan sementara sehingga tidak menjadi masalah produksi yang harus Anda selidiki.

Sumber

Untuk informasi selengkapnya, lihat sumber berikut ini:

Dokumentasi terutama tentang telemetri:

• Pola dan Praktik Microsoft - Panduan Azure. Lihat Panduan instrumentasi dan Telemetri, panduan Pengukuran Layanan, pola Pemantauan Titik Akhir Kesehatan, dan pola Konfigurasi Ulang Runtime.
• Penny Pinching di Cloud: Mengaktifkan Pemantauan Performa Relik Baru di Situs Web Azure.
• Praktik Terbaik untuk Desain Layanan Large-Scale di Azure Cloud Services. Laporan resmi oleh Mark Simms dan Michael Thomassy. Lihat bagian Telemetri dan Diagnostik.
• Pengembangan Generasi Berikutnya dengan Application Insights. Artikel Majalah MSDN.

Dokumentasi terutama tentang pengelogan:

• Blok Aplikasi Pengelogan Semantik (SLAB). Neil Mackenzie menyajikan kasus untuk pengelogan semantik dengan SLAB.
• Membuat Log Terstruktur dan Bermakna dengan Pengelogan Semantik. (Video) Julian Dominguez menyajikan kasus untuk pengelogan semantik dengan SLAB.
• Pengelogan SQL EF6 – Bagian 1: Pengelogan Sederhana. Arthur Vickers menunjukkan cara mencatat kueri yang dijalankan oleh Entity Framework di EF 6.
• Ketahanan Koneksi dan Intersepsi Perintah dengan Kerangka Kerja Entitas dalam Aplikasi MVC ASP.NET. Keempat dalam seri tutorial sembilan bagian, menunjukkan cara menggunakan fitur intersepsi perintah EF 6 untuk mencatat perintah SQL yang dikirim ke database oleh Entity Framework.
• Tingkatkan Pengelogan menggunakan Atribut Info Penelepon C# 5.0. Cara mudah mencatat nama metode panggilan tanpa mengodekannya secara permanen menjadi harfiah atau menggunakan pantulan untuk mendapatkannya secara manual.

Dokumentasi terutama tentang pemecahan masalah:

• Blog Azure Troubleshooting & Debugging.
• AzureTools – Utilitas Diagnostik yang digunakan oleh Tim Dukungan Pengembang Azure. Memperkenalkan dan menyediakan tautan unduhan untuk alat yang dapat digunakan pada Azure VM untuk mengunduh dan menjalankan berbagai alat diagnostik dan pemantauan. Berguna saat Anda perlu mendiagnosis masalah pada VM tertentu.
• Memecahkan masalah aplikasi web di Azure App Service menggunakan Visual Studio. Tutorial langkah demi langkah untuk memulai pelacakan System.Diagnostics dan penelusuran kesalahan jarak jauh.

Video:

• FailSafe: Membangun Cloud Services yang Dapat Diskalakan dan Tangguh. Seri sembilan bagian oleh Ulrich Homann, Marc Mercuri, dan Mark Simms. Menyajikan konsep tingkat tinggi dan prinsip arsitektur dengan cara yang sangat mudah diakses dan menarik, dengan cerita yang diambil dari pengalaman Microsoft Customer Advisory Team (CAT) dengan pelanggan aktual. Episode 4 dan 9 adalah tentang pemantauan dan telemetri. Episode 9 mencakup gambaran umum layanan pemantauan MetricsHub, AppDynamics, New Relic, dan PagerDuty.
• Membangun Besar: Pelajaran yang dipelajari dari pelanggan Azure - Bagian II. Mark Simms berbicara tentang merancang kegagalan dan melengkapi semuanya. Mirip dengan seri Failsafe tetapi masuk ke detail cara penggunaan yang lebih banyak.

Sampel kode:

• Dasar-Dasar Layanan Cloud di Azure. Aplikasi sampel yang dibuat oleh Tim Penasihat Pelanggan Microsoft Azure. Menunjukkan praktik telemetri dan pengelogan, seperti yang dijelaskan dalam artikel berikut. Sampel mengimplementasikan pengelogan aplikasi dengan menggunakan NLog. Untuk dokumentasi terkait, lihat rangkaian empat artikel wiki TechNet tentang telemetri dan pengelogan.

SebelumnyaBerikutnya