Ajánlott eljárások: Azure Copilot megfigyelhetőségi ügynök (előzetes verzió)

Az Azure Monitor problémái és vizsgálatai az Azure Copilot megfigyelhetőségi ügynökével elemzik az Application Insights telemetriáját, és azonosítják a problémák lehetséges okait az alkalmazásokban és az infrastruktúrában.

A vizsgálat pontossága attól függ, hogy az alkalmazás teljes telemetriát bocsát-e ki, megőrzi-e a korrelációs mezőket, és elegendő szolgáltatási és erőforrás-környezetet tartalmaz-e.

Ez a cikk az Application Insights és az Azure Monitor OpenTelemetry telemetriai adatainak konfigurálásához ajánlott eljárásokat ismerteti. Ezeknek az ajánlott eljárásoknak a követésével az Azure Copilot megfigyelhetőségi ügynöke segít biztosítani a vizsgálatok pontos, megfelelő hatókörű és végrehajthatóságát.

Útmutató használata

Alkalmazza az eljárásokat ebben a sorrendben:

  1. A szükséges telemetriajelek összegyűjtése
  2. Szolgáltatás- és erőforrás-környezet hozzáadása
  3. Kövesse a biztonságos telemetriai tervezési szabályokat
  4. Valósítsa meg a kritikus fontosságú munkafolyamatokat és működési változásokat

A későbbi eljárások a korábbiaktól függenek. Az előfeltételek kihagyása csökkenti a vizsgálati lefedettséget és a pontosságot.

1. fázis: A szükséges telemetriai jelek összegyűjtése

Ezek a gyakorlatok szükségesek ahhoz, hogy a vizsgálatok megfelelően működjenek.

Kérelmek, függőségek és kivételek rögzítése

Győződjön meg arról, hogy a következő telemetriai típusok vannak összegyűjtve és láthatók az Application Insightsban:

  • Kérelmek – A legtöbb Application Insights SDK, például ASP.NET és ASP.NET Core automatikusan gyűjti a bejövő HTTP-kéréseket. A kérelemtelemetria magában foglalja az időtartamot, a válaszkódot, a sikert vagy a hibát, valamint a műveletkörnyezetet, amely a vizsgálatok fő belépési pontja.

  • Függőségek – A külső szolgáltatásokhoz, például HTTP-végpontokhoz, SQL-adatbázisokhoz és tárfiókokhoz érkező kimenő hívásokat kell gyűjtenie függőségi telemetriaként. A legtöbb SDK automatikusan észleli a gyakori függőségeket, amikor engedélyezi a függőségkövetési modulokat. Olyan környezetekben, ahol a függőségeket nem gyűjti össze automatikusan (például néhány Python-számítási feladatot), kövesse nyomon manuálisan egy telemetriai ügyfél API használatával. Használhatja például track_dependency Pythonban vagy TrackDependency .NET-ben.

  • Kivételek – A legtöbb konfiguráció automatikusan gyűjti a kezeletlen kivételeket. Ha az alkalmazás kivételeket kezel, a kivételkövetési API meghívásával (például TrackException) naplózza őket kifejezetten, vagy a naplózás után újradobja őket.

A megfigyelhetőségi ügynök a leggyakoribb sikertelen eseményeket elemzi a kérések, függőségek és kivételek között. Ha ezek közül a telemetriatípusok közül bármelyik hiányzik, a vizsgálati eredmények hiányosak lehetnek.

Diagnosztikai naplók engedélyezése az összes erőforráson

A megfigyelhetőségi ügynök támogatja az erőforrásnaplók vizsgálatát bármely erőforrás esetében. Alapértelmezés szerint azonban nem gyűjt erőforrásnaplókat. Az átfogó láthatóság érdekében engedélyezze a diagnosztikai naplókat az összes erőforráson. Ez a láthatóság a következőket tartalmazza:

  • Vezérlősík műveletei
  • Adatsík kérelmek
  • Hibák, szabályozás és egyéb hibaelhárítási jelek

További információ: Diagnosztikai beállítások az Azure Monitorban.

Kezeletlen kivételek terjedésének engedélyezése

Ne nyomja el a kivételeket naplózás nélkül.

Az alábbiak közül az egyik feltételnek meg kell felelniük a kivételeknek:

  • Terjesztés az Application Insights SDK-ba vagy az OpenTelemetry adatfolyamatba, vagy
  • A kivételkövetési API meghívásával explicit módon nyomon követhető

