Azure Monitor gyakori kérdések

Ez a Microsoft GYIK a gyakori kérdések listáját tartalmazza a Azure Monitor. Ha további kérdései vannak, a fórumon tegye fel kérdéseit. Ha gyakran feltenek egy kérdést, azt hozzáadjuk ehhez a cikkhez, hogy gyorsan és egyszerűen megtalálható legyen.

Általános kérdések

Mi az Azure Monitor?

Azure Monitor szolgáltatás az Azure-ban, amely teljesítmény- és rendelkezésre állási monitorozást biztosít az Azure-ban, más felhőkörnyezetekben vagy a helyszínen található alkalmazásokhoz és szolgáltatásokhoz. Azure Monitor több forrásból származó adatokat gyűjt egy közös adatplatformra, ahol elemezhetők a trendek és anomáliák. A funkciók gazdag Azure Monitor segítenek az alkalmazást érintő kritikus helyzetek gyors azonosításában és az ezekre való reagálásban.

Mi a különbség a Azure Monitor, a Log Analytics és az Application Elemzések?

2018 szeptemberében a Microsoft az Azure Monitor, a Log Analytics és az Application Elemzések szolgáltatást egyesítette egyetlen szolgáltatásban, hogy hatékony, teljes mértékben monitorozást biztosítson az alkalmazásokról és az összetevőkről, amelyekre támaszkodnak. A Log Analytics és az Application Elemzések szolgáltatásai nem változtak, bár egyes funkciókat Azure Monitor, hogy jobban tükrözzék az új hatókörüket. A Log Analytics naplóadatmotorját és lekérdezési nyelvét mostantól naplónaplóknak Azure Monitor nevezzük. Lásd a Azure Monitor frissítéseit.

Mi a Azure Monitor költsége?

Az automatikusan Azure Monitor funkciók, például a metrikák és a tevékenységnaplók gyűjtése, költség nélkül biztosítanak. Más funkciókkal, például naplólekérdezésekkel és riasztásokkal jár egy költség. Részletes díjszabási Azure Monitor a díjszabást a díjszabást részletező oldalon.

Hogyan engedélyezni Azure Monitor?

Azure Monitor az új Azure-előfizetés létrehozásakor, és a rendszer automatikusan gyűjti a tevékenységnaplót és a platformmetrikákat. Diagnosztikai beállításokat hozhat létre, amelyek részletesebb információkat gyűjtenek az Azure-erőforrások működéséről, valamint monitorozási megoldásokat és elemzéseket adhat hozzá az összegyűjtött adatok további elemzéséhez az egyes szolgáltatásokhoz.

Hogyan hozzáférési Azure Monitor?

Az összes Azure Monitor és adatot elérheti az alkalmazás Figyelése Azure Portal. A különböző Azure-szolgáltatások menüjének Figyelés szakasza hozzáférést biztosít ugyanazokhoz az eszközökhöz egy adott erőforrásra szűrt adatokkal. Azure Monitor a parancssori felület, a PowerShell és egy REST API.

Is there an on-premises version of Azure Monitor?

Nem. Azure Monitor egy méretezhető felhőszolgáltatás, amely nagy mennyiségű adatot feldolgoz és tárol, bár a Azure Monitor a helyszínen és más felhőkben található erőforrásokat is képes figyelni.

Figyelheti Azure Monitor helyszíni erőforrásokat?

Igen, a monitorozási adatok Azure-erőforrásokból való gyűjtése mellett a Azure Monitor más felhőkben és a helyszínen található virtuális gépekről és alkalmazásokból is gyűjthet adatokat. Lásd: A monitorozási adatok forrásai a Azure Monitor.

Integrálható Azure Monitor a System Center Operations Manager?

Meglévő felügyeleti csoportját összekapcsolhatja System Center Operations Manager felügyeleti csoporttal, Azure Monitor adatokat gyűjthet az ügynökökről az Azure Monitor naplókba. Ez lehetővé teszi, hogy naplólekérdezésekkel és megoldásokkal elemezze az ügynököktől gyűjtött adatokat. A meglévő ügynököket úgy is System Center Operations Manager, hogy közvetlenül a Azure Monitor. Lásd: Csatlakozás Operations Manager a Azure Monitor.

Milyen IP-címeket Azure Monitor használni?

Az ügynökök és egyéb külső erőforrások eléréséhez szükséges IP-címek és portok listáját az Application Elemzések és a Log Analytics által használt IP-címek Azure Monitor.

Adatok monitorozása

Honnan Azure Monitor le az adatokat?

Azure Monitor forrásokból gyűjt adatokat, beleértve az Azure-platformról és -erőforrásokból, egyéni alkalmazásokból és virtuális gépeken futó ügynökökből származó naplókat és metrikákat. Más szolgáltatások, például Azure Security Center és Network Watcher adatokat gyűjtenek egy Log Analytics-munkaterületre, hogy elemezhetők Azure Monitor adatokkal. Egyéni adatokat is küldhet a Azure Monitor a REST API vagy metrikákhoz való használatával. Lásd: A monitorozási adatok forrásai a Azure Monitor.

Milyen adatokat gyűjt a Azure Monitor?

Azure Monitor különböző forrásokból származó adatokat naplókba vagy metrikákba gyűjt. Minden adattípusnak megvannak a maga relatív előnyei, és mindegyik támogatja a szolgáltatások egy adott készletét a Azure Monitor. Minden Azure-előfizetéshez egyetlen metrika-adatbázis érhető el, a követelményektől függően azonban több Log Analytics-munkaterületet is létrehozhat a naplók gyűjtéséhez. Lásd Azure Monitor adatplatformot.

Van olyan maximális adatmennyiség, amely összegyűjthető a Azure Monitor?

A gyűjthető metrikaadatok mennyisége nincs korlátozva, de ezek az adatok legfeljebb 93 napig vannak tárolva. Lásd: A metrikák megőrzése. A gyűjthető naplóadatok mennyisége nincs korlátozva, de a Log Analytics-munkaterülethez választott tarifacsomag hatással lehet rá. Tekintse meg a díjszabás részleteit.

Hogyan által gyűjtött hozzáférési adatokat Azure Monitor?

Elemzések megoldások egyéni felhasználói élményt biztosítanak a szolgáltatásban tárolt adatok Azure Monitor. A naplóadatokat közvetlenül is használhatja a Kusto lekérdezési nyelven (KQL) írt naplólekérdezésekkel. A Azure Portal a Log Analytics használatával lekérdezéseket írhat és futtathat, valamint interaktív módon elemezheti az adatokat. Metrikák elemzése a Azure Portal a Metrikaböngésző. Lásd: Naplóadatok elemzése a Azure Monitor és Ismerkedés az Azure Metrikaböngésző.

Megoldások és elemzések

Mit jelent a Azure Monitor?

Elemzések azure-szolgáltatásokhoz egyéni monitorozási élményt biztosít. A metrikák és naplók a Azure Monitor más funkcióival azonosak, de további adatokat gyűjthetnek, és egyedi felhasználói élményt nyújthatnak a Azure Portal. Lásd: Elemzések a Azure Monitor.

Az elemzéseket a Azure Portal a Figyelés Elemzések vagy a szolgáltatás menüjének Figyelés szakaszában láthatja.

Mi az a megoldás a Azure Monitor?

A monitorozási megoldások olyan csomagolt logikakészletek, amelyek egy adott alkalmazást vagy szolgáltatást figyelnek a Azure Monitor alapján. Naplóadatokat gyűjtenek a Azure Monitor és naplólekérdezéseket és nézeteket biztosítanak az elemzésük számára a Azure Portal. Lásd: Megoldások figyelése a Azure Monitor.

A megoldásokat a Azure Portal a Figyelés menü Elemzések szakaszában kattintson a További gombra. Kattintson a Hozzáadás gombra, ha további megoldásokat szeretne hozzáadni a munkaterülethez.

Naplók

Mi a különbség a naplók és Azure Monitor között Azure Data Explorer?

Az Azure Adatkezelő egy gyors és hatékonyan skálázható adatáttekintési szolgáltatás napló- és telemetriaadatokhoz. Azure Monitor-naplók az adatbázisra épülnek Azure Data Explorer és ugyanazt a Kusto lekérdezési nyelvet (KQL) használják néhány kisebb eltéréssel. Lásd Azure Monitor a naplólekérdezés nyelvének eltéréseit.

Hogyan lekérni a naplóadatokat?

Minden adat lekérhető egy Log Analytics-munkaterületről egy Kusto lekérdezési nyelv (KQL) használatával írt naplólekérdezés használatával. Írhat saját lekérdezéseket, vagy olyan megoldásokat és elemzéseket használhat, amelyek naplólekérdezéseket tartalmaznak egy adott alkalmazáshoz vagy szolgáltatáshoz. Lásd: A naplólekérdezések áttekintése a Azure Monitor.

Törölhetek adatokat egy Log Analytics-munkaterületről?

Az adatok a megőrzési időszaknak megfelelően törlődnek a munkaterületről. Adott adatokat adatvédelmi vagy megfelelőségi okokból törölhet. További információ: Privát adatok exportálása és törlése.

A Log Analytics-tároló nem módosítható?

Az adatbázis-tárolóban lévő adatok nem módosíthatók a betelt után, de törölhetők a privát adatok törléséhez szükséges végleges törlési API-útvonalon keresztül. Bár az adatok nem módosíthatók, egyes tanúsítványok megkövetelik, hogy az adatok nem módosíthatók, és ne módosíthatók vagy törölhetők a tárolóban. Az adatok nem módosíthatók az adatexportációval egy nem módosítható tárfiókként konfigurált tárfiókba.

Mi a Log Analytics-munkaterület?

