Özel Service Fabric durum raporları ekleme

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. Özellikle köke yakın sorunları işaretlemeye yardımcı olabilirse, sistem durumunu etkileyebilecek herhangi bir koşul bildirilmelidir. Sistem durumu bilgileri hata ayıklama ve araştırma için zaman ve çaba tasarrufu sağlayabilir. Özellikle hizmet bulutta (özel veya Azure) uygun ölçekte çalışmaya başladığında kullanışlılık açıktır.

Service Fabric muhabirleri, belirlenen ilgi koşullarını izler. Bu koşulları yerel görünümlerine göre bildirir. 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. İyi durumda olmayan sorunları yanlış gösteren hatalı pozitifler, 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ını tasarlamak ve uygulamak için, watchdogs ve sistem bileşenleri şunları yapmalıdır:

• İ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 durumuna karar verin.
• Raporun geçerli olduğu varlığı belirleyin.
• Raporlamanın nerede yapıldığını, hizmetin içinden veya bir iç ya da dış watchdog'dan 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 rapor veren durum bilgisi olmayan bir Service Fabric hizmeti). İzlemeler 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.
• Kaynağı Service Fabric kümesinin dışından yoklayan dış watchdogs (örneğin, Gomez gibi izleme hizmeti).

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üğümleri toplu iş raporları.

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 tek bir ileti göndermek yerine tek bir ileti halinde toplu iş yapmak 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. İleti zaman aşımına uğradıysa, sistem durumu yöneticisi raporun işlendiğini onaylayana kadar sistem durumu istemcisi bunu yeniden denenir. Varsayılan: iki dakika.

İstemcideki 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 az biri istemci kuyruğunda bulunur. Toplu işlem yapılandırılırsa, sistem durumu yöneticisine gönderilen rapor sayısı gönderme aralığı başına yalnızca bir tanedir. Bu rapor, varlığın en güncel durumunu yansıtan son eklenen rapordur. Sistem durumuyla ilgili girdiler 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 raporların eklendiğinde 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ı HealthReportSendInterval önerilir. 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ğunda sistem durumu istemcisi toplu işleminden 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önderme işleminden sonra birikmiş tüm raporları toplu olarak oluşturur.

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önderilmek üzere 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 olarak rapor gönderecek şekilde yapılandırılır. Üzerinde küme yapılandırma ayarıyla HttpGatewayHealthReportSendInterval HttpGatewaytoplu iş aralığını değiştirebilirsiniz. Belirtildiği gibi, raporları true ile Immediate göndermek daha iyi bir seçenektir.

Düşük ayrıcalıklı hizmetlerin içinden rapor

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

• Durum bilgisi olmayan hizmetler için, geçerli hizmet örneğini raporlamak için IStatelessServicePartition.ReportInstanceHealth kullanın.
• Durum bilgisi olan hizmetler için, geçerli çoğaltmayı raporlamak için IStatefulServicePartition.ReportReplicaHealth kullanın.
• Geçerli bölüm varlığını raporlamak için IServicePartition.ReportPartitionHealth kullanın.
• Geçerli uygulamayı raporlamak için CodePackageActivationContext.ReportApplicationHealth kullanın.
• Geçerli düğümde dağıtılan geçerli uygulamayı raporlamak için CodePackageActivationContext.ReportDeployedApplicationHealth kullanın.
• Geçerli düğümde dağıtılan uygulamanın hizmet paketini raporlamak için CodePackageActivationContext.ReportDeployedServicePackageHealth kullanın.

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. Anında 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 istemcisi toplu işleminden yararlanmak istiyoruz.

Sistem durumu raporlamayı tasarlama

Yüksek kaliteli raporlar oluşturmanın ilk adımı, hizmetin durumunu etkileyebilecek koşulları belirlemektir. Bir sorun gerçekleşmeden önce hizmet veya kümedeki sorunları bayrakla işaretlemeye yardımcı olabilecek her koşul milyarlarca dolar tasarruf edebilir. Avantajlar arasında daha az çalışma süresi, sorunları araştırmak ve onarmak için daha az gece saati harcanır ve müşteri memnuniyeti daha yüksektir.

Koşullar belirlendikten sonra, izleyici yazarları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. Bir watchdog, yeterli alanın kullanılabilir olduğundan emin olmak için paylaşımı izleyebilir. Dosya veya dizin değişikliklerinin bildirimlerini dinleyebilecek. Ön eşiklere 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. Durum durumlarının sistem durumu açısından nasıl açıklandığına dikkat edin: iyi durumda (tamam) veya iyi durumda olmayan (uyarı veya hata) olarak kabul edilebilecek koşulun durumu.

İzleme ayrıntıları ayarlandıktan sonra, bir watchdog yazıcısının watchdog'un nasıl uygulanacaklarını belirlemesi gerekir. Koşullar hizmetin içinden belirlenebiliyorsa izleme, izlenen hizmetin bir parçası olabilir. Örneğin, hizmet kodu paylaşım kullanımını denetleyebilir 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. Karar verme mantığına veya verilerine 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 watchdog da bir seçenek değildir. İzlenen koşul, kullanıcıların gördüğü hizmetin kullanılabilirliği veya işlevselliğiyse, watchdogs'ların 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 yaşayan, hizmete istekler veren ve sonucun gecikmesini ve doğruluğunu denetleen bir watchdog'nuz 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ürdeki birden çok watchdog yaşıyorsa, farklı varlıklara rapor vermesi veya aynı varlıkta rapor vermesi durumunda farklı kaynak kimliği veya özelliği kullanması gerekir. Bu şekilde raporları bir arada bulunabilir. Sistem durumu raporunun özelliği izlenen koşulu yakalamalıdır. (Yukarıdaki örnekte özelliği şu şekilde olabilir: ShareSize.) Aynı koşula birden çok rapor uygulanırsa, özelliği raporların bir arada var olmasını sağlayan bazı dinamik bilgiler içermelidir. Örneğin, birden çok paylaşımın izlenmesi gerekiyorsa özellik adı ShareSize-sharename olabilir.

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 örnekleri vardır. Koşul, çoğaltma gibi bir varlığı etkiliyorsa ancak koşulun çoğaltma ömrü süresinden daha uzun bir süre bayrakla işaretlenmesini istiyorsanız, bölüme bildirilmelidir. Aksi takdirde, çoğaltma silindiğinde sistem durumu deposu tüm raporlarını temizler. watchdog yazarlarının varlığın ve raporun yaşam süreleri hakkında düşünmesi gerekir. Bir 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.

Şimdi açıkladığım noktaları bir araya getiren bir örneğe bakalım. Durum bilgisi olan ana 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 şablon, ikinciller tarafından yürütülecek komutları içeren bir işleme kuyruğuna sahiptir. İkinciller gelen istekleri yürütür ve onay sinyallerini geri 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. Watchdog hizmetin içinde bulunur ve ana birincil çoğaltmada 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 devre dışı kalırsa, rapor mağazadan otomatik olarak temizlenir. Hizmet çoğaltması çalışır durumdaysa ancak kilitlenmesi 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, tamamlandıklarında ikincillerin geri onay sinyalleri göndermesini de bekleyebilir. İkinci durumda, ikincillerin öldüğü veya iletilerin kaybolduğu durumları tespit etmek için dikkatli olunmalıdır. Bir seçenek, ana dosyanın durumunu geri gönderen aynı ikincil sunucuya 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 yolla yapılabilir:

• Ana birincil çoğaltma belirli aralıklarla kendisi ü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, uygun olan bir uyarı veya hatadır. Bekleyen görev yoksa veya yürütmeye başlayan tüm görevler varsa, 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) denetleyip 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örevin çalıştırılması 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 temizlenir. İkincil hizmetle ilgili rapor verebilir. İkincil görevi tamamlarsa, ikincil örnek raporu depodan temizler. Rapor, onay iletisinin kaybolduğu ve görevin 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

Watchdogs, sistem durumu raporlama modelini kullanarak raporları düzenli aralıklarla veya geçişlerde gönderebilir. Kod çok daha basit ve hatalara daha az eğilimli olduğundan, izleme raporlaması için önerilen yol düzenli aralıklarla yapılır. watchdogs, yanlış raporları tetikleyen hataları önlemek için mümkün olduğunca basit olmaya çalışmalıdır. Yanlış iyi durumda olmayan raporlar, sistem durumu değerlendirmelerini ve yükseltmeler de dahil olmak üzere sistem durumuna bağlı senaryoları etkiler. Hatalı iyi durumdaki raporlar kümedeki sorunları gizler ve bu durum istenmiyor.

Düzenli raporlama için izleme bir zamanlayıcı ile uygulanabilir. Zamanlayıcı geri çağırmada, watchdog 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ı tutulsa da, 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şler hakkında raporlama, durumun dikkatli bir şekilde işlenmesini gerektirir. watchdog bazı koşulları izler ve yalnızca koşullar değiştiğinde raporlar. Bu yaklaşımın iyi tarafı, daha az rapora ihtiyaç duyulmasıdır. Bunun dezavantajı, watchdog mantığının karmaşık olmasıdır. Watchdog, durum değişikliklerini belirlemek için denetlenebilmeleri için koşulları veya raporları korumalıdır. 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 geçen gün artmalıdır. Aksi takdirde, raporlar eski olarak reddedilir. Veri kaybının yaşandığı nadir durumlarda, muhabirin durumu ile sistem durumu deposunun durumu arasında eşitleme gerekebilir.

Geçişler hakkında 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ında eşitleme gereksinimini gevşetir. Rapor üst bölüme veya üst uygulamaya yönelikse, sistem durumu deposundaki eski raporları önlemek için yük devretme işleminde dikkatli olunmalıdır. Artık gerekli olmadığında doğru durumu korumak ve raporu depodan temizlemek için mantık eklenmelidir.

Sistem durumu raporlamayı uygulama

Varlık ve rapor ayrıntıları temizlendikten sonra, sistem durumu raporlarını göndermek API, PowerShell veya REST aracılığıyla yapılabilir.

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 bu bilgileri 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 watchdog'dan düzenli raporlamayı gösterir. İzleme, bir dış kaynağa düğüm 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 her 30 saniyede bir gönderilmelidir ve iki dakikalık 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 uzun bir 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