Özel Service Fabric sistem durumu raporları ekleme

  • Makale

Azure Service Fabric, belirli varlıklardaki iyi durumda olmayan kümeye ve uygulama koşullarına bayrak eklemek için tasarlanmış bir sistem durumu modeli sunar. Sistem durumu modeli, sistem durumu muhabirlerini (sistem bileşenleri ve watchdogs) kullanır. Amaç kolay ve hızlı tanı ve onarımdır. Hizmet yazarlarının sistem durumu hakkında önceden düşünmesi gerekir. Sistem durumunu etkileyebilecek her koşul, özellikle de köke yakın sorunları işaretlemeye yardımcı olabilirse bildirilmelidir. Sistem durumu bilgileri hata ayıklama ve araştırma için zaman ve çabadan tasarruf edebilir. Hizmet bulutta (özel veya Azure) büyük ölçekte çalışır duruma gelince kullanışlılık özellikle açıktır.

Service Fabric muhabirleri, belirlenen ilgi koşullarını izler. Bu koşulları yerel görünümlerine göre rapor eder. Sistem durumu deposu , varlıkların genel olarak iyi durumda olup olmadığını belirlemek için tüm muhabirler tarafından gönderilen sistem durumu verilerini toplar. Modelin zengin, esnek ve kullanımı kolay olması amaçlanmıştır. Sistem durumu raporlarının kalitesi, kümenin sistem durumu görünümünün doğruluğunu belirler. Yanlış şekilde iyi durumda olmayan sorunlar gösteren hatalı pozitif sonuçlar, yükseltmeleri veya sistem durumu verilerini kullanan diğer hizmetleri olumsuz etkileyebilir. Bu tür hizmetlere örnek olarak onarım hizmetleri ve uyarı mekanizmaları verilebilir. Bu nedenle, ilgi koşullarını mümkün olan en iyi şekilde yakalayan raporlar sağlamak için bazı düşünceler gereklidir.

Sistem durumu raporlaması tasarlamak ve uygulamak için izleme yöneticilerinin ve sistem bileşenlerinin şunları yapması gerekir:

  • İlgilendikleri koşulu, nasıl izlendiğini ve küme veya uygulama işlevselliği üzerindeki etkisini tanımlayın. Bu bilgilere dayanarak sistem durumu raporu özelliğine ve sistem durumu'na karar verin.
  • Raporun uygulandığı varlığı belirleyin.
  • Raporlamanın nerede yapıldığını, hizmetin içinden veya bir iç ya da dış izlemeden saptayın.
  • Muhabiri tanımlamak için kullanılan bir kaynak tanımlayın.
  • Düzenli aralıklarla veya geçişlerde bir raporlama stratejisi seçin. Önerilen yol, daha basit kod gerektirdiğinden ve hatalara daha az eğilimli olduğundan düzenli aralıklarla yapılır.
  • İyi durumda olmayan koşullar için raporun ne kadar süreyle sağlık deposunda kalması gerektiğini ve nasıl temizleneceğini belirleyin. Bu bilgileri kullanarak raporun yaşam süresine ve sona erme tarihinde kaldırma davranışına karar verin.

Belirtildiği gibi, raporlama şu kaynaklardan yapılabilir:

  • İzlenen Service Fabric hizmet çoğaltması.
  • Service Fabric hizmeti olarak dağıtılan iç watchdogs (örneğin, koşulları izleyen ve raporları veren durum bilgisi olmayan bir Service Fabric hizmeti). watchdog'lar tüm düğümlere dağıtılabilir veya izlenen hizmete bağlanabilir.
  • Service Fabric düğümlerinde çalışan ancak Service Fabric hizmetleri olarak uygulanmayan iç izlemeler.
  • Service Fabric kümesinin dışından kaynağı yoklayan dış izlemeler (örneğin, Gomez gibi izleme hizmeti).

Not

Küme, sistem bileşenleri tarafından gönderilen sistem durumu raporlarıyla doldurulur. Sorun giderme için sistem durumu raporlarını kullanma makalesini okuyun. Kullanıcı raporları, sistem tarafından önceden oluşturulmuş olan sistem durumu varlıklarına gönderilmelidir.

Sistem durumu raporlama tasarımı temizlendikten sonra, sistem durumu raporları kolayca gönderilebilir. Küme güvenli değilse veya doku istemcisinin yönetici ayrıcalıkları varsa sistem durumunu bildirmek için FabricClient'ı kullanabilirsiniz. Raporlama , FabricClient.HealthManager.ReportHealth kullanılarak, PowerShell aracılığıyla veya REST aracılığıyla API aracılığıyla yapılabilir. İyileştirilmiş performans için yapılandırma düğmeleri toplu iş raporları.