A nem rögzített kivételeket a megfigyelhetőségi ügynök nem figyeli meg, és nem szerepel a vizsgálatokban. Ha globális vagy központosított hibakezelést használ, a kezelés előtt győződjön meg arról, hogy a kivételek naplózása történik.

Az Application Insights SDK vagy az OpenTelemetry legújabb disztribúciójának használata

Használja a legújabb támogatott Application Insights SDK - vagy Azure Monitor OpenTelemetry-disztribúciót.

Az újabb verziók a következőt biztosítják:

  • A vizsgálatok által használt legújabb telemetriai sémák támogatása
  • Továbbfejlesztett automatikus függőség és környezetgyűjtemény
  • Teljesítmény- és helyességi javítások

Új alkalmazások esetén használja az OpenTelemetry-alapú instrumentációt. A régebbi SDK-verziók elavult modellek vagy nem hatékony gyűjtési módszerek használatával telemetriát bocsáthatnak ki.

2. fázis: Szolgáltatás- és erőforrás-környezet hozzáadása

A szolgáltatás- és erőforrás-környezet lehetővé teszi, hogy a megfigyelhetőségi ügynök meghatározza, honnan erednek a problémák, és automatikusan hatókörbe helyezi a kapcsolódó összetevőket.

Felhőbeli szerepkör nevének beállítása az egyes szolgáltatásokhoz

Adjon hozzá egy értelmezhető felhőbeli szerepkörnevet az egyes mikroszolgáltatásokhoz, API-khoz, feldolgozókhoz vagy függvényekhez.

A felhőbeli szerepkörnevek azonosítják a telemetria logikai forrását, és megjelennek az Alkalmazástérkép és a vizsgálati eredmények között. Az SDK-k alapértelmezés szerint a szerelvény vagy szolgáltatás metaadataiból származtathatják a szerepkörneveket. Felülbírálja ezeket az alapértelmezett értékeket az architektúrát tükröző és következetesen alkalmazott névvel. A konfiguráció különböző nyelveken való beállításáról további információt a felhőbeli szerepkör nevének és a felhőbeli szerepkörpéldánynak a beállítása című témakörben talál.

Erőforrás-környezet belefoglalása az automatikus átmásoláshoz

Adjon meg azonosítókat az Azure-hoz és az alkalmazás által használt külső erőforrásokhoz.

A függőségi telemetria általában automatikusan rögzíti a célvégpontokat, például az adatbázisneveket vagy a szolgáltatás URL-címeit. Győződjön meg arról, hogy az Application Insights függőségkövetése engedélyezve van, hogy ezek az adatok elérhetők legyenek.

Az egyéni telemetria esetében explicit módon adja meg az erőforrás-azonosítókat. Az erőforrás-környezet lehetővé teszi, hogy a megfigyelhetőségi ügynök automatikusan kiterjesztse a vizsgálatokat a kapcsolódó szolgáltatásokra, adatbázisokra vagy infrastruktúra-összetevőkre.

Az OpenTelemetry alapértelmezés szerint nem tölti fel az erőforrás-környezetet. Erőforrás-detektorok konfigurálása a szabványos szemantikai attribútumok kibocsátásához, mint például:

  • service.name
  • cloud.resource_id
  • k8s.cluster.name

Kubernetes-klaszter kontextusának rögzítése

Az Azure Kubernetes Service-ben (AKS) futó alkalmazások esetében rögzítse a fürtszintű metaadatokat.

Az AKS autoinstrumentation (előzetes verzió) használata támogatott Java- és Node.js számítási feladatokhoz a telemetriai adatok fürt-, névtér-, pod- és csomópontinformációkkal való gazdagításához.

Más futtatókörnyezetek esetén adjon hozzá Kubernetes-metaadatokat SDK-bővítmények, telemetriai inicializálók vagy a Kubernetes-hez készült Application Insights-kódtár használatával.

Fürtkörnyezet nélkül a vizsgálatok nem kapcsolhatják az alkalmazáshibákat pod-újraindításokhoz, csomópontproblémákhoz vagy más fürtszintű eseményekhez.

3. fázis: A biztonságos telemetriai tervezési szabályok követése

Kövesse ezeket a szabályokat a telemetriai integritás és a korreláció megőrzéséhez.

Konzisztens és kiszámítható erőforrás-elnevezés használata

