Memantau kluster

  • Artikel

Penting untuk memantau di tingkat kluster untuk menentukan apakah perangkat keras dan kluster Anda berperilaku seperti yang diharapkan atau tidak. Meskipun Service Fabric dapat menjaga aplikasi tetap berjalan selama kegagalan perangkat keras, tetapi Anda masih perlu mendiagnosis apakah kesalahan terjadi dalam aplikasi atau dalam infrastruktur yang mendasarinya. Anda juga harus memantau kluster Anda untuk merencanakan kapasitas dengan lebih baik, membantu dalam keputusan tentang menambahkan atau menghapus perangkat keras.

Service Fabric memaparkan beberapa peristiwa platform terstruktur, sebagai Peristiwa Service Fabric, melalui EventStore dan berbagai saluran log out-of-the-box.

Di Windows, peristiwa Service Fabric tersedia dari satu penyedia ETW dengan sekumpulan yang relevan logLevelKeywordFilters yang digunakan untuk memilih antara saluran Pesan Operasional dan Data - ini adalah cara kami memisahkan peristiwa Service Fabric keluar untuk difilter sesuai kebutuhan.

  • Operasional Operasi tingkat tinggi yang dilakukan oleh Service Fabric dan kluster, termasuk peristiwa untuk node yang akan datang, aplikasi baru yang sedang digunakan, atau rollback upgrade, dll. Lihat daftar lengkap peristiwa di sini.

  • Operasional - terperinci
    Laporan kesehatan dan keputusan penyeimbangan beban.

Saluran operasi dapat diakses melalui berbagai cara termasuk ETW/Log Peristiwa Windows, EventStore (tersedia di Windows dalam versi 6.2 dan yang lebih baru untuk kluster Windows). EventStore memberi Anda akses ke peristiwa kluster Anda berdasarkan per entitas (entitas termasuk kluster, node, aplikasi, layanan, partisi, replika, dan kontainer) dan mengeksposnya melalui REST API dan pustaka klien Service Fabric. Gunakan EventStore untuk memantau kluster dev/test Anda, dan untuk mendapatkan pemahaman titik-waktu-tertentu tentang keadaan kluster produksi Anda.

  • Data & Olahpesan
    Log dan peristiwa penting yang dihasilkan dalam olahpesan (saat ini hanya ReverseProxy) dan jalur data (model layanan yang andal).

  • Data & Olahpesan - terperinci
    Saluran Verbose yang berisi semua log non-kritis dari data dan olahpesan dalam kluster (saluran ini memiliki volume peristiwa yang sangat tinggi).

Selain itu, ada dua saluran EventSource terstruktur yang disediakan, serta log yang kami kumpulkan untuk tujuan dukungan.

  • Peristiwa Reliable Service
    Memprogram model peristiwa tertentu.

  • Peristiwa Reliable Actor
    Memprogram model peristiwa tertentu dan penghitung kinerja.

  • Log dukungan
    Log sistem yang dihasilkan oleh Service Fabric hanya untuk digunakan oleh kami saat memberikan dukungan.

Berbagai saluran ini mencakup sebagian besar pembuatan log tingkat platform yang disarankan. Untuk meningkatkan pembuatan log tingkat platform, pertimbangkan untuk berinvestasi dalam memahami model kesehatan dengan lebih baik dan menambahkan laporan kesehatan khusus, dan menambahkan Penghitung Kinerja khusus untuk membangun pemahaman real-time tentang dampak layanan dan aplikasi Anda pada kluster.

Untuk memanfaatkan log ini, sangat disarankan untuk membiarkan "Diagnostik" diaktifkan selama pembuatan kluster di Portal Azure. Dengan mengaktifkan diagnostik, ketika kluster diterapkan, Diagnostik Windows Azure dapat mengakui saluran Operasional, Reliable Service, dan Reliable actor, serta menyimpan data sebagaimana dijelaskan lebih lanjut dalam peristiwa Agregat dengan Diagnostik Azure.

Pelaporan kesehatan dan beban Azure Service Fabric

Service Fabric memiliki model kesehatan sendiri, yang dijelaskan secara rinci dalam artikel ini:

Pemantauan kesehatan sangat penting untuk beberapa aspek pengoperasian layanan, terutama selama peningkatan aplikasi. Setelah setiap domain peningkatan layanan ditingkatkan, domain peningkatan harus melewati pemeriksaan kesehatan sebelum penyebaran pindah ke domain peningkatan berikutnya. Jika status kesehatan OK tidak dapat dicapai, penyebaran dibatalkan, sehingga aplikasi tetap dalam keadaan OK yang diketahui. Meskipun beberapa pelanggan mungkin terpengaruh sebelum layanan dibatalkan, sebagian besar pelanggan tidak akan mengalami masalah. Selain itu, resolusi terjadi relatif cepat tanpa harus menunggu tindakan dari operator manusia. Semakin banyak pemeriksaan kesehatan yang dimasukkan ke dalam kode Anda, semakin tangguh layanan Anda untuk masalah penyebaran.

Aspek lain dari kesehatan layanan adalah melaporkan metrik dari layanan. Metrik penting dalam Service Fabric karena digunakan untuk menyeimbangkan penggunaan sumber daya. Metrik juga dapat menjadi indikator kesehatan sistem. Misalnya, Anda mungkin memiliki aplikasi yang memiliki banyak layanan, dan setiap instans melaporkan permintaan per detik (RPS) metrik. Jika satu layanan menggunakan lebih banyak sumber daya dari layanan lain, Service Fabric memindahkan instans layanan di sekitar kluster, untuk mencoba mempertahankan pemanfaatan sumber daya yang merata. Untuk penjelasan lebih rinci tentang cara kerja pemanfaatan sumber daya, lihat Mengelola konsumsi sumber daya dan beban di Service Fabric dengan metrik.