A naplózási szolgáltatások által gyűjtött Azure Monitor Log Analytics-munkaterületen tárolódnak. A munkaterület lényegében egy olyan tároló, amelyben a naplóadatok különböző forrásokból vannak összegyűjtve. Egyetlen Log Analytics-munkaterülettel is lehet az összes monitorozási adathoz, vagy több munkaterületre vonatkozó követelmények is lehetnek. Lásd: A Azure Monitor naplók üzembe helyezésének megtervezése.

Áthelyezhet egy meglévő Log Analytics-munkaterületet egy másik Azure-előfizetésbe?

A munkaterületeket áthelyezheti erőforráscsoportok vagy előfizetések között, de nem áthelyezheti őket egy másik régióba. Lásd: Log Analytics-munkaterület áthelyezése másik előfizetésbe vagy erőforráscsoportba.

Miért nem látom a Lekérdezéskezelő és a Mentés gombokat a Log Analyticsben?

A Lekérdezéskezelő, a Mentés és az Új riasztási szabály gombok nem érhetők el, ha a lekérdezés hatóköre egy adott erőforrásra van beállítva. Riasztások létrehozásához, lekérdezés mentéséhez vagy betöltéséhez a Log Analytics hatókörét egy munkaterületre kell kiterjedni. A Log Analytics munkaterületi környezetben való megnyitásához válassza a Naplók lehetőséget a Azure Monitor menüben. Az utoljára használt munkaterület van kijelölve, de bármelyik másik munkaterületet kiválaszthatja. Lásd: Naplólekérdezés hatóköre és időtartománya Azure Monitor Log Analyticsben

Miért jelenik meg a következő hibaüzenet: "Register resource provider 'Microsoft. Elemzések, hogy ez az előfizetés engedélyezze ezt a lekérdezést", amikor virtuális gépről nyitja meg a Log Analyticset?

Számos erőforrás-szolgáltató automatikusan regisztrálva van, de előfordulhat, hogy manuálisan kell regisztrálnia néhány erőforrás-szolgáltatót. A regisztráció hatóköre mindig az előfizetés. További információ: Erőforrás-szolgáltatók és típusaik.

Miért nem kapok hozzáférési hibaüzenetet, amikor virtuális gépről nyitom meg a Log Analyticset?

A virtuálisgép-naplók megtekintéséhez olvasási engedéllyel kell rendelkeznie a virtuális gép naplóit tároló munkaterületeken. Ezekben az esetekben a rendszergazdának meg kell adnunk Önnek az Azure-beli engedélyeket.

Mérőszámok

Miért nem ömlnek meg az Azure-beli virtuális gépem vendég operációs rendszerének metrikai a Metrikák explorerben?

A platformmetrikákat a rendszer automatikusan gyűjti az Azure-erőforrásokhoz. A virtuális gép vendég operációs rendszerének metrikák gyűjtéséhez azonban el kell végeznie néhány konfigurálást. Virtuális gép Windows telepítse a diagnosztikai bővítményt, és konfigurálja a Azure Monitor-fogadót az Azure diagnostics bővítmény (WAD)telepítése és konfigurálása Windows leírtak szerint. Linux rendszeren telepítse a Telegraf-ügynököt a Collect custom metrics for a Linux VM with the InfluxData Telegraf agent (Egyéni metrikák gyűjtése Linux rendszerű virtuális gépeken az InfluxData Telegraf-ügynökkel) leírás szerint.

Riasztások

Mi az a riasztás a Azure Monitor?

A riasztások proaktívan értesítik, ha fontos feltételek találhatók a monitorozási adatokban. Lehetővé teszik a problémák azonosítását és megoldását, mielőtt a felhasználók észreveik őket. Többféle riasztás létezik:

  • Metrika – A metrika értéke meghaladja a küszöbértéket.
  • Naplólekérdezés – A naplólekérdezés eredménye megfelel a megadott feltételeknek.
  • Tevékenységnapló – A tevékenységnapló-esemény megfelel a megadott feltételeknek.
  • Webes teszt – A rendelkezésre állási teszt eredménye megfelel a megadott feltételeknek.

Lásd: A riasztások áttekintése a Microsoft Azure.

Mi az a műveletcsoport?

A műveletcsoportok riasztások által aktiválható értesítések és műveletek gyűjteményei. Több riasztás is használhat egyetlen műveletcsoportot, így kihasználhatja a gyakori értesítéseket és műveleteket. Lásd: Műveletcsoportok létrehozása és kezelése a Azure Portal.

Mi az a műveletszabály?

A műveletszabály lehetővé teszi egy adott feltételnek megfelelő riasztáskészlet viselkedésének módosítását. Ez lehetővé teszi olyan követelmények elvégzését, mint például a riasztási műveletek letiltása a karbantartási időszakban. A riasztások egy csoportjára is alkalmazhat műveletcsoportokat ahelyett, hogy közvetlenül a riasztási szabályokra alkalmazva lenne. Lásd: Műveletszabályok.

Ügynökök

Szükséges Azure Monitor ügynök?

Ügynökre csak az operációs rendszer és a virtuális gépeken lévő számítási feladatok adatainak gyűjtéséhez van szükség. A virtuális gépek az Azure-ban, egy másik felhőkörnyezetben vagy a helyszínen is találhatók. Lásd: A Azure Monitor áttekintése.

Mi a különbség a két Azure Monitor között?

Az Azure Diagnostics bővítmény Azure-beli virtuális gépekhez való, és adatokat gyűjt Azure Monitor Metrikák, az Azure Storage és a Azure Event Hubs. A Log Analytics-ügynök az Azure-beli virtuális gépekhez, egy másik felhőalapú környezethez vagy helyszíni környezethez való, és adatokat gyűjt a Azure Monitor naplókba. A függőségi ügynökhöz szükség van a Log Analytics-ügynökre, valamint a gyűjtött folyamat részleteire és függőségeire. A Azure Monitor Agent az új, továbbfejlesztett ügynök, amely idővel összevonja a fent említett ügynökök funkcióit, ugyanakkor további előnyöket biztosít, például a központosított adatgyűjtést, a szűrést, a többtényezős szolgáltatásokat. Lásd: A Azure Monitor áttekintése.

Az ügynököm forgalma az ExpressRoute-kapcsolatot használja?

A forgalom Azure Monitor Microsoft társviszony-létesítés ExpressRoute-kapcsolatkört használ. A különböző ExpressRoute-forgalomtípusok leírását az ExpressRoute dokumentációjában találhatja meg.

Hogyan ellenőrizhetem, hogy a Log Analytics-ügynök képes-e kommunikálni Azure Monitor?

Az Vezérlőpult számítógépen található számítógépeken válassza a Security & Gépház, Microsoft Monitoring Agent lehetőséget. Az Azure Log Analytics (OMS) lapon egy zöld pipa ikon jelzi, hogy az ügynök tud-e kommunikálni a Azure Monitor. A sárga figyelmeztető ikon azt jelenti, hogy az ügynöknek problémái vannak. Ennek egyik gyakori oka, hogy a Microsoft Monitoring Agent szolgáltatás leállt. A szolgáltatás újraindítása a Szolgáltatásvezérlő kezelővel.

Hogyan a Log Analytics-ügynök nem kommunikál a Azure Monitor?

A Log Analyticshez közvetlenül csatlakozó ügynökök számára nyissa meg a Vezérlőpult, és válassza a Security & Gépház( Microsoft Monitoring Agent) lehetőséget. Az Azure Log Analytics (OMS) lapon távolítsa el az összes felsorolt munkaterületet. A System Center Operations Manager távolítsa el a számítógépet a Log Analytics által felügyelt számítógépek listájáról. Operations Manager frissíti az ügynök konfigurációját, hogy a továbbiakban ne jelentsen a Log Analyticsnek.

Mennyi adatot küld a rendszer ügynökenként?

Az ügynökként küldött adatok mennyisége a következőtől függ:

  • Az Ön által engedélyezett megoldások
  • Az összegyűjtött naplók és teljesítményszámlálók száma
  • A naplókban az adatok mennyisége

Részletekért lásd: Használat és költségek kezelése Azure Monitor naplókban.

A WireData-ügynököt futtatni képes számítógépeken a következő lekérdezéssel láthatja, hogy mennyi adatot küld a rendszer:

WireData
| where ProcessName == "C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\MonitoringHost.exe"
| where Direction == "Outbound"
| summarize sum(TotalBytes) by Computer 

Mekkora hálózati sávszélességet használ a Microsoft Management Agent (MMA) az adatoknak a Azure Monitor?

A sávszélesség az elküldött adatok mennyiségének függvénye. A hálózaton keresztül küldött adatok tömörítve adatokat tartalmaznak.

Hogyan kaphatok értesítést, ha a Log Analytics-ügynöktől való adatgyűjtés leáll?

Kövesse az új naplóriasztás létrehozása lépésben leírt lépéseket, hogy értesítést kap a rendszer, ha az adatgyűjtés leáll. A riasztási szabályhoz használja a következő beállításokat:

  • Riasztási feltétel meghatározása: Adja meg a Log Analytics-munkaterületet erőforrás-célként.
  • Riasztási feltételek
    • Jel neve: Egyéni naplókeresés
    • Keresési lekérdezés:Heartbeat | summarize LastCall = max(TimeGenerated) by Computer | where LastCall < ago(15m)
    • Riasztási logika: Az eredmények száma, a Feltétel nagyobb, mint , Küszöbérték 0
    • Kiértékelve a következő alapján: Period (in minutes) 30, Frequency (in minutes) 10
  • Riasztás részleteinek megadása
    • Név: Az adatgyűjtés leállt
    • Súlyosság: Figyelmeztetés

Adjon meg egy meglévő vagy új műveletcsoportot, hogy amikor a naplóriasztás megfelel a feltételeknek, értesítést kap, ha 15 percnél tovább hiányzik a szívverés.

Mik a Log Analytics-ügynökök tűzfalkövetelményei?

A tűzfalkövetelményekkel kapcsolatosrészletekért lásd: Hálózati tűzfalkövetelmények.

Azure Monitor-ügynök

Mi a Log Analytics-ügynökök frissítési útvonala a Azure Monitor ügynökre? Hogyan lehet az áttelepítést?

Mi a Frissítési útvonal a Log Analytics-ügynökről (MMA) a Azure Monitor Agentre (AMA) a System Center Operations Manager? Használhatjuk az AMA-t System Center Operations Manager forgatókönyvekhez?

Az AMA a következő hatással van a System Center Operations Manager kapcsolódó figyeléses forgatókönyvekre:

  • 1. forgatókönyv: Az System Center Operations Manager Windows operációs rendszerének figyelése esetén a frissítési útvonal megegyezik a többi gépével, ahol az MMA-ból (2016-os, 2019-es verziók) az AMA-ra mihelyst a szükséges paritási funkciók már elérhetők az AMA-ban.
  • 2. forgatókönyv: A System Center Operations Manager Log Analytics-munkaterületekbe való beléptetése/csatlakoztatása esetén, mivel ezt a Log Analytics/Azure Monitor System Center Operations Manager-összekötővel lehet engedélyezni, az MMA-t és az AMA-t sem kell telepíteni az Operations Manager felügyeleti kiszolgálóra. Ebből következően az AMA szempontjából nincs hatással erre a használatra.

Megjegyzés

Mindkét fenti forgatókönyvet futtathatja az MMA-val és az AMA-val egymás mellett, hatás nélkül.

Az új Azure Monitor támogatja az adatgyűjtést a különböző Log Analytics-megoldások és Azure-szolgáltatások, például a Security Center, a Sentinel stb.?

Tekintse át az előzetes verzióban jelenleg elérhető AMA-bővítmények listáját. Ezek ugyanazok a megoldások és szolgáltatások, amelyek az új Azure Monitor használatával érhetők el. Előfordulhat, hogy további bővítmények is telepítve vannak a megoldáshoz/szolgáltatáshoz. Ez további adatokat gyűjt, vagy a megoldáshoz/szolgáltatáshoz szükséges átalakítást/feldolgozást végez, majd az AMA használatával a végső adatokat a Azure Monitor.

Az alábbi ábra az új, a extenzibilitási architektúrát mutatja be:

Bővítményarchitektúra

Mely Log Analytics-megoldásokat támogatja az új Azure Monitor Agent?

Hogyan gyűjthetőek biztonsági Windows az új Azure Monitor Agent használatával?

Az új ügynökkel kétféleképpen gyűjthet biztonsági eseményeket a Log Analytics-munkaterületre való küldéskor:

  • Az AMA használatával natív módon gyűjthet biztonsági eseményeket, ugyanúgy, mint Windows eseményeket. Ezek a Log Analytics-munkaterület "Esemény" táblába áramlnak.
  • Ha engedélyezve van a Sentinel a munkaterületen, a Biztonsági események az AMA-n keresztül a "SecurityEvent" táblába áramolnak (ugyanaz, mint a Log Analytics-ügynök használata). Ehhez mindig először engedélyezni kell a megoldást.

Létezhet az Azure Monitor és a Log Analytics-ügynök egymás mellett?

Igen, de bizonyos szempontokat figyelembe véve. További tudnivalók itt.

Az új ügynök Azure Monitor a meglévő ügynökökkel?

Még nem rendelkezik teljes paritással a meglévő ügynökökkel. Íme néhány magas szintű hiányosság:

  • Összehasonlítás a Log Analytics-ügynökökkel (MMA/OMS)

    • Jelenleg nem minden Log Analytics-megoldás támogatott. A támogatott verziók
    • A privát kapcsolatok nem támogatottak
    • Nem támogatott az egyéni naplók vagy IIS-naplók gyűjtése
  • Összehasonlítás az Azure Diagnostics bővítményekkel (WAD/MIT)

    • A fiókok Event Hubs Storage nem támogatottak

Támogatja az új Azure Monitor Agent a nem Azure-beli környezeteket (más felhőkben, a helyszínen)?

A kiszolgálók jelenleg mind a helyszíni gépeket, mind a más felhőkhöz csatlakoztatott gépeket támogatják, miután telepítette a Azure Arc ügynököt. Az AMA és a DCR futtatásához az ARC-követelmény nem jár további költséggel vagy erőforrás-felhasználással, mivel az ARC-ügynök csak telepítési mechanizmust használ, és nem hajt végre semmilyen műveletet, kivéve, ha Ön engedélyezi őket

Milyen típusú gépeket támogat az új Azure Monitor Agent?

Közvetlenül telepítheti őket a Virtual Machines, Virtual Machines méretezési csoportokat és csak arc-kompatibilis kiszolgálókat.

Szűrhetők az események az eseményazonosítóval, vagyis részletesebb eseményszűrés az új Azure Monitor Agent használatával?

Igen. Az Xpath-lekérdezésekkel szűrheti az eseményeket a Windows gépeken. További információ
Teljesítményszámlálókhoz megadhatja a gyűjteni kívánt számlálókat, és kizárhatja azokat, amelyekre nincs szüksége. Linux rendszeren a rendszernaplókhoz kiválaszthatja az egyes összegyűjthető létesítmények létesítményeket és naplózási szinteket.

Támogatja az új Azure Monitor, hogy adatokat küld az EventHubsba és az Azure Storage-fiókokba?

Még nem, de az új ügynök és az adatgyűjtési szabályok a jövőben támogatni fogják az adatok Event Hubs Azure Storage-fiókokba való küldését. Figyelje meg az Azure Updates bejelentéseit, vagy csatlakozzon a Teams a gyakori frissítésekhez, támogatáshoz, hírekhez és sok máshoz!

Az új Azure Monitor támogatja a Linuxot?

Ez jelenleg nem érhető el az előzetes verzióban elérhető ügynökhöz, és a ga ga után tervezünk hozzáadni.

Vizualizációk

Miért nem látom a Nézettervező?

Nézettervező csak a Log Analytics-munkaterület közreműködői vagy magasabb szintű engedélyekkel rendelkező felhasználói számára érhető el.

Application Insights

Konfigurációs problémák

Használhatom az Application Elemzések a ...?

Ingyenes?

Igen, kísérleti használatra. Az alapszintű tarifacsomagban az alkalmazás minden hónapban díjmentesen küldhet bizonyos adatokat. Az ingyenes támogatás elég nagy ahhoz, hogy lefedje a fejlesztést és az alkalmazások kis számú felhasználó számára való közzétételét. Beállíthatja a maximális értéket, hogy megakadályozza a megadottnál több adat feldolgozását.

A nagyobb mennyiségű telemetriát a Gb számítja fel. Néhány tippet biztosítunk a díjak korlátozására.

A nagyvállalati csomag minden napért díjat számít fel, amikor az egyes webkiszolgáló-csomópontok telemetriai adatokat küldnek. Ez akkor megfelelő, ha nagy léptékben szeretné használni a Folyamatos exportálást.

Olvassa el a díjszabási tervet.

Mennyibe kerül?

  • Nyissa meg a Használat és becsült költségek lapot egy Application Elemzések erőforrásban. A legutóbbi használat diagramja. Ha szeretné, beállíthatja az adatmennyiségek felső beállítását.
  • Nyissa meg az Azure Billing panelt, és tekintse meg az összes erőforrás számláit.

Mit módosít az Elemzések a projektben?

A részletek a projekt típusától függnek. Webalkalmazások:

  • Hozzáadja ezeket a fájlokat a projekthez:
    • ApplicationInsights.config
    • ai.js
  • Telepíti ezeket a NuGet-csomagokat:
    • Application Elemzések API – a fő API
    • Application Elemzések API for Web Applications – telemetria küld a kiszolgálóról
    • Application Elemzések API For JavaScript Applications – telemetria küldése az ügyfélről
  • A csomagok a következő szerelvényeket tartalmazzák:
    • Microsoft.ApplicationInsights
    • Microsoft.ApplicationInsights.Platform
  • Elemeket szúr be a következőbe:
    • Web.config
    • packages.config
  • (Csak új projektek – ha az Application Elemzések meglévő projekthez adhozzá, ezt manuálisan kell megtennie.) Kódrészleteket szúr be az ügyfél- és kiszolgálókódba, hogy inicializálja őket az alkalmazás Elemzések erőforrás-azonosítójával. Például egy MVC-alkalmazásban a kódot a rendszer beszúrja a Views/Shared/ _ Layout.cshtml főoldalra

Hogyan a régebbi SDK-verziókról?

Tekintse meg az adott alkalmazástípusnak megfelelő SDK kibocsátási megjegyzéseit.

Hogyan módosítom, hogy a projektem melyik Azure-erőforrásnak küldi az adatokat?

A Megoldáskezelő kattintson a jobb gombbal, ApplicationInsights.config és válassza az Update Application Elemzések lehetőséget. Az adatokat elküldheti egy meglévő vagy új Azure-erőforrásnak. A frissítési varázsló módosítja az eszközkulcsot a ApplicationInsights.config, amely meghatározza, hogy a kiszolgálói SDK hová küldi az adatokat. Hacsak nem törölje az "Összes frissítése" kijelölését, az azt a kulcsot is módosítja, ahol az megjelenik a weblapon.

Szükség van-e az új Azure-régiók kapcsolati sztringek használatára?

Az új Azure-régiókhoz kapcsolati sztringek használata szükséges a rendszerkulcsok helyett. A kapcsolati sztring azonosítja azt az erőforrást, amellyel társítani szeretné a telemetriai adatokat. Azt is lehetővé teszi, hogy módosítsa azokat a végpontokat, amelyekre az erőforrás a telemetria célhelyeként fog használni. Ki kell másolnia a kapcsolati sztringet, és hozzá kell adni az alkalmazás kódjához vagy egy környezeti változóhoz.

Használjak kapcsolati sztringeket vagy eszközkulcsokat?

A kapcsolati sztringek használata javasolt a beállítási kulcsokhoz.

Használhatom a `providers('Microsoft.Insights', 'components').apiVersions[0]` következőt a Azure Resource Manager üzemelő példányban?

Nem javasoljuk az API-verzió ezen módszerének használatát. A legújabb verzió jelentheti az előzetes kiadásokat, amelyek akár a legfrissebb változásokat is tartalmazhatnak. Még az újabb, nem előzetes verziók esetén sem mindig kompatibilisek az API-verziók a meglévő sablonokkal, vagy bizonyos esetekben előfordulhat, hogy az API-verzió nem érhető el minden előfizetés számára.

Milyen telemetriát gyűjt az Application Elemzések?

A kiszolgálói webalkalmazásokban:

Az ügyfél weblapjain:

Más forrásokból, ha konfigurálja őket:

Kiszűrhetők vagy módosíthatók bizonyos telemetriai adatok?

Igen, a kiszolgálón megírhatja a következőt:

  • Telemetriafeldolgozó, ha tulajdonságokat szeretne szűrni vagy hozzáadni a kiválasztott telemetriai elemekhez, mielőtt elkülde őket az alkalmazásból.
  • Telemetria-inicializáló, amely tulajdonságokat ad hozzá a telemetria összes elemhez.

További információ a ASP.NET Javáról.

Hogyan történik a város,ország/régió és egyéb földrajzi hely adatainak kiszámítása?

A GeoLite2használatával kinézzük a webes ügyfél IP-címét (IPv4 vagy IPv6).

  • Böngésző-telemetria: Összegyűjtjük a küldő IP-címét.
  • Kiszolgálói telemetria: Az Application Elemzések modul gyűjti az ügyfél IP-címét. Ha be van állítva, a gyűjtés X-Forwarded-For nem történik meg.
  • Ha többet szeretne megtudni arról, hogyan gyűjti a rendszer az IP-címeket és a földrajzihely-adatokat az Application Elemzések tekintse meg ezt a cikket.

A konfigurálható úgy, hogy egy másik ClientIpHeaderTelemetryInitializer fejlécből vegye át az IP-címet. Bizonyos rendszerekben például egy proxy, egy terheléselosztás vagy egy CDN X-Originating-IP áthelyezi. További információ.

A Power BI a kérés telemetriai adatainak térképen való megjelenítéséhez.

Mennyi ideig őrzi meg a rendszer az adatokat a portálon? Biztonságos?

Nézze meg az Adatmegőrzés és adatvédelem részt.

Mi történik az Application Insight telemetriával, ha egy kiszolgáló vagy eszköz kapcsolata megszakad az Azure-ral?

Minden SDK-nk, beleértve a webes SDK-t is, "megbízható szállítást" vagy "robusztus szállítást" tartalmaz. Ha a kiszolgáló vagy az eszköz kapcsolata megszakad az Azure-ral, a telemetria tárolása helyileg történik a fájlrendszerben (Kiszolgáló SDK-k) vagy a HTML5 Session Storage (Web SDK) szolgáltatásban. Az SDK rendszeres időközönként újrapróbálkozás a telemetria elküldése érdekében, amíg az ingestion szolgáltatás "elavultnak" nem tekinti (naplók esetében 48 óra, metrikák esetében 30 perc). Az elavult telemetria el lesz dobva. Bizonyos esetekben, például amikor a helyi tárterület megtelik, az újrapróbálkozás nem történik meg.

Küldhetnénk személyes adatokat a telemetriában?

Ez akkor lehetséges, ha a kód ilyen adatokat küld. Akkor is előfordulhat, ha a veremkövetések változói személyes adatokat tartalmaznak. A fejlesztői csapatnak kockázatfelméréseket kell végeznie a személyes adatok megfelelő kezelése érdekében. További információ az adatmegőrzésről és az adatvédelemről.

Az ügyfél webcímének minden oktettjére mindig 0-ra van állítva a földrajzi hely attribútumainak ki- és betekintő értéke.

Az Application Elemzések JavaScript SDK alapértelmezés szerint nem tartalmaz személyes adatokat az automatikus kiegészítésben. Előfordulhat azonban, hogy az SDK az alkalmazásban használt egyes személyes adatokat (például az XHR URL-lekérdezési paraméterekben szereplő teljes neveket vagy window.title fiók-értékeket) veszi fel. Egyéni személyes adatmaszkoláshoz adjon hozzá egy telemetria-inicializálót.

A saját eszközkulcs látható a weblap forrásában.

  • Ez gyakori eljárás a monitorozási megoldásokban.
  • Nem használható az adatok ellopása érdekében.
  • Az adatok elajátsztása vagy riasztások aktiválása is használható.
  • Nem tudjuk, hogy egy ügyfélnek is voltak ilyen problémái.

Ön ilyenkor az alábbiakat teheti:

  • Használjon két különálló eszközkulcsot (külön Application Elemzések) az ügyfél- és kiszolgálóadatokhoz. Vagy
  • Írjon egy, a kiszolgálón futó proxyt, és a webes ügyféllel küldje el az adatokat ezen a proxyn keresztül.

Hogyan POST-adatokat a diagnosztikai keresésben?

A POST-adatokat nem naplózjuk automatikusan, de használhat TrackTrace-hívást is: helyezze az adatokat az üzenetparaméterbe. Ez hosszabb méretkorlátot ad meg, mint a sztringtulajdonságokra vonatkozó korlátozások, de nem szűrhet rá.

Egy vagy több application Elemzések használnom?

Egyetlen erőforrást használjon egyetlen üzleti rendszer összes összetevőéhez vagy szerepköréhez. Használjon külön erőforrásokat a fejlesztéshez, a teszteléshez és a kiadási verziókhoz, valamint a független alkalmazásokhoz.

Hogyan módosítani a rendszerkulcsot?

Mik a felhasználók és a munkamenetek számai?

  • A JavaScript SDK beállítja a felhasználói cookie-t a webes ügyfélen a visszatérő felhasználók azonosításához, valamint egy munkamenet-cookie-t a tevékenységek csoportosításához.
  • Ha nincs ügyféloldali szkript, a cookie-kat beállíthatja a kiszolgálón.
  • Ha egy valós felhasználó különböző böngészőkben vagy privát/inkognitó módban vagy más gépeken használja a webhelyet, akkor azok egynél több alkalommal lesznek megszámolva.
  • A bejelentkezett felhasználók gépeken és böngészőkben való azonosításához adjon hozzá egy hívást a setAuthenticatedUserContext() hívásával.

Hogyan hoz létre az Elemzések eszközinformációt (böngésző, operációs rendszer, nyelv, modell)?

A böngésző átadja a felhasználói ügynök sztringjét a kérés HTTP-fejlécében, az Application Elemzések ingestion szolgáltatás pedig az UA Parser használatával hozza létre az adattáblákban és -élményekben látható mezőket. Ennek eredményeképpen az Application Elemzések felhasználók nem tudják módosítani ezeket a mezőket.

Előfordulhat, hogy ezek az adatok hiányoznak vagy pontatlanok, ha a felhasználó vagy a vállalat letiltja a felhasználói ügynök küldését a böngésző beállításaiban. Emellett előfordulhat, hogy az UA Parser regexe-ek nem tartalmaznak minden eszközinformációt, vagy az Elemzések nem fogadták el a legújabb frissítéseket.

Mindent engedélyeztem az Application Elemzések?

Mit kell látnia Hogyan lehet behozni? Miért van rá jó?
Rendelkezésre állási diagramok Webes tesztek Annak tudata, hogy a webalkalmazása van
Kiszolgálóalkalmazás 2. 4. válaszideja, ... Az Application Elemzések hozzáadása a projekthez vagy az Install Azure Monitor Application Elemzések Agent a kiszolgálón (vagy saját kód írása a függőségek nyomon követéséhez) Perf-problémák észlelése
Függőségi telemetria Az Azure Monitor Application Elemzések Agent telepítése a kiszolgálón Adatbázisokkal vagy más külső összetevőkkel kapcsolatos problémák diagnosztizálása
Veremkövetések lekérte a kivételekből TrackException hívások beszúrása a kódba (de néhányról a rendszer automatikusan jelentést ad) Kivételek észlelése és diagnosztizálása
Nyomkövetési naplók keresése Naplózási adapter hozzáadása Kivételek és perf problémák diagnosztizálása
Az ügyfél-használat alapjai: lapnézetek, munkamenetek, ... JavaScript-inicializáló weblapok Használatelemzés
Egyéni ügyfélmetrikák Hívások nyomon követése weboldalakon Felhasználói élmény fokozása
Egyéni kiszolgálómetrikák Hívások nyomon követése a kiszolgálón Üzleti intelligencia

Miért nem egyenlők a keresési és metrikadiagramok számai?

A mintavételezés csökkenti az alkalmazásból a portálra ténylegesen küldött telemetriai elemek (kérések, egyéni események stb.) számát. A Keresésben láthatja a ténylegesen fogadott elemek számát. Az események számát megjelenítő metrikadiagramokon láthatja a bekövetkezett eredeti események számát.

Minden átvitt elemhez egy tulajdonság is megjelenik, amely megmutatja, hogy az elem itemCount hány eredeti eseményt képvisel. A mintavételezés működésének megfigyeléséhez futtassa ezt a lekérdezést az Analyticsben:

    requests | summarize original_events = sum(itemCount), transmitted_events = count()

Hogyan egy Application Elemzések-erőforrást egy új régióba?

A meglévő Application Elemzések erőforrások egyik régióból a másikba való áthelyezése jelenleg nem támogatott. Az összegyűjtött előzményadatok nem migrálhatóak új régióba. Az egyetlen részleges áthidaló megoldás a következő:

  1. Hozzon létre egy teljesen új Application Elemzések erőforrást(klasszikus vagy munkaterület-alapú) az új régióban.
  2. Hozza létre újra az eredeti erőforrásra jellemző összes egyedi testreszabást az új erőforrásban.
  3. Módosítsa az alkalmazást úgy, hogy az új régióerőforrás rendszerkulcsát vagy kapcsolati sztringet használja.
  4. Ellenőrizze, hogy minden a várt módon működik-e az új Application Elemzések erőforrással.
  5. Ezen a ponton törölheti az eredeti erőforrást, amely az összes előzményadat elveszhet. Vagy őrizze meg az eredeti erőforrást korábbi jelentéskészítési célokra az adatmegőrzési beállításainak időtartamára.

