Dela via


Överväganden för drifthantering för AIS Services-landningszonacceleratorn

Den här artikeln innehåller överväganden och rekommendationer för drifthantering och övervakning när du använder AIS-erbjudandena.

De flesta rekommendationerna i det här avsnittet gäller standardversionen (en klient) av Logic Apps, som i sig är en del av Azure App Service erbjudande och delar många av samma hanteringsfunktioner.

Många resurser som utgör AIS kan konfigureras för att lagra logg-, telemetri- och måttdata i Log Analytics/Application Insights eller på anpassade lagringsplatser (dessa resurser omfattar lagringskonton, händelsehubbar och andra).

Vi kan använda den här informationen för att visualisera den övergripande hälsan för våra resurser och vidta lämpliga hanteringsåtgärder.

Definitioner

  • Azure Monitor-loggar samlar in och organiserar logg- och prestandadata från övervakade resurser. Verktyg som Log Analytics kan sedan fråga eller visualisera den här logginformationen, eller låta dig avisera om vissa villkor uppfylls.

  • Azure Metric Logs samlar in numeriska data i en tidsseriedatabas från övervakade resurser. Verktyg som Application Insights kan sedan visualisera dessa data, hjälpa dig att identifiera prestanda- och körningsproblem.

  • Log Analytics är ett Azure Monitoring-erbjudande som tillhandahåller en plats för att lagra logg- och prestandadata, ger en mekanism och ett språk för att fråga dessa loggar (Kusto); och ger möjlighet att skapa aviseringar och instrumentpaneler baserat på dessa loggar (bland andra funktioner).

  • Application Insights är ett Azure Monitoring-erbjudande som ger möjlighet att visualisera och avisera om prestandadata som genereras av övervakade resurser.

  • Kusto-frågespråk (KQL) är ett kraftfullt frågespråk som är optimerat för fråge- och formateringsdata. Det är till exempel det primära frågespråket för Log Analytics.

Designanmärkningar

  • Överväg din övervakningslösning som helhet:

    • Vilka resurser behöver du övervaka?

    • Hur spårar du meddelanden som flödar mellan resurser?

    • Vilka externa system kommer du att ansluta till?

    • Vilka typer av aviseringar behöver du?

  • Tänk på vilka frågor du behöver köra. Behöver du till exempel veta om en viss begäran tar längre tid än förväntat? Eller om du får ett enda fel jämfört med ett kluster med fel?

  • Vilken spårningsnivå behöver du? Om ett meddelande till exempel kommer från en tredje part, behöver du spåra meddelandet via alla associerade resurser?

  • Vilka hanteringsuppgifter behöver du utföra? Behöver du skicka meddelanden eller filer igen?

  • Logikappens körningshistorik lagras som standard i Azure Storage, men du kan välja att även exportera mått och loggfiler till andra källor (till exempel Log Analytics eller ett externt lagringskonto). Överväg hur du använder loggningsinformationen och om du använder ett centraliserat loggarkiv.

  • Application Insights används för att tillhandahålla övervakning av programprestanda. Det gör den genom att samla in mått från de resurser som utgör din lösning.

  • Log Analytics används för att fråga loggar och konfigurera aviseringar, så att du kan se hälsotillståndet för dina resurser och förstå problem som kan uppstå. Loggdata kan innehålla anpassade egenskaper (se Spårade egenskaper nedan).

  • Mer information och rekommendationer som är specifika för App Services finns i artikeln App Service acceleratorhantering för landningszoner

Designrekommendationer

  • Konfigurera Application Insights så att den använder en Log Analytics-arbetsyta som datakälla (kallas för en arbetsytebaserad resurs). På så sätt kan loggnings- och prestandadata sparas på en konsoliderad plats.

  • Konfigurera aviseringar för alla resurser för att meddela lämpliga team om händelser relaterade till enskilda resurser eller till arbetsbelastningen.

  • Länka resurserna i din lösning till Application Insights, om det stöds. En logikapp kan till exempel länkas till Application Insights, så att körningsdata och mått är tillgängliga för frågor. Se här för ett exempel.

  • Använd funktionen clientTrackingId i Logic Apps för att ange ett anpassat spårnings-ID, så att du kan korrelera händelser mellan logikappkörningar. Du kan använda huvudet x-ms-client-tracking-id för att uppnå det här resultatet med utlösare för begäran, HTTP eller HTTP+WebHook.

  • Använd funktionen Spårade egenskaper i Logic Apps för att logga andra data (indata eller utdata) från en åtgärd i loggfilerna. Dessa egenskaper är sedan tillgängliga för användning vid frågor mot loggar med hjälp av KQL med Log Analytics eller någon annan lösning.

  • Överväg att använda resurstaggar. Resurstaggar kan hjälpa dig att hantera och organisera resurser i Azure. Du kan använda dem för att tilldela metadata till resurser. Du kan använda dessa metadata för olika syften, till exempel kategorisera resurser efter program eller affärsenhet, spåra kostnaden för resurser och identifiera resurser för efterlevnad.

Kusto-exempelfrågor

Frågorna nedan visar hur du frågar efter de tre huvudtabellerna som används för AIS-loggdata. Var och en av dessa tabeller kan nås från alternativet Loggar i avsnittet Övervakning i logikappen.

Huvudfrågetabellerna är:

  • Undantag
    Den här tabellen innehåller undantag som loggas av resursen, till exempel undantag som genereras av Logic App-körningen. Den kan användas för att leta efter den underliggande orsaken till eventuella problem som du ser, antingen i portalen eller under körningen av koden.

  • begäran
    Den här tabellen loggar alla begäranden som görs av Logic App-körningen till en annan resurs ELLER till specifika åtgärder i arbetsflödet.

  • Spår
    Den här tabellen innehåller huvuddelen av Logic Apps-körningsloggar, loggningsinformation om utlösarkörning, arbetsflödesstart och stopp samt åtgärdskörning. Om du har loggat spårade egenskaper från dina åtgärder hittar du dessa data i avsnittet customDimensions . Du kan sedan använda extend-satsen i en fråga för att lägga till data som kolumner i frågesvaret.

Arbetsflöden med fel:

> traces
>
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
>
> \| where customDimensions.LogLevel == "Error"

Antal arbetsflödeskörningar under de senaste 24 timmarna i alla arbetsflöden:

> traces
>
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
>
> \| where customDimensions\["EventName"\] == "WorkflowActionStart"
>
> \| where timestamp \> ago(1d)
>
> \| count

Framgångsfrekvens för utlösare, diagram över tid

> traces  
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"  
> \| where customDimensions\["EventName"\] == "WorkflowTriggerEnd"  
> \|summarize
>
> success = countif(customDimensions\["prop\_\_status"\] ==
> "Succeeded"),
>
> failures = countif(customDimensions\["prop\_\_status"\] == "Failed")
>
> by bin(timestamp, 1m)  
> \| render timechart

Nästa steg

Granska de kritiska designområdena för att göra fullständiga överväganden och rekommendationer för din arkitektur.