Not

Rapor durumu zaman uyumludur ve yalnızca istemci tarafındaki doğrulama çalışmasını temsil eder. Raporun sistem durumu istemcisi veya Partition veya CodePackageActivationContext nesneleri tarafından kabul edilmiş olması, raporun depoya uygulandığı anlamına gelmez. Zaman uyumsuz olarak gönderilir ve büyük olasılıkla diğer raporlarla toplu olarak oluşturulur. Sunucudaki işlem yine başarısız olabilir: sıra numarası eski olabilir, raporun uygulanması gereken varlık silinmiş vb.

Sistem durumu istemcisi

Sistem durumu raporları, doku istemcisinin içinde bulunan bir sistem durumu istemcisi aracılığıyla sistem durumu yöneticisine gönderilir. Sistem durumu yöneticisi raporları sistem durumu deposuna kaydeder. Sistem durumu istemcisi aşağıdaki ayarlarla yapılandırılabilir:

  • HealthReportSendInterval: Raporun istemciye eklenmesiyle sistem durumu yöneticisine gönderilmesi arasındaki gecikme. Raporları her rapor için bir ileti göndermek yerine tek bir ileti halinde toplu olarak oluşturmak için kullanılır. Toplu işlem performansı artırır. Varsayılan: 30 saniye.
  • HealthReportRetrySendInterval: Sistem durumu istemcisinin birikmiş sistem durumu raporlarını sistem durumu yöneticisine yeniden gönderme aralığı. Varsayılan: 30 saniye, en az: 1 saniye.
  • HealthOperationTimeout: Sistem durumu yöneticisine gönderilen bir rapor iletisinin zaman aşımı süresi. bir ileti zaman aşımına uğradıysa, sistem durumu yöneticisi raporun işlendiğini onaylayana kadar sistem durumu istemcisi bu iletiyi yeniden denenir. Varsayılan: iki dakika.

Not

Raporlar toplu işlendiğinde, doku istemcisinin gönderildiğinden emin olmak için en azından HealthReportSendInterval için canlı tutulması gerekir. İleti kaybolursa veya geçici hatalar nedeniyle sistem durumu yöneticisi bunları uygulayamazsa, doku istemcisinin yeniden deneme şansı vermesi için daha uzun süre canlı tutulması gerekir.

İstemcide arabelleğe alma, raporların benzersizliğini dikkate alır. Örneğin, belirli bir hatalı muhabir aynı varlığın aynı özelliği üzerinde saniyede 100 rapor bildiriyorsa, raporlar son sürümle değiştirilir. Bu tür raporlardan en fazla biri istemci kuyruğunda bulunur. Toplu işlem yapılandırıldıysa, sistem durumu yöneticisine gönderilen rapor sayısı her gönderme aralığı için yalnızca bir tanedir. Bu rapor, varlığın en güncel durumunu yansıtan son eklenen rapordur. Sistem durumuyla ilgili girişler FabricClient için istenen değerlerle FabricClientSettings geçirilerek oluşturulduğunda yapılandırma parametrelerini belirtin.

Aşağıdaki örnek bir doku istemcisi oluşturur ve eklendiklerinde raporların gönderilmesi gerektiğini belirtir. Yeniden denenebilecek zaman aşımları ve hatalarda, yeniden denemeler her 40 saniyede bir gerçekleşir.

var clientSettings = new FabricClientSettings()
{
    HealthOperationTimeout = TimeSpan.FromSeconds(120),
    HealthReportSendInterval = TimeSpan.FromSeconds(0),
    HealthReportRetrySendInterval = TimeSpan.FromSeconds(40),
};
var fabricClient = new FabricClient(clientSettings);

Varsayılan doku istemci ayarlarının 30 saniye olarak ayarlanmasını HealthReportSendInterval öneririz. Bu ayar, toplu işleme nedeniyle en iyi performansı sağlar. En kısa sürede gönderilmesi gereken kritik raporlar için, FabricClient.HealthClient.ReportHealth API'sinde Anında true ile kullanınHealthReportSendOptions. Anında raporlar toplu işlem aralığını atlar. Bu bayrağı dikkatli kullanın; mümkün olduğunca sistem durumu istemcisi toplu işlemlerinden yararlanmak istiyoruz. Doku istemcisi kapatılırken de anında gönderme yararlı olur (örneğin, işlem geçersiz durum belirlemiştir ve yan etkileri önlemek için kapatılması gerekir). Birikmiş raporların en iyi şekilde gönderilmesini sağlar. Anlık bayrağıyla bir rapor eklendiğinde, sistem durumu istemcisi son göndermeden bu yana birikmiş tüm raporları toplu işliyor.

PowerShell aracılığıyla bir küme bağlantısı oluşturulduğunda aynı parametreler belirtilebilir. Aşağıdaki örnek yerel bir kümeye bağlantı başlatır:

PS C:\> Connect-ServiceFabricCluster -HealthOperationTimeoutInSec 120 -HealthReportSendIntervalInSec 0 -HealthReportRetrySendIntervalInSec 40
True

ConnectionEndpoint   :
FabricClientSettings : {
                       ClientFriendlyName                   : PowerShell-1944858a-4c6d-465f-89c7-9021c12ac0bb
                       PartitionLocationCacheLimit          : 100000
                       PartitionLocationCacheBucketCount    : 1024
                       ServiceChangePollInterval            : 00:02:00
                       ConnectionInitializationTimeout      : 00:00:02
                       KeepAliveInterval                    : 00:00:20
                       HealthOperationTimeout               : 00:02:00
                       HealthReportSendInterval             : 00:00:00
                       HealthReportRetrySendInterval        : 00:00:40
                       NotificationGatewayConnectionTimeout : 00:00:00
                       NotificationCacheUpdateTimeout       : 00:00:00
                       }
GatewayInformation   : {
                       NodeAddress                          : localhost:19000
                       NodeId                               : 1880ec88a3187766a6da323399721f53
                       NodeInstanceId                       : 130729063464981219
                       NodeName                             : Node.1
                       }

API'ye benzer şekilde raporlar, değerden HealthReportSendInterval bağımsız olarak hemen gönderilecek anahtar kullanılarak -Immediate gönderilebilir.

REST için raporlar, iç doku istemcisi olan Service Fabric ağ geçidine gönderilir. Varsayılan olarak, bu istemci her 30 saniyede bir toplu raporlar gönderecek şekilde yapılandırılır. üzerinde küme yapılandırma ayarıyla HttpGatewayHealthReportSendIntervalHttpGatewaytoplu iş aralığını değiştirebilirsiniz. Belirtildiği gibi, raporları true ile Immediate göndermek daha iyi bir seçenektir.

Not

Yetkisiz hizmetlerin kümedeki varlıklara karşı sistem durumunu bildirediğinden emin olmak için sunucuyu yalnızca güvenli istemcilerden gelen istekleri kabul etmek üzere yapılandırın. Raporlama için kullanılan kümeyle FabricClient iletişim kurabilmek için güvenliğin etkinleştirilmiş olması gerekir (örneğin, Kerberos veya sertifika kimlik doğrulaması ile). Küme güvenliği hakkında daha fazla bilgi edinin.

Düşük ayrıcalıklı hizmetlerden rapor

Service Fabric hizmetlerinin kümeye yönetici erişimi yoksa, veya CodePackageActivationContextaracılığıyla Partition geçerli bağlamdan varlıklarda sistem durumunu bildirebilirsiniz.

Not

ve varsayılan Partition ayarlarla yapılandırılmış bir sistem durumu istemcisini CodePackageActivationContext dahili olarak tutar. Sistem durumu istemcisi için açıklandığı gibi raporlar toplu olarak oluşturulur ve bir zamanlayıcıda gönderilir. Raporu gönderme şansına sahip olmak için nesnelerin canlı tutulması gerekir.

Ve CodePackageActivationContext sistem durumu API'leri aracılığıyla Partition rapor gönderirken belirtebilirsinizHealthReportSendOptions. En kısa sürede gönderilmesi gereken kritik raporlarınız varsa, Anında trueile kullanınHealthReportSendOptions. Anlık raporlar, iç sistem durumu istemcisinin toplu işlem aralığını atlar. Daha önce belirtildiği gibi, bu bayrağı dikkatli kullanın; mümkün olduğunda sistem durumu istemcisini toplu işlemden yararlanmak istiyoruz.

Sistem durumu raporlamayı tasarlama