Az egyedi testreszabások, amelyek általában manuálisan hozhatók létre vagy frissíthetők az erőforráshoz az új régióban, többek között a következők:

  • Egyéni irányítópultok és munkafüzetek újbóli létrehozása.
  • Hozza létre újra vagy frissítse az egyéni napló-/metrikariasztás hatókörét.
  • Rendelkezésre állási riasztások újbóli létrehozása.
  • Hozza létre újra az azure-beli szerepköralapú hozzáférés-vezérlés (Azure RBAC) azon egyéni beállításait, amelyekre a felhasználóknak az új erőforrás eléréséhez szüksége van.
  • Replikálja a beállításokat, beleértve a bebevétel mintavételezését, az adatmegőrzést, a napi felső megőrzést és az egyéni metrikák engedélyezését. Ezeket a beállításokat a Használat és becsült költségek panelen lehet szabályozni.
  • Bármely integráció, amely API-kulcsokra, például kiadási jegyzetekre, élő metrikák biztonságos vezérlési csatornára stb. támaszkodik. Új API-kulcsokat kell létrehoznia, és frissítenie kell a társított integrációt.
  • A folyamatos exportálást a klasszikus erőforrásokon újra kell konfigurálni.
  • A munkaterület-alapú erőforrások diagnosztikai beállításait újra konfigurálni kell.

Megjegyzés

Ha az új régióban létrehoz egy erőforrást, lecserél egy klasszikus erőforrást, javasoljuk, hogy ismerkedjon meg az új munkaterület-alapú erőforrás létrehozásának vagy a meglévő erőforrás munkaterület-alapúra való áttelepítésének előnyeivel.

Automation

Alkalmazáskonfiguráció Elemzések

PowerShell-szkripteket az Azure erőforrás-figyelő meg a következőre:

  • Alkalmazás-erőforrások Elemzések frissítése.
  • Állítsa be a tarifacsomagot.
  • Szerezze be a eszközkulcsot.
  • Metrikariasztás hozzáadása.
  • Rendelkezésre állási teszt hozzáadása.

Nem állíthat be Metrikakezelő-jelentést vagy folyamatos exportálást.

A telemetria lekérdezése

A REST API Analytics-lekérdezések futtatásához.

Hogyan állíthatok be riasztást egy eseményhez?

Az Azure-riasztások csak metrikákon vannak. Hozzon létre egy egyéni metrikát, amely túllépi az értékküszöböt az esemény bekövetkezése esetén. Ezután állítson be egy riasztást a metrikán. Értesítést kap, ha a metrika mindkét irányban átlépi a küszöbértéket; az első átkelésig nem kap értesítést, függetlenül attól, hogy a kezdeti érték magas vagy alacsony; A késés mindig néhány perc.

Vannak adatátviteli díjak az Azure-webalkalmazások és az Elemzések?

  • Ha az Azure-webalkalmazást egy olyan adatközpontban üzemelteti, ahol van application Elemzések gyűjteményvégpont, akkor díjmentes.
  • Ha nincs gyűjteményvégpont a gazdagép adatközpontjában, akkor az alkalmazás telemetriása Azure-beli kimenő díjakat fog fizetni.

Ez nem függ attól, hogy az Application Elemzések erőforrás hol van üzemeltetve. Csupán a végpontok eloszlásától függ.

Küldhetek telemetriát az Application Elemzések portálra?

Javasoljuk, hogy használja az SDK-kat és az SDK API-t. Az SDK-nak több változata is van a különböző platformokon. Ezek az SDK-k pufferelést, tömörítést, szabályozást, újragépelést stb. kezelnek. Az adatbeéklési séma és a végponti protokoll azonban nyilvános.

Figyelhetek intranetes webkiszolgálót?

Igen, de engedélyeznie kell a szolgáltatásokhoz való forgalmat tűzfal-kivételekkel vagy proxyátirányításokkal.

  • QuickPulse (Gyorspulse) https://rt.services.visualstudio.com:443
  • ApplicationIdProvider https://dc.services.visualstudio.com:443
  • TelemetryChannel https://dc.services.visualstudio.com:443

Tekintse át a szolgáltatások és IP-címek teljes listáját itt.

Tűzfal kivétele

Engedélyezze, hogy a webkiszolgáló telemetriát küldjön a végpontokra.

Átjáró átirányítása

A konfiguráció végpontjainak felülírása által irányítsa a forgalmat a kiszolgálóról egy intranetes átjáróra. Ha ezek a "Végpont" tulajdonságok nem jelennek meg a konfigurációban, ezek az osztályok az alább látható alapértelmezett értékeket fogják használni a ApplicationInsights.config.

Az átjárónak a forgalmat a végpont alapcímére kell irányítanunk. A konfigurációban cserélje le az alapértelmezett értékeket a http://<your.gateway.address>/<relative path> következőre: .

Példa ApplicationInsights.config alapértelmezett végpontokkal:

<ApplicationInsights>
  ...
  <TelemetryModules>
    <Add Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryModule, Microsoft.AI.PerfCounterCollector">
      <QuickPulseServiceEndpoint>https://rt.services.visualstudio.com/QuickPulseService.svc</QuickPulseServiceEndpoint>
    </Add>
  </TelemetryModules>
    ...
  <TelemetryChannel>
     <EndpointAddress>https://dc.services.visualstudio.com/v2/track</EndpointAddress>
  </TelemetryChannel>
  ...
  <ApplicationIdProvider Type="Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId.ApplicationInsightsApplicationIdProvider, Microsoft.ApplicationInsights">
    <ProfileQueryEndpoint>https://dc.services.visualstudio.com/api/profiles/{0}/appId</ProfileQueryEndpoint>
  </ApplicationIdProvider>
  ...
</ApplicationInsights>

Megjegyzés

Az ApplicationIdProvider a 2.6.0-stól kezdődően érhető el.

Proxy-áthaladás

A proxy-áthaladás egy számítógép- vagy alkalmazásszintű proxy konfigurálásával érhető el. További információért tekintse meg a dotnet defaultproxyval kapcsolatos cikkét.

Példa Web.config:

<system.net>
    <defaultProxy>
      <proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
    </defaultProxy>
</system.net>

Futtatok rendelkezésre állási webes teszteket intranetes kiszolgálón?

Webes tesztjeink a világ különböző pontjain található jelenléti pontokon futnak. Két megoldás íme:

  • Tűzfalkapu – Engedélyezi a kiszolgálóra vonatkozó kéréseket a webes tesztügynökök hosszú és változtatható listájáról.
  • Írjon egy saját kódot, amely rendszeres időközönként kéréseket küld a kiszolgálónak az intraneten belülről. Erre a célra Visual Studio webes teszteket is futtathat. A tesztelő elküldhet eredményeket az Application Elemzések a TrackAvailability() API használatával.

Mennyi ideig tart a telemetria gyűjtése?

A legtöbb Elemzések 5 perces késéssel rendelkezik. Egyes adatok hosszabb ideig is tarthatnak; általában nagyobb naplófájlok. További információ: Application Elemzések SLA.

Az Application Elemzések

Az "502 hibás átjáró" és az "503-as szolgáltatás nem érhető el" hibákat az Application Elemzések. Ha csak ügyféloldali JavaScriptet használna a monitorozáshoz, ez az elvárt működés lenne, mivel a rendszer a hibaüzenetet a megjelenített monitorozási JavaScript-kódrészletet tartalmazó HTML-fejlécet tartalmazó oldal előtt ad vissza választ.

Ha az 502-es vagy az 503-as válasz olyan kiszolgálóról lett elküldve, amely esetében engedélyezve van a kiszolgálóoldali figyelés, az Application Elemzések SDK gyűjti a hibákat.

Vannak azonban olyan esetek, amikor az Application Elemzések, még akkor sem rögzíti az 502-es vagy 503-as hibát, ha a kiszolgálóoldali figyelés engedélyezve van az alkalmazás webkiszolgálón. Számos modern webkiszolgáló nem teszi lehetővé, hogy az ügyfelek közvetlenül kommunikáljanak, hanem olyan megoldásokat alkalmaznak, mint a fordított proxyk, amelyek oda-vissza adatokat adnak át az ügyfél és az előoldali webkiszolgálók között.

Ebben a forgatókönyvben 502-es vagy 503-as választ lehet visszaadni az ügyfélnek a fordított proxyrétegben található probléma miatt, és az Application Elemzések. A réteg problémáinak észlelése érdekében előfordulhat, hogy a naplókat a fordított proxyról a Log Analyticsbe kell továbbítani, és létre kell hoznia egy egyéni szabályt az 502/503-as válaszok ellenőrzésére. Az 502-es és 503-as hibák gyakori okairól az "502 hibás átjáró" és az "503-asszolgáltatás nem érhető el" hibákkal kapcsolatos Azure App Service-hibaelhárítási cikkben talál további információt.

OpenTelemetry

Mi az az OpenTelemetry?

Új nyílt forráskódú szabvány a megfigyelhetőség érdekében. További információ: https://opentelemetry.io/ .

Miért fektet be a Microsoft/Azure Monitor Application Elemzések az OpenTelemetryba?

A Microsoft az OpenTelemetry egyik legnagyobb közreműködője.

Az OpenTelemetry legfontosabb értéke az, hogy szállítósemleges, és konzisztens API-kat/SZOFTVERDK-kat biztosít a nyelvek között.