Konzisztens elnevezési konvenció alkalmazása azure-erőforrásokhoz és logikai összetevőkhöz.

A világos és kiszámítható nevek megkönnyítik a vizsgálati összefoglalók megértését és a kapcsolódó erőforrások korrelációját. Konzisztens elnevezést használhat az Azure-erőforrások, a felhőbeli szerepkörnevek és a telemetriai tulajdonságok között. További információ: Az elnevezési konvenció meghatározása.

Ne bíráljuk felül a beépített telemetriai tulajdonságokat

Ne bírálja felül a szabványos telemetriai mezőket, beleértve a következőket:

  • OperationId
  • OperationName
  • UserId
  • SessionId
  • cloud_RoleName

A szabványos telemetriamezők listájáért tekintse meg az Application Insights adatmodellt.

Ezek a mezők korrelációhoz és elemzéshez vannak fenntartva. A felülírás elrontja az elosztott nyomkövetést és a vizsgálat pontosságát.

Ha tartományspecifikus vagy üzleti adatokat kell csatolnia, vegye fel inkább egyéni dimenzióként.

4. fázis: Kritikus fontosságú eszközök munkafolyamatai

Ezek a gyakorlatok növelik a vizsgálati mélységet és a magyarázhatóságot.

Kritikus fontosságú műveletek monitorozása az egyéni telemetria használatával

A rendszer nem gyűjt automatikusan minden fontos munkafolyamatot.

Használat:

  • Egyéni események (TrackEvent) a jelentős üzleti vagy funkcionális mérföldkövek rögzítéséhez.
  • Egyéni műveletek (StartOperation / StopOperation) a hosszú ideig futó vagy aszinkron munkafolyamatok, például az üzenetsor-feldolgozás, a kötegelt feladatok vagy az ütemezett feladatok nyomon követéséhez.

Az egyéni műveletek időtartammal, sikerrel vagy hibával, korrelált függőségekkel és kivételekkel jelennek meg az Azure Monitorban. A megfigyelhetőségi ügynök ugyanúgy elemzi ezeket a műveleteket, mint a kérelmek telemetriáját. Az egyéni műveletek rendszerezésével kapcsolatos további információkért lásd: Egyéni műveletek nyomon követése az Application Insights használatával.

Kibocsátási széljegyzetek engedélyezése

Használja a kiadási megjegyzéseket az üzembe helyezések, a konfigurációs változások, a funkciójelző frissítések és az infrastruktúra változások megjelölésére.

A kibocsátási széljegyzetek időalapú környezetet adnak a vizsgálati ütemtervekhez, és segítenek megállapítani, hogy a problémák egybeesnek-e a módosításokkal. Az Azure Pipelines automatikusan hozhat létre széljegyzeteket. A PowerShell használatával manuálisan is létrehozhat széljegyzeteket .

Alkalmazásnaplók gyűjtése és nyomon követése

Nyomkövetési naplók gyűjtésének engedélyezése az Application Insightsban .NET-alkalmazásokhoz. Integrálható olyan naplózási keretrendszerekkel, mint a ILoggerlog4net vagy az NLog. További információ: .NET-nyomkövetési naplók felfedezése az Application Insightsban.

Az összegyűjtött naplók megjelennek a traces táblázatban, és a vizsgálatok során a telemetriával együtt elemzik. Gyűjtse össze a naplókat a megfelelő részletességi szinten, és kerülje a túlzott zajt.

Más nyelvek, például a Java és a Python, valamint az újabb .NET-alkalmazások esetében konfigurálja az Azure Monitor-exportőr vagy az OpenTelemetria naplózási integrációját. További információ: Az Azure Monitor OpenTelemetria engedélyezése .NET-, Node.js-, Python- és Java-alkalmazásokhoz.

Rendelkezésre állási tesztek létrehozása

Az Application Insights rendelkezésre állási tesztjeinek beállítása kritikus végpontokhoz.

A standard rendelkezésre állási tesztekkel proaktív módon pingelheti a végpontokat, érvényesítheti a válaszokat, és riasztásokat indíthat el a hibákról. A rendelkezésre állási riasztások integrálhatók az Azure Monitor-vizsgálatokkal, és automatikusan elemzést kezdeményezhetnek, ha a végpontok elérhetetlenné válnak. További információ: Rendelkezésre állási teszt létrehozása.

Kapcsolódó tartalom

  • Last updated on