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 (klasszikus) | Előfizetésenként 100 aktív riasztási szabály. A rendszer kivonja a klasszikus riasztásokat a nyilvános felhőfelhasználók számára. Az Azure Government-felhőre és a 21Vianet által üzemeltetett Microsoft Azure-ra vonatkozó klasszikus riasztások 2024. február 29-én megszűnnek. |
Hívja fel az ügyfélszolgálatot. |
| 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 5000 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. Egyszerre legfeljebb 6000 aktivált állapotalapú riasztás. |
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 e-mail-címhez Az e-mail-címekben a caraccter korlá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: 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. Azonos idősorként kezeli a sztringeket, például a metrikaneveket, a címkeneveket vagy a címkeértékeket, ha csak a sztring esetében térnek el egy másik idősortó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
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átoz | É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 alkalmazások Elemzések erőforrások és Log Analytics-munkaterületek maximális száma egyetlen lekérdezésben legfeljebb 100. A Tervező megtekintése nem támogatja az erőforrásközi lekérdezést. 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. |
- 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 használati szint csak olyan előfizetésekre korlátozódik, amelyek 2018. április 2-án log analytics-munkaterületet vagy alkalmazás-Elemzések erőforrást tartalmaztak, vagy amelyek egy 2019. február 1. előtt elindított Nagyvállalati Szerződés kapcsolódnak, é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 használati szint csak olyan előfizetésekre korlátozódik, amelyek 2018. április 2-án log analytics-munkaterületet vagy alkalmazás-Elemzések erőforrást tartalmaztak, vagy amelyek egy 2019. február 1. előtt elindított Nagyvállalati Szerződés kapcsolódnak, é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. |
Általános munkaterületkorlátok
| Kategória | Korlát | Megjegyzések |
|---|---|---|
| Táblák oszlopainak maximális száma | 500 | |
| Egyéni naplótáblák maximális száma | 500 | |
| 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 mennyiségi korlát az Azure-erőforrásokból a diagnosztikai beállítások és a Data Collector API használatával betöltött adatokra 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átozás nem vonatkozik az ügynököktől vagy a DCR-n keresztül betöltött adatokra.
Ha a munkaterületre küldött adatok mennyisége meghaladja a munkaterületen konfigurált küszöbérték 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 továbbra is meghaladja a küszöbértéket. Ha a betöltött 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, miközben a küszöbérték továbbra is meghaladja a küszöbértéket.
Ha a betöltési mennyiség mértéke továbbra is meghaladja a küszöbértéket, vagy várhatóan hamarosan eléri, támogatási kérés megnyitásával kérheti a korlát növelését.
Azt is javasoljuk, hogy hozzon létre egy riasztási szabályt, amely proaktívan értesíti, ha eléri a betöltési korlátokat. 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. |
| Rendelkezésre állási tesztek száma alkalmazásonként Elemzések erőforrásonként | 100 | 100 | |
| Profiler és pillanatkép adatmegőrzése | Két hét | Kapcsolatfelvétel az ügyfélszolgálattal. A maximális megőrzési korlát hat hónap. | |
| Profiler naponta küldött adatai | Korlátlan | Nincs korlát. | |
| Naponta küldött pillanatkép-adatok | 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ással és kvótával kapcsolatos további információkért tekintse meg az Alkalmazás Elemzések számlázást.
Azure Monitor Private Link Scope (AMPLS)
Az AMPLS-objektumra 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 1000 alkalmazás-Elemzések összetevőhöz csatlakozhatnak.
- Egy Azure Monitor-erőforrás (munkaterület vagy alkalmazás Elemzések összetevő vagy adatgyűjtési végpont) legfeljebb öt AMPLS-hez csatlakozhat.
- Az AMPLS-objektumok legfeljebb 10 privát végponthoz csatlakozhatnak.
Feljegyzés
A 2021. december 1. előtt létrehozott AMPLS-erőforrások csak 50 erőforrást támogatnak.