Yüksek kaliteli raporlar oluşturmanın ilk adımı, hizmetin durumunu etkileyebilecek koşulları belirlemektir. Bir sorun ortaya çıkmadan önce hizmet veya kümedeki sorunları bayrakla işaretlemeye yardımcı olabilecek her koşul milyarlarca dolar tasarruf edebilir. Bunun avantajları arasında daha az çalışma süresi, sorunları araştırmak ve onarmak için harcanan gece saatlerinin daha az olması ve müşteri memnuniyetinin daha yüksek olması sayılabilir.

Koşullar belirlendikten sonra, izleme yazıcılarının ek yük ve kullanışlılık arasında denge sağlamak için bunları izlemenin en iyi yolunu bulamaları gerekir. Örneğin, bir paylaşımda bazı geçici dosyalar kullanan karmaşık hesaplamalar yapan bir hizmeti düşünün. İzleyici, yeterli alanın kullanılabilir olduğundan emin olmak için paylaşımı izleyebilir. Dosya veya dizin değişikliklerinin bildirimlerini dinleyebilecektir. Ön eşiğine ulaşılırsa bir uyarı bildirebilir ve paylaşım doluysa bir hata bildirebilir. Bir uyarı üzerine, onarım sistemi paylaşımdaki eski dosyaları temizlemeye başlayabilir. Bir hatada, onarım sistemi hizmet çoğaltmasını başka bir düğüme taşıyabilir. Koşul durumlarının sistem durumu açısından nasıl açıklandığını unutmayın: iyi durumda (tamam) veya iyi durumda olmayan (uyarı veya hata) olarak kabul edilebilecek koşulun durumu.

İzleme ayrıntıları ayarlandıktan sonra, bir izleme yazarının izlemenin nasıl uygulanıp uygulanayacağını öğrenmesi gerekir. Koşullar hizmetin içinden belirlenebiliyorsa, izleme izleyicisi izlenen hizmetin bir parçası olabilir. Örneğin, hizmet kodu paylaşım kullanımını denetleyebiliyor ve her dosya yazmaya çalıştığında raporlayabilir. Bu yaklaşımın avantajı, raporlamanın basit olmasıdır. İzleme hatalarının hizmet işlevselliğini etkilemesini önlemek için dikkatli olunmalıdır.

İzlenen hizmetin içinden raporlama her zaman bir seçenek değildir. Hizmet içindeki bir izleme, koşulları algılayamayabilir. Bu, belirlemeyi yapacak mantığa veya verilere sahip olmayabilir. Koşulları izleme yükü yüksek olabilir. Koşullar bir hizmete özgü olmayabilir, bunun yerine hizmetler arasındaki etkileşimleri etkiler. Bir diğer seçenek de kümede watchdog'ların ayrı işlemler olarak olmasıdır. watchdogs, ana hizmetleri hiçbir şekilde etkilemeden koşulları ve raporu izler. Örneğin, bu watchdog'lar aynı uygulamada durum bilgisi olmayan hizmetler olarak uygulanabilir, tüm düğümlere veya hizmetle aynı düğümlere dağıtılabilir.

Bazen kümede çalışan bir izleme de bir seçenek değildir. İzlenen koşul, kullanıcıların gördüğü hizmetin kullanılabilirliği veya işlevselliğiyse, izlemelerin kullanıcı istemcileri ile aynı yerde olması en iyisidir. Burada, işlemleri kullanıcıların çağırdıkları şekilde test edebilir. Örneğin, kümenin dışında bulunan, hizmete yönelik istekler veren ve sonucun gecikmesini ve doğruluğunu denetlemiş bir izleme köpeğiniz olabilir. (Örneğin hesap makinesi hizmeti için 2+2 makul bir süre içinde 4 döndürür mü?)

İzleme ayrıntıları tamamlandıktan sonra, bunu benzersiz olarak tanımlayan bir kaynak kimliğine karar vermeniz gerekir. Kümede aynı türde birden çok watchdog yaşıyorsa, farklı varlıklar üzerinde rapor vermeleri veya aynı varlıkta rapor vermeleri durumunda farklı kaynak kimliği veya özellik kullanmaları gerekir. Bu şekilde raporları bir arada bulunabilir. Sistem durumu raporunun özelliği izlenen koşulu yakalamalıdır. (Yukarıdaki örnekte özelliği ShareSize olabilir.) Aynı koşula birden çok rapor uygulanırsa, özelliği raporların bir arada bulunmasına izin veren bazı dinamik bilgiler içermelidir. Örneğin, birden çok paylaşımın izlenmesi gerekiyorsa özellik adı ShareSize-sharename olabilir.

Not