Metrik juga dapat membantu memberi Anda wawasan tentang kinerja layanan Anda. Seiring waktu, Anda dapat menggunakan metrik untuk memeriksa apakah layanan beroperasi dalam parameter yang diharapkan. Misalnya, jika tren menunjukkan bahwa pada pukul 9 pagi pada hari Senin pagi rata-rata RPS adalah 1.000, maka Anda dapat mengatur laporan kesehatan yang memperingatkan Anda jika RPS di bawah 500 atau di atas 1.500. Semuanya mungkin baik-baik saja, tetapi mungkin layak untuk dilihat untuk memastikan pelanggan Anda memiliki pengalaman hebat. Layanan Anda dapat menentukan sekumpulan metrik yang dapat dilaporkan untuk tujuan pemeriksaan kesehatan, tetapi itu tidak memengaruhi penyeimbangan sumber daya kluster. Untuk melakukan ini, atur bobot metrik ke nol. Sebaiknya Anda memulai semua metrik dengan bobot nol, dan tidak menambah bobot hingga yakin bahwa Anda memahami cara pembobotan metrik memengaruhi penyeimbangan sumber daya untuk kluster Anda.

Tip

Jangan gunakan terlalu banyak metrik berbobot. Mungkin sulit untuk memahami mengapa instans layanan dipindahkan untuk penyeimbangan. Beberapa metrik bisa berjalan jauh!

Informasi apa pun yang dapat menunjukkan kesehatan dan kinerja aplikasi Anda adalah kandidat untuk metrik dan laporan kesehatan. Penghitung kinerja CPU dapat memberi tahu Anda bagaimana node Anda digunakan, tetapi tidak memberi tahu Anda apakah layanan tertentu sehat, karena beberapa layanan mungkin berjalan pada satu node. Tapi, metrik seperti RPS, item yang diproses, dan latensi permintaan, semua dapat menunjukkan kesehatan layanan tertentu.

Log dukungan Service Fabric

Jika Anda perlu menghubungi dukungan Microsoft untuk mendapatkan bantuan dengan kluster Azure Service Fabric Anda, log dukungan hampir selalu diperlukan. Jika kluster Anda dihost di Azure, log dukungan akan dikonfigurasi dan dikumpulkan secara otomatis sebagai bagian dari pembuatan kluster. Log disimpan dalam akun penyimpanan khusus di grup sumber daya kluster Anda. Akun penyimpanan tidak memiliki nama tetap, tetapi di akun, Anda melihat kontainer dan tabel blob dengan nama yang dimulai dengan fabric. Untuk informasi tentang menyiapkan kumpulan log untuk kluster mandiri, lihat Membuat dan mengelola kluster Azure Service Fabric mandiri dan Pengaturan konfigurasi untuk kluster Windows mandiri. Untuk instans Service Fabric mandiri, log harus dikirim ke pembagian file lokal. Anda diharuskan memiliki log ini untuk dukungan, tetapi tidak dimaksudkan untuk digunakan oleh siapa pun di luar tim dukungan pelanggan Microsoft.

Mengukur kinerja

Mengukur kinerja kluster Anda akan membantu Anda memahami bagaimana ia mampu menangani keputusan beban dan drive seputar penskalaan kluster Anda (lihat selengkapnya tentang penskalaan kluster di Azure,atau lokal). Data kinerja juga berguna jika dibandingkan dengan tindakan yang mungkin telah dilakukan Anda atau aplikasi dan layanan Anda, saat menganalisis log di masa mendatang.

Untuk daftar penghitung kinerja yang dikumpulkan saat menggunakan Service Fabric, lihat Penghitung Kinerja di Service Fabric

Berikut adalah dua cara umum yang dapat Anda lakukan untuk mengatur pengumpulan data kinerja untuk kluster Anda:

  • Menggunakan agen
    Ini adalah cara yang lebih disukai untuk mengumpulkan kinerja dari mesin, karena agen biasanya memiliki daftar kemungkinan metrik kinerja yang dapat dikumpulkan, dan ini adalah proses yang relatif mudah untuk memilih metrik yang ingin dikumpulkan atau diubah. Baca tentang Azure Monitor yang menawarkan log Azure Monitor dalam Integrasi log Azure Monitor Service Fabric dan Mengatur agen Analitik Log untuk mempelajari selengkapnya tentang agen Analitik Log, yang merupakan salah satu agen pemantauan tersebut yang dapat mengambil data kinerja untuk VM kluster dan kontainer yang disebarkan.

  • Penghitung kinerja ke Penyimpanan Tabel Azure
    Anda juga dapat mengirim metrik kinerja ke penyimpanan tabel yang sama dengan peristiwa. Ini mengharuskan mengubah konfigurasi Diagnostik Azure untuk mengambil penghitung kinerja yang sesuai dari VM di kluster Anda, dan memungkinkannya untuk mengambil statistik docker jika Anda akan menyebarkan kontainer apa pun. Baca tentang mengonfigurasi Penghitung Kinerja di WAD di Service Fabric untuk mengatur pengumpulan penghitung kinerja.

Langkah berikutnya