Dela via

Tjänsteobservabilitet för Azure Arc-aktiverade Kubernetes

  • Artikel

Observerbarhet är en programeaktör som refererar till hur väl systemets interna tillstånd eller status kan förstås från dess externa utdata. Vi mäter datorsystem genom att observera CPU-tid, minne, diskutrymme, svarstid, fel och andra mått. Ju mer observerbart ett system är, desto enklare är det för oss att förstå vad det gör genom att titta på det.

Ett systems observerbarhet har en betydande inverkan på driftskostnaden. Observerbara system ger meningsfulla, användbara data till sina operatörer, vilket gör att de kan uppnå gynnsamma resultat och få mindre stilleståndstid. Mer information översätts inte nödvändigtvis till ett mer observerbart system. I själva verket kan ibland mängden information som genereras av ett system göra det svårare att identifiera värdefulla hälsosignaler från bruset som genereras av programmet.

Tjänstobservabilitet är viktigt eftersom det hjälper dig att förstå prestanda och problem i distribuerade system och molnsystem baserat på dynamiska arkitekturer.

Implementering av en lösning för att uppnå tjänsteobservabilitet kan hjälpa dig:

  • Se till att slutanvändarna kan använda ditt program och att företagets förväntningar uppfylls.
  • Förstå ett helt system och hur det fungerar tillsammans med en enda fönsterruta.
  • Upprätta en baslinje för systemet och förstå hur olika omständigheter påverkar systemets prestanda.
  • Generera åtgärdsobjekt från oväntade scenarier och beteenden.

Azure Arc-aktiverade Kubernetes innehåller två integrerade tilläggsalternativ som hjälper dig att uppnå tjänsteobservabilitet: Open Service Mesh och EN API Management-gateway med egen värd. De här alternativen beskrivs i detalj i följande avsnitt om designöverväganden.

Arkitektur

Följande diagram illustrerar de tre grundpelarna i Tjänsteobservabilitet med datavolympåverkan.

Ett diagram som visar pelare för tjänsteobservabilitet.

Följande diagram visar olika Open Service Mesh-komponenter som körs i ett Arc-aktiverat Kubernetes-kluster. Den visar också ett exempelprogram som är aktiverat i tjänstnätet, som konfigureras automatiskt med en Envoy-container på sidovagnen.

Ett diagram som visar Open Service Mesh som körs i Azure Arc-aktiverade Kubernetes.

Utformningsbeaktanden

De tre grundpelarna för observerbarhet är mått, loggar och spårningar. Införliva dem i din observerbarhetsstrategi för att göra systemet observerbart.

  • Mått är numeriska värden som beskriver någon aspekt av ett system vid en viss tidpunkt, och de samlas alltid in med jämna mellanrum.

Följande skärmbild visar en visualisering av ett exempel på HTTP-begärandemått för en tjänst. Måttet i det här exemplet visas som HTTP-begärandefrekvens per minut under en angiven tidsperiod.

En skärmbild som visar måttet för H T T P-begäran för en tjänst.

  • Loggar kan lagra olika datatyper som har egna strukturer. En logg innehåller information om transaktioner som gör att du kan få en mer fullständig berättelse för en viss händelse. Programloggar omfattar vanligtvis tidsstämplar, loggnivåer och all information som behövs för att förstå kontexten för en händelse. Loggar samlas in och skickas till en loggtjänst för lagring och analys.

  • Distribuerad spårning är en diagnostikteknik som hjälper användare att lokalisera fel och prestandaproblem i program, särskilt alla som distribueras över flera datorer eller processer. Den här tekniken spårar begäranden via ett program, korrelerar arbete som utförs av olika programkomponenter och separerar det från annat arbete som programmet kan utföra för samtidiga begäranden.

Följande skärmbild visar en visualisering av en transaktion från slutpunkt till slutpunkt med Application Insights. Det här visuella objektet ger enkel förståelse för svarstider, svarskoder och eventuella undantag som inträffar mellan begäranden i en transaktionskedja.

En skärmbild som visar transaktionsspårning från slutpunkt till slutpunkt.

De tre grundpelarna för mått, loggar och distribuerad spårning är sammankopplade. Mått lagras som numeriska värden i en tidsseriedatabas. De är också mycket mindre än loggar, vilket gör dem enklare att utvärdera och användbara för nästan realtidsaviseringar. Loggar samlar in och förmedlar mycket mer information än mått, vilket gör dem användbara för djupare felsökning. Spårningar är omfångsbegränsade och användbara för att få insyn i en begäran när den passerar olika komponenter i ett distribuerat system.

I följande tabell visas samlingspåverkan för de tre pelarna.

Samlingsegenskaper Mått Loggar Distribuerad spårning
Konton för varje transaktion Ja Ja Nej (samplad)
Immun mot kardinalitetsproblem Nej Ja Ja
Kostnad Låg Hög Låg

Det finns olika sätt att uppnå serviceobservabilitet. Du kan använda ett tjänstnät för att göra det på plattformsnivå, där ditt program är omedvetet och oförändrat. Du kan också instrumentera ett program med ett bibliotek, vilket vanligtvis görs med hjälp av ett APM-verktyg (Application Performance Monitoring) som Application Insights. API-gatewayer ger observerbarhet i trafik mellan nord och syd, men saknar observerbarhet i podden för poddkommunikation och enkel konfiguration i stor skala.

I följande avsnitt förklaras hur du kan använda ett tjänstnät och den lokalt installerade API Gateway som är tillgänglig för Azure Arc för att uppnå tjänsteobservabilitet.

Tjänstnät

Ett servicenät innehåller funktioner som trafikhantering, återhämtning, principframtvingande, transportsäkerhet, identitetssäkerhet och observerbarhet för dina arbetsbelastningar. Programmet är frikopplat från dessa driftfunktioner. Service Mesh flyttar dem från programskiktet och ned till infrastrukturlagret. Detta görs via en högpresterande proxy som förmedlar all inkommande och utgående trafik till din tjänst.

  • Azure Arc-aktiverade Kubernetes stöder Open Service Mesh (OSM), ett CNCF-projekt (Cloud Native Computing Foundation), som distribueras som ett tillägg. Open Service Mesh är ett enkelt, utökningsbart, molnbaserat tjänstnät som gör det möjligt för användare att hantera, skydda och få färdiga observerbarhetsfunktioner för mycket dynamiska mikrotjänstmiljöer.
  • Andra populära Service Meshes som kräver leverantörsstöd är Istio, Consul Anslut och Linkerd.
  • Beroende på vilka funktioner du använder när du implementerar ett tjänstnät kan du lägga extra ansvar på programoperatörer för att definiera en konfiguration för varje tjänst (till exempel åtkomstregler och registreringstjänster). Klusteroperatörer måste också hantera och vara medvetna om service mesh-kontrollanten. På grund av hur Service Mesh använder sidovagnsmönstret behövs åtkomstloggar från service mesh-kontrollplanet och sidovagnen vid felsökning av utgående och ingress.

Observerbarhet för servicenät

Observerbarhet är en viktig funktion bland de många som tjänstnät tillhandahåller. Välj ett Service Mesh som uppfyller dina minimikrav för observerbarhet så att du minskar mängden komplexitet och komponenter som tjänstnätet kan komma med och som måste konfigureras. Utvärdera följande vanliga funktioner och användningsfall av observerbarhet som tjänstnät tillhandahåller:

  • Måttgenerering, inklusive de fyra gyllene signalerna: svarstid, trafik, fel och mättnad.
  • RED-metoden (Rates-calls/sek, Errors, Duration-call latencies), som är en delmängd av de fyra gyllene signalerna och används för att mäta tjänster. Ditt servicenät bör vara ett standardiserat sätt att samla in RED-mått, spårningar osv.
  • Observerbarheten ökar, från att öka täckningens bredd till alla tjänster som ingår i ditt servicenät.
  • Funktioner som ökar implementeringen av observerbarheten genom att automatiskt instrumentera alla tjänster.
  • Stark integrering med pelare för tjänsteobservabilitet. Ditt servicenät bör kunna skrapa mått och samla in loggar som visas i din övervakningslösning. Se till att service mesh-telemetrisamlingen stöder dina affärsbehov och integreras väl med din befintliga övervakningslösning.

Följande diagram visar ett exempel på Service Mesh Proxy-funktionen för datainsamling och vidarebefordran.

Ett diagram som visar ett exempel på observerbarhet med en Service Mesh-proxy.

EGEN värdbaserad API-hanteringsgateway

Med integreringen mellan Azure API Management och Azure Arc på Kubernetes kan du distribuera API Management-gatewaykomponenten som ett tillägg i ditt Azure Arc-aktiverade Kubernetes-kluster. På så sätt kan en containerbaserad version av API Management-gatewayen köras i klustret. Alla gatewayer med egen värd hanteras från DEN API Management-tjänst som de är federerade med, vilket ger dig insyn och en enhetlig hanteringsupplevelse för alla interna och externa API:er.

Om du konfigurerar den lokalt installerade gatewayen för att acceptera inkommande trafik till direkt till dina tjänster måste du skapa en princip. Dess hantering kan bli mer komplex när tjänstskalan växer.

Mer information finns i översikten över lokalt installerad gateway

Api Management Med egen värd- och gatewayobservabilitet

Den lokalt installerade gatewayen genererar mått, stdout-loggar och stderr-loggar. Mått som genereras kan konfigureras av en ConfigMap i klustret. Information om avancerad övervakning med API Management finns i Avancerad övervakning.

Lokala gatewayobservabilitetskonton för extern trafik (nord-syd) som kommer in i klustret, men ger ingen observerbarhet för podd-till-pod-trafik i klustret (öst-väst).

Molnmått och loggar: Mått skickas som standard till Azure Monitor. Med Log Analytics kan du samla in och visa lokala gatewaycontainerloggar med hjälp av Azure Monitor för containrar. Mer information finns i Konfigurera lokala mått och loggar för en lokalt installerad Azure API Management-gateway.

