Azure'da Dayanıklı İşlevler'de Tanılama
Dayanıklı İşlevler ile ilgili sorunları tanılamak için çeşitli seçenekler vardır. Bu seçeneklerden bazıları normal işlevlerle aynıdır ve bazıları da Dayanıklı İşlevler için benzersizdir.
Application Insights
Uygulama Analizler, Azure İşlevleri tanılama ve izleme gerçekleştirmenin önerilen yoludur. Aynı durum Dayanıklı İşlevler için de geçerlidir. İşlev uygulamanızda Application Analizler'ı kullanma hakkında genel bilgi için bkz. İzleme Azure İşlevleri.
Azure İşlevleri Dayanıklı Uzantı, bir düzenlemenin uçtan uca yürütülmesini izlemenize olanak sağlayan izleme olayları da yayar. Bu izleme olayları Azure portalındaki Application Analizler Analytics aracı kullanılarak bulunabilir ve sorgulanabilir.
Verileri izleme
Düzenleme örneğinin her yaşam döngüsü olayı, uygulama Analizler izleme koleksiyonuna bir izleme olayının yazılmasına neden olur. Bu olay çeşitli alanlara sahip customDimensions yükü içerir. Alan adlarının tümü ile prop__
eklenir.
- hubName: Düzenlemelerinizin çalıştığı görev hub'ının adı.
- appName: İşlev uygulamasının adı. Bu alan, aynı Uygulama Analizler örneğini paylaşan birden çok işlev uygulamanız olduğunda kullanışlıdır.
- slotName: Geçerli işlev uygulamasının çalıştığı dağıtım yuvası . Bu alan, düzenlemelerinizi sürüm olarak dağıtmak için dağıtım yuvalarını kullandığınızda kullanışlıdır.
- functionName: Orchestrator veya activity işlevinin adı.
- functionType: Orchestrator veya Activity gibi işlevin türü.
- instanceId: Düzenleme örneğinin benzersiz kimliği.
- durum: Örneğin yaşam döngüsü yürütme durumu. Geçerli değerler şunlardır:
- Zamanlandı: İşlev yürütme için zamanlandı ancak henüz çalışmaya başlamadı.
- Başlatıldı: İşlev çalışmaya başladı ancak henüz beklenmedi veya tamamlanmadı.
- Bekleniyor: Düzenleyici bazı çalışmalar zamanladı ve tamamlanmasını bekliyor.
- Dinleme: Düzenleyici bir dış olay bildirimini dinliyor.
- Tamamlandı: İşlev başarıyla tamamlandı.
- Başarısız: İşlev bir hatayla başarısız oldu.
- neden: İzleme olayıyla ilişkili ek veriler. Örneğin, bir örnek dış olay bildirimi bekliyorsa, bu alan beklediği olayın adını gösterir. Bir işlev başarısız olduysa, bu alan hata ayrıntılarını içerir.
- isReplay: İzleme olayının yeniden oynatılan yürütme için olup olmadığını gösteren Boole değeri.
- extensionVersion: Dayanıklı Görev uzantısının sürümü. Sürüm bilgileri, uzantıdaki olası hataları bildirirken özellikle önemli verilerdir. Uzun süre çalışan örnekler, bir güncelleştirme çalışırken gerçekleşirse birden çok sürüm bildirebilir.
- sequenceNumber: Bir olay için yürütme sırası numarası. Zaman damgası ile birlikte yürütme zamanına göre olayları sıralamaya yardımcı olur. Örnek çalışırken konak yeniden başlatılırsa bu sayı sıfırlanır, bu nedenle her zaman önce zaman damgasına, sonra sequenceNumber'a göre sıralamak önemlidir.
Application Analizler'a yayılan izleme verilerinin ayrıntı düzeyi, dosyanın (İşlevler 1.x) veya logging
(İşlevler 2.0) bölümünde host.json
yapılandırılabilir logger
.
İşlevler 1.0
{
"logger": {
"categoryFilter": {
"categoryLevels": {
"Host.Triggers.DurableTask": "Information"
}
}
}
}
İşlevler 2.0
{
"logging": {
"logLevel": {
"Host.Triggers.DurableTask": "Information",
},
}
}
Varsayılan olarak, tüm yeniden yürütme olmayan izleme olayları yayılır. Veri hacmi, olarak ayarlanarak Host.Triggers.DurableTask
"Warning"
veya "Error"
bu durumda izleme olayları yalnızca istisnai durumlar için yayılarak azaltılabilir. Ayrıntılı düzenleme yeniden yürütme olaylarının yayılabilmesi için true
host.json yapılandırma dosyasında olarak ayarlayınlogReplayEvents
.
Not
Varsayılan olarak, uygulama Analizler telemetri verileri çok sık yaymamak için Azure İşlevleri çalışma zamanı tarafından örneklenir. Bu, kısa bir süre içinde birçok yaşam döngüsü olayı gerçekleştiğinde izleme bilgilerinin kaybolmasına neden olabilir. Azure İşlevleri İzleme makalesinde bu davranışın nasıl yapılandırılması açıklanır.
Düzenleyici, etkinlik ve varlık işlevlerinin girişleri ve çıkışları varsayılan olarak günlüğe kaydedilmez. Giriş ve çıkışların günlüğe kaydedilmesi Uygulama Analizler maliyetlerini artırabileceğinden bu varsayılan davranış önerilir. İşlev giriş ve çıkış yükleri de hassas bilgiler içerebilir. Bunun yerine, varsayılan olarak gerçek yüklerin yerine işlev girişlerinin ve çıkışlarının bayt sayısı günlüğe kaydedilir. Dayanıklı İşlevler uzantısının tam giriş ve çıkış yüklerini günlüğe kaydetmesini istiyorsanız, host.json yapılandırma dosyasında özelliğini true
olarak ayarlayıntraceInputsAndOutputs
.
Tek örnekli sorgu
Aşağıdaki sorgu, Hello Sequence işlevi düzenlemesinin tek bir örneğine ait geçmiş izleme verilerini gösterir. Kusto Sorgu Dili kullanılarak yazılır. Yalnızca mantıksal yürütme yolunun gösterilmesi için yeniden yürütme yürütmesini filtreler. Olaylar, aşağıdaki sorguda gösterildiği gibi ve sequenceNumber
ölçütüne göre sıralanarak timestamp
sıralanabilir:
let targetInstanceId = "ddd1aaa685034059b545eb004b15d4eb";
let start = datetime(2018-03-25T09:20:00);
traces
| where timestamp > start and timestamp < start + 30m
| where customDimensions.Category == "Host.Triggers.DurableTask"
| extend functionName = customDimensions["prop__functionName"]
| extend instanceId = customDimensions["prop__instanceId"]
| extend state = customDimensions["prop__state"]
| extend isReplay = tobool(tolower(customDimensions["prop__isReplay"]))
| extend sequenceNumber = tolong(customDimensions["prop__sequenceNumber"])
| where isReplay != true
| where instanceId == targetInstanceId
| sort by timestamp asc, sequenceNumber asc
| project timestamp, functionName, state, instanceId, sequenceNumber, appName = cloud_RoleName
Sonuç, yürütme zamanına göre artan düzende sıralanmış etkinlik işlevleri de dahil olmak üzere düzenlemenin yürütme yolunu gösteren izleme olaylarının listesidir.
Örnek özet sorgusu
Aşağıdaki sorgu, belirtilen zaman aralığında çalıştırılan tüm düzenleme örneklerinin durumunu görüntüler.
let start = datetime(2017-09-30T04:30:00);
traces
| where timestamp > start and timestamp < start + 1h
| where customDimensions.Category == "Host.Triggers.DurableTask"
| extend functionName = tostring(customDimensions["prop__functionName"])
| extend instanceId = tostring(customDimensions["prop__instanceId"])
| extend state = tostring(customDimensions["prop__state"])
| extend isReplay = tobool(tolower(customDimensions["prop__isReplay"]))
| extend output = tostring(customDimensions["prop__output"])
| where isReplay != true
| summarize arg_max(timestamp, *) by instanceId
| project timestamp, instanceId, functionName, state, output, appName = cloud_RoleName
| order by timestamp asc
Sonuç, örnek kimliklerinin ve bunların geçerli çalışma zamanı durumunun listesidir.
Dayanıklı Görev Çerçevesi Günlüğü
Dayanıklı uzantı günlükleri, düzenleme mantığınızın davranışını anlamak için kullanışlıdır. Ancak bu günlükler her zaman çerçeve düzeyinde performans ve güvenilirlik sorunlarını ayıklamak için yeterli bilgi içermez. Dayanıklı uzantısının v2.3.0'dan başlayarak, temel alınan Dayanıklı Görev Çerçevesi (DTFx) tarafından yayılan günlükler de koleksiyon için kullanılabilir.
DTFx tarafından yayılan günlüklere bakarken, DTFx altyapısının iki bileşenden oluştuğunu anlamak önemlidir: çekirdek dağıtım altyapısı (DurableTask.Core
) ve desteklenen birçok depolama sağlayıcısından biri (Dayanıklı İşlevler varsayılan olarak kullanılırDurableTask.AzureStorage
, ancak diğer seçenekler kullanılabilir).
- DurableTask.Core: Çekirdek düzenleme yürütmesi ve alt düzey zamanlama günlükleri ve telemetri.
- DurableTask.Azure Depolama: Azure Depolama durum sağlayıcısına özgü arka uç günlükleri. Bu günlükler, iç düzenleme durumunu depolamak ve getirmek için kullanılan iç kuyruklar, bloblar ve depolama tabloları ile ayrıntılı etkileşimleri içerir.
- DurableTask.Netherite: Etkinse Netherite depolama sağlayıcısına özgü arka uç günlükleri.
- DurableTask.SqlServer: Etkinleştirildiyse Microsoft SQL (MSSQL) depolama sağlayıcısına özgü arka uç günlükleri.
İşlev uygulamanızın host.json dosyasının logging/logLevel
bölümünü güncelleştirerek bu günlükleri etkinleştirebilirsiniz. Aşağıdaki örnekte hem hem de DurableTask.Core
öğesinden uyarı ve hata günlüklerinin nasıl etkinleştirileceği gösterilmektedir DurableTask.AzureStorage
:
{
"version": "2.0",
"logging": {
"logLevel": {
"DurableTask.AzureStorage": "Warning",
"DurableTask.Core": "Warning"
}
}
}
Uygulama Analizler etkinleştirdiyseniz, bu günlükler koleksiyona trace
otomatik olarak eklenir. Kusto sorgularını kullanarak bunları diğer trace
günlüklerde yaptığınız gibi arayabilirsiniz.
Not
Üretim uygulamaları için, filtreyi kullanarak "Warning"
uygun depolama sağlayıcısını (örn. DurableTask.AzureStorage
) etkinleştirmeniz DurableTask.Core
önerilir. gibi "Information"
daha yüksek ayrıntı filtreleri, performans sorunlarının hatalarını ayıklamak için çok yararlıdır. Ancak bu günlük olayları yüksek hacimli olabilir ve Uygulama Analizler veri depolama maliyetlerini önemli ölçüde artırabilir.
Aşağıdaki Kusto sorgusunda DTFx günlüklerinin nasıl sorgu yapılacağı gösterilmektedir. Sorgunun en önemli bölümü, where customerDimensions.Category startswith "DurableTask"
sonuçları ve DurableTask.AzureStorage
kategorilerindeki günlüklere göre filtrelediğindendirDurableTask.Core
.
traces
| where customDimensions.Category startswith "DurableTask"
| project
timestamp,
severityLevel,
Category = customDimensions.Category,
EventId = customDimensions.EventId,
message,
customDimensions
| order by timestamp asc
Sonuç, Dayanıklı Görev Çerçevesi günlük sağlayıcıları tarafından yazılmış bir günlük kümesidir.
Hangi günlük olaylarının kullanılabilir olduğu hakkında daha fazla bilgi için GitHub'daki Dayanıklı Görev Çerçevesi yapılandırılmış günlük kaydı belgelerine bakın.
Uygulama Günlüğü
Doğrudan bir orchestrator işlevinden günlük yazarken düzenleyicinin yeniden yürütme davranışını göz önünde bulundurmak önemlidir. Örneğin, aşağıdaki orchestrator işlevini göz önünde bulundurun:
[FunctionName("FunctionChain")]
public static async Task Run(
[OrchestrationTrigger] IDurableOrchestrationContext context,
ILogger log)
{
log.LogInformation("Calling F1.");
await context.CallActivityAsync("F1");
log.LogInformation("Calling F2.");
await context.CallActivityAsync("F2");
log.LogInformation("Calling F3");
await context.CallActivityAsync("F3");
log.LogInformation("Done!");
}
Sonuçta elde edilen günlük verileri aşağıdaki örnek çıktıya benzer şekilde görünecektir:
Calling F1.
Calling F1.
Calling F2.
Calling F1.
Calling F2.
Calling F3.
Calling F1.
Calling F2.
Calling F3.
Done!
Not
Günlüklerin F1, F2 ve F3'i çağırdığını iddia ederken, bu işlevlerin yalnızca ilk kez karşılaşıldığında çağrıldığını unutmayın. Yeniden yürütme sırasında gerçekleşen sonraki çağrılar atlanır ve çıkışlar düzenleyici mantığına yeniden oynatılır.
Yalnızca yeniden yürütme olmayan yürütmelerde günlük yazmak istiyorsanız, yalnızca "yeniden yürütülmektedir" bayrağı false
ise günlüğe bir koşullu ifade yazabilirsiniz. Yukarıdaki örneği göz önünde bulundurun, ancak bu kez yeniden yürütme denetimleriyle.
[FunctionName("FunctionChain")]
public static async Task Run(
[OrchestrationTrigger] IDurableOrchestrationContext context,
ILogger log)
{
if (!context.IsReplaying) log.LogInformation("Calling F1.");
await context.CallActivityAsync("F1");
if (!context.IsReplaying) log.LogInformation("Calling F2.");
await context.CallActivityAsync("F2");
if (!context.IsReplaying) log.LogInformation("Calling F3");
await context.CallActivityAsync("F3");
log.LogInformation("Done!");
}
.NET düzenleyici işlevleri, Dayanıklı İşlevler 2.0'dan başlayarak, yeniden yürütme sırasında günlük deyimlerini otomatik olarak filtreleyen bir ILogger
oluşturma seçeneğine de sahiptir. Bu otomatik filtreleme IDurableOrchestrationContext.CreateReplay Kasa Logger(ILogger) API'si kullanılarak yapılır.
[FunctionName("FunctionChain")]
public static async Task Run(
[OrchestrationTrigger] IDurableOrchestrationContext context,
ILogger log)
{
log = context.CreateReplaySafeLogger(log);
log.LogInformation("Calling F1.");
await context.CallActivityAsync("F1");
log.LogInformation("Calling F2.");
await context.CallActivityAsync("F2");
log.LogInformation("Calling F3");
await context.CallActivityAsync("F3");
log.LogInformation("Done!");
}
Not
Önceki C# örnekleri Dayanıklı İşlevler 2.x içindir. Dayanıklı İşlevler 1.x için yerine IDurableOrchestrationContext
kullanmanız DurableOrchestrationContext
gerekir. Sürümler arasındaki farklar hakkında daha fazla bilgi için Dayanıklı İşlevler sürümleri makalesine bakın.
Daha önce bahsedilen değişikliklerle günlük çıkışı aşağıdaki gibidir:
Calling F1.
Calling F2.
Calling F3.
Done!
Özel Durum
Özel düzenleme durumu, orchestrator işleviniz için özel durum değeri ayarlamanıza olanak tanır. Bu özel durum daha sonra HTTP durum sorgu API'si veya dile özgü API çağrıları aracılığıyla dış istemciler tarafından görülebilir. Özel düzenleme durumu, düzenleyici işlevleri için daha zengin izleme sağlar. Örneğin, orchestrator işlev kodu uzun süre çalışan bir işlemin ilerleme durumunu güncelleştirmek için "özel durum ayarla" API'sini çağırabilir. Daha sonra web sayfası veya başka bir dış sistem gibi bir istemci, daha zengin ilerleme bilgileri için HTTP durum sorgusu API'lerini düzenli aralıklarla sorgulayabilir. Orchestrator işlevinde özel durum değeri ayarlamaya yönelik örnek kod aşağıda verilmiştir:
[FunctionName("SetStatusTest")]
public static async Task SetStatusTest([OrchestrationTrigger] IDurableOrchestrationContext context)
{
// ...do work...
// update the status of the orchestration with some arbitrary data
var customStatus = new { completionPercentage = 90.0, status = "Updating database records" };
context.SetCustomStatus(customStatus);
// ...do more work...
}
Not
Önceki C# örneği Dayanıklı İşlevler 2.x içindir. Dayanıklı İşlevler 1.x için yerine IDurableOrchestrationContext
kullanmanız DurableOrchestrationContext
gerekir. Sürümler arasındaki farklar hakkında daha fazla bilgi için Dayanıklı İşlevler sürümleri makalesine bakın.
Düzenleme çalışırken dış istemciler şu özel durumu getirebilir:
GET /runtime/webhooks/durabletask/instances/instance123?code=XYZ
İstemciler aşağıdaki yanıtı alır:
{
"runtimeStatus": "Running",
"input": null,
"customStatus": { "completionPercentage": 90.0, "status": "Updating database records" },
"output": null,
"createdTime": "2017-10-06T18:30:24Z",
"lastUpdatedTime": "2017-10-06T19:40:30Z"
}
Uyarı
Azure Tablo Depolama sütununa sığabilmesi gerektiğinden özel durum yükü 16 KB UTF-16 JSON metniyle sınırlıdır. Daha büyük yüke ihtiyacınız varsa dış depolamayı kullanabilirsiniz.
Dağıtılmış İzleme
Dağıtılmış İzleme istekleri izler ve farklı hizmetlerin birbirleriyle nasıl etkileşim kuracaklarını gösterir. Dayanıklı İşlevler' de, düzenleme ve etkinlikleri birlikte ilişkilendirir. Bu, düzenleme adımlarının düzenlemenin tamamına göre ne kadar zaman alacağını anlamanıza yardımcı olur. Bir uygulamanın nerede sorun yaşadığını veya bir özel durumun nerede oluşturulduğunı anlamak da yararlıdır. Bu özellik tüm diller ve depolama sağlayıcıları için desteklenir.
Not
Dağıtılmış İzleme V2, v2.12.0 veya üzeri Dayanıklı İşlevler gerektirir. Ayrıca, Dağıtılmış İzleme V2 önizleme durumundadır ve bu nedenle bazı Dayanıklı İşlevler desenleri izlenmedi. Örneğin, Dayanıklı Varlıklar işlemleri izlenmez ve izlemeler Uygulama Analizler'de gösterilmez.
Dağıtılmış İzlemeyi Ayarlama
Dağıtılmış izlemeyi ayarlamak için lütfen host.json güncelleştirin ve bir Application Analizler kaynağı ayarlayın.
host.json
"durableTask": {
"tracing": {
"distributedTracingEnabled": true,
"Version": "V2"
}
}
Application Insights
İşlev uygulaması bir Uygulama Analizler kaynağıyla yapılandırılmamışsa lütfen buradaki yönergeleri izleyerek yapılandırın.
İzlemeleri inceleme
Uygulama Analizler kaynağında İşlem Arama'ya gidin. Sonuçlarda, belirli Dayanıklı İşlevler öneklerle (örneğinorchestration:
, , activity:
vb.) başlayan ve Dependency
olaylarını denetleyinRequest
. Bu olaylardan birinin seçilmesi, uçtan uca dağıtılmış izlemeyi gösterecek bir Gantt grafiği açar.
Sorun giderme
Uygulama Analizler'nde izlemeleri görmüyorsanız, tüm verilerin Application Analizler kaynağına yayılmasını sağlamak için lütfen uygulamayı çalıştırdıktan sonra yaklaşık beş dakika beklemeyi unutmayın.
Hata ayıklama
Azure İşlevleri, işlev kodunda hata ayıklamayı doğrudan destekler ve aynı destek, Azure'da veya yerel olarak çalışırken Dayanıklı İşlevler devam eder. Ancak hata ayıklama sırasında dikkat etmeniz gereken birkaç davranış vardır:
- Yeniden yürütme: Orchestrator, yeni girişler alındığında düzenli olarak yeniden oynatılır . Bu davranış, özellikle işlev kodunda erken ayarlanmışsa, bir orchestrator işlevinin tek bir mantıksal yürütmesinin aynı kesme noktasına birden çok kez isabet etmesiyle sonuçlanacağı anlamına gelir.
- Await: Bir orchestrator işlevinde bir
await
ile karşılaşıldığında denetimi Dayanıklı Görev Çerçevesi dağıtıcısına geri verir. Belirliawait
bir görevle ilk kez karşılaşılıyorsa, ilişkili görev hiçbir zaman sürdürülemez . Görev hiçbir zaman devam etmediğinden await (Visual Studio'da F10) üzerine adım atmak mümkün değildir. Üzerine adımlama yalnızca bir görev yeniden yürütülüyorken çalışır. - Mesajlaşma zaman aşımları: Dayanıklı İşlevler düzenleyici, etkinlik ve varlık işlevlerinin yürütülmesini sağlamak için kuyruk iletilerini dahili olarak kullanır. Çoklu VM ortamında, uzun süre hata ayıklamaya girilmesi, başka bir VM'nin iletiyi almasına neden olarak yinelenen yürütmeye neden olabilir. Bu davranış normal kuyruk tetikleyici işlevleri için de mevcuttur, ancak kuyruklar bir uygulama ayrıntısı olduğundan bu bağlamda dikkat edilmesi önemlidir.
- Durdurma ve başlatma: Dayanıklı işlevlerdeki iletiler hata ayıklama oturumları arasında kalır. Dayanıklı bir işlev yürütülürken hata ayıklamayı durdurur ve yerel konak işlemini sonlandırırsanız, bu işlev gelecekteki bir hata ayıklama oturumunda otomatik olarak yeniden yürütülebilir. Bu davranış beklenmediği zaman kafa karıştırıcı olabilir. Bu davranışı önlemek için yeni bir görev hub'ı kullanmak veya hata ayıklama oturumları arasında görev hub'ı içeriğini temizlemek bir tekniktir.
İpucu
Orchestrator işlevlerinde kesme noktalarını ayarlarken, yalnızca yeniden yürütülmeyen yürütmede kesme yapmak istiyorsanız, yalnızca "yeniden oynatılıyor" değeri ise false
kesen bir koşullu kesme noktası ayarlayabilirsiniz.
Depolama
Varsayılan olarak, Dayanıklı İşlevler durumu Azure Depolama'da depolar. Bu davranış, Microsoft Azure Depolama Gezgini gibi araçları kullanarak düzenlemelerinizin durumunu inceleyebileceğiniz anlamına gelir.
Bir düzenlemenin tam olarak hangi durumda olabileceğini gördüğünüzden, bu hata ayıklama için yararlıdır. Kuyruklardaki iletiler, hangi çalışmanın beklemede olduğunu (veya bazı durumlarda takıldığını) öğrenmek için de incelenebilir.
Uyarı
Tablo depolamada yürütme geçmişini görmek kullanışlı olsa da, bu tabloya bağımlılık yapmaktan kaçının. Dayanıklı İşlevler uzantısı geliştikçe değişebilir.
Not
Diğer depolama sağlayıcıları, varsayılan Azure Depolama sağlayıcısı yerine yapılandırılabilir. Uygulamanız için yapılandırılan depolama sağlayıcısına bağlı olarak, temel alınan durumu incelemek için farklı araçlar kullanmanız gerekebilir. Daha fazla bilgi için Dayanıklı İşlevler Depolama Sağlayıcıları belgelerine bakın.
Dayanıklı İşlevler İzleyicisi
Dayanıklı İşlevler İzleyici, düzenleme ve varlık örneklerini izlemeye, yönetmeye ve hata ayıklamaya yönelik bir grafik aracıdır. Visual Studio Code uzantısı veya tek başına uygulama olarak kullanılabilir. Kurulum hakkındaki bilgileri ve özelliklerin listesini bu Wiki'de bulabilirsiniz.
Dayanıklı İşlevler sorun giderme kılavuzu
Düzenlemelerin takılması, başlatılamaması, yavaş çalışması vb. gibi yaygın sorun belirtilerini gidermek için bu sorun giderme kılavuzuna bakın.