Durum bilgilerini korumak için sistem durumu depolarını kullanmayın. Bu bilgiler bir varlığın sistem durumu değerlendirmesini etkileyene kadar yalnızca sistem durumuyla ilgili bilgiler sistem durumu olarak bildirilmelidir. Sağlık deposu genel amaçlı bir mağaza olarak tasarlanmamıştır. Tüm verileri sistem durumu olarak toplamak için sistem durumu değerlendirme mantığını kullanır. Sistem durumuyla ilgili olmayan bilgilerin gönderilmesi (durumu Tamam olan raporlama gibi) toplanmış sistem durumunu etkilemez, ancak sistem durumu deposunun performansını olumsuz etkileyebilir.

Bir sonraki karar noktası, hangi varlığın raporleneceğidir. Çoğu zaman koşul varlığı açıkça tanımlar. Mümkün olan en iyi ayrıntı düzeyine sahip varlığı seçin. Bir koşul bir bölümdeki tüm çoğaltmaları etkiliyorsa, hizmette değil, bölümde rapor edin. Ancak daha fazla düşüncenin gerekli olduğu köşe durumları vardır. Koşul, çoğaltma gibi bir varlığı etkiliyorsa ancak koşulun çoğaltma ömründen daha uzun süre bayrakla işaretlenmesi arzulanıyorsa, bölüme bildirilmelidir. Aksi takdirde, çoğaltma silindiğinde sistem durumu deposu tüm raporlarını temizler. İzleme yazarlarının varlığın ve raporun yaşam süreleri hakkında düşünmesi gerekir. Raporun bir mağazadan ne zaman temizlenmesi gerektiği (örneğin, bir varlıkta bildirilen bir hatanın artık geçerli olmadığı durumlarda) net olması gerekir.

Anlattığım noktaları bir araya getiren bir örneğe bakalım. Ana durum bilgisi olan kalıcı hizmet ve tüm düğümlere dağıtılan ikincil durum bilgisi olmayan hizmetlerden (her görev türü için bir ikincil hizmet türü) oluşan bir Service Fabric uygulaması düşünün. Ana, ikinciller tarafından yürütülecek komutları içeren bir işleme kuyruğuna sahiptir. İkinciller gelen istekleri yürütür ve geri onay sinyalleri gönderir. İzlenebilen bir koşul, ana işlem kuyruğunun uzunluğudur. Ana kuyruk uzunluğu eşiğe ulaşırsa bir uyarı bildirilir. Uyarı, ikincillerin yükü işleyemiyor olduğunu gösterir. Kuyruk uzunluk üst sınırına ulaşırsa ve komutlar bırakılırsa, hizmet kurtarılamadığını için bir hata bildirilir. Raporlar QueueStatus özelliğinde olabilir. İzleme hizmeti içinde bulunur ve ana birincil çoğaltmaya düzenli aralıklarla gönderilir. Yaşam süresi iki dakikadır ve her 30 saniyede bir düzenli olarak gönderilir. Birincil rapor kapanırsa rapor mağazadan otomatik olarak temizlenir. Hizmet çoğaltması çalışır durumdaysa ancak kilitlenmediyse veya başka sorunlarla karşılaşıyorsa raporun süresi sistem durumu deposunda dolar. Bu durumda varlık hata durumunda değerlendirilir.

İzlenebilen bir diğer koşul da görev yürütme süresidir. Ana, görevleri görev türüne göre ikincillere dağıtır. Tasarıma bağlı olarak, ana görev durumu için ikincilleri yoklayabilir. Ayrıca, iş bittiğinde ikincillerin geri onay sinyalleri göndermesini de bekleyebilir. İkinci durumda, ikincillerin öldüğü veya iletilerin kaybolduğu durumları algılamaya dikkat edilmelidir. Bir seçenek, ana şablonun durumunu geri gönderen aynı ikincil öğeye ping isteği göndermesidir. Durum alınmazsa, ana öğe bunu bir hata olarak kabul eder ve görevi yeniden zamanlar. Bu davranış, görevlerin bir kez etkili olduğunu varsayar.

İzlenen koşul, görev belirli bir süre içinde (örneğin 10 dakika) yapılmazsa uyarı olarak çevrilebilir. Görev zamanında tamamlanmazsa (t2, örneğin 20 dakika), izlenen koşul Hata olarak çevrilebilir. Bu raporlama birden çok şekilde yapılabilir:

  • Ana birincil çoğaltma belirli aralıklarla kendi üzerinde raporlar. Kuyruktaki tüm bekleyen görevler için bir özelliğiniz olabilir. En az bir görev daha uzun sürerse PendingTasks özelliğindeki rapor durumu uyarı veya hatadır. Bekleyen görev yoksa veya tüm görevler yürütülmeye başladıysa, rapor durumu Tamam'dır. Görevler kalıcıdır. Birincil devre dışı kalırsa, yeni yükseltilen birincil doğru şekilde rapor etmeye devam edebilir.
  • Başka bir izleme işlemi (bulutta veya dışta) görevleri (istenen görev sonucuna göre dışarıdan) denetler ve tamamlandığını denetler. Eşiklere uyulmazsa, ana hizmete bir rapor gönderilir. PendingTask+taskId gibi görev tanımlayıcısını içeren her göreve de bir rapor gönderilir. Raporlar yalnızca iyi durumda olmayan durumlarda gönderilmelidir. Yaşam süresini birkaç dakika olarak ayarlayın ve temizlendiğinden emin olmak için raporların süresi dolduğunda kaldırılacak şekilde işaretleyin.
  • Bir görevi yürüten ikincil, görevi çalıştırması beklenenden uzun sürdüğünde bildirir. PendingTasks özelliğindeki hizmet örneğini raporlar. Rapor, sorunları olan hizmet örneğini tespit eder, ancak örneğin öldüğü durumu yakalamaz. Raporlar o zaman temizlenir. İkincil hizmetle ilgili rapor verebilir. İkincil görev tamamlanırsa, ikincil örnek raporu depodan temizler. Rapor, onay iletisinin kaybolduğu ve görevin ana ana bakış açısından tamamlanmadığı durumu yakalamaz.

Ancak raporlama yukarıda açıklanan durumlarda yapılır, sistem durumu değerlendirildiğinde raporlar uygulama durumu içinde yakalanır.

Geçişte düzenli aralıklarla raporla

İzlemeler, sistem durumu raporlama modelini kullanarak raporları düzenli aralıklarla veya geçişler üzerinde gönderebilir. Kod çok daha basit ve hatalara daha az yatkın olduğundan, izleme raporlaması için önerilen yol düzenli aralıklarla yapılır. watchdog'lar, yanlış raporları tetikleyen hataları önlemek için mümkün olduğunca basit olmaya çalışmalıdır. Hatalı iyi durumda olmayan raporlar, sistem durumu değerlendirmelerini ve yükseltmeler de dahil olmak üzere sistem durumuna dayalı senaryoları etkiler. Hatalı iyi durumdaki raporlar kümedeki sorunları gizler ve bu istenen bir durum değildir.

Düzenli raporlama için izleme bir zamanlayıcı ile uygulanabilir. Zamanlayıcı geri çağırmada, izleyici durumu denetleyip geçerli duruma göre bir rapor gönderebilir. Daha önce hangi raporun gönderildiğini görmenize veya mesajlaşma açısından herhangi bir iyileştirme yapmanıza gerek yoktur. Sistem durumu istemcisinin performansa yardımcı olmak için toplu işlem mantığı vardır. Sistem durumu istemcisi canlı tutulurken, rapor sistem durumu deposu tarafından onaylanana veya izleyici aynı varlık, özellik ve kaynağa sahip daha yeni bir rapor oluşturana kadar dahili olarak yeniden denenir.

Geçişleri raporlamak, durumun dikkatli bir şekilde işlenmesini gerektirir. İzleme, bazı koşulları ve raporları yalnızca koşullar değiştiğinde izler. Bu yaklaşımın iyi tarafı, daha az rapora ihtiyaç duyulmasıdır. Dezavantajı, izleme mantığının karmaşık olmasıdır. İzlemenin durum değişikliklerini belirlemek için denetlenebilmesi için koşulları veya raporları koruması gerekir. Yük devretme sırasında, raporlar eklendiğinde dikkatli olunmalıdır, ancak henüz sistem durumu deposuna gönderilmemelidir. Sıra numarası her zaman artmalıdır. Aksi takdirde, raporlar eski olarak reddedilir. Veri kaybının oluştuğu nadir durumlarda, muhabirin durumu ile sistem durumu deposunun durumu arasında eşitleme gerekebilir.

Geçişler üzerinde raporlama, veya CodePackageActivationContextaracılığıyla Partition kendi kendilerine raporlama yapan hizmetler için anlamlıdır. Yerel nesne (çoğaltma veya dağıtılan hizmet paketi / dağıtılan uygulama) kaldırıldığında, tüm raporları da kaldırılır. Bu otomatik temizleme, muhabir ve sistem durumu deposu arasındaki eşitleme gereksinimini rahatlatır. Rapor üst bölüme veya üst uygulamaya yönelikse, sistem durumu deposundaki eski raporları önlemek için yük devretmeye dikkat edilmelidir. Doğru durumu korumak ve artık gerekmediğinde raporu mağazadan temizlemek için mantık eklenmelidir.

Sistem durumu bildirimi uygulama

Varlık ve rapor ayrıntıları temizlendikten sonra, sistem durumu raporlarını göndermek API, PowerShell veya REST aracılığıyla gerçekleştirilebilir.

API

API aracılığıyla raporlamak için, raporlamak istedikleri varlık türüne özgü bir sistem durumu raporu oluşturmanız gerekir. Raporu bir sistem durumu istemcisine verin. Alternatif olarak, bir sistem durumu bilgileri oluşturun ve bunu geçerli varlıklardaki Partition raporlama yöntemlerini düzeltmek veya CodePackageActivationContext raporlamak için geçirin.

Aşağıdaki örnek, küme içindeki bir izlemeden düzenli olarak raporlamayı gösterir. İzleme, bir dış kaynağa bir düğümün içinden erişilip erişilemeyeceğini denetler. Kaynak, uygulama içindeki bir hizmet bildirimi tarafından gereklidir. Kaynak kullanılamıyorsa uygulama içindeki diğer hizmetler düzgün çalışmaya devam edebilir. Bu nedenle rapor, dağıtılan hizmet paketi varlığında her 30 saniyede bir gönderilir.

private static Uri ApplicationName = new Uri("fabric:/WordCount");
private static string ServiceManifestName = "WordCount.Service";
private static string NodeName = FabricRuntime.GetNodeContext().NodeName;
private static Timer ReportTimer = new Timer(new TimerCallback(SendReport), null, 30 * 1000, 30 * 1000);
private static FabricClient Client = new FabricClient(new FabricClientSettings() { HealthReportSendInterval = TimeSpan.FromSeconds(0) });

public static void SendReport(object obj)
{
    // Test whether the resource can be accessed from the node
    HealthState healthState = this.TestConnectivityToExternalResource();

    // Send report on deployed service package, as the connectivity is needed by the specific service manifest
    // and can be different on different nodes
    var deployedServicePackageHealthReport = new DeployedServicePackageHealthReport(
        ApplicationName,
        ServiceManifestName,
        NodeName,
        new HealthInformation("ExternalSourceWatcher", "Connectivity", healthState));

    // TODO: handle exception. Code omitted for snippet brevity.
    // Possible exceptions: FabricException with error codes
    // FabricHealthStaleReport (non-retryable, the report is already queued on the health client),
    // FabricHealthMaxReportsReached (retryable; user should retry with exponential delay until the report is accepted).
    Client.HealthManager.ReportHealth(deployedServicePackageHealthReport);
}

PowerShell

Send-ServiceFabricEntityTypeHealthReport ile sistem durumu raporları gönderin.

Aşağıdaki örnekte bir düğümdeki CPU değerleriyle ilgili düzenli raporlama gösterilmektedir. Raporların her 30 saniyede bir gönderilmesi gerekir ve iki dakikalık bir yaşam süresi vardır. Süresi dolarsa, muhabirin sorunları vardır, bu nedenle düğüm hata durumunda değerlendirilir. CPU eşiğin üzerinde olduğunda raporun sistem durumu uyarıdır. CPU, yapılandırılan süreden daha fazla süre için eşiğin üzerinde kaldığında hata olarak bildirilir. Aksi takdirde, muhabir Tamam sistem durumu gönderir.

PS C:\> Send-ServiceFabricNodeHealthReport -NodeName Node.1 -HealthState Warning -SourceId PowershellWatcher -HealthProperty CPU -Description "CPU is above 80% threshold" -TimeToLiveSec 120

PS C:\> Get-ServiceFabricNodeHealth -NodeName Node.1
NodeName              : Node.1
AggregatedHealthState : Warning
UnhealthyEvaluations  :
                        Unhealthy event: SourceId='PowershellWatcher', Property='CPU', HealthState='Warning', ConsiderWarningAsError=false.

HealthEvents          :
                        SourceId              : System.FM
                        Property              : State
                        HealthState           : Ok
                        SequenceNumber        : 5
                        SentAt                : 4/21/2015 8:01:17 AM
                        ReceivedAt            : 4/21/2015 8:02:12 AM
                        TTL                   : Infinite
                        Description           : Fabric node is up.
                        RemoveWhenExpired     : False
                        IsExpired             : False
                        Transitions           : ->Ok = 4/21/2015 8:02:12 AM

                        SourceId              : PowershellWatcher
                        Property              : CPU
                        HealthState           : Warning
                        SequenceNumber        : 130741236814913394
                        SentAt                : 4/21/2015 9:01:21 PM
                        ReceivedAt            : 4/21/2015 9:01:21 PM
                        TTL                   : 00:02:00
                        Description           : CPU is above 80% threshold
                        RemoveWhenExpired     : False
                        IsExpired             : False
                        Transitions           : ->Warning = 4/21/2015 9:01:21 PM

Aşağıdaki örnek, bir çoğaltma üzerinde geçici bir uyarı bildirir. Önce bölüm kimliğini ve ardından ilgilendiği hizmetin çoğaltma kimliğini alır. Ardından ResourceDependency özelliğinde PowershellWatcher'dan bir rapor gönderir. Rapor yalnızca iki dakika ilgi çekicidir ve otomatik olarak mağazadan kaldırılır.

PS C:\> $partitionId = (Get-ServiceFabricPartition -ServiceName fabric:/WordCount/WordCount.Service).PartitionId

PS C:\> $replicaId = (Get-ServiceFabricReplica -PartitionId $partitionId | where {$_.ReplicaRole -eq "Primary"}).ReplicaId

PS C:\> Send-ServiceFabricReplicaHealthReport -PartitionId $partitionId -ReplicaId $replicaId -HealthState Warning -SourceId PowershellWatcher -HealthProperty ResourceDependency -Description "The external resource that the primary is using has been rebooted at 4/21/2015 9:01:21 PM. Expect processing delays for a few minutes." -TimeToLiveSec 120 -RemoveWhenExpired

PS C:\> Get-ServiceFabricReplicaHealth  -PartitionId $partitionId -ReplicaOrInstanceId $replicaId


PartitionId           : 8f82daff-eb68-4fd9-b631-7a37629e08c0
ReplicaId             : 130740415594605869
AggregatedHealthState : Warning
UnhealthyEvaluations  :
                        Unhealthy event: SourceId='PowershellWatcher', Property='ResourceDependency', HealthState='Warning', ConsiderWarningAsError=false.

HealthEvents          :
                        SourceId              : System.RA
                        Property              : State
                        HealthState           : Ok
                        SequenceNumber        : 130740768777734943
                        SentAt                : 4/21/2015 8:01:17 AM
                        ReceivedAt            : 4/21/2015 8:02:12 AM
                        TTL                   : Infinite
                        Description           : Replica has been created.
                        RemoveWhenExpired     : False
                        IsExpired             : False
                        Transitions           : ->Ok = 4/21/2015 8:02:12 AM

                        SourceId              : PowershellWatcher
                        Property              : ResourceDependency
                        HealthState           : Warning
                        SequenceNumber        : 130741243777723555
                        SentAt                : 4/21/2015 9:12:57 PM
                        ReceivedAt            : 4/21/2015 9:12:57 PM
                        TTL                   : 00:02:00
                        Description           : The external resource that the primary is using has been rebooted at 4/21/2015 9:01:21 PM. Expect processing delays for a few minutes.
                        RemoveWhenExpired     : True
                        IsExpired             : False
                        Transitions           : ->Warning = 4/21/2015 9:12:32 PM

REST

İstenen varlığa giden ve gövdede sistem durumu raporu açıklamasını içeren POST istekleriyle REST kullanarak sistem durumu raporları gönderin. Örneğin, bkz. REST kümesi sistem durumu raporları veya hizmet durumu raporları gönderme. Tüm varlıklar desteklenir.

Sonraki adımlar

Sistem durumu verilerine bağlı olarak, hizmet yazarları ve küme/uygulama yöneticileri bilgileri kullanmanın yollarını düşünebilir. Örneğin, kesintilere neden olmadan önce ciddi sorunları yakalamak için sistem durumu temelinde uyarılar ayarlayabilirler. Yöneticiler, sorunları otomatik olarak düzeltmek için onarım sistemleri de ayarlayabilir.

Service Fabric sistem durumunu izlemeye giriş

Service Fabric sistem durumu raporlarını görüntüleme

Hizmet durumunu bildirme ve denetleme

Sorun giderme için sistem durumu raporlarını kullanma

Hizmetleri yerel olarak izleme ve tanılama

Service Fabric uygulama yükseltmesi