Sunucusuz olay işlemeyi izleme
Bu makale sunucusuz olay odaklı mimarileri izleme konusunda rehberlik sağlar.
İzleme, sistemlerinizin davranışı ve durumu hakkında içgörü sağlar. Ortamın bütünsel bir görünümünü oluşturmanıza, tarihi eğilimleri alıp farklı faktörlerin arasında ilişki kurmanıza ve performans, tüketim veya hata oranı değişikliklerini ölçmeye yardımcı olur. İzlemeyi, hizmetinizin kalitesini etkileyen koşullar oluştuğunda veya ortamınıza özgü ilginizi etkileyen koşullar ortaya çıktığında uyarı tanımlamak için kullanabilirsiniz.
Bu makalede, Azure İzleyici ve uygulaması kullanılarak bir sunucusuz uygulamayı izlemek için Event HubsAzure İşlevleri. İzlemek için yararlı ölçümleri açıklar, Application Analizler ile tümleştirin ve özel ölçümleri yakalamayı açıklar ve kod örnekleri sağlar.
Varsayımlar
Bu makalede, Sunucusuz olay işleme başvuru mimarisinde açıklanana benzer bir mimariye sahip olduğunu varsaymaktadır. Temelde:
- Olaylar bir Azure Event Hubs.
- Olayı işlemek için bir İşlev Uygulaması tetiklenir.
- Azure İzleyici mimariniz ile kullanılabilir.
Ölçümler Azure İzleyici
Öncelikle mimari hakkında yararlı içgörüler formüle etmek için hangi ölçümlerin gerekli olduğuna karar vermemiz gerekir. Her kaynak farklı görevler gerçekleştirir ve farklı ölçümler üretir.
Event Hub'dan gelen bu ölçümler yararlı içgörüleri yakalamak için ilginizi çekti:
- Gelen istekler
- Giden istekler
- Kısıtlandı istekleri
- Başarılı istekler
- Gelen iletiler
- Giden iletiler
- Yakalanan iletiler
- Gelen bayt sayısı
- Giden bayt sayısı
- Yakalanan bayt sayısı
- Kullanıcı hataları
Benzer şekilde, bu Azure İşlevleri yararlı içgörüleri yakalamak ilginizi olacaktır:
- İşlev yürütme sayısı
- Bağlantılar
- Veri kaynağı
- Verileri dışarı
- HTTP sunucusu hataları
- İstekler
- Uygulama kuyruğunda istekler
- Yanıt süresi
Tanılama günlüğünü kullanarak içgörüleri yakalama
Birlikte analiz edilirken, aşağıdaki içgörüleri formüle etmek ve yakalamak için yukarıdaki ölçümler kullanılabilir:
- İşlenen isteklerin Event Hubs
- İşlenen isteklerin Azure İşlevleri
- Toplam Olay Hub'ı aktarım hızı
- Kullanıcı hataları
- Azure İşlevleri
- Uz-uza gecikme süresi
- Her aşamada gecikme süresi
- Kaybedilen ileti sayısı
- Birden çok kez işlenen ileti sayısı
Gerekli ölçümleri Event Hubs emin olmak için önce tanılama günlüklerini (varsayılan olarak devre dışıdır) etkinleştirmemiz gerekir. Ardından hangi günlüklerin istenen olduğunu seçmemiz ve doğru Log Analytics çalışma alanını bunlar için hedef olarak yapılandırmamız gerekir.
İlgilenen günlük ve ölçüm kategorileri:
- OperationalLogs
- AutoScaleLogs
- KafkaCoordinatorLogs (Apache Kafka için)
- KafkaUserErrorLogs (Apache Kafka için)
- EventHubVNetConnectionEvent
- Tüm Ölçümler
Azure belgeleri, Azure olay hub'ı için tanılama günlüklerini ayarlama yönergelerini sağlar. Aşağıdaki ekran görüntüsünde, doğru günlük ve ölçüm kategorilerinin seçili olduğu örnek bir Tanılama ayarı yapılandırma paneli ve hedef olarak bir Log Analytics çalışma alanı gösterilir. (Günlükleri analiz etmek için bir dış sistem kullanılıyorsa, bunun yerine olay hub'ı için Akış seçeneği kullanılabilir.)
Not
Öngörüleri yakalamak için günlük tanılamayı kullanmak için farklı ad alanlarında olay hub'ları oluşturmanız gerekir. Bunun nedeni Azure'daki bir kısıtlamadır.
Verilen Event Hubs bir ad Event Hubs kümesi, adlı Azure İzleyici ölçümlerde temsil EntityName edilir. Bu Azure portal, belirli bir olay hub'larının verileri normalde bu olay hub'larının Azure İzleyici. Ancak ölçüm verileri günlük tanılamaya yönlendirilen veriler şu anda boyuta göre filtre kullanarak olay hub'ı başına veri görüntülemenin bir yolu EntityName yoktur.
Geçici bir çözüm olarak, farklı ad alanlarında olay hub'ları oluşturmak belirli bir hub'a yönelik ölçümlerin bulunmasına yardımcı olur.
Uygulama Analizler
Application Analizler'ı etkinleştirebilir ve bu verilerden ölçümleri ve özel telemetri Azure İşlevleri. Bu, sunucusuz olay işleme senaryosu için önemli içgörüler elde etmek için başka bir yol sağlayarak kendi amaçlarınıza uygun analizler tanımlamanızı sağlar.
Bu ekran görüntüsünde, Application Analizler içindeki özel ölçümlerin ve telemetrilerin örnek bir listesi Analizler:
Varsayılan özel ölçümler
Uygulama Analizler'de, Azure İşlevleri için özel ölçümler tabloda customMetrics depolanır. Farklı işlev örnekleri için zaman çizelgesine yayılmış aşağıdaki değerleri içerir:
AvgDurationMsMaxDurationMsMinDurationMsSuccessesFailuresSuccessRateCount
Bu ölçümler, bir çalıştırmada çağrılan birden çok işlev örneğinde toplanan ortalamaları verimli bir şekilde hesaplamak için kullanılabilir.
Bu ekran görüntüsünde, Bu varsayılan özel ölçümler Uygulama Örnek uygulamasında görüntü Analizler:
Özel iletiler
Azure İşlevi kodunda günlüğe kaydedilen özel iletiler (kullanılarak) Application ILogger Analizler traces alın.
Tabloda traces aşağıdaki önemli özellikler (diğerleri) vardır:
timestampcloud_RoleInstanceoperation_Idoperation_Namemessage
Application Analizler arabiriminde özel bir iletinin nasıl Analizler:
Gelen Olay Hub'ı iletisi veya bu özel iletinin bir parçası olarak günlüğe kaydedilmişse, bu durum EventData[]ILogger Application Analizler. Bu çok yararlı olabilir.
Sunucusuz olay işleme senaryomuz için olay hub'larından alınan JSON serileştirilmiş ileti gövdelerini günlüğe kaydedilir. Bu, , ve gibi ham byte dizisini SystemPropertiesx-opt-sequence-numberx-opt-offset yakalamamıza olanak x-opt-enqueued-time sağlar. Her iletinin Olay Hub'ı tarafından ne zaman alın olduğunu belirlemek x-opt-enqueued-time için özelliği kullanılır.
Örnek sorgu:
traces
| where timestamp between(min_t .. max_t)
| where message contains "Body"
| extend m = parse_json(message))
| project timestamp = todatetime(m.SystemProperties.["x-opt-enqueued-time"])
Örnek sorgu, Application Analizler'da varsayılan olarak günlüğe kaydedilen aşağıdaki örnek sonuça benzer bir Analizler. özellikleri, , Trigger Details ve başına alınan iletiler hakkında ek içgörüler bulmak ve yakalamak için PartitionIdOffsetSequenceNumber kullanılabilir.
Örnek sorgunun örnek sonucu:
"message": Trigger Details: PartitionId: 26, Offset: 17194119200, EnqueueTimeUtc: 2020-11-03T02:14:01.7740000Z, SequenceNumber: 843572, Count: 10,
Uyarı
Azure Java İşlevleri kitaplığı şu anda kullanırken ve erişimi engelleyen PartitionID bir PartitionContext soruna EventHubTrigger sahiptir. Daha fazla bilgi için bu GitHub raporuna girin.
Application Analizler ile işlem kimliği kullanarak ileti akışını izleme
Uygulama Analizler'de, belirli bir işlemle ilgili tüm telemetrileri, işlem değerinde bir İşlem araması sorgusu yaparak Operation Id görüntülebilirsiniz. Bu, işlem olay akışı ardışık düzeninde hareket ederken iletiler için ortalama sürelerin yüzdelik değerlerini yakalamaya yönelik olarak kullanışlı olabilir.
aşağıdaki ekran görüntüsünde Application Insights arabiriminde örnek bir işlem araması gösterilmektedir. İstenen Operation ID sorgu alanına, büyüteç simgesiyle tanımlanır (ve burada kırmızı bir kutu içinde gösterilir). Ana bölmenin en altında, Results sekme eşleşen olayları sıralı sırayla gösterir. Her olay girişinde, Operation ID kolay doğrulama için değer koyu mavi renkle vurgulanır.
Belirli bir işlem KIMLIĞI için oluşturulan sorgu aşağıdaki gibi görünür. Operation IDGUID 'nin üçüncü çizginin yan tümcesinde belirtildiğine unutmayın where * has . Bu örnek iki farklı sorgu arasında sorguyu daha da daraltır datetimes .
union isfuzzy=true availabilityResults, requests, exceptions, pageViews, traces, customEvents, dependencies
| where timestamp > datetime("2020-10-09T06:58:40.024Z") and timestamp < datetime("2020-11-11T06:58:40.024Z")
| where * has "1c8c9d7073a00e4bbdcc8f2e6570e46"
| order by timestamp desc
| take 100
sorgunun ve eşleşen sonuçlarının Application Insights arabiriminde nasıl görünebileceğini aşağıda görebilirsiniz:
Azure Işlevlerinden özel ölçümleri yakala
.NET işlevleri
yapılandırılmış günlük kaydı , .net Azure işlevlerinde Application Insights izlemeleri tablosundaki özel boyutları yakalamak için kullanılır. Bu özel boyutlar, daha sonra verileri sorgulamak için kullanılabilir.
Örnek olarak, .NET 'teki log deyimleri aşağıda verilmiştir TransformingFunction :
log.LogInformation("TransformingFunction: Processed sensorDataJson={sensorDataJson}, " +
"partitionId={partitionId}, offset={offset} at {enqueuedTimeUtc}, " +
"inputEH_enqueuedTime={inputEH_enqueuedTime}, processedTime={processedTime}, " +
"transformingLatencyInMs={transformingLatencyInMs}, processingLatencyInMs={processingLatencyInMs}",
sensorDataJson,
partitionId,
offset,
enqueuedTimeUtc,
inputEH_enqueuedTime,
processedTime,
transformingLatency,
processingLatency);
Application Insights oluşturulan elde edilen günlükler, bu ekran görüntüsünde gösterildiği gibi yukarıdaki parametreleri özel boyutlar olarak içerir:
Bu Günlükler şu şekilde sorgulanabilir:
traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name == "{Function_Name}"
| where message has "{Function_Name}: Processed"
| project timestamp = todatetime(customDimensions.prop__enqueuedTimeUtc)
Not
bu testlerde performansı etkilemediğinden emin olmak için, host.json aşağıda gösterildiği gibi dosyayı kullanarak Application Insights için Azure işlev günlüklerinin örnekleme ayarlarını açtık. Bu, günlük kaydı üzerinden yakalanan tüm istatistiklerin, ortalama değer olarak kabul edildiği ve gerçek sayımlar olmadığı anlamına gelir.
Host. JSON örneği:
"logging": {
"applicationInsights": {
"samplingExcludedTypes": "Request",
"samplingSettings": {
"isEnabled": true
}
}
}
Java işlevleri
şu anda yapılandırılmış günlüğe kaydetme, Application Insights izlemeleri tablosunda özel boyutları yakalamak için Java Azure işlevlerinde desteklenmez.
Örnek olarak, Java 'daki log deyimleri aşağıda verilmiştir TransformingFunction :
LoggingUtilities.logSuccessInfo(
context.getLogger(),
"TransformingFunction",
"SuccessInfo",
offset,
processedTimeString,
dateformatter.format(enqueuedTime),
transformingLatency
);
Application Insights oluşturulan elde edilen günlükler, aşağıda gösterildiği gibi iletideki yukarıdaki parametreleri içerir:
Bu Günlükler şu şekilde sorgulanabilir:
traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name in ("{Function name}") and message contains "SuccessInfo"
| project timestamp = todatetime(tostring(parse_json(message).enqueuedTime))
Not
bu testlerde performansı etkilemediğinden emin olmak için, host.json aşağıda gösterildiği gibi dosyayı kullanarak Application Insights için Azure işlev günlüklerinin örnekleme ayarlarını açtık. Bu, günlük kaydı üzerinden yakalanan tüm istatistiklerin, ortalama değer olarak kabul edildiği ve gerçek sayımlar olmadığı anlamına gelir.
Host. JSON örneği:
"logging": {
"applicationInsights": {
"samplingExcludedTypes": "Request",
"samplingSettings": {
"isEnabled": true
}
}
}
İlgili kaynaklar
- Sunucusuz olay işleme , kod örnekleri ve önemli noktaların tartışılması ile bu türden tipik bir mimariyi ayrıntılarıyla açıklayan bir başvuru mimarisidir.
- Event Hubs ile sunucusuz olay Işlemede de toplu işleme ve filtreleme , başvuru mimarisinin bu bölümlerinin nasıl çalıştığı hakkında daha ayrıntılı bilgi için açıklanmaktadır.
- Olay akışı Işlemedeki özel bağlantı senaryosu , güvenliği artırmak için, Özel uç noktaları olan bir sanal ağ (VNet) içinde benzer bir mimari uygulamaya yönelik bir çözüm fikridir.
- Olay akışı Işlemede Azure Kubernetes , Keda Scaler Ile Azure Kubernetes üzerinde çalışan sunucusuz olay odaklı mimarinin çeşitlemesini açıklamaktadır.