Úgy gondoljuk, hogy az OpenTelemetry idővel lehetővé teszi az Azure Monitor ügyfelei számára, hogy a támogatott nyelveken túlra írt alkalmazásokat figyeljék, és bővítsék az ügyfelek számára elérhető rendszerelemetriai kódtárakat. Az OpenTelemetry .NET SDK nagyobb léptékben teljesít, mint elődje, az Application Elemzések SDK.

Végül az OpenTelemetry összhangban van a Microsoft nyílt forráskódra vonatkozó stratégiájával.

Mi az OpenTelemetry állapota?

A teljes megfigyelhetőségi megoldás a megfigyelhetőség mindhárom alappillérét magában foglalja. Az OpenTelemetry közösség jelentős kötelezettséget vállal az elosztott nyomkövetésre, és a specifikációk, valamint a támogatott nyelvi implementációk stabilként vannak megjelölve. A metrikák és a naplók még folyamatban vannak. Azure Monitor egy OpenTelemetry-alapú támogatott telemetriamegoldáson dolgozik, amely csak elosztott nyomkövetést tartalmaz olyan tervekkel, amelyek a többi alappillér hozzáadását tervezik, ahogy az OpenTelemetry-közösségben kiforrnak.

Hogyan tesztelem az OpenTelemetry-t?

Regisztráljon, és csatlakozzon a Azure Monitor application Elemzések korai befogadó közösségéhez https://aka.ms/AzMonOtel a(on).

Hogyan, hogy az OpenTelemetry megfelelő-e számomra?

Az OpenTelemetry közösség stabil vagy kísérleti módszerrel jelzi egy szoftver érettségét. A Azure Monitor "Nyilvános előzetes verzió" és "GA" jelzéssel jelzi a stabilitást és a támogatási kötelezettségvállalást.

Ha Ön egy meglévő Azure Monitor Application Elemzések-ügyfél, akkor még nem javasoljuk, hogy az OpenTelemetry szolgáltatásra minkétere mináljon (kivéve a Java-alkalmazásokat, ahol OpenTelemetry-alapú ajánlatunkat mindenki számára ajánljuk, amelyet 2020novemberében mindenki számára ajánlott.

A jelenlegi Application Elemzések SDK for C#(ASP.NET és ASP.NET Core) és JavaScript (Node.js) vagy OpenCensus Python az Application Elemzések.

Az OpenTelemetry későbbinél hamarabbi megépítési forgatókönyvei közé tartozik a telemetria egyidejűleg történő küldése az Azure Monitor+ egy másik szállítónak, a meglévő rendszerkonvergens protokollok gyűjtése és átkonvergense, vagy az OpenTelemetry-Collectorban elérhető funkciók használata. Az ügyfelek például a kötegelt processzor, a tail-based sampler, és/vagy attribútumfeldolgozó használatával jelentették a jelentést. Bár a meglévő Application Elemzések AZDK-k hasonló funkciókat tartalmaznak, egyes ügyfelek inkább egy ügynökben szeretnék elhelyezni ezt a feldolgozást.

A nyílt forráskódú adattárakban OpenTelemetry-Based Azure Monitor C#, JavaScriptés Python esetében is látható, hogy haladunk előre.

Használhatok előzetes verziójú buildeket éles környezetben?

Mi a különbség a manuális és az automatikus rendszerművelet között?

A manuális rendszer használata az OpenTelemetry API kódolása, amely általában egy nyelvspecifikus SDK egy alkalmazásban való telepítését foglalja magában. A "Manuális" nem jelenti azt, hogy összetett kódot kell írnia az elosztott nyomkövetések időtartamának meghatározásához (bár ez továbbra is lehetőség marad). Az OpenTelemetry-közreműködők által karbantartott eszközkódtárak gazdag és növekvő készlete lehetővé teszi, hogy könnyedén rögzítse a telemetriai jeleket a közös keretrendszerek és kódtárak között.

Az automatikus rendszerkonfiguráció lehetővé teszi a telemetria gyűjtését a konfiguráción keresztül anélkül, hogy az alkalmazás kódjának érintésével érik el. Bár rendkívül kényelmes, általában kevésbé konfigurálható, és nem érhető el minden nyelven.

Az OpenTelemetry automatikus rendszerműveletei tartalmaznak egy Java-ajánlatot, amelyet a Microsoft egy Java 3.Xnevű disztribúción keresztül támogat. A Python és a .NET kísérleti automatikus rendszerműveleteket tartalmaz, amelyeket a Microsoft jelenleg nem támogat. Minden más OpenTelemetry nyelv csak a manuális eszközműveletre összpontosít.

Használhatom az OpenTelemetry-Collectort?

Egyes ügyfelek annak ellenére kezdték használni az OpenTelemetry-Collectort az ügynök alternatívaként, hogy a Microsoft hivatalosan még nem támogatja az alkalmazásfigyelés ügynökalapú megközelítését. Addig is a nyílt forráskódú közösség közzétett egy OpenTelemetry-Collector Azure Monitor Egy Olyan adatgyűjtőt, amely segítségével egyes ügyfelek adatokat küldenek Azure Monitor Application Elemzések.

Tervezzük az ügynökalapú megközelítés támogatását a jövőben, bár a részletek és az idővonal egyelőre nem érhető el. A célunk, hogy biztosítsunk egy útvonalat az OpenTelemetry által támogatott bármely nyelv számára, amelyet az OpenTelemetry Protocol (OTLP Azure Monitor n keresztül küldhet az opentelemetry protokollal. Ez lehetővé teszi, hogy az ügyfelek a támogatott nyelveken túli nyelveken is megfigyelhetik az alkalmazásokat.

Mi a különbség az OpenCensus és az OpenTelemetry között?

Az OpenCensus az OpenTelemetry elődje. A Microsoft segített az OpenTracing és az OpenCensus együttesében az OpenTelemetry létrehozásában, amely a világ egyetlen megfigyelhetőségi szabványa. Azure Monitor jelenleg az éles környezetben ajánlott Python SDK az OpenCensuson alapul, de végül az Azure Monitor összes SDK-ja az OpenTelemetry-ra fog épülni.

Tárolóelemzések

Mit jelent az "Egyéb folyamatok" a Csomópont nézet alatt?

Más folyamatok célja, hogy egyértelműen megértsék a csomópont magas erőforrás-használatának alapvető okát. Ez lehetővé teszi a használat megkülönböztetését a tárolóba helyezni és a nem tárolóba helyezni folyamat között.

Mik ezek az egyéb folyamatok?

Ezek nem tárolóba ezett folyamatok, amelyek a csomóponton futnak.

Hogyan számítjuk ki ezt?

Egyéb folyamatok = Teljes használat AC-ból - Használat tárolóba ezett folyamatból

Az Egyéb folyamatok a következőket foglalják magában:

  • Saját maga által felügyelt vagy felügyelt Kubernetes, nem tárolóba ezett folyamatok

  • Tárolók futásidővel kapcsolatos folyamatai

  • Kubelet

  • A csomóponton futó rendszerfolyamatok

  • Csomóponthardveren vagy virtuális gépen futó egyéb, nem Kubernetes-hez nem használt számítási feladatok

A ContainerLog-tábla lekérdezésekor nem látom az Image és a Name tulajdonság értékeit.

A ciprod12042019-es vagy újabb ügynökverziók esetén a rendszer alapértelmezés szerint nem tölti ki a két tulajdonságot minden naplósorhoz, hogy minimalizálja az összegyűjtött naplóadatokra vonatkozó költségeket. Két lehetőség van a tábla lekérdezésére, amelyek tartalmazzák ezeket a tulajdonságokat az értékükkel:

1. lehetőség

Más táblákat illesztve foglalja bele ezeket a tulajdonságértékeket az eredményekbe.

Módosítsa a lekérdezéseket úgy, hogy tartalmazzák a tábla Image és ImageTag tulajdonságait a ContainerID tulajdonsághoz ContainerInventory való csatlakozáshoz. A ContainerID tulajdonsághoz való csatlakozást a KubepodInventory tábla ContaineName mezőjében használhatja a Name (Név) tulajdonságban (ahogyan korábban megjelent a ContainerLog táblában). Ez az ajánlott lehetőség.

Az alábbi példa egy részletes mintalekérdezés, amely bemutatja, hogyan lehet lekérdezni ezeket a mezőértékeket illesztésekkel.

//lets say we are querying an hour worth of logs
let startTime = ago(1h);
let endTime = now();
//below gets the latest Image & ImageTag for every containerID, during the time window
let ContainerInv = ContainerInventory | where TimeGenerated >= startTime and TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID, Image, ImageTag | project-away TimeGenerated | project ContainerID1=ContainerID, Image1=Image ,ImageTag1=ImageTag;
//below gets the latest Name for every containerID, during the time window
let KubePodInv  = KubePodInventory | where ContainerID != "" | where TimeGenerated >= startTime | where TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID2 = ContainerID, Name1=ContainerName | project ContainerID2 , Name1;
//now join the above 2 to get a 'jointed table' that has name, image & imagetag. Outer left is safer in-case there are no kubepod records are if they are latent
let ContainerData = ContainerInv | join kind=leftouter (KubePodInv) on $left.ContainerID1 == $right.ContainerID2;
//now join ContainerLog table with the 'jointed table' above and project-away redundant fields/columns and rename columns that were re-written
//Outer left is safer so you don't lose logs even if we cannot find container metadata for loglines (due to latency, time skew between data types etc...)
ContainerLog
| where TimeGenerated >= startTime and TimeGenerated < endTime
| join kind= leftouter (
   ContainerData
) on $left.ContainerID == $right.ContainerID2 | project-away ContainerID1, ContainerID2, Name, Image, ImageTag | project-rename Name = Name1, Image=Image1, ImageTag=ImageTag1

2. lehetőség

Engedélyezze újra a gyűjteményt ezekhez a tulajdonságokhoz minden tárolónaplósorhoz.

Ha az első lehetőség a lekérdezések módosítása miatt nem kényelmes, újra engedélyezheti a mezők gyűjtését, ha engedélyezi az ügynökkonfigurációs térképen a beállítást az adatgyűjtés konfigurációs beállításaiban leírtak log_collection_settings.enrich_container_logs szerint.

Megjegyzés

A második lehetőség nem ajánlott olyan nagy fürtök esetén, amelyek 50-esnél több csomóponttal vannak, mert api-kiszolgálóhívásokat hoz létre a fürt minden csomópontján a bővítés végrehajtásához. Ez a beállítás az összegyűjtött naplósorok adatméretét is növeli.

Megtekintem a Grafanában gyűjtött metrikákat?

A Container Insights támogatja a Log Analytics-munkaterületen tárolt metrikák Grafana-irányítópultokon való megtekintését. Biztosítottunk egy sablont, amely a Grafana irányítópult-adattárából tölthető le az első lépésekhez, és amelyből megtudhatja, hogyan lehet további adatokat lekérdezni a figyelt fürtökről az egyéni Grafana-irányítópultokon való megjelenítéshez.

Monitorom az AKS-motorfürtömet a Container Insights segítségével?

A Container Insights támogatja az Azure-ban üzemeltetett AKS-motoron (korábbi nevén ACS-motor) üzembe helyezett tárolók számítási feladatainak monitorozását. További részletekért és a monitorozás engedélyezéséhez szükséges lépések áttekintését lásd: Using Container insights for AKS-engine (Tárolóelemzések használata az AKS-motorhoz).

Miért nem látom az adatokat a Log Analytics-munkaterületen?

Ha az adatok minden nap egy adott időpontban nem jelennek meg a Log Analytics-munkaterületen, előfordulhat, hogy elérte az alapértelmezett 500 MB-os vagy a naponta gyűjthető adatok mennyiségének szabályozására szolgáló napi korlátot. Ha elérte a napi korlátot, az adatgyűjtés leáll, és csak a következő napon folytatódik. Az adathasználat áttekintéséhez és a várt használati minták alapján egy másik tarifacsomagra való frissítéshez lásd: Naplóadatok használata és költségei.

Milyen tároló-államok vannak megadva a ContainerInventory táblában?

A ContainerInventory tábla a leállított és a futó tárolókról is tartalmaz információkat. A táblát az ügynökön belüli munkafolyamat tölti fel, amely lekérdezi a Dockerből az összes (futó és leállított) tárolót, és továbbítja ezeket az adatokat a Log Analytics-munkaterületen.

Hogyan a hiányzó előfizetés-regisztrációval kapcsolatos hibát?

Ha a Hiányzó előfizetés-regisztráció a Microsoft.OperationsManagementhez hibaüzenetet kapja, a probléma megoldásához regisztrálja a Microsoft.OperationsManagement erőforrás-szolgáltatót abban az előfizetésben, amelyben a munkaterület definiálva van. Ennek dokumentációját itt találhatja.

Támogatottak a Kubernetes RBAC-kompatibilis AKS-fürtök?

A tárolófigyelési megoldás nem támogatja a Kubernetes RBAC-t, de a Container Insights támogatja. Előfordulhat, hogy a megoldás részleteit tartalmazó oldal nem a megfelelő információkat mutatja a panelen, amelyek a fürtök adatait mutatják.

Hogyan a Helmen keresztül a kube-system névtérben található tárolók naplógyűjtését?

A kube-system névtérben található tárolókból származó naplógyűjtemény alapértelmezés szerint le van tiltva. A naplógyűjtés úgy engedélyezhető, ha egy környezeti változót ad meg az omsagenten. További információt a Container Insights GitHub oldalon.

Hogyan az omsagentet a legújabb kiadott verzióra?

Az ügynök frissítésével kapcsolatos további információkért lásd: Ügynökkezelés.

Miért vannak több rekordra felosztva a 16 KB-osnál nagyobb naplósorok a Log Analyticsben?

Az ügynök a Docker JSON fájlnaplózási illesztőprogramját használja a tárolók stdout és stderr rögzítéséhez. Ez a naplózási illesztőprogram több sorra osztja fel a 16 KB-osnál nagyobb naplósorokat, amikor az stdoutból vagy az stderrből egy fájlba másol.

Hogyan a többsoros naplózást?

A Container Insights jelenleg nem támogatja a többsoros naplózást, de vannak áthidaló megoldások. Az összes szolgáltatást konfigurálhatja úgy, hogy JSON formátumban írja őket, majd a Docker/Moby egyetlen sorként fogja őket írni.

A naplót becsomagolhatja például JSON-objektumként az alábbi példában látható módon egy node.js alkalmazáshoz:

console.log(json.stringify({ 
      "Hello": "This example has multiple lines:",
      "Docker/Moby": "will not break this into multiple lines",
      "and you will receive":"all of them in log analytics",
      "as one": "log entry"
      }));

Ezek az adatok a következő példához Azure Monitor a naplók lekérdezésekor:

LogEntry : ({"Hello": "This example has multiple lines:","Docker/Moby": "will not break this into multiple lines", "and you will receive":"all of them in log analytics", "as one": "log entry"}

A probléma részletes áttekintését a következő hivatkozáson GitHub meg.

Hogyan Azure AD-hibákat, amikor engedélyezem az élő naplókat?

A következő hibaüzenet jelenhet meg: A kérésben megadott válasz-URL-cím nem egyezik az alkalmazáshoz konfigurált válasz-URL-címekkel: "<alkalmazásazonosító > ". A megoldását a Tárolóadatok megtekintése valós időben a Container Insights segítségével cikkben talál.

Miért nem tudom frissíteni a fürtöt az onboarding után?

Ha a Container Insights AKS-fürtön való engedélyezése után törli azt a Log Analytics-munkaterületet, amelybe a fürt az adatokat küldte, a fürt frissítésének megkísérlése sikertelen lesz. Ennek a helyzetnek a kioldásához le kell tiltania a monitorozást, majd újra engedélyeznie kell, hogy az előfizetés egy másik érvényes munkaterületére hivatkozik. Amikor ismét megpróbálja végrehajtani a fürtfrissítést, a folyamatnak sikeresen le kell fejeződötte.

Milyen portokat és tartományokat kell megnyitnom/engedélyezni az ügynök számára?

Tekintse meg a hálózati tűzfalra vonatkozó követelményeket az Azure,az Azure US Government és a Azure China 21Vianet tárolóalapú ügynökhöz szükséges proxy- és tűzfal-konfigurációs információkért.

Támogatott a Kubernetes-auditnaplók gyűjtése az ARO-fürtökhöz?

Nem, a container Elemzések nem támogatja a Kubernetes-auditnaplók gyűjtését.

Virtuálisgép-elemzések

Tudok egy meglévő munkaterületre is bevetni?

Ha a virtuális gépek már csatlakoztatva vannak egy Log Analytics-munkaterülethez, a virtuálisgép-elemzésekhez való csatlakozáskor továbbra is használhatja ezt a munkaterületet, feltéve, hogy az a támogatott régiók valamelyikében található.

Tudok új munkaterületre is bevetni?

Ha a virtuális gépek jelenleg nem csatlakoznak egy meglévő Log Analytics-munkaterülethez, létre kell hoznia egy új munkaterületet az adatok tárolására. Új alapértelmezett munkaterület létrehozása automatikusan történik, ha egyetlen Azure-beli virtuális gépet konfigurál a virtuális gépek elemzéséhez a Azure Portal.

Ha a szkriptalapú módszer használatát választja, ezeket a lépéseket a Virtuálisgép-elemzések engedélyezése Azure PowerShell vagy Resource Manager sablon használatával cikkben olvashatja.

Mit tegyek, ha a virtuális gépem már egy meglévő munkaterületnek jelent?

Ha már gyűjt adatokat a virtuális gépekről, lehet, hogy már konfigurálta, hogy egy meglévő Log Analytics-munkaterületnek jelentse az adatokat. Ha ez a munkaterület az egyik támogatott régióban van, engedélyezheti a virtuálisgép-elemzéseket a meglévő munkaterületen. Ha a már használt munkaterület nem található a támogatott régiók egyikében sem, akkor jelenleg nem fog tudni virtuálisgép-elemzéseket használni. Folyamatosan dolgozunk a további régiók támogatásán.

Miért nem sikerült a virtuális gépem üzembevétele?

Amikor azure-beli virtuális gépet hoz létre a Azure Portal, a következő lépésekre lesz szükség:

  • Ha ez a lehetőség be van jelölve, a rendszer létrehoz egy alapértelmezett Log Analytics-munkaterületet.
  • A Log Analytics-ügynök az Azure-beli virtuális gépekre egy virtuálisgép-bővítmény használatával telepíthető, ha úgy határoz, hogy szükség van rá.
  • A VM Insights Map Dependency Agent bővítmény használatával telepíthető az Azure-beli virtuális gépekre, ha úgy határozták, hogy szükség van rá.

Az értesítési állapot portálon való visszaküldése érdekében a folyamat során ellenőrizzük a fentiek állapotát. A munkaterület és az ügynök telepítése általában 5–10 percet vesz igénybe. A monitorozási adatok portálon való megtekintése további 5–10 percet is igénybe fog venni.

Ha ön kezdeményezte az üzembe adatokat, és olyan üzeneteket lát, amelyek azt jelzik, hogy a virtuális gépet be kell indítani, akár 30 percet is igénybe vehet, hogy a virtuális gép befejezi a folyamatot.

Nem látok adatokat vagy adatokat a virtuális gép teljesítménydiagramjaiban

A teljesítménydiagramok úgy frissültek, hogy az InsightsMetrics táblában tárolt adatokat használják. A diagramok adatainak csak akkor használhatja az új virtuálisgép-Elemzések frissítéssel. További információkért tekintse meg az ga ga gyIK-et.

Ha nem látja a teljesítményadatokat a lemeztáblában vagy egyes teljesítménydiagramokban, akkor előfordulhat, hogy a teljesítményszámlálók nincsenek konfigurálva a munkaterületen. A probléma megoldásához futtassa a következő PowerShell-szkriptet:.

Miben különbözik a VM Insights térkép funkciója a Service Map?

A VIRTUÁLISGÉP-elemzések leképezés funkciója Service Map, de a következő különbségeket tartalmazza:

  • A Térkép nézet a virtuális gép panelről és a virtuálisgép-elemzésekből érhető el az Azure Monitor.
  • A térkép kapcsolatai most már kattinthatók, és a kiválasztott kapcsolat oldalpaneljén jelennek meg a kapcsolatmetrika-adatok.
  • A térképeket egy új API-val lehet létrehozni, amely jobban támogatja az összetettebb térképeket.
  • A figyelt virtuális gépeket mostantól az ügyfélcsoport csomópontja is tartalmazza, és a fánkdiagramon a figyelt és a nem figyelt virtuális gépek aránya látható a csoportban. A csoport kibontott géplistán is szűrhető.
  • A figyelt virtuális gépek most már szerepelnek a kiszolgálóportcsoport csomópontjaiban, és a fánkdiagramon a figyelt és a nem figyelt gépek aránya látható a csoportban. A csoport kibontott géplistán is szűrhető.
  • A térképstílus frissítve lett, hogy jobban konzisztens legyen az Application Insights Alkalmazástérképe használatával.
  • Az oldalpanelek frissültek, és nem állják meg a Service Map - Update Management, Change Tracking, Security és ügyfélszolgálat.
  • Frissült a leképezni kívánt csoportok és gépek kiválasztásának lehetősége, és mostantól támogatja az előfizetéseket, az erőforráscsoportokat, az Azure-beli virtuálisgép-méretezési csoportokat és a felhőszolgáltatásokat.
  • Nem hozhat létre új virtuálisgép Service Map csoportokat a VM Insights Térkép funkcióban.

Miért pontozott vonalakat mutatnak a teljesítménydiagramjaim?

Ez több okból is előfordulhat. Abban az esetben, ha eltérés van az adatgyűjtésben, a vonalakat pontozottként ábrázoljuk. Ha módosította az engedélyezett teljesítményszámlálók adat mintavételezési gyakoriságát (az alapértelmezett beállítás az adatok gyűjtése 60 másodpercenként), pontozott vonalakat láthat a diagramon, ha szűk időtartományt választ a diagramhoz, és a mintavételezési gyakoriság kisebb, mint a diagramon használt gyűjtőméret (például a mintavételezési gyakoriság 10 percenként, a diagramon minden gyűjtő pedig 5 perc). Ha szélesebb időtartományt választ ki a nézethez, a diagramvonalak pont helyett folytonos vonalként jelennek meg.

Támogatottak a csoportok a virtuálisgép-elemzésekben?

Igen, a függőségi ügynök telepítése után adatokat gyűjtünk a virtuális gépekről a csoportok előfizetés, erőforráscsoport, virtuálisgép-méretezési csoportok és felhőszolgáltatások alapján való megjelenítéséhez. Ha már használt Service Map és létrehozott gépcsoportokat, ezek is megjelennek. A számítógépcsoportok akkor is megjelennek a csoportszűrőben, ha a megtekintő munkaterülethez hozta létre őket.

Hogyan az összesített teljesítménydiagramok 95. percentilisvonalának részleteit?

Alapértelmezés szerint a lista a kiválasztott metrika 95. percentilisének legmagasabb értékével rendelkező virtuális gépeket jeleníti meg, kivéve a Rendelkezésre álló memória diagramot, amely az 5. percentilis legalacsonyabb értékével rendelkező gépeket jeleníti meg. Ha a diagramra kattint, megnyílik a Felső N lista nézet a kiválasztott megfelelő metrikával.

Hogyan kezeli a Térkép funkció a különböző virtuális hálózatok és alhálózatok ismétlődő IP-címeit?

Ha virtuális gépekkel vagy Azure-beli virtuálisgép-méretezési készletekkel használja az IP-címtartományokat az alhálózatok és virtuális hálózatok között, az azt okozhatja, hogy a VM Insights Map helytelen információkat jelenít meg. Ez egy ismert probléma, és vizsgáljuk a felhasználói élmény javítására rendelkezésre álló lehetőségeket.

Támogatja a Térkép funkció az IPv6-ot?

A Térkép funkció jelenleg csak az IPv4-et támogatja, és vizsgáljuk az IPv6 támogatását. Az IPv6-alapú alagútba bújt IPv4-et is támogatjuk.

Amikor betöltek egy térképet egy erőforráscsoporthoz vagy egy másik nagy csoporthoz, a térképet nehéz megtekinteni

Bár a Mapet nagy és összetett konfigurációk kezeléséhez továbbfejlesztjük, rájöttünk, hogy a leképezések sok csomóponttal, kapcsolattal és fürtként működő csomóponttal is bírnak. Elkötelezettek vagyunk amellett, hogy tovább növeljük a támogatást a méretezhetőség növelése érdekében.

Miért különbözik a Teljesítmény lap hálózati diagramja, mint az Azure-beli virtuális gépek áttekintési oldalán található hálózati diagram?

Az Azure-beli virtuális gépek áttekintő oldala diagramokat jelenít meg a gazdagép vendég virtuális gépen végzett tevékenységmérése alapján. Az Azure-beli virtuális gépek áttekintésének hálózati diagramja csak a kiszámlázható hálózati forgalmat jeleníti meg. Ez nem tartalmazza a virtuális hálózatok közötti forgalmat. A virtuális gépek elemzéséhez látható adatok és diagramok a vendég virtuális gépről származó adatokon alapulnak, a hálózati diagram pedig megjeleníti az adott virtuális gépre irányuló összes bejövő és kimenő TCP/IP-forgalmat, beleértve a virtuális hálózatok közötti forgalmat is.

Hogyan történik a VÁLASZidő mérése a VMConnectionben tárolt és a kapcsolati panelen és munkafüzetekben tárolt adatok esetén?

A válaszidő egy közelítés. Mivel nem juk meg az alkalmazás kódját, nem igazán tudjuk, mikor kezdődik a kérés, és mikor érkezik a válasz. Ehelyett azt figyeljük meg, hogy a rendszer egy kapcsolaton küldi el az adatokat, majd visszatér a kapcsolathoz. Ügynökünk nyomon követi ezeket a küldött és fogadási és párosítási kísérleteket: a kérések sorozatát, majd a fogadások sorozatát kérelem/válasz párként értelmezi a rendszer. A műveletek közötti időzítés a válaszidő. Ez magában foglalja a hálózati késést és a kiszolgáló feldolgozási idejét.

Ez a közelítés jól működik a kérésen/válaszon alapuló protokollok esetén: egyetlen kérés érkezik ki a kapcsolaton, és egyetlen válasz érkezik. Ez igaz a HTTP(S)-re (a pipelining nélkül), de más protokollokkal nem elégedett.

Vonatkoznak korlátozások a Log Analytics ingyenes díjszabási csomagjában?

Ha az ingyenes Azure Monitor log Analytics-munkaterülettel konfigurálta a virtuális gépeket, a VM Insights Térkép szolgáltatás csak öt, a munkaterülethez csatlakoztatott gépet fog támogatni. Ha öt virtuális gép csatlakozik egy ingyenes munkaterülethez, leválasztja az egyiket, majd később csatlakozik egy új virtuális géphez, a rendszer nem figyeli az új virtuális gépet, és megjelenik a Térkép lapon.

Ebben a feltételben a rendszer felkéri a Kipróbálom most lehetőségre, amikor megnyitja a virtuális gépet, és kiválasztja a Elemzések lehetőséget a bal oldali panelen, még akkor is, ha már telepítve van a virtuális gépen. A rendszer azonban nem kéri fel a beállításokat, mint általában akkor, ha a virtuális gép nincs elővetve a virtuálisgép-elemzésekhez.

SQL (előzetes verzió)

A SQL Server verziói támogatottak?

A 2012 SQL Server és az összes újabb verziót támogatjuk. További részletekért lásd: Támogatott verziók.

Milyen SQL támogatott erőforrástípusok?

  • Azure SQL Database
  • Felügyelt Azure SQL-példány
  • SQL Server Azure Virtual Machines (SQL Server virtuális gép szolgáltatójával regisztrált virtuális gépeken futó SQL)
  • Azure-beli virtuális gépek (SQL Server virtuális gépeken futó virtuális gépek, amelyek nem regisztrálva vannak SQL virtuálisgép SQL szolgáltatónál)

A támogatott verziókról további részleteket és a támogatást és korlátozott támogatást nem tartalmazó forgatókönyvekről itt talál további információt.

Milyen operációs rendszerek támogatottak a virtuális SQL Server gépeken?

Az Azure-beli virtuális gépek Windows Linux-dokumentációja által SQL Server operációs rendszereket Virtual Machines.

Milyen operációs rendszer támogatott a monitorozási virtuális géphez?

Jelenleg az Ubuntu 18.04 az egyetlen operációs rendszer, amelyet a monitorozási virtuális gép támogat.

Hol lesznek tárolva a monitorozási adatok a Log Analyticsben?

Az összes monitorozási adat az InsightsMetrics táblában van tárolva. A Forrás oszlop értéke solutions.azm.ms/telegraf/SqlInsights . A Névtér oszlop értékei a következővel kezdődnek: sqlserver_ .

Milyen gyakran gyűjtik az adatokat?

Az adatgyűjtés gyakorisága testre szabható. Az alapértelmezett gyakoriságokkal SQL információkért lásd az SQL által gyűjtött adatokat, a gyakoriságok testreszabásával kapcsolatos útmutatásért pedig tekintse meg SQL monitorozási profil létrehozása.

Következő lépések

Ha itt nem talál választ a kérdésére, az alábbi fórumokon további kérdéseket és válaszokat találhat.

A visszajelzésekkel kapcsolatos általános Azure Monitor a visszajelzési fórumon.