Lokala mått och loggar: Mått och loggar från din lokala gateway kan integreras med ditt lokala övervakningsverktyg eller genereras av konfigurationskartan. Mått kan konfigureras för publicering till måttservrar. Gatewayloggar genereras som standard till stdout och stderr. Mer information finns i Konfigurera lokala mått och loggar för en lokalt installerad Azure API Management-gateway.

Jämförelsetabell för teknik

I följande tabell visas skillnader mellan implementeringsalternativ som hjälper dig att välja en metod för att hämta tjänsters observerbarhet.

Kapacitet Service Mesh Övervakning av programprestanda API Gateway med egen värd
Öst-västlig trafik stöds Ja Ja Nej
Måttfunktion Ja Ja Ja
Loggningsfunktion Ja Ja Anpassad implementering
Funktioner för distribuerade spårningar Ja Ja Ja
Implementeringslager Nätverk Program Nätverk
Protokoll som stöds HTTP(S), TCP, gRPC Ej tillämpligt HTTP(S), websockets
Konfigurationsansvar Klusteroperatorer Programutvecklare Programoperatorer och klusteroperatorer
Konfigurationskomplexitet för observerbarhet Låg Högt Medium

Designrekommendationer

Implementera Open Service Mesh för att få observerbarhet i hälsa och prestanda för dina tjänster. Open Service Mesh använder sidovagnsproxy som matas in som en separat container i samma poddar som dina arbetsbelastningar för att hämta telemetridata. Dessa proxyservrar fångar upp all inkommande och utgående HTTP-trafik till dina arbetsbelastningar och rapporterar data till Open Service Mesh. Med det här systemet behöver inte tjänstutvecklare instrumentera sin kod för att samla in telemetridata.

Aktivera Open Service Mesh med hjälp av den Azure Arc-aktiverade Kubernetes-klustertilläggsfunktionen, vilket gör att Microsoft kan hantera kontrollplanet åt dig. Mer information finns i Distribuera Azure Arc-aktiverat Open Service Mesh (förhandsversion).

Om du vill maximera tillgängligheten och prestandan för dina program och tjänster aktiverar du Azure Monitor Container Insights. Det ger en omfattande lösning för att samla in, analysera och agera på telemetri från dina molnmiljöer och lokala miljöer. Azure Arc-aktiverade Open Service Mesh integreras djupt med Azure Monitor, vilket ger dig en sömlös metod för att visa och svara på kritiska KPI:er som tillhandahålls av OSM-mått och programcontainerloggar. Du kan aktivera OSM-mått genom att följa dessa steg. För distribuerad spårning rekommenderar vi Jaeger, som kan integreras med ditt OSM-kontrollplan.

Open Service Mesh innehåller också dokumenterade observerbarhetsintegreringar för mått med Prometheus och Grafana, spårning med Jaeger och vidarebefordring av loggar med Fluent Bit. Dessa integreringar ger alternativa alternativ om du inte använder Azure-övervakningslösningar. Du kan använda dessa integreringar för att utöka till andra interna övervakningsverktyg efter behov.

Du bör minst definiera följande tre RED-mått och mäta dem för alla tjänster:

  • Begärandefrekvens: Antalet begäranden som tjänsten tar emot per sekund.
  • Fel: Antalet misslyckade begäranden eller antalet misslyckade begäranden per sekund.
  • Varaktighet: Hur lång tid det tar för en tjänst att hantera en begäran.

Open Service Mesh innehåller flera förkonfigurerade tjänstarbetsböcker i Azure Monitor så att du inte behöver konfigurera instrumentpaneler och diagram manuellt. Med den här detaljerade telemetrin kan du observera tjänstens beteende och ge dig möjlighet att felsöka, underhålla och optimera dina program. Med osm-övervakningsarbetsboken i Azure Monitor kan du:

  • Få en översikt över alla tjänster i ditt nät och få kritiska mått på servicenivå för tre av de fyra gyllene signalerna för övervakning: svarstid, begäranden och fel.
  • Definiera, granska och ange aviseringar mot servicenivåmål (SLO) som sammanfattar tjänstens användar synliga prestanda.
  • Visa måttdiagram för enskilda tjänster så att du kan analysera dem djupt med hjälp av filtrering och uppdelningar, sålla data efter svarskod, protokoll, målpodd, trafikkälla med mera.

Använd visualiseringar från Jaeger-användargränssnittet för att:

  • Observera en topologigrafvisualisering som visar vilka mikrotjänster som kommunicerar med varandra, vart begäranden går och hur lång tid de tar.
  • Kontrollera om det finns specifika begäranden och svar för att se hur och när de sker för övervakning och felsökning av distribuerade system.

Tjänsteobservabilitet är bara ett område i din molnövervakningsstrategi. Mer information om hanteringsområden finns i det kritiska designområdet för hanteringsområden.

Nästa steg

Mer information om din hybrid- och molnresa med flera moln finns i följande artiklar: