Ez a cikk az Azure Kubernetes Service-en (AKS) futó mikroszolgáltatási alkalmazások monitorozásának ajánlott eljárásait ismerteti. Konkrét témakörök a telemetriagyűjtés, a fürt állapotának monitorozása, a metrikák, a naplózás, a strukturált naplózás és az elosztott nyomkövetés. Az utóbbit az alábbi ábra szemlélteti:
Töltse le az architektúra Visio-fájlját.
Telemetriai gyűjtemény
Egy összetett alkalmazásban egy bizonyos ponton hiba történik. Egy mikroszolgáltatási alkalmazásban nyomon kell követnie, hogy mi történik több tucat vagy akár több száz szolgáltatásban. A történtek értelmezéséhez telemetriát kell gyűjtenie az alkalmazásból. A telemetriai adatok a következő kategóriákba sorolhatók: naplók, nyomkövetések és metrikák.
A naplók olyan események szöveges rekordjai , amelyek egy alkalmazás futtatása közben következnek be. Ilyenek például az alkalmazásnaplók (nyomkövetési utasítások) és a webkiszolgálói naplók. A naplók elsősorban a kriminalisztika és a kiváltó okok elemzéséhez hasznosak.
A nyomkövetések, más néven műveletek egyetlen kérés lépéseit kötik össze több híváson belül és a mikroszolgáltatásokban. Strukturált megfigyelhetőséget biztosítanak a rendszerösszetevők interakcióiban. A nyomkövetések a kérelem folyamatának korai szakaszában kezdődhetnek, például egy alkalmazás felhasználói felületén belül, és a kérést kezelő mikroszolgáltatások hálózatán keresztül terjeszthetők.
- A spanok egy nyomkövetésen belüli munkaegységek. Minden span egyetlen nyomkövetéssel van összekapcsolva, és más spanokkal is beágyazható. Ezek gyakran egy szolgáltatásközi művelet egyes kéréseinek felelnek meg, de a szolgáltatáson belüli egyes összetevőkben is meghatározhatják a munkát. Emellett az egyik szolgáltatásból a másikba irányuló kimenő hívásokat is nyomon követi. (A spanokat néha függőségi rekordoknak is nevezik.)
A metrikák elemezhető numerikus értékek. Segítségével valós időben (vagy közel valós időben) figyelheti meg a rendszert, vagy elemezheti a teljesítménybeli trendeket az idő függvényében. A rendszer holisztikus megértéséhez metrikákat kell gyűjtenie az architektúra különböző szintjein, a fizikai infrastruktúrától az alkalmazásig, beleértve a következőket:
Csomópontszintű metrikák, beleértve a PROCESSZOR, a memória, a hálózat, a lemez és a fájlrendszer használatát. A rendszermetrikák segítségével megismerheti a fürt minden csomópontjának erőforrás-lefoglalását, és elháríthatja a kiugró értékeket.
Tárolómetrikák . Tárolóalapú alkalmazások esetén a metrikákat nem csak a virtuális gép szintjén, hanem a tároló szintjén kell összegyűjtenie.
Alkalmazásmetrikák . Ezek a metrikák relevánsak a szolgáltatás viselkedésének megértéséhez. Ilyen például az üzenetsorba helyezett bejövő HTTP-kérések száma, a kérelmek késése és az üzenetsor hossza. Az alkalmazások a tartományra jellemző egyéni metrikákat is használhatnak, például a percenként feldolgozott üzleti tranzakciók számát.
Függő szolgáltatásmetrikák . A szolgáltatások néha külső szolgáltatásokat vagy végpontokat is meghívnak, például felügyelt PaaS- vagy SaaS-szolgáltatásokat. Előfordulhat, hogy a külső szolgáltatások nem biztosítanak metrikákat. Ha nem, saját alkalmazásmetrikákra kell támaszkodnia a késés és a hibaarány statisztikáinak nyomon követéséhez.
Fürt állapotának figyelése
Az Azure Monitor használatával monitorozza a fürtök állapotát. Az alábbi képernyőképen egy olyan fürt látható, amelynek kritikus hibái vannak a felhasználó által üzembe helyezett podokban:
Innen tovább részletezheti a problémát. Ha például a pod állapota, ImagePullBackoffa Kubernetes nem tudta lekérni a tárolórendszerképet a beállításjegyzékből. Ezt a problémát egy érvénytelen tárolócímke vagy hitelesítési hiba okozhatja a beállításjegyzékből való lekérés során.
Ha egy tároló összeomlik, a tároló State a következővel ReasonCrashLoopBackOffleszWaiting: Egy tipikus forgatókönyv esetében, amikor egy pod egy replikakészlet része, és az újrapróbálkozési szabályzat az Always, ez a probléma nem jelenik meg hibaként a fürt állapotában. Azonban lekérdezéseket futtathat, vagy riasztásokat állíthat be ehhez a feltételhez. További információ: Az AKS-fürt teljesítményének ismertetése az Azure Monitor Container Insights használatával.
Az AKS-erőforrás munkafüzetpaneljén több tárolóspecifikus munkafüzet is elérhető. Ezekkel a munkafüzetekkel gyors áttekintést, hibaelhárítást, felügyeletet és elemzéseket végezhet. Az alábbi képernyőképen az AKS-számítási feladatokhoz alapértelmezés szerint elérhető munkafüzetek listája látható.
Metrics
Javasoljuk, hogy a Monitor használatával gyűjtse össze és tekintse meg az AKS-fürtök és bármely más függő Azure-szolgáltatás mérőszámait.
Fürt- és tárolómetrikákhoz engedélyezze az Azure Monitor Container Insightst. Ha ez a funkció engedélyezve van, a Monitor a Kubernetes Metrics API-n keresztül gyűjti össze a vezérlők, csomópontok és tárolók memória- és processzormetrikáit. A Container Insightsból elérhető metrikákkal kapcsolatos további információkért lásd : Az AKS-fürt teljesítményének ismertetése az Azure Monitor Container Insights használatával.
Alkalmazásmetrikák gyűjtése az Application Elemzések használatával. Az alkalmazás Elemzések egy bővíthető alkalmazásteljesítmény-kezelési (APM-) szolgáltatás. A használatához telepítenie kell egy rendszerállapot-csomagot az alkalmazásban. Ez a csomag figyeli az alkalmazást, és telemetriai adatokat küld az Alkalmazás Elemzések. Telemetriai adatokat is lekérhet a gazdagépkörnyezetből. Ezután a rendszer elküldi az adatokat a Monitornak. Az alkalmazás Elemzések beépített korreláció- és függőségkövetést is biztosít. (Lásd: Elosztott nyomkövetés, a cikk későbbi részében.)
Az alkalmazás Elemzések a másodpercenkénti eseményekben mért maximális átviteli sebességgel rendelkezik, és szabályozza a telemetriát, ha az adatsebesség meghaladja a korlátot. További részletekért lásd az alkalmazás Elemzések korlátait. Hozzon létre különböző alkalmazáspéldányokat Elemzések minden környezethez, hogy a fejlesztői/tesztelési környezetek ne versenyezzenek a kvóta éles telemetriájával.
Egyetlen művelet számos telemetriai eseményt generálhat, így ha egy alkalmazás nagy mennyiségű forgalmat tapasztal, a telemetriai rögzítése valószínűleg szabályozva lesz. A probléma megoldásához mintavételezést végezhet a telemetriai forgalom csökkentése érdekében. A kompromisszum az, hogy a metrikák kevésbé pontosak lesznek, hacsak a rendszerezés nem támogatja az elő-aggregációt. Ebben az esetben kevesebb nyomkövetési minta lesz a hibaelhárításhoz, de a metrikák megőrzik a pontosságot. További információ: Mintavételezés az alkalmazás Elemzések. Az adatmennyiséget metrikák előzetes összesítésével is csökkentheti. Ez azt teszi lehetővé, hogy statisztikai értékeket számítsunk ki, például az átlagot és a szórást, és ezeket az értékeket a nyers telemetria helyett küldjük el. Ez a blogbejegyzés az Alkalmazás Elemzések nagy léptékű használatát ismerteti: Azure Monitoring and Analytics at Scale.
Ha az adatsebesség elég magas a szabályozás aktiválásához, és a mintavételezés vagy az összesítés nem elfogadható, érdemes lehet metrikákat exportálni egy idősoros adatbázisba, például az Azure Data Explorerbe, a Prometheusba vagy az InfluxDB-be, amely a fürtben fut.
Az Azure Data Explorer egy Azure-natív, nagy mértékben méretezhető adatfeltárási szolgáltatás napló- és telemetriaadatokhoz. Számos adatformátumot, gazdag lekérdezési nyelvet és kapcsolatokat támogat olyan népszerű eszközökben, mint a Jupyter Notebooks és a Grafana. Az Azure Data Explorer beépített összekötőkkel rendelkezik a napló- és metrikaadatok Azure Event Hubson keresztüli betöltéséhez. További információ: Betöltési és lekérdezésfigyelési adatok az Azure Data Explorerben.
Az InfluxDB egy leküldéses alapú rendszer. Az ügynöknek le kell küldenie a metrikákat. A TICK verem használatával beállíthatja a Kubernetes monitorozását. Ezután leküldheti a metrikákat az InfluxDB-be a Telegraf használatával, amely a metrikák gyűjtésére és jelentésére szolgáló ügynök. Az InfluxDB-t szabálytalan eseményekhez és sztring adattípusokhoz használhatja.
A Prometheus egy pull-alapú rendszer. Rendszeresen lekaparja a metrikákat a konfigurált helyekről. A Prometheus lekaparhatja az Azure Monitor vagy a kube-state metrikák által létrehozott metrikákat. A kube-state-metrics egy olyan szolgáltatás, amely metrikákat gyűjt a Kubernetes API-kiszolgálóról, és elérhetővé teszi őket a Prometheus számára (vagy egy Prometheus-ügyfélvégponttal kompatibilis kaparó). Rendszermetrikákhoz használja a csomópontexportálót, amely a Rendszermetrikák Prometheus-exportőre. A Prometheus támogatja a lebegőpontos adatokat, sztringadatokat azonban nem, ezért rendszermetrikákhoz, naplókhoz nem. A Kubernetes Metrics Server az erőforrás-használati adatok fürtszintű összesítője.
Naplózás
Íme néhány, a mikroszolgáltatás-alkalmazásokban való naplózás általános kihívásai:
- Az ügyfélkérések végpontok közötti feldolgozásának ismertetése, ahol több szolgáltatás is meghívható egyetlen kérés kezeléséhez.
- Naplók összevonása több szolgáltatásból egyetlen összesített nézetbe.
- Több forrásból származó naplók elemzése, amelyek saját naplózási sémákat használnak, vagy amelyek nem rendelkeznek adott sémával. A naplókat olyan külső összetevők hozhatják létre, amelyeket ön nem szabályoz.
- A mikroszolgáltatás-architektúrák gyakran nagyobb mennyiségű naplót hoznak létre, mint a hagyományos monolitok, mivel a tranzakciókban több szolgáltatás, hálózati hívás és lépés található. Ez azt jelenti, hogy maga a naplózás teljesítménybeli vagy erőforrás-szűk keresztmetszet lehet az alkalmazás számára.
A Kubernetes-alapú architektúrák esetében további kihívások merülnek fel:
- A tárolók mozoghatnak és ütemezhetők újra.
- A Kubernetes egy hálózati absztrakcióval rendelkezik, amely virtuális IP-címeket és portleképezéseket használ.
A Kubernetesben a naplózás szokásos módszere, hogy egy tároló naplókat ír az stdout és a stderr fájlba. A tárolómotor átirányítja ezeket a streameket egy naplózási illesztőprogramba. A lekérdezés megkönnyítése és a naplóadatok esetleges elvesztésének megakadályozása érdekében, ha a csomópontok nem válaszolnak, a szokásos módszer a naplók összegyűjtése az egyes csomópontokról, és egy központi tárolóhelyre elküldeni őket.
Az Azure Monitor az AKS-sel integrálva támogatja ezt a megközelítést. A Monitor összegyűjti a tárolónaplókat, és elküldi őket egy Log Analytics-munkaterületre. Innen a Kusto lekérdezésnyelv használatával lekérdezéseket írhat az összesített naplókba. Íme például egy Kusto-lekérdezés egy adott pod tárolónaplóinak megjelenítéséhez:
ContainerLogV2
| where PodName == "podName" //update with target pod
| project TimeGenerated, Computer, ContainerId, LogMessage, LogSource
Az Azure Monitor egy felügyelt szolgáltatás, és az AKS-fürtök monitorozásra való konfigurálása egyszerű konfigurációmódosítás a CLI-ben vagy az Azure Resource Manager-sablonban. (További információ: Az Azure Monitor Container Insights engedélyezése.) Az Azure Monitor használatának másik előnye, hogy összevonja az AKS-naplókat más Azure-platformnaplókkal, hogy egységes monitorozási élményt nyújtson.
Az Azure Monitor gigabájtonként (GB) számlázva van a szolgáltatásba betöltött adatokból. (Lásd: Azure Monitor díjszabása.) Nagy mennyiségben a költségek megfontolandók lehetnek. A Kubernetes-ökoszisztémához számos nyílt forráskódú alternatíva érhető el. Sok szervezet például a Fluentdet használja az Elasticsearch használatával. A Fluentd egy nyílt forráskódú adatgyűjtő, az Elasticsearch pedig egy keresésre használt dokumentumadatbázis. Ezekkel a beállításokkal az a kihívás, hogy a fürt további konfigurálását és felügyeletét igénylik. Éles számítási feladatok esetén előfordulhat, hogy kísérleteznie kell a konfigurációs beállításokkal. A naplózási infrastruktúra teljesítményét is figyelnie kell.
OpenTelemetry
Az OpenTelemetria iparágközi törekvés a nyomkövetés javítására az alkalmazások, kódtárak, telemetria és adatgyűjtők közötti interfész szabványosításával. Az OpenTelemetryvel létrehozott kódtárak és keretrendszerek használata esetén a hagyományosan rendszerműveletnek számító nyomkövetési műveletek többségét az alapul szolgáló kódtárak kezelik, amelyek a következő gyakori forgatókönyveket tartalmazzák:
- Alapszintű kérelemműveletek naplózása, például kezdési időpont, kilépési idő és időtartam
- Kidobott kivételek
- Környezet propagálása (például korrelációs azonosító küldése HTTP-híváshatárokon keresztül)
Ehelyett az ezeket a műveleteket kezelő alapkódtárak és keretrendszerek gazdag, egymáshoz kapcsolódó span- és nyomkövetési adatstruktúrákat hoznak létre, és a környezetek között propagálják őket. Az OpenTelemetria előtt ezeket általában csak speciális naplóüzenetekként vagy védett adatstruktúrákként adták be, amelyek a monitorozási eszközöket létrehozó szállítóra vonatkoztak. Az OpenTelemetria a hagyományos naplózási első megközelítésnél gazdagabb rendszerállapot-adatmodellt is ösztönöz, a naplók pedig hasznosabbak, mivel a naplóüzenetek a létrehozásuk helyéhez kapcsolódó nyomkövetésekhez és időtartamokhoz kapcsolódnak. Ez gyakran megkönnyíti egy adott művelethez vagy kéréshez társított naplók keresését.
Az Azure SDK-k közül sok már openTelemetria-alapú, vagy már folyamatban van annak implementálása.
Az alkalmazásfejlesztők az OpenTelemetry SDK-k használatával adhatnak hozzá manuális kialakítást a következő tevékenységek végrehajtásához:
- Olyan rendszerállapot hozzáadása, amelyben egy mögöttes kódtár nem biztosítja azt.
- Bővítse a nyomkövetési környezetet az alkalmazásspecifikus munkaegységek elérhetővé tételéhez (például egy rendelési ciklushoz, amely az egyes rendeléssorok feldolgozásához létrehoz egy időtartamot).
- A könnyebb nyomkövetés érdekében bővítse a meglévő spanokat entitáskulcsokkal. (Például adjon hozzá egy OrderID-kulcsot/értéket a rendelést feldolgozó kérelemhez.) Ezeket a kulcsokat a monitorozási eszközök strukturált értékekként jelennek meg a lekérdezéshez, szűréshez és összesítéshez (a naplóüzenet-sztringek elemzése és a naplóüzenet-sorozatok kombinációinak keresése nélkül, ahogyan az a naplózási első megközelítésben is előfordult).
- A nyomkövetési környezet propagálása nyomkövetési és span attribútumok elérésével, a traceId-ek válaszokba és hasznos adatokba való injektálásával, valamint a bejövő üzenetekből származó traceId-ek olvasásával, kérések és spanok létrehozása érdekében.
A rendszerállapotról és az OpenTelemetria SDK-járól az OpenTelemetry dokumentációjában olvashat bővebben.
Application Insights
Az alkalmazás Elemzések gazdag adatokat gyűjt az OpenTelemetryből és annak rendszerállapot-kódtáraiból, és egy hatékony adattárban rögzíti azokat, hogy gazdag vizualizációs és lekérdezési támogatást nyújtson. Az alkalmazás Elemzések OpenTelemetry-alapú eszközkódtárak, például a .NET, a Java, a Node.js és a Python nyelvhez, megkönnyítik a telemetriai adatok küldését az Alkalmazás Elemzések.
Ha .NET Core-t használ, javasoljuk, hogy vegye figyelembe a Kubernetes-kódtár alkalmazás Elemzések is. Ez a kódtár további információkkal bővíti az alkalmazás Elemzések nyomkövetéseit, például a tárolót, a csomópontot, a podot, a címkéket és a replikakészletet.
Az alkalmazás Elemzések leképezheti az OpenTelemetry-környezetet a belső adatmodellre:
- Nyomkövetés –> Művelet
- Nyomkövetési azonosító –> Műveletazonosító
- Span –> Kérelem vagy függőség
Vegye figyelembe a következő szempontokat:
- Az alkalmazás Elemzések szabályozza a telemetriát, ha az adatsebesség meghaladja a maximális korlátot. További részletekért lásd az alkalmazás Elemzések korlátait. Egyetlen művelet több telemetriaeseményt is létrehozhat, így ha egy alkalmazás nagy mennyiségű forgalmat tapasztal, valószínűleg szabályozva lesz.
- Mivel az alkalmazás Elemzések kötegeket kötegel, a kötegek elveszhetnek, ha egy folyamat kezeletlen kivétellel meghiúsul.
- Az alkalmazás Elemzések számlázása az adatmennyiségen alapul. További információ: Díjszabás és adatmennyiség kezelése az Alkalmazás Elemzések.
Strukturált naplózás
A naplók elemzésének megkönnyítése érdekében szükség esetén használjon strukturált naplózást. Strukturált naplózás használata esetén az alkalmazás strukturált formátumban, például JSON formátumban írja a naplókat a strukturálatlan szöveges sztringek kimenete helyett. Számos strukturált naplózási kódtár érhető el. Íme például egy naplózási utasítás, amely a Serilog könyvtárat használja a .NET Core-hoz:
public async Task<IActionResult> Put([FromBody]Delivery delivery, string id)
{
logger.LogInformation("In Put action with delivery {Id}: {@DeliveryInfo}", id, delivery.ToLogInfo());
...
}
Itt a meghívás LogInformation egy paramétert és DeliveryInfo paramétert Id tartalmaz. Strukturált naplózás használatakor ezek az értékek nem lesznek interpolálva az üzenetsztringbe. Ehelyett a naplókimenet a következőképpen néz ki:
{"@t":"2019-06-13T00:57:09.9932697Z","@mt":"In Put action with delivery {Id}: {@DeliveryInfo}","Id":"36585f2d-c1fa-4a3d-9e06-a7f40b7d04ef","DeliveryInfo":{...
Ez egy JSON-sztring, ahol a @t mező időbélyeg, @mt az üzenet sztringje, a többi kulcs/érték pár pedig a paraméterek. A JSON formátum kimenete megkönnyíti az adatok strukturált lekérdezését. A kusto lekérdezési nyelven írt alábbi Log Analytics-lekérdezés például az adott üzenet példányait keresi az összes nevesített fabrikam-deliverytárolóból:
traces
| where customDimensions.["Kubernetes.Container.Name"] == "fabrikam-delivery"
| where customDimensions.["{OriginalFormat}"] == "In Put action with delivery {Id}: {@DeliveryInfo}"
| project message, customDimensions["Id"], customDimensions["@DeliveryInfo"]
Ha az eredményt az Azure Portalon tekinti meg, láthatja, hogy DeliveryInfo ez egy strukturált rekord, amely a modell szerializált ábrázolását DeliveryInfo tartalmazza:
Íme a példa JSON-ja:
{
"Id": "36585f2d-c1fa-4a3d-9e06-a7f40b7d04ef",
"Owner": {
"UserId": "user id for logging",
"AccountId": "52dadf0c-0067-43e7-af76-86e32b48bc5e"
},
"Pickup": {
"Altitude": 0.29295161612934972,
"Latitude": 0.26815900219052985,
"Longitude": 0.79841844309047727
},
"Dropoff": {
"Altitude": 0.31507750848078986,
"Latitude": 0.753494655598651,
"Longitude": 0.89352830773849423
},
"Deadline": "string",
"Expedited": true,
"ConfirmationRequired": 0,
"DroneId": "AssignedDroneId01ba4d0b-c01a-4369-ba75-51bde0e76cc9"
}
Számos naplóüzenet jelzi egy munkaegység kezdetét vagy végét, vagy egy üzleti entitást üzenetek és műveletek készletével kapcsol össze a nyomon követhetőség érdekében. Az OpenTelemetry-tartomány és a kérelemobjektumok bővítése sok esetben jobb módszer, mint a művelet kezdetének és befejezésének naplózása. Ezzel hozzáadja ezt a kontextust az összes csatlakoztatott nyomkövetési és gyermekművelethez, és ezt az információt a teljes művelet hatókörébe helyezi. A különböző nyelvek OpenTelemetria SDK-jai támogatják a spanok létrehozását vagy egyéni attribútumok hozzáadását a spanokon. Az alábbi kód például a Java OpenTelemetry SDK-t használja, amelyet az Alkalmazás Elemzések támogat. A meglévő fölérendeltség (például egy REST-vezérlő hívásához társított és a használt webes keretrendszer által létrehozott kéréstartomány) bővíthető a hozzá társított entitásazonosítóval, ahogyan az itt látható:
import io.opentelemetry.api.trace.Span;
// ...
Span.current().setAttribute("A1234", deliveryId);
Ez a kód beállít egy kulcsot vagy értéket az aktuális tartományon, amely az adott időtartam alatt előforduló műveletekhez és naplóüzenetekhez kapcsolódik. Az érték az Alkalmazás Elemzések kérelemobjektumban jelenik meg, az itt látható módon:
requests
| extend deliveryId = tostring(customDimensions.deliveryId) // promote to column value (optional)
| where deliveryId == "A1234"
| project timestamp, name, url, success, resultCode, duration, operation_Id, deliveryId
Ez a technika akkor válik hatékonyabbá, ha naplókkal, szűréssel és széljegyzetekkel használja a naplókövetéseket a span környezettel, ahogy az itt látható:
requests
| extend deliveryId = tostring(customDimensions.deliveryId) // promote to column value (optional)
| where deliveryId == "A1234"
| project deliveryId, operation_Id, requestTimestamp = timestamp, requestDuration = duration // keep some request info
| join kind=inner traces on operation_Id // join logs only for this deliveryId
| project requestTimestamp, requestDuration, logTimestamp = timestamp, deliveryId, message
Ha olyan kódtárat vagy keretrendszert használ, amely már az OpenTelemetryvel van kialakítva, az kezeli a spanok és a kérések létrehozását, de az alkalmazáskód munkaegységeket is létrehozhat. Például egy olyan metódus, amely az egyes entitásokon munkát végző entitások tömbjén keresztül hurkol, a feldolgozási ciklus egyes iterációihoz egy-egy időtartamot hozhat létre. A rendszerállapot alkalmazáshoz és kódtárkódhoz való hozzáadásáról az OpenTelemery rendszerállapot dokumentációjában talál további információt.
Elosztott nyomkövetés
A mikroszolgáltatások használatakor az egyik kihívás az események szolgáltatások közötti áramlásának megértése. Egyetlen tranzakció több szolgáltatás hívását is magában foglalhatja.
Példa az elosztott nyomkövetésre
Ez a példa egy elosztott tranzakció útvonalát ismerteti mikroszolgáltatások halmazán keresztül. A példa egy drónkézbesítési alkalmazáson alapul.
Ebben a forgatókönyvben az elosztott tranzakció a következő lépéseket tartalmazza:
- A Betöltési szolgáltatás üzenetet helyez el egy Azure Service Bus-üzenetsoron.
- A Munkafolyamat szolgáltatás lekéri az üzenetet az üzenetsorból.
- A Munkafolyamat szolgáltatás három háttérszolgáltatást hív meg a kérés feldolgozásához (Drone Scheduler, Package és Delivery).
Az alábbi képernyőképen a drónkézbesítési alkalmazás alkalmazástérképe látható. Ez a térkép a nyilvános API-végpontra irányuló hívásokat jeleníti meg, amelyek öt mikroszolgáltatást tartalmazó munkafolyamatot eredményeznek.
A Service Bus-üzenetsorból fabrikam-workflow és fabrikam-ingestion az üzenetsorba mutató nyilak jelzik az üzenetek küldésének és fogadásának helyét. A diagramból nem állapítható meg, hogy melyik szolgáltatás küld üzeneteket, és melyiket fogadja. A nyilak csak azt mutatják, hogy mindkét szolgáltatás a Service Bust hívja. Az alábbiakban azonban az alábbi információk érhetők el arról, hogy melyik szolgáltatást küldi és melyiket fogadja:
Mivel minden hívás tartalmaz egy műveletazonosítót, egyetlen tranzakció végpontok közötti lépéseit is megtekintheti, beleértve az időzítési információkat és a HTTP-hívásokat minden lépésnél. Íme egy ilyen tranzakció vizualizációja:
Ez a vizualizáció a betöltési szolgáltatástól az üzenetsorig, az üzenetsortól a Munkafolyamat szolgáltatásig, a Munkafolyamat szolgáltatástól a többi háttérszolgáltatásig végigvezeti a lépéseket. Az utolsó lépés a Munkafolyamat szolgáltatás, amely befejezettként jelöli meg a Service Bus-üzenetet.
Ez a példa egy sikertelen háttérszolgáltatás hívásait mutatja be:
Ez a térkép azt mutatja, hogy a Drone Scheduler szolgáltatásba irányuló hívások nagy része (36%) meghiúsult a lekérdezés során. A végpontok közötti tranzakciónézetből kiderül, hogy kivétel történik, ha HTTP PUT-kérést küldenek a szolgáltatásnak:
Ha tovább részletez, láthatja, hogy a kivétel szoftvercsatorna-kivétel: "Nincs ilyen eszköz vagy cím."
Fabrikam.Workflow.Service.Services.BackendServiceCallFailedException:
No such device or address
---u003e System.Net.Http.HttpRequestException: No such device or address
---u003e System.Net.Sockets.SocketException: No such device or address
Ez a kivétel arra utal, hogy a háttérszolgáltatás nem érhető el. Ezen a ponton a kubectl használatával tekintheti meg az üzembehelyezési konfigurációt. Ebben a példában a szolgáltatás gazdagépének neve nem oldható fel a Kubernetes konfigurációs fájljaiban lévő hiba miatt. A Kubernetes dokumentációjában található Hibakeresési szolgáltatások című cikkben talál tippeket az ilyen típusú hibák diagnosztizálásához.
Az alábbiakban néhány gyakori hibalehetőséget talál:
- Kódhibák. Ezek a hibák a következőképpen jelenhetnek meg:
- Kivételek. A kivétel részleteinek megtekintéséhez tekintse meg az Alkalmazás Elemzések naplóit.
- Egy folyamat meghiúsul. Tekintse meg a tároló és a pod állapotát, és tekintse meg a tárolónaplókat vagy az alkalmazás Elemzések nyomkövetéseket.
- HTTP 5xx hibák.
- Erőforrás-kimerülés:
- A szabályozást (HTTP 429) vagy a kérelmek időtúllépését keresi.
- Vizsgálja meg a processzor, a memória és a lemez tárolómetrikáit.
- Tekintse meg a tároló- és poderőforrás-korlátok konfigurációit.
- Szolgáltatásfelderítés. Vizsgálja meg a Kubernetes-szolgáltatás konfigurációját és portleképezéseit.
- API-eltérés. Keresse meg a HTTP 400-hibákat. Ha az API-k verziószámozottak, tekintse meg a hívott verziót.
- Hiba történt egy tárolórendszerkép lekérése közben. Nézze meg a pod specifikációját. Győződjön meg arról is, hogy a fürt jogosult lekérni a tárolóregisztrációs adatbázisból.
- RBAC-problémák.
Következő lépések
További információ az Azure Monitor azon funkcióiról, amelyek támogatják az alkalmazások monitorozását az AKS-en:
- Az Azure Monitor container insights áttekintése
- Az AKS-fürt teljesítményének megismerése az Azure Monitor Container Insights használatával