Az Azure Monitor Application Insights adatgyűjtési alapjai
Cikk
Mielőtt monitorozni tudja az alkalmazást, rendszerezettnek kell lennie.
A következő szakaszokban az Azure Monitor Application Insights adatgyűjtési alapjait tárgyaljuk.
A rendszerállapot beállításai
Alapszinten a "rendszerezés" egyszerűen lehetővé teszi az alkalmazások számára a telemetriai adatok rögzítését.
Az alkalmazásnak két módszere van:
Automatikus rendszerállapot (autoinstrumentáció)
Manuális rendszerezés
Az autoinstrumentáció lehetővé teszi a telemetriai adatgyűjtést a konfiguráción keresztül anélkül, hogy az alkalmazás kódját érintenie kéne. Bár kényelmesebb, általában kevésbé konfigurálható. Nem minden nyelven érhető el. Lásd: Autoinstrumentation supported environments and languages. Ha az autoinstrumentáció elérhető, ez a legegyszerűbb módja az Azure Monitor Application Insights engedélyezésének.
Tipp.
A Microsoft Entra-hitelesítés jelenleg nem érhető el automatikusan. Ha Microsoft Entra hitelesítést igényel, manuális rendszerezést kell használnia.
A manuális rendszerállapot az Application Insights vagy az OpenTelemetry API kódolása. A felhasználó kontextusában általában egy nyelvspecifikus SDK-t telepít egy alkalmazásban. Ez azt jelenti, hogy egyedül kell kezelnie a legújabb csomagverzió frissítéseit. Ezt a lehetőséget akkor használhatja, ha olyan egyéni függőségi hívásokat vagy API-hívásokat kell kezdeményeznie, amelyeket alapértelmezés szerint nem rögzít automatikusan az automatikus beléptetés. A manuális kialakításnak két lehetősége van:
Bár az OpenTelemetryt tekintjük jövőbeli irányunknak, nem tervezzük leállítani az adatok gyűjtését a régebbi SDK-kból. Az Azure OpenTelemetry Distros továbbra is elérhető az Application Insights SDK-kkal való funkcióparitás elérése előtt. Az ügyfelek sok esetben továbbra is az Application Insights SDK-k használatát választják jó ideig.
Fontos
A "manuális" nem jelenti azt, hogy összetett kódot kell írnia az elosztott nyomkövetési tartományokra vonatkozó spanok meghatározásához, bár ez továbbra is lehetőség marad. A Disztribúcióinkba csomagolt rendszerállapot-kódtárak lehetővé teszik a telemetriai jelek egyszerű rögzítését a közös keretrendszerekben és kódtárakban. Aktívan dolgozunk a legnépszerűbb Azure Service SDK-k OpenTelemetria használatával történő kialakításán, hogy ezek a jelek elérhetők legyenek az Azure Monitor OpenTelemetry Distro-t használó ügyfelek számára.
Telemetriai típusok
Az alkalmazás megfigyeléséhez gyűjtött telemetriai adatok három típusra vagy "pillérre" bonthatók:
Elosztott nyomkövetés
Mérőszámok
Naplók
A teljes megfigyelhetőségi történet mindhárom pillért tartalmazza, és az Application Insights tovább bontja ezeket a pilléreket táblákra az adatmodell alapján. Az Application Insights SDK-k vagy az Azure Monitor OpenTelemetria-disztribúciói tartalmazzák az Azure-beli alkalmazásteljesítmény-figyeléshez szükséges összes elemet. Maga a csomag ingyenesen telepíthető, és csak az Azure Monitorban betöltött adatokért kell fizetnie.
Az adatokat kétféleképpen küldheti el az Azure Monitornak (vagy bármely szállítónak):
Közvetlen exportőren keresztül
Ügynökkel
A közvetlen exportőr közvetlenül az Azure Monitor betöltési végpontjára küldi a folyamatban lévő telemetriát (az alkalmazás kódjából). Ennek a megközelítésnek a fő előnye az egyszerűség bevezetése.
A jelenleg elérhető Application Insights SDK-k és az Azure Monitor OpenTelemetry Distros közvetlen exportőrre támaszkodnak.
Feljegyzés
Az Azure Monitor OpenTelemetry-Collector-ben elfoglalt pozícióját az OpenTelemetry gyikben találja.
Tipp.
Ha az OpenTelemetry-Collectort tervezi mintavételezésre vagy további adatfeldolgozásra használni, előfordulhat, hogy ezeket a képességeket az Azure Monitor beépítetten is használhatja. A munkaterület-alapú Application Insightsba migrált ügyfelek kihasználhatják az Ingestion-time Transformations előnyeit. Az engedélyezéshez kövesse az oktatóanyag részleteit, kihagyva azt a lépést, amely bemutatja, hogyan állíthat be diagnosztikai beállításokat, mivel a munkaterület-központú Application Insightsban ez már konfigurálva van. Ha a teljes mennyiség kevesebb, mint 50%-át szűri, az nem jár további költséggel. 50%, van egy költség, de sokkal kisebb, mint a standard gb-díj.
OpenTelemetry
A Microsoft örömmel fogadja az OpenTelemetryt , mint a telemetriai rendszerezés jövőjét. Ön, ügyfeleink gyártósemleges kialakítást kértek, és örömmel együttműködünk az OpenTelemetry-közösséggel, hogy egységes API-kat és SDK-kat hozzunk létre különböző nyelveken.
A Microsoft két korábban népszerű nyílt forráskódú telemetriai projekt, az OpenCensus és az OpenTracing projekt résztvevőivel dolgozott együtt. Közösen segítettünk létrehozni egyetlen projektet, az OpenTelemetryt. Az OpenTelemetria az összes fő felhő- és alkalmazásteljesítmény-kezelő (APM) gyártó hozzájárulását tartalmazza, és a Cloud Native Computing Foundationben (CNCF) található. A Microsoft platinum tag a CNCF-ben.
Az Application Insights néhány régi kifejezése zavaró az OpenTelemetry iparági konvergenciája miatt. Az alábbi táblázat ezeket a különbségeket emeli ki. Az OpenTelemetry-kifejezések az Application Insights-kifejezéseket váltják fel.
Az Azure Monitor-exportőr az EventSource-t használja a belső naplózáshoz. Az exportőr naplói bármely EventListener számára elérhetők, ha a névvel ellátott OpenTelemetry-AzureMonitor-Exporterforrást választják. A hibaelhárítási lépésekért tekintse meg az OpenTelemetria hibaelhárítását a GitHubon.
2. lépés: Az alkalmazásgazda és a betöltési szolgáltatás közötti kapcsolat tesztelése
Az Application Insights SDK-k és -ügynökök telemetriát küldenek, hogy REST-hívásként legyenek betöltve a betöltési végpontjainkon. A webkiszolgálóról vagy az alkalmazásgazdaszámítógépről a betöltési szolgáltatás végpontjaihoz való kapcsolódás teszteléséhez használjon cURL-parancsokat vagy nyers REST-kéréseket a PowerShellből. További információ: Hiányzó alkalmazástelemetria hibaelhárítása az Azure Monitor Application Insightsban.
Ismert problémák
Az Alábbi elemek ismert problémák az Azure Monitor OpenTelemetry-exportőrök esetében:
A művelet neve hiányzik a függőségi telemetriából. A hiányzó műveletnév hibákhoz vezet, és hátrányosan befolyásolja a teljesítmény lap használatát.
Az eszközmodell hiányzik a kérelem- és függőségi telemetriából. A hiányzó eszközmodell hátrányosan befolyásolja az eszköz kohorszelemzését.
1. lépés: Diagnosztikai naplózás engedélyezése
Az Azure Monitor-exportőr az EventSource-t használja a belső naplózáshoz. Az exportőr naplói bármely EventListener számára elérhetők, ha a névvel ellátott OpenTelemetry-AzureMonitor-Exporterforrást választják. A hibaelhárítási lépésekért tekintse meg az OpenTelemetria hibaelhárítását a GitHubon.
2. lépés: Az alkalmazásgazda és a betöltési szolgáltatás közötti kapcsolat tesztelése
Az Application Insights SDK-k és -ügynökök telemetriát küldenek, hogy REST-hívásként legyenek betöltve a betöltési végpontjainkon. A webkiszolgálóról vagy az alkalmazásgazdaszámítógépről a betöltési szolgáltatás végpontjaihoz való kapcsolódás teszteléséhez használjon cURL-parancsokat vagy nyers REST-kéréseket a PowerShellből. További információ: Hiányzó alkalmazástelemetria hibaelhárítása az Azure Monitor Application Insightsban.
Ismert problémák
Az Alábbi elemek ismert problémák az Azure Monitor OpenTelemetry-exportőrök esetében:
A művelet neve hiányzik a függőségi telemetriából. A hiányzó műveletnév hibákhoz vezet, és hátrányosan befolyásolja a teljesítmény lap használatát.
Az eszközmodell hiányzik a kérelem- és függőségi telemetriából. A hiányzó eszközmodell hátrányosan befolyásolja az eszköz kohorszelemzését.
2. lépés: Az alkalmazásgazda és a betöltési szolgáltatás közötti kapcsolat tesztelése
Az Application Insights SDK-k és -ügynökök telemetriát küldenek, hogy REST-hívásként legyenek betöltve a betöltési végpontjainkon. A webkiszolgálóról vagy az alkalmazásgazdaszámítógépről a betöltési szolgáltatás végpontjaihoz való kapcsolódás teszteléséhez használjon cURL-parancsokat vagy nyers REST-kéréseket a PowerShellből. További információ: Hiányzó alkalmazástelemetria hibaelhárítása az Azure Monitor Application Insightsban.
Ismert problémák
Ha letölti az Application Insights ügyfélkódtárat a telepítéshez egy böngészőből, előfordulhat, hogy a letöltött JAR-fájl sérült, és körülbelül a forrásfájl méretének fele. Ha ezt a problémát tapasztalja, töltse le a JAR-fájlt a curl vagy wget parancs futtatásával, ahogyan az alábbi példaparancshívásokban látható:
Az alábbi lépések a Spring Boot natív alkalmazásaira vonatkoznak.
1. lépés: Az OpenTelemetry verziójának ellenőrzése
Az alkalmazás indításakor a következő üzenet jelenhet meg:
WARN c.a.m.a.s.OpenTelemetryVersionCheckRunner - The OpenTelemetry version is not compatible with the spring-cloud-azure-starter-monitor dependency.
The OpenTelemetry version should be <version>
Ebben az esetben importálnia kell az OpenTelemetry Anyagjegyzéket az OpenTelemetry dokumentációjának követésével a Spring Boot starterben.
2. lépés: Öndiagnosztika engedélyezése
Ha valami nem a várt módon működik, engedélyezheti az öndiagnosztikát a DEBUG szinten, hogy betekintést nyerjen. Ehhez állítsa be az öndiagnosztikai szintet ERROR, WARN, INFO, DEBUGvagy TRACE a APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL környezeti változó használatával.
Ha docker-tároló futtatásakor szeretné engedélyezni az DEBUG öndiagnosztika szintjét, futtassa a következő parancsot:
docker run -e APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL=DEBUG <image-name>
Feljegyzés
Cserélje le <image-name> ennek megfelelően a Docker-rendszerkép nevét.
Külső féltől származó információra vonatkozó felelősséget kizáró nyilatkozat
A jelen cikkben tárgyalt, külső féltől származó termékeket a Microsofttól független vállalatok állítják elő. A Microsoft sem hallgatólagosan, sem egyéb módon nem vállal szavatosságot a termékek teljesítményére vagy megbízhatóságára vonatkozóan.
1. lépés: Diagnosztikai naplózás engedélyezése
Az Azure Monitor Exporter az OpenTelemetry API-naplózót használja a belső naplókhoz. A naplózó engedélyezéséhez futtassa a következő kódrészletet:
2. lépés: Az alkalmazásgazda és a betöltési szolgáltatás közötti kapcsolat tesztelése
Az Application Insights SDK-k és -ügynökök telemetriát küldenek, hogy REST-hívásként legyenek betöltve a betöltési végpontjainkon. A webkiszolgálóról vagy az alkalmazásgazdaszámítógépről a betöltési szolgáltatás végpontjaihoz való kapcsolódás teszteléséhez használjon cURL-parancsokat vagy nyers REST-kéréseket a PowerShellből. További információ: Hiányzó alkalmazástelemetria hibaelhárítása az Azure Monitor Application Insightsban.
Ismert problémák
Az Alábbi elemek ismert problémák az Azure Monitor OpenTelemetry-exportőrök esetében:
A művelet neve hiányzik a függőségi telemetriából. A hiányzó műveletnév hibákhoz vezet, és hátrányosan befolyásolja a teljesítmény lap használatát.
Az eszközmodell hiányzik a kérelem- és függőségi telemetriából. A hiányzó eszközmodell hátrányosan befolyásolja az eszköz kohorszelemzését.
Az adatbázis-kiszolgáló neve hiányzik a függőségi névből. Mivel az adatbázis-kiszolgáló neve nem szerepel benne, az OpenTelemetry-exportőrök helytelenül összesítik az azonos nevű táblákat a különböző kiszolgálókon.
1. lépés: Diagnosztikai naplózás engedélyezése
A Microsoft Azure Monitor-exportőr a Python standard naplózási kódtárat használja a belső naplózáshoz. Az OpenTelemetry API és az Azure Monitor Exportnaplók súlyossági szinthez WARNING vagy ERROR szabálytalan tevékenységekhez vannak hozzárendelve. A INFO súlyossági szint a rendszeres vagy sikeres tevékenységhez használatos.
Alapértelmezés szerint a Python naplózási kódtára a súlyossági szintet WARNINGállítja be . Ezért módosítania kell a súlyossági szintet, hogy a naplók megjelenjenek ebben a súlyossági beállításban. Az alábbi példakód bemutatja, hogyan jelenítheti meg az összes súlyossági szint naplóit a konzolon és egy fájlban:
2. lépés: Az alkalmazásgazda és a betöltési szolgáltatás közötti kapcsolat tesztelése
Az Application Insights SDK-k és -ügynökök telemetriát küldenek, hogy REST-hívásként legyenek betöltve a betöltési végpontjainkon. A webkiszolgálóról vagy az alkalmazásgazdaszámítógépről a betöltési szolgáltatás végpontjaihoz való kapcsolódás teszteléséhez használjon cURL-parancsokat vagy nyers REST-kéréseket a PowerShellből. További információ: Hiányzó alkalmazástelemetria hibaelhárítása az Azure Monitor Application Insightsban.
3. lépés: Az ismétlődő telemetriai adatok elkerülése
A telemetriai adatok duplikálása gyakran akkor fordulhat elő, ha több processzor- vagy exportőrpéldányt hoz létre. Győződjön meg arról, hogy egyszerre csak egy exportőrt és feldolgozót futtat az egyes telemetriai pillérekhez (naplókhoz, metrikákhoz és elosztott nyomkövetéshez).
A következő szakaszok olyan forgatókönyveket ismertetnek, amelyek ismétlődő telemetriát okozhatnak.
Ismétlődő nyomkövetési naplók az Azure Functionsben
Ha az Application Insightsban minden nyomkövetési naplóhoz egy-egy bejegyzéspár jelenik meg, valószínűleg a következő naplózási rendszerállapot-típusokat engedélyezte:
A natív naplózási rendszerállapot az Azure Functionsben
A azure-monitor-opentelemetry naplózási rendszerállapot a disztribúción belül
A duplikációk elkerülése érdekében letilthatja a disztribúció naplózását, de a natív naplózási rendszerállapot engedélyezve marad az Azure Functionsben. Ehhez állítsa a környezeti változót a OTEL_LOGS_EXPORTER következőre None: .
Ismétlődő telemetriai adatok az "Always On" Azure Functionsben
Ha az Azure Functions Always On beállítása Be értékre van állítva, az Azure Functions minden futtatás után a háttérben futtat néhány folyamatot. Tegyük fel például, hogy van egy ötperces időzítőfüggvénye, amely minden alkalommal hív configure_azure_monitor . 20 perc elteltével előfordulhat, hogy négy metrikaexportőr fut egyszerre. Ez a helyzet lehet az ismétlődő metrikák telemetriájának forrása.
Ebben az esetben állítsa be az Always On beállítást kikapcsolva, vagy próbálja meg manuálisan leállítani a szolgáltatókat az egyes configure_azure_monitor hívások között. Az egyes szolgáltatók leállításához futtassa a leállítási hívásokat az egyes aktuális mérők, jelölők és naplózók szolgáltatói számára, ahogyan az az alábbi kódban látható:
Előfordulhat, hogy az Azure-munkafüzetek és a Jupyter-jegyzetfüzetek a háttérben futtatják az exportőri folyamatokat. Az ismétlődő telemetriai adatok megelőzéséhez törölje a gyorsítótárat, mielőtt további hívásokat kezdeményez.configure_azure_monitor
4. lépés: Győződjön meg arról, hogy a Flask-kérelem adatainak gyűjtése történik
Flask-alkalmazás implementálása esetén előfordulhat, hogy a PythonHoz készült Azure Monitor OpenTelemetry Distro ügyféloldali kódtár használata során nem tud adatokat gyűjteni a Requests táblaadatokból az Application Insightsból. Ez a probléma akkor fordulhat elő, ha nem megfelelően strukturálja a import deklarációkat. Előfordulhat, hogy importálja a flask.Flask webalkalmazás-keretrendszert, mielőtt meghívja a függvényt configure_azure_monitor a Flask-kódtár rendszerezésére. A következő kód például nem tudja sikeresen a Flask-alkalmazást eszközként használni:
from azure.monitor.opentelemetry import configure_azure_monitor
from flask import Flask
configure_azure_monitor()
app = Flask(__name__)
Ehelyett azt javasoljuk, hogy importálja a flask modult egészként, majd hívja meg configure_azure_monitor , hogy konfigurálja az OpenTelemetryt az Azure Monitor használatára a hozzáférés flask.Flaskelőtt:
from azure.monitor.opentelemetry import configure_azure_monitor
import flask
configure_azure_monitor()
app = flask.Flask(__name__)
Másik lehetőségként az importálás flask.Flaskelőtt hívhatja meg a következőtconfigure_azure_monitor:
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()
from flask import Flask
app = Flask(__name__)
Támogatás
Válasszon egy lapot a választott nyelvhez a támogatási lehetőségek felderítéséhez.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: