Az Azure Monitor szolgáltatási korlátai
Ez a cikk az Azure Monitor különböző területeire vonatkozó korlátozásokat sorolja fel.
Riasztások
Erőforrás | Alapértelmezett korlát | Maximális korlát |
---|---|---|
Metrikariasztások | Előfizetésenként 5000 aktív riasztási szabály a nyilvános Azure-ban, a 21Vianet által üzemeltetett Microsoft Azure-ban és az Azure Government-felhőkben. Ha eléri ezt a korlátot, vizsgálja meg, hogy használhatja-e ugyanazt a típusú többerőforrás-riasztást. Riasztási szabályonként 10 000 metrikaidősor. |
Hívja fel az ügyfélszolgálatot. |
Tevékenységnapló-alapú riasztások | Előfizetésenként 100 aktív riasztási szabály (nem növelhető). Mivel ez a korlát nem növelhető, érdemes lehet a tevékenységnaplókat egy Log Analytics-munkaterületre küldeni, és inkább naplókeresési riasztásokat létrehozni, ha előfizetésenként nagyobb számú szabályra van szüksége. |
Ugyanaz, mint az alapértelmezett. |
Eseménynapló-alapú riasztások | Előfizetésenként 5000 aktív riasztási szabály. Ebből 100 aktív riasztási szabály 1 perces gyakorisággal. Erőforrásonként 1000 aktív riasztási szabály. Minden állapot nélküli riasztási szabály legfeljebb 6000 riasztást indíthat kiértékelésenként. Minden állapotalapú riasztási szabály legfeljebb 300 riasztást indíthat kiértékelésenként. Riasztási szabályonként legfeljebb 5000 aktivált állapotalapú riasztás. A naplóriasztási szabály tulajdonságaiban szereplő összes adat együttes mérete nem haladhatja meg a 64 KB-ot. A Kusto-lekérdezés eredménye nem haladhatja meg a 20 MB-ot. |
Hívja fel az ügyfélszolgálatot. |
Riasztásfeldolgozási szabályok | Előfizetésenként 1000 aktív szabály. | Hívja fel az ügyfélszolgálatot. |
Riasztási szabályok és riasztásfeldolgozási szabályok leírása | Naplókeresési riasztások 4096 karakterből állnak. Minden más 2048 karakterből áll. |
Ugyanaz, mint az alapértelmezett. |
Riasztások API
Az Azure Monitor-riasztások számos szabályozási korláttal rendelkeznek, hogy védelmet nyújtsanak a túl sok hívást kezdeményező felhasználók ellen. Az ilyen viselkedés potenciálisan túlterhelheti a rendszer háttérerőforrását, és veszélyeztetheti a szolgáltatás válaszkészségét. Az alábbi korlátok célja, hogy megvédjék az ügyfeleket a megszakításoktól, és egységes szolgáltatási szintet biztosítsanak. A felhasználók szabályozása és korlátozásai csak a szélsőséges használati helyzetekre vannak hatással. Ezek nem lehetnek relevánsak a tipikus használathoz.
Feljegyzés
Az API-hívások száma példányonként korlátozott. A példányok számának pontos korlátszáma.
Erőforrás | Alapértelmezett korlát | Maximális korlát |
---|---|---|
Riasztások – Összegzés lekérése | Előfizetésenként percenként 50 hívás | Ugyanaz, mint az alapértelmezett |
Riasztások – Az összes lekérése (nem "Get By ID") | Előfizetésenként percenként 100 hívás | Ugyanaz, mint az alapértelmezett |
Minden más riasztási hívás | Előfizetésenként percenként 1000 hívás | Ugyanaz, mint az alapértelmezett |
Műveletcsoportok
Korlátlan számú műveletcsoportot használhat egy előfizetésben.
Erőforrás | Alapértelmezett korlát | Maximális korlát |
---|---|---|
Azure-alkalmazás leküldése | Műveletcsoportonként 10 Azure-alkalmazásművelet. | Ugyanaz, mint az alapértelmezett |
1000 e-mail művelet egy műveletcsoportban. Óránként legfeljebb 100 e-mail található minden egyes e-mail-címhez régiónként Az e-mail-címek karakterkorlátja 64. Az e-mailek karakterkorlátja 55296. Tekintse meg a sebességkorlátozó információkat is. |
Ugyanaz, mint az alapértelmezett | |
Azure Resource Manager-szerepkör küldése e-mailben | Műveletcsoportonként 10 E-mail ARM-szerepkörművelet. Éles környezetben: Régiónként legfeljebb 100 e-mail egy óra alatt. Tesztműveleti csoportban: Legfeljebb két e-mail egy (1) percenként. |
Ugyanaz, mint az alapértelmezett |
Event Hubs | Műveletcsoportonként 10 Event Hubs-művelet. | Ugyanaz, mint az alapértelmezett |
ITSM | 10 ITSM-művelet egy műveletcsoportban. | Ugyanaz, mint az alapértelmezett |
Logikai alkalmazás | 10 logikai alkalmazásművelet egy műveletcsoportban. | Ugyanaz, mint az alapértelmezett |
Forgatókönyv | 10 runbook-művelet egy műveletcsoportban. | Ugyanaz, mint az alapértelmezett |
Biztonságos webhook | 10 biztonságos webhookművelet egy műveletcsoportban. A webhookhívások maximális száma előfizetésenként percenként 1500. | Ugyanaz, mint az alapértelmezett |
SMS | 10 SMS-művelet egy műveletcsoportban. Éles környezetben: Öt percenként legfeljebb egy SMS-üzenet. Tesztműveletcsoportban: Percenként legfeljebb egy SMS. |
Ugyanaz, mint az alapértelmezett |
Hang | 10 hangművelet egy műveletcsoportban. Éles környezetben: Öt percenként legfeljebb egy hanghívás. Tesztműveletcsoportban: Percenként legfeljebb egy hanghívás. |
Ugyanaz, mint az alapértelmezett |
Webhook | 10 webhookművelet egy műveletcsoportban. A webhookhívások maximális száma előfizetésenként percenként 1500. | Ugyanaz, mint az alapértelmezett |
Automatikus méretezés
Erőforrás | Alapértelmezett korlát | Maximális korlát |
---|---|---|
Automatikus skálázási beállítások | Régiónként 100 előfizetésenként. | Ugyanaz, mint az alapértelmezett |
Automatikus méretezési profilok | Automatikus méretezési beállításonként 20 profil. | Ugyanaz, mint az alapértelmezett |
Prometheus-metrikák
Lenyelés
Az Azure által felügyelt Prometheus egy kis- és nagybetűket érzéketlen rendszer. A program a karakterláncokat, például a metrikus neveket, a címkék neveit vagy a címkeértékeket azonos idősornak tekinti, ha azok csak a karakterlánc esetében különböznek a másik idősoroktól. További információ: Prometheus-metrikák áttekintése.
Az alábbi korlátozások a Prometheus-metrikákat tartalmazó Azure Monitor-munkaterületre vonatkoznak.
Korlát | Érték |
---|---|
Aktív idősor az elmúlt ~12 órában jelentett metrikákkal. | 1,000,000 Kérhet emelést. |
Események percenként betöltve. | 1,000,000 Kérhet emelést. |
Az alábbi korlátozások az adatgyűjtési szabályra (DCR) és az adatgyűjtési végpontra (DCE) vonatkoznak, amely Prometheus-metrikák adatait küldi el az Azure Monitor-munkaterületre.
Korlát | Érték |
---|---|
Adatgyűjtő végpontra irányuló percenkénti betöltési kérelmek | 15 000 Ez a korlát nem növelhető. |
Adatbetöltés percenként egy adatgyűjtési végpontra | 50 GB Ez a korlát nem növelhető. |
Lekérdezések
A Prometheus-lekérdezések a PromQL használatával jönnek létre, és az Azure Managed Grafana vagy az ön által felügyelt Grafana használatával hozhatók létre.
Korlát | Érték |
---|---|
Adatmegőrzés | 18 hónap. Ez a korlát nem növelhető. |
Lekérdezési időtartomány | A PromQL-lekérdezés kezdési és befejezési időpontja között 32 nap. Ez a korlát nem növelhető. |
Lekérdezési idősorok metrikánként | 500 000 idősor. |
Visszaadott lekérdezésminták | Lekérdezésenként 50 000 000 minta. |
Lekérdezési lépés minimális mérete időtartomány >= 48 óra |
60 másodperc. |
Adatkorlátok lekérdezése
Ügyfélforgalom esetén:
Korlát | Érték |
---|---|
Az ablak keresési hosszának szabályozása | 30 másodperc |
Azure Monitor-munkaterületenként visszaadott adatok | 0,5 GB |
Szabályforgalom rögzítéséhez:
Korlát | Érték |
---|---|
Az ablak keresési hosszának szabályozása | 3 perc |
Azure Monitor-munkaterületenként visszaadott adatok | 1 GB |
Lekérdezések előzetes elemzési korlátai
A lekérdezési időtartomány és a kérés típusa alapján egy 30 másodperces ablakban (ügyfélforgalom esetén):
Korlát | Érték |
---|---|
Lekérdezési órák felhasználónként (Microsoft Entra-azonosító, felügyelt identitás, Azure Managed Grafana-munkaterület) | 30 000 |
Lekérdezési órák Azure Monitor-munkaterületenként | 60 000 |
Azure-bérlőnkénti lekérdezési órák | 600,000 |
A lekérdezési időtartomány és a kérés típusa alapján egy 3 perces időszakon keresztül (a szabályok forgalmának rögzítéséhez):
Korlát | Érték |
---|---|
Lekérdezési órák Azure Monitor-munkaterületenként | 60 000 |
Azure-bérlőnkénti lekérdezési órák | 600,000 |
Lekérdezések elemzés utáni korlátai
A lekérdezés időtartománya és tartományvektorai alapján egy 30 másodperces ablakban (ügyfélforgalom esetén):
Korlát | Érték |
---|---|
Lekérdezési órák felhasználónként (Microsoft Entra-azonosító, felügyelt identitás, Azure Managed Grafana-munkaterület) | 2,000,000 |
Lekérdezési órák Azure Monitor-munkaterületenként | 2,000,000 |
Azure-bérlőnkénti lekérdezési órák | 20,000,000 |
A lekérdezés időtartománya és tartományvektorai alapján egy 3 perces ablakban (a szabályok forgalmának rögzítéséhez):
Korlát | Érték |
---|---|
Lekérdezési órák Azure Monitor-munkaterületenként | 2,000,000 |
Azure-bérlőnkénti lekérdezési órák | 20,000,000 |
Költségszabályozási korlátok lekérdezése
Korlát | Érték |
---|---|
Lekérdezésenkénti lekérdezési költség maximális száma | 15 000 |
A szabályok lekérdezésének rögzítéséhez szükséges lekérdezési költségek maximális száma | 3000 |
A lekérdezés költségszámítása az alábbiak szerint történik:
Lekérdezési költség = (Kért idősorok száma * (lekérdezett idő másodpercben / Lekérdezett adatok késleltetett időfeloldása)) / 5000
Lekérdezett adatok késleltetett időfeloldása = A lekérdezett metrikák véletlenszerűen kiválasztott idősorkulcsaiban tárolt adatpontok száma másodpercben
Feljegyzés
A lekérdezés egyetlen metrikája legfeljebb 64 MB méretű bájtban a lekérdezésben kért idősorkulcsok eredményéhez.
Riasztási és rögzítési szabályok
A Prometheus riasztási szabályai és a rögzítési szabályok a PromQL-ben vannak definiálva. Ezeket a felügyelt Vonalzó szolgáltatáson hajtják végre a Prometheushoz készült Azure Monitor felügyelt szolgáltatás részeként.
Korlát | Érték |
---|---|
Szabálycsoportok Azure Monitor-munkaterületenként egy Azure-előfizetésben | 500 Kérhet emelést. |
Szabályok szabálycsoportonként | 20 Ez a korlát nem növelhető. |
Szabálycsoport kiértékelési időköze | 1 perc és 24 óra között. Az alapértelmezett érték 1 perc. |
Aktív riasztások | Jelenleg nincs korlátozás. |
Távoli írás
A számításokat egy 500-es távoli kötegméret használatával határozták meg, amely az alapértelmezett.
Korlát | Érték |
---|---|
Processzorhasználat | 0,25 x (metrikák száma) + 1,25 x (az adatsorok átlagos száma metrikánként) |
CPU-kérés | 0,75 x (processzorhasználat) |
CPU-korlát | 2 x (CPU-kérés) |
Memóriakérelem | 150 Mb |
Memóriakorlát | 200 Mb |
Maximális átviteli sebesség | A távoli írási tároló legfeljebb 150 000 egyedi idősort képes feldolgozni. A tároló az egyidejű kapcsolatok magas száma miatt 150 000-esnél több kérést kiszolgáló hibákat jelezhet. Ez a probléma a távoli kötegméret 500-ról 1000-re való növelésével hárítható el. Ez a módosítás csökkenti a nyitott kapcsolatok számát. |
Logs Ingestion API
Korlát | Érték | Megjegyzések |
---|---|---|
API-hívás maximális mérete | 1 MB | Tömörített és tömörítetlen adatok is. |
Mezőértékek maximális mérete | 64 KB | A 64 KB-nál hosszabb mezők csonkoltak. |
DCR-enként maximális adat/perc | 2 GB | Tömörített és tömörítetlen adatok is. Próbálkozzon újra a válasz fejlécében Retry-After szereplő időtartam után. |
Kérelmek maximális száma/perc/DCR | 12 000 | Próbálkozzon újra a válasz fejlécében Retry-After szereplő időtartam után. |
Adatgyűjtési szabályok
Korlát | Érték |
---|---|
Adatforrások maximális száma | 10 |
Számlálók maximális száma a teljesítményszámlálóban | 100 |
Létesítménynevek maximális száma a Syslogban | 20 |
XPath-lekérdezések maximális száma az eseménynaplóban | 100 |
Adatfolyamok maximális száma | 10 |
Adatfolyamok maximális száma | 10 |
Bővítmények maximális száma | 10 |
A bővítménybeállítások maximális mérete | 32 Kb |
Log Analytics-munkaterületek maximális száma | 10 |
Az átalakításban szereplő karakterek maximális száma | 15,360 |
Diagnosztikai beállítások
Erőforrás | Alapértelmezett korlát | Felső korlát |
---|---|---|
Diagnosztikai beállítások maximális száma erőforrásonként | 5 | Ugyanaz, mint az alapértelmezett. |
Napló lekérdezések és nyelv
Általános lekérdezési korlátok
Korlát | Leírás |
---|---|
Lekérdezés nyelve | Az Azure Monitor ugyanazt a Kusto lekérdezésnyelv (KQL) használja, mint az Azure Data Explorer. Tekintse meg az Azure Monitor naplólekérdezési nyelvi különbségeit az Azure Monitorban nem támogatott KQL nyelvi elemek esetében. |
Azure-régiók | A naplózási lekérdezések túlzott többletterhelést okozhatnak, ha az adatok több Azure-régióban lévő Log Analytics-munkaterületekre terjednek ki. Részletekért tekintse meg a lekérdezés korlátait . |
Erőforrásközi lekérdezések | Az Application Insights-erőforrások és a Log Analytics-munkaterületek maximális száma egyetlen lekérdezésben legfeljebb 100. Az erőforrásközi lekérdezés nem támogatott a Nézettervezőben. A naplóriasztásokban lévő erőforrásközi lekérdezések támogatottak az új ütemezettQueryRules API-ban. Részletekért tekintse meg az erőforrásközi lekérdezés korlátait . |
Log Analytics-irányítópult lekérdezései | Egyetlen Log Analytics-irányítópult lekérdezésében visszaadott rekordok maximális száma 2000. |
Felhasználói lekérdezés szabályozása
Az Azure Monitor számos szabályozási korlátozással rendelkezik a túl sok lekérdezést küldő felhasználók ellen. Az ilyen viselkedés potenciálisan túlterhelheti a rendszer háttérerőforrását, és veszélyeztetheti a szolgáltatás válaszkészségét. Az alábbi korlátok célja, hogy megvédjék az ügyfeleket a megszakításoktól, és egységes szolgáltatási szintet biztosítsanak. A felhasználó szabályozása és korlátozásai csak a szélsőséges használati helyzetekre vannak hatással, és nem lehetnek relevánsak a tipikus használathoz.
Mérőszám | Felhasználónkénti korlát | Leírás |
---|---|---|
Egyidejű lekérdezések | 5 | A felhasználók legfeljebb öt egyidejű lekérdezést futtathatnak. A rendszer minden más lekérdezést hozzáad egy üzenetsorhoz. Amikor az egyik futó lekérdezés befejeződik, a rendszer az üzenetsor első lekérdezését lekérte az üzenetsorból, és elindul. A riasztási lekérdezések nem részei ennek a korlátnak. |
Idő egyidejűségi üzenetsorban | 3 perc | Ha egy lekérdezés 3 percnél hosszabb ideig ül az üzenetsorban anélkül, hogy elindítanák, a 429-ben kódolt HTTP-hibaválaszsal végződik. |
Az egyidejűségi üzenetsor összes lekérdezése | 200 | Amikor az üzenetsor lekérdezéseinek száma eléri a 200-ot, a következő lekérdezést a rendszer a 429-es HTTP-hibakóddal elutasítja. Ez a szám az egyidejűleg futtatható öt lekérdezésen kívül van. |
Lekérdezések sebessége | 200 lekérdezés 30 másodpercenként | Az egy felhasználó által az összes munkaterületre elküldhető lekérdezések összesített aránya. Ez a korlátozás olyan vizualizációs részek által kezdeményezett programozott lekérdezésekre vagy lekérdezésekre vonatkozik, mint az Azure-irányítópultok és a Log Analytics-munkaterület összefoglaló (elavult) oldala. |
- A tevékenységnaplók API-nak 30 másodpercenként 50 lekérdezésre vonatkozó külön sebességkorlátja van.
- Optimalizálja a lekérdezéseket az Azure Monitor napló lekérdezésének optimalizálása című cikkben leírtak szerint.
- Az irányítópultok és a munkafüzetek egyetlen nézetben több lekérdezést is tartalmazhatnak, amelyek minden betöltéskor vagy frissítéskor nagy számú lekérdezést eredményezhetnek. Érdemes lehet ezeket több nézetre felosztani, amelyeket igény szerint lehet majd betölteni.
- A Power BI-ban érdemes lehet a nyers naplók helyett csak az aggregált eredményeket lekérni.
Log Analytics-munkaterületek
Adatgyűjtés mennyisége és megőrzése
Tarifacsomag | Napi korlát | Adatmegőrzés | Megjegyzés |
---|---|---|---|
Használatalapú fizetés (bevezetve: 2018. április) |
Korlátlan | Akár 730 napos interaktív megőrzés/ legfeljebb 12 éves adatarchívum |
A 31 napnál hosszabb adatmegőrzés további díjakért érhető el. További információ az Azure Monitor díjszabásáról. |
Kötelezettségvállalási szintek (bevezetve: 2019. november) |
Korlátlan | Akár 730 napos interaktív megőrzés/ legfeljebb 12 éves adatarchívum |
A 31 napnál hosszabb adatmegőrzés további díjakért érhető el. További információ az Azure Monitor díjszabásáról. |
Örökölt csomópontonként (OMS) (bevezetve: 2016. április) |
Korlátlan | 30–730 nap | A 31 napnál hosszabb adatmegőrzés további díjakért érhető el. További információ az Azure Monitor díjszabásáról. A hozzáférési szint csak olyan előfizetésekre korlátozódik, amelyek 2018. április 2-án Log Analytics-munkaterületet vagy Application Insights-erőforrást tartalmaztak, vagy amelyek egy 2019. február 1- je előtt elindított Nagyvállalati Szerződés vannak társítva, és továbbra is aktívak. |
Örökölt önálló szint (bevezetve: 2016. április) |
Korlátlan | 30–730 nap | A 31 napnál hosszabb adatmegőrzés további díjakért érhető el. További információ az Azure Monitor díjszabásáról. A hozzáférési szint csak olyan előfizetésekre korlátozódik, amelyek 2018. április 2-án Log Analytics-munkaterületet vagy Application Insights-erőforrást tartalmaztak, vagy amelyek egy 2019. február 1- je előtt elindított Nagyvállalati Szerződés vannak társítva, és továbbra is aktívak. |
Örökölt ingyenes szint (bevezetve: 2016. április) |
500 MB | 7 nap | Amikor a munkaterület eléri a napi 500 MB-os korlátot, az adatbetöltés leáll, és a következő nap elején folytatódik. A napi elszámolás UTC-alapú. Az Felhőhöz készült Microsoft Defender által gyűjtött adatok nem szerepelnek ebben a napi 500 MB-os korlátban, és továbbra is ezen korlát felett lesznek összegyűjtve. Az örökölt ingyenes próbaverziós tarifacsomagban új munkaterületek létrehozása vagy meglévő munkaterületek áthelyezése csak 2022. július 1-ig lehetséges. |
Örökölt standard szint | Korlátlan | 30 nap | A megőrzés nem módosítható. Ez a szint 2016. október 1. óta nem érhető el új munkaterületek számára. |
Örökölt prémium szint | Korlátlan | 365 nap | A megőrzés nem módosítható. Ez a szint 2016. október 1. óta nem érhető el új munkaterületek számára. |
Munkaterületek száma előfizetésenként
Tarifacsomag | Munkaterület korlátja | Megjegyzések |
---|---|---|
Örökölt ingyenes szint | 10 | Ez a korlát nem növelhető. Az örökölt ingyenes próbaverziós tarifacsomagban új munkaterületek létrehozása vagy meglévő munkaterületek áthelyezése csak 2022. július 1-ig lehetséges. |
Minden más szint | Korlátlan | Az erőforráscsoporton belüli erőforrások száma és az előfizetésenkénti erőforráscsoportok száma korlátozza. |
Azure Portalra
Kategória | Korlát | Megjegyzések |
---|---|---|
Napló lekérdezés által visszaadott rekordok maximális száma | 30 000 | A lekérdezés hatókörének, időtartományának és szűrőinek használatával csökkentheti az eredményeket. |
Data Collector API
Kategória | Korlát | Megjegyzések |
---|---|---|
Egyetlen bejegyzés maximális mérete | 30 MB | Nagyobb kötetek felosztása több bejegyzésre. |
Mezőértékek maximális mérete | 32 kB | A 32 KB-nál hosszabb mezők csonkolva lesznek. |
Lekérdezés API
Kategória | Korlát | Megjegyzések |
---|---|---|
Egyetlen lekérdezésben visszaadott rekordok maximális száma | 500,000 | |
Visszaadott adatok maximális mérete | ~104 MB (~100 MiB) | Az API legfeljebb 64 MB tömörített adatot ad vissza, ami akár 100 MB nyers adatra is lefordítható. |
Lekérdezések maximális futási ideje | 10 perc | Részletekért tekintse meg az időtúllépéseket . |
Maximális kérelemarány | 200 kérés 30 másodpercenként a Microsoft Entra-felhasználó vagy az ügyfél IP-címe alapján | Lásd: Napló lekérdezések és nyelv. |
Azure Monitor-naplók összekötője
Kategória | Korlát | Megjegyzések |
---|---|---|
Az adatok maximális mérete | ~16,7 MB (~16 MIB) | Az összekötő-infrastruktúra azt diktálja, hogy a korlát alacsonyabb legyen, mint a lekérdezési API-korlát. |
Rekordok maximális száma | 500,000 | |
Az összekötő maximális időtúllépése | 110 másodperc | |
Maximális lekérdezési időtúllépés | 100 másodperc | |
Diagramok | A Naplók lap és az összekötő különböző diagramtárakat használ a vizualizációhoz. Néhány funkció jelenleg nem érhető el az összekötőben. |
Összefoglaló szabályok
Kategória | Korlát |
---|---|
Aktív szabályok maximális száma egy munkaterületen | 30 |
Találatok maximális száma tárolónként | 500,000 |
A maximális eredményhalmaz kötete | 100 MB |
Lekérdezési időtúllépés a tárolók feldolgozásához | 10 perc |
Általános munkaterületkorlátok
Kategória | Korlát | Megjegyzések |
---|---|---|
Táblák oszlopainak maximális száma | 500 |
AzureDiagnostics – a korlát feletti oszlopok hozzáadódnak a dinamikus "AdditionalFields" oszlophoz Az Adatgyűjtő API által létrehozott egyéni napló – a korlát feletti oszlopok hozzáadódnak a dinamikus "AdditionalFields" oszlophoz Egyéni napló – további információért forduljon az ügyfélszolgálathoz |
Egyéni naplótáblák maximális száma | 500 | További információért forduljon az ügyfélszolgálathoz |
Oszlopnév maximális karakterei | 45 |
Adatbetöltési kötetek sebessége
Az Azure Monitor egy nagy léptékű adatszolgáltatás, amely több ezer ügyfelet szolgál ki, akik naponta több terabájtnyi adatot küldenek, és egyre nagyobb ütemben. Egy puha kötetsebesség-korlát el kívánja különíteni az Azure Monitor-ügyfeleket a több-bérlős környezet hirtelen betöltési csúcsaitól. A munkaterületeken az alapértelmezett betöltési sebesség küszöbértéke 500 MB (tömörített), amely körülbelül 6 GB/perc tömörítetlenre van lefordítva.
A kötetsebesség-korlát a munkaterület-alapú Application Insightsból, az Azure-erőforrásokból diagnosztikai beállításokon keresztül betöltött adatokra és a Data Collector API-ra vonatkozik. A kötetsebesség-korlát elérésekor egy újrapróbálkozási mechanizmus 12 óra alatt négyszer próbálja meg beolvasni az adatokat, és elvetni, ha a művelet meghiúsul. A korlát nem vonatkozik az ügynököktől vagy az adatgyűjtési szabályon (DCR) keresztül betöltött adatokra.
Ha a kötetmennyiség meghaladja a munkaterület küszöbértékének 80%-át, a rendszer 6 óránként küld egy eseményt a Operation
munkaterület táblájának, miközben a küszöbérték meghaladja a küszöbértéket. Ha a betöltendő mennyiség nagyobb, mint a küszöbérték, egyes adatok el lesznek dobva, a rendszer 6 óránként küld egy eseményt a Operation
munkaterület táblájának, amíg a küszöbérték túllépi a küszöbértéket.
Ha a betöltési mennyiség sebessége meghaladja a küszöbértéket, vagy a küszöbértéket elérő betöltési mennyiséget szeretné növelni, forduljon az ügyfélszolgálathoz, és kérje a sebességkorlát növelését a munkaterületen.
Javasoljuk, hogy hozzon létre egy riasztási szabályt, amely értesítést küld a betöltési sebességkorlátok közeledésekor vagy elérésekor. Lásd: Log Analytics-munkaterület állapotának monitorozása az Azure Monitorban.
Feljegyzés
Attól függően, hogy mennyi ideig használja a Log Analyticst, előfordulhat, hogy rendelkezik hozzáféréssel az örökölt tarifacsomagokhoz. További információ a Log Analytics örökölt tarifacsomagjairól.
Application Insights
Az alkalmazásonkénti metrikák és események, vagyis a rendszerállapot-kulcsok száma korlátozott. A korlátozások a választott díjszabási csomagtól függően változnak.
Erőforrás | Alapértelmezett korlát | Maximális korlát | Jegyzetek |
---|---|---|---|
Napi teljes adatmennyiség | 100 GB | Kapcsolatfelvétel az ügyfélszolgálattal. | Az adatok csökkentéséhez beállíthat egy korlátot. Ha több adatra van szüksége, a portálon akár 1000 GB-ra is növelheti a korlátot. Az 1000 GB-nál nagyobb kapacitások esetén küldjön e-mailt a következő címre AIDataCap@microsoft.com: . |
Szabályozás | 32 000 esemény/másodperc | Kapcsolatfelvétel az ügyfélszolgálattal. | A korlát megállapítása egy percnyi mérés alapján történik. |
Adatmegőrzési naplók | 30–730 nap | 730 nap | Ez az erőforrás naplókhoz készült. |
Adatmegőrzési metrikák | 90 nap | 90 nap | Ez az erőforrás a Metrics Explorerhez készült. |
Rendelkezésre állási többlépéses teszt részletes eredményeinek megőrzése | 90 nap | 90 nap | Ez az erőforrás minden lépésről részletes eredményeket biztosít. |
Telemetriai elemek maximális mérete | 64 KB | 64 KB | |
Telemetriaelemek maximális száma kötegenként | 64,000 | 64,000 | |
Tulajdonság- és metrikanév hossza | 150 | 150 | Lásd a típussémákat. |
Tulajdonságérték-sztring hossza | 8,192 | 8,192 | Lásd a típussémákat. |
Nyomkövetési és kivételüzenet hossza | 32,768 | 32,768 | Lásd a típussémákat. |
A rendelkezésre állási tesztek száma Application Insights-erőforrásonként | 100 | 100 | |
Rendelkezésre állási tesztek száma erőforráscsoportonként | 800 | 800 | Lásd: Azure Resource Manager |
A rendelkezésre állási tesztek maximális átirányítása tesztenként | 10 | 10 | |
Rendelkezésre állási tesztek minimális tesztelési gyakorisága | 300 másodperc | Az 5 percnél rövidebb egyéni tesztelési gyakoriságok vagy frekvenciák egyéni TrackAvailability implementációt igényelnek. | |
.NET Profiler és Snapshot Debugger adatmegőrzés | Két hét | Kapcsolatfelvétel az ügyfélszolgálattal. A maximális megőrzési korlát hat hónap. | |
Naponta küldött .NET Profiler-adatok | Korlátlan | Nincs korlát. | |
Pillanatkép-hibakereső naponta küldött adatai | Naponta 30 pillanatkép figyelt alkalmazásonként | Nincs korlát. | Az alkalmazásonként gyűjtött pillanatképek száma konfigurációval módosítható. |
A díjszabásról és a kvótákról további információt az Application Insights számlázásában talál.
Azure Monitor Private Link Scope (AMPLS)
Az AMPLS-objektumokra a következő korlátozások vonatkoznak:
- Egy virtuális hálózat csak egy AMPLS-objektumhoz tud csatlakozni. Ez azt jelenti, hogy az AMPLS-objektumnak hozzáférést kell biztosítania az összes Azure Monitor-erőforráshoz, amelyhez a virtuális hálózatnak hozzáféréssel kell rendelkeznie.
- Az AMPLS-objektumok legfeljebb 300 Log Analytics-munkaterülethez és legfeljebb 1000 Application Insights-összetevőhöz csatlakozhatnak. Ezek a korlátok 2025 február végéig 3000 Log Analytics-munkaterületre és 10 000 Application Insights-összetevőre növekednek.
- Egy Azure Monitor-erőforrás legfeljebb 5 AMPLS-hez tud csatlakozni. Ez a korlát 2025 február végéig 100 AMPLS-re nő.
- Az AMPLS-objektumok legfeljebb 10 privát végponthoz csatlakozhatnak.