Správa využití a nákladů pro službu Application Insights

Application Insights je navržený tak, aby získal vše, co potřebujete k monitorování dostupnosti, výkonu a využití webových aplikací, ať už jsou hostované v Azure nebo místně. Application Insights podporuje oblíbené jazyky a architektury, jako je .net, Java a Node.js, a integruje se s DevOps procesy a nástroji, jako jsou Azure DevOps, Jira a PagerDuty. Je důležité porozumět tomu, co určuje náklady na monitorování vašich aplikací. V tomto článku si projdeme, jaké jednotky vaše aplikace sledují a jak je můžete aktivně monitorovat a řídit.

pokud máte dotazy ohledně toho, jak ceny fungují pro Application Insights, můžete odeslat dotaz na stránce s dotazem pro Microsoft Q&.

Cenový model

ceny za Azure Application Insights jsou model průběžných plateb na základě ingestování objemu dat a volitelně pro delší dobu uchovávání dat. každý prostředek Application Insights se účtuje jako samostatná služba a přispívá vám k fakturaci za vaše předplatné Azure. objem dat se měří jako velikost balíčku nekomprimovaného data JSON, který přijímá Application Insights z vaší aplikace. Objem dat se měří v GB (10 ^ 9 bajtů). Za použití Live Metrics Streamse neúčtují žádné poplatky za objem dat. na faktuře Azure nebo ve službě Azure Cost Management + fakturacese vaše příjem dat a uchovávání dat pro klasický Application Insights prostředek hlásí s kategorií měřičů Log Analytics.

U více kroků webové testy se účtují další poplatky. Webové testy s více kroky jsou webové testy, které provádějí posloupnost akcí. Pro testy pomocí příkazů testování jedné stránky se neúčtují žádné samostatné poplatky. Telemetrie z testů příkazového testu a testů pro více kroků se účtují stejně jako jiné telemetrie z vaší aplikace.

možnost Application Insights povolit upozorňování na vlastní dimenze metriky může také generovat další náklady, protože to může způsobit vytvoření dalších metrik před agregací. přečtěte si další informace o cenách založených na protokolu a předem agregovaných metrikách v Application Insights a o cenách pro Azure Monitor vlastních metrik.

Application Insights na základě pracovního prostoru

u Application Insights prostředků, které odesílají svá data do pracovního prostoru Log Analytics nazývaného prostředky Application Insights založené na pracovním prostoru, se fakturace za příjem a uchování dat provádí v pracovním prostoru, kde se nacházejí Application Insights data. To vám umožní využít všechny možnosti Log Analytics cenového modelu, včetně úrovní závazku , spolu s průběžnými platbami. Úrovně závazku nabízejí ceny až o 30% nižší než průběžné platby. Log Analytics také obsahuje další možnosti uchovávání dat, včetně uchovávání informací podle datového typu. Application Insights datové typy v pracovním prostoru obdrží 90 dnů uchování bez poplatků. použití webových testů a povolení upozorňování na vlastní dimenze metriky je stále hlášeno prostřednictvím Application Insights. Přečtěte si, jak sledovat příjem dat a dobu uchovávání v Log Analytics pomocí odhadu využití a odhadované náklady, Azure cost management + fakturace a Log Analytics dotazy.

Odhad nákladů na správu aplikace

pokud ještě nepoužíváte Application Insights, můžete pomocí cenové kalkulačky Azure Monitor odhadnout náklady na používání Application Insights. Začněte zadáním "Azure Monitor" do vyhledávacího pole a kliknutím na výslednou Azure Monitor dlaždici. posuňte se dolů na stránku Azure Monitor a rozbalte část Application Insights. Odhadované náklady závisí na množství přijatých dat protokolu. Existují dva způsoby, jak odhadnout objemy dat:

1. Odhadněte vaše pravděpodobná příjem dat na základě toho, co podobné aplikace generují, nebo
2. použití výchozího monitorování a adaptivního vzorkování, které je k dispozici v sadě ASP.NET SDK.

Informace o tom, co podobné aplikace shromažďují

v cenové kalkulačkě monitorování Azure pro Application Insights klikněte a povolte objem dat odhadu na základě aktivity aplikace. Tady můžete zadat vstupy vaší aplikace (požadavky za měsíc a zobrazení stránky měsíčně), pokud budete shromažďovat telemetrii na straně klienta) a pak Kalkulačka bude informovat medián a 90. percentil dat shromažďovaných podobnými aplikacemi. tyto aplikace rozcházejí z rozsahu konfigurace Application Insights (například některé mají výchozí vzorkování, některé nemají žádné vzorkování atd.), takže stále máte kontrolu nad tím, jak omezit objem dat, která jsou až na střední úrovni, a to pomocí vzorkování.

Shromažďování dat při použití vzorkování

díky adaptivnímu vzorkovánísady ASP.NET SDK se datový svazek automaticky upraví tak, aby udržoval v rámci zadané maximální míry provozu pro výchozí Application Insights monitorování. Pokud aplikace vytvoří nízké množství telemetrie, například při ladění nebo z důvodu nízkého využití, položky se nebudou vyřadit procesorem vzorkování, pokud je svazek pod úrovní konfigurovaných událostí za sekundu. U vysoce výkonných aplikací s výchozí prahovou hodnotou pět událostí za sekundu se adaptivní vzorkování omezí počet denních událostí na 432 000. Když použijete typickou průměrnou velikost události 1 KB, bude to odpovídat 13,4 GB telemetrie za 31 dní na uzel, který hostuje vaši aplikaci, protože vzorkování se provádí místně pro každý uzel.

pro sady sdk, které nepodporují adaptivní vzorkování, můžete využívat vzorkováníingestování, které vzorky při přijímání dat Application Insights na základě procentuálního podílu dat, které se mají zachovat, nebo vzorkování s pevnou sazbou pro ASP.NET, ASP.NET Core a weby Java , abyste snížili provoz odeslaný z webového serveru a webových prohlížečů.

zobrazení využití Application Insights na faktuře Azure

nejjednodušší způsob, jak zobrazit fakturované využití jednoho Application Insightsho prostředku, který není pracovním prostorem baed, je přejít na stránku přehled prostředku a kliknout na zobrazit náklady v pravém horním rohu. Je možné, že budete potřebovat další přístup k Cost Management dat (dalšíinformace).

Pokud se chcete dozvědět víc, Azure poskytuje skvělou užitečnou funkci v centru Azure cost management + fakturace . Například funkce "cost Analysis" umožňuje zobrazit vaše výdaje na prostředky Azure. přidání filtru podle typu prostředku (do microsoft. insights/components for Application Insights) vám umožní sledovat vaše útraty. Pak u možnosti "seskupit podle" vyberte kategorii měřičů "nebo" měřič ". všimněte si, že Application Insights fakturované využití pro přijímání dat a uchovávání dat se zobrazí jako Log Analytics pro kategorii měřiče, od Log Analytics back-endu pro všechny protokoly Azure Monitor.

Ještě více informací o využití se dá získat stažením vašeho využití z Azure Portal. Ve stažených tabulkách můžete zobrazit využití podle prostředku Azure za den. v tomto Excel tabulce můžete využití vašich prostředků Application Insights najít prvním filtrováním ve sloupci měřiče měření, aby se zobrazila možnost Application Insights a Log Analytics, a pak jste přidali filtr do sloupce "ID Instance", který je "obsahuje microsoft. Insights/components". většina využití Application Insights se oznamuje u měřičů s kategorií měřičů Log Analytics, protože pro všechny Azure Monitor komponenty existuje back-end s jedním protokolem. pouze Application Insights prostředky se staršími cenovými úrovněmi a webovými testy ve více krocích jsou hlášeny s kategorií měřičů Application Insights. Využití se zobrazí ve sloupci "spotřebované množství" a jednotka pro každou položku je zobrazena ve sloupci Měrná jednotka. K dispozici jsou také další podrobnosti, které vám pomůžou porozumět informacím na faktuře za Microsoft Azure.

Pochopení využití a optimalizace nákladů

Application Insights usnadňuje pochopení toho, jaké náklady budou pravděpodobně založeny na nedávných vzorech použití. začněte tím, že v Azure Portal pro prostředek Application Insights přejdete na stránku využití a odhadované náklady :

A. Prohlédněte si svůj objem dat za měsíc. To zahrnuje všechna data, která jsou přijatá a zachovaná (po případném vzorkování) z vašich serverových a klientských aplikací, a z testů dostupnosti.
B. Pro webové testy s více krokyse provede samostatný poplatek. (Nezahrnuje jednoduché testy dostupnosti, které jsou zahrnuté do poplatků za objem dat.)
C. Zobrazení trendů objemu dat za minulý měsíc.
D. Povolit vzorkovánípřijímání dat E. Nastavte limit denního objemu dat.

(Všimněte si, že všechny ceny zobrazené na snímcích obrazovky v tomto článku jsou například jenom pro účely. aktuální ceny v měně a oblasti najdete v tématu Application Insights ceny.)

pokud chcete prozkoumat využití Application Insightsější, otevřete stránku metriky , přidejte metriku s názvem "svazek datových bodů" a pak vyberte možnost použít rozdělení pro rozdělení dat podle typu položky telemetrie.

do faktury Azure se přidají poplatky za Application Insights. Podrobnosti o fakturaci Azure najdete v části cost management + fakturace Azure Portal nebo na portálu fakturace Azure. podrobnosti o použití tohoto pro Application Insights najdete níže .

Použití metriky objemu dat

pokud chcete získat další informace o vašich datových svazcích, vyberte metriky pro prostředek Application Insights a přidejte nový graf. U metriky grafu v části metriky založené na protokolu vyberte svazek datového bodu. Klikněte na použít rozdělení a vyberte seskupit podle Telemetryitem typu.

Dotazy pro pochopení podrobností o objemu dat

existují dva způsoby, jak prozkoumat datové svazky pro Application Insights. První používá agregované informace v systemEvents tabulce a druhá používá _BilledSize vlastnost, která je k dispozici na všech přijatých událostech. systemEvents nebude mít informace o velikosti dat pro Application-Insights založené na pracovních prostorech.

Použití informací agregovaného objemu dat

V tabulce můžete například pomocí systemEvents dotazu zobrazit datový svazek, který se v posledních 24 hodinách podrží:

systemEvents
| where timestamp >= ago(24h)
| where type == "Billing"
| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])
| extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])
| summarize sum(BillingTelemetrySizeInBytes)

Nebo pokud chcete zobrazit graf objemu dat (v bajtech) podle datového typu za posledních 30 dní, můžete použít:

systemEvents
| where timestamp >= startofday(ago(30d))
| where type == "Billing"
| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])
| extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])
| summarize sum(BillingTelemetrySizeInBytes) by BillingTelemetryType, bin(timestamp, 1d) | render barchart  

Všimněte si, že tento dotaz je možné použít v upozornění protokolu Azure k nastavení upozornění na datové svazky.

Pokud se chcete dozvědět více o změnách telemetrických dat, můžeme pomocí dotazu zjistit počet událostí podle typu:

systemEvents
| where timestamp >= startofday(ago(30d))
| where type == "Billing"
| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])
| summarize count() by BillingTelemetryType, bin(timestamp, 1d)
| render barchart  

Použití informací o velikosti dat na událost

Pokud chcete získat další podrobnosti o zdroji datových svazků, můžete použít vlastnost , která se nachází u každé _BilledSize ingestované události.

Pokud se například chcete podívat, které operace generují nejvíce objemu dat za posledních 30 dnů, můžeme sečíst _BilledSize všechny události závislostí:

dependencies
| where timestamp >= startofday(ago(30d))
| summarize sum(_BilledSize) by operation_Name
| render barchart  

Objem dat pro prostředky application Přehledy založené na pracovních prostorech

Pokud se chcete podívat na trendy objemu dat pro všechny prostředky Application Přehledy založené na pracovních prostorech v pracovním prostoru za poslední týden, přejděte do pracovního prostoru služby Log Analytics a spusťte dotaz:

union (AppAvailabilityResults),
      (AppBrowserTimings),
      (AppDependencies),
      (AppExceptions),
      (AppEvents),
      (AppMetrics),
      (AppPageViews),
      (AppPerformanceCounters),
      (AppRequests),
      (AppSystemEvents),
      (AppTraces)
| where TimeGenerated >= startofday(ago(7d)) and TimeGenerated < startofday(now())
| summarize sum(_BilledSize) by _ResourceId, bin(TimeGenerated, 1d)
| render areachart

Pokud se chcete dotazovat na trendy objemu dat podle typu pro konkrétní prostředek Application Přehledy, v pracovním prostoru služby Log Analytics použijte:

union (AppAvailabilityResults),
      (AppBrowserTimings),
      (AppDependencies),
      (AppExceptions),
      (AppEvents),
      (AppMetrics),
      (AppPageViews),
      (AppPerformanceCounters),
      (AppRequests),
      (AppSystemEvents),
      (AppTraces)
| where TimeGenerated >= startofday(ago(7d)) and TimeGenerated < startofday(now())
| where _ResourceId contains "<myAppInsightsResourceName>"
| summarize sum(_BilledSize) by Type, bin(TimeGenerated, 1d)
| render areachart

Správa objemu dat

Objem dat, která odešlete, je možné spravovat pomocí následujících technik:

• Vzorkování: Vzorkováním můžete snížit množství telemetrie odesílané ze serveru a klientských aplikací s minimálními nároky na metriky. Vzorkování je primární nástroj, který můžete použít k vyladění objemu odesílaného dat. Přečtěte si další informace o funkcích vzorkování.

• Omezit volání Ajax: Můžete omezit počet volání Ajax, která mohou být hlášena v každém zobrazení stránky, nebo vypnout generování sestav Ajax. Všimněte si, že zakázáním volání Ajax zakážete korelaci JavaScriptu.

• Zakažte nepou3/4ené moduly: ApplicationInsights.configa vypněte moduly kolekcí, které nepotřebujete. Můžete se například rozhodnout, že čítače výkonu nebo data závislostí jsou inessential.

• Metriky předem agregované: Pokud do aplikace vložili volání TrackMetric, můžete snížit provoz pomocí přetížení, které přijímá výpočet průměru a směrodatné odchylky dávky měření. Nebo můžete použít předem agregační balíček.

• Denní limit: Při vytváření prostředku Přehledy v Azure Portal se denní limit nastaví na 100 GB za den. Když vytvoříte prostředek application Přehledy v Visual Studio, výchozí hodnota je malá (pouze 32,3 MB/den). Výchozí denní limit je nastavený pro usnadnění testování. Je určené, aby uživatel zvýšil denní limit před nasazením aplikace do produkčního prostředí.

  Maximální limit v aplikaci Přehledy 1 000 GB za den, pokud pro aplikaci s vysokým provozem nepožádáte o vyšší maximum.

  Tip

  Pokud máte prostředek Application Přehledy založený na pracovním prostoru, doporučujeme použít denní limit pracovního prostoru k omezení příjmu dat a nákladů místo limitu v části Application Přehledy.

  E-maily s upozorněním týkající se denního limitu se posílají na účet, který je členy těchto rolí pro váš prostředek služby Application Přehledy: ServiceAdmin, AccountAdmin, CoAdmin, Owner.

  Při nastavování denního limitu postupujte opatrně. Vaším záměrem by mělo být nikdy nedosáhne denního limitu. Pokud dosáhnete denního limitu, po zbytek dne budete ztrácet data a nebudete moct monitorovat svou aplikaci. Ke změně denního limitu použijte možnost Denní limit objemu. K této možnosti můžete přistupovat v podokně Využití a odhadované náklady (podrobnější popis najdete dále v tomto článku).

  Odebrali jsme omezení některých typů předplatného, která mají kredit, který se nešlo použít pro application Přehledy. Pokud má předplatné dříve limit útraty, dialogové okno denního limitu obsahuje pokyny k odebrání limitu útraty a povolení, aby se denní limit zvýšil nad 32,3 MB za den.

• Omezování: Omezování omezuje přenos dat na 32 000 událostí za sekundu, průměr je 1 minuta na instrumentační klíč. Objem dat, která vaše aplikace odesílá, se posuzuje každou minutu. Pokud překročí průměrnou sazbu za sekundu v průběhu minuty, server odmítne některé žádosti. Sada SDK data do vyrovnávací paměti zachytá a pokusí se je znovu odeslat. Rozprostíří nárůst během několika minut. Pokud vaše aplikace konzistentně odesílá data s vyšším než omezením, některá data se zahodí. (ASP.NET, Java a JavaScript SDK se tímto způsobem pokoušet data znovu odeslat; jiné sdk můžou jednoduše vypustit stíněná data.) Pokud dojde k omezování, upozornění vás upozorní, že k tomu došlo.

Správa maximálního denního objemu dat

Shromážděná data můžete omezit pomocí denního limitu objemu. Pokud je však limit splněn, dojde ke ztrátě veškeré telemetrie odeslané z vaší aplikace po zbytek dne. Nedoporučuje se, aby vaše aplikace dosála denního limitu. Jakmile aplikace dosáhne denního limitu, nemůžete sledovat stav a výkon.

Místo denního limitu objemu vylaďte pomocí vzorkování objem dat na úroveň, kterou chcete. Potom denní limit použijte pouze jako "poslední možnost" pro případ, že vaše aplikace neočekávaně začne odesílat mnohem větší objemy telemetrie.

Určení denního limitu dat, který se má definovat

Informace o trendu příjmu Přehledy a denním limitu objemu, který je třeba definovat, Přehledy využití aplikací a odhadované náklady. Měli byste ji pečlivě zvážit, protože po dosažení limitu nebudete moct monitorovat prostředky.

Nastavení denního limitu

Denní limit změníte tak, že v části Konfigurace prostředku Application Přehledy na stránce Využití a odhadované náklady vyberete Denní limit.

Pokud chcete denní limit změnit Azure Resource Manager, vlastností, která se má změnit, je dailyQuota . Prostřednictvím Azure Resource Manager můžete také nastavit a dailyQuotaResetTime denní limit warningThreshold .

Vytváření upozornění pro denní limit

Aplikace Přehledy Denní limit vytvoří událost v protokolu aktivit Azure, když ingestované objemy dat dosáhne úrovně upozornění nebo denního limitu. Na základě těchto událostí protokolu aktivit můžete vytvořit upozornění. Názvy signálů pro tyto události jsou:

• Dosažení prahové hodnoty Přehledy denního limitu komponenty aplikačního serveru

• Dosažení denního limitu Přehledy komponenty aplikačního serveru

Vzorkování

Vzorkování je metoda, která snižuje rychlost posílání telemetrie do vaší aplikace při zachování možnosti najít související události během diagnostických hledání. Zachováte také správné počty událostí.

Vzorkování je efektivní způsob, jak snížit poplatky a zůstat v rámci měsíční kvóty. Algoritmus vzorkování uchovává související položky telemetrie, takže například při použití funkce Search můžete najít požadavek související s konkrétní výjimkou. Algoritmus také zachovává správné počty, takže se v Průzkumníku metrik zobrazí správné hodnoty pro frekvence požadavků, výjimky a další počty.

Vzorkování má několik forem.

• Adaptivní vzorkování je výchozí pro sadu ASP.NET SDK. Adaptivní vzorkování se automaticky přizpůsobí objemu telemetrie, kterou vaše aplikace odesílá. Funguje automaticky v sadě SDK ve vaší webové aplikaci, aby se snížil provoz telemetrie v síti.
• Vzorkování příjmu dat je alternativa, která funguje v okamžiku, kdy telemetrie z vaší aplikace vstupuje do služby Application Přehledy Service. Vzorkování příjmu dat nemá vliv na objem telemetrických dat odesílaných z vaší aplikace, ale snižuje objem uchovávaný službou. Pomocí vzorkování příjmu dat můžete snížit kvótu využitou telemetrií z prohlížečů a jiných sdk.

Pokud chcete nastavit vzorkování příjmu dat, přejděte do podokna Ceny:

Pokud chcete zjistit skutečnou vzorkovací frekvenci, použijte dotaz Analytics bez ohledu na to, kde byla použita. Dotaz vypadá takhle:

requests | where timestamp > ago(1d)
| summarize 100/avg(itemCount) by bin(timestamp, 1h)
| render areachart

V každém zachovaném itemCount záznamu označuje počet původních záznamů, které představuje. Rovná se 1 + počet předchozích zahozených záznamů.

Změna doby uchovávání dat

Výchozí uchovávání prostředků application Přehledy je 90 dnů. Pro každý prostředek služby Application Přehledy dobu uchovávání informací. Úplná sada dostupných období uchovávání je 30, 60, 90, 120, 180, 270, 365, 550 nebo 730 dnů. Přečtěte si další informace o cenách za delší uchovávání dat.

Pokud chcete změnit uchovávání dat, v prostředku Přehledy přejděte na stránku Využití a odhadované náklady a vyberte možnost Uchovávání dat:

Když se doba uchovávání sníží, existuje období odkladu za několik dní, než se nejstarší data odstraní.

Uchovávání je také možné nastavit programově pomocí PowerShellu pomocí retentionInDays parametru . Pokud nastavíte uchovávání dat na 30 dní, můžete pomocí parametru aktivovat okamžité vymazání starších dat, což může být užitečné ve scénářích souvisejících s dodržováním immediatePurgeDataOn30Days předpisů. Tato funkce vymazání je přístupná pouze prostřednictvím Azure Resource Manager a měla by se používat s extrémní opatrností. Denní dobu resetování limitu objemu dat je možné nakonfigurovat pomocí Azure Resource Manager k nastavení dailyQuotaResetTime parametru .

Poplatky za přenos dat pomocí služby Application Přehledy

odesílání dat do Application Insights může mít za následek poplatky za šířku pásma dat. Jak je popsáno na stránce ceny za Azure šířku pásma, přenos dat mezi službami Azure v rámci dvou oblastí se v normální sazbě účtuje jako odchozí přenos dat. Příchozí přenos dat je zdarma. tento poplatek je ale ve srovnání s náklady na Application Insights příjmu dat protokolu velmi malé (několik%). V důsledku toho se řídí náklady na Log Analytics se musí soustředit na přijatý objem dat a máme vám Rady, jak to porozumět .

Souhrn omezení

K dispozici jsou určitá omezení počtu metrik a událostí na aplikaci, tj. na klíč instrumentace. Omezení závisí na zvoleném cenovém plánu.

Další informace najdete v tématu Ceny a kvóty ve službě Application Insights.

Zakázat e-maily denního Cap

pokud chcete zakázat e-maily denního limitu objemu, v části konfigurace prostředku Application Insights v podokně využití a odhadované náklady vyberte denní limit. K dispozici je nastavení pro odeslání e-mailu, když je dosaženo limitu, a také při dosažení nastavitelné úrovně upozornění. Pokud chcete zakázat všechny e-maily s velkým objemem, zrušte zaškrtněte obě políčka.

cenová úroveň starší verze Enterprise (na uzel)

pro včasnou přihlášené služby Azure Application Insights stále existují dvě možné cenové úrovně: základní a Enterprise. Cenová úroveň Basic je stejná, jak je popsáno výše, a je výchozí úroveň. zahrnuje všechny funkce Enterprise vrstev bez dalších poplatků. Úroveň Basic se účtuje primárně na množství dat, která se ingestují.

Tyto starší cenové úrovně se přejmenovaly. cenová úroveň Enterprise se teď zavolala na uzel a cenová úroveň Basic se teď zavolala za GB. Tyto nové názvy se používají níže a v Azure Portal.

úroveň na uzel (dříve Enterprise) má poplatek za uzel a každý uzel obdrží denní povolený objem dat. V cenové úrovni jednotlivých uzlů se vám budou účtovat data ingestovaná nad rámec zahrnutého příspěvku. Pokud používáte Operations Management Suite, měli byste zvolit vrstvu na jednu uzel. V dubnu 2018 jsme zavedli nový cenový model pro monitorování Azure. Tento model přijímá jednoduchý model průběžných plateb v rámci kompletního portfolia monitorovacích služeb. Přečtěte si další informace o novém cenovém modelu.

aktuální ceny v měně a oblasti najdete v tématu Application Insights ceny.

porozumění fakturovanému využití na úrovni starší Enterprise (na uzel)

jak je popsáno níže podrobněji, vrstva starší Enterprise (na úrovni uzlu) kombinuje využití napříč všemi Application Insights prostředky v rámci předplatného pro výpočet počtu uzlů a překročení dat. z důvodu tohoto kombinovaného procesu se využití všech Application Insights prostředků v rámci předplatného hlásí pouze v jednom z prostředků. díky tomu bude vaše fakturované využití sladěné s využitím, které sledujete u každého Application Insightsch prostředků velmi komplikované.

Nároky na úroveň a předplatné Operations Management Suite

zákazníci, kteří si koupí operations Management Suite E1 a E2, můžou získat Application Insights na jeden uzel jako další komponentu bez dalších poplatků, jak už bylo oznámeno dřív. konkrétně každá jednotka operations Management Suite E1 a E2 zahrnuje nárok na jeden uzel Application Insights na vrstvu uzlu. každý uzel Application Insights zahrnuje až 200 MB dat, která se ingestují za den (oddělené od Log Analytics příjmu dat), s uchováváním dat za 90 dnů bez dalších nákladů. Úroveň je podrobněji popsána dále v článku.

Vzhledem k tomu, že tato úroveň platí jenom pro zákazníky s předplatným Operations Management Suite, zákazníci, kteří nemají předplatné Operations Management Suite, nevidí možnost výběru této úrovně.

Jak funguje vrstva na úrovni uzlu

• Platíte za každý uzel, který odesílá telemetrii pro všechny aplikace v rámci vrstvy na úrovni uzlů.
  • Uzel je fyzický nebo virtuální počítač nebo instance role platforma jako služba, která hostuje vaši aplikaci.
  • Vývojové počítače, klientské prohlížeče a mobilní zařízení se nepočítají jako uzly.
  • Pokud má vaše aplikace několik komponent, které odesílají telemetrii, jako je například webová služba a pracovní proces back-endu, komponenty se počítají samostatně.
  • Pro účely cen se nepočítají Live Metrics Stream data. V rámci předplatného jsou poplatky za uzel, ne pro jednotlivé aplikace. Pokud máte pět uzlů, které odesílají telemetrii pro 12 aplikací, účtuje se poplatky za pět uzlů.
• I když se účtují poplatky za měsíc, účtují se vám jenom hodiny, kdy uzel posílá telemetrii z aplikace. Hodinová sazba je cena za 744 měsíc uzavřenou v uvozovkách (počet hodin za 31. den v měsíci).
• Pro každý zjištěný uzel (s hodinovým rozlišením) je zadáno přidělení datových svazků 200 MB za den. Nevyužité přidělení dat se nepřevádí z jednoho dne na další.
  • pokud zvolíte cenovou úroveň jednotlivých uzlů, každé předplatné získá denní příspěvek dat na základě počtu uzlů, které odesílají telemetrii do prostředků Application Insights v tomto předplatném. takže pokud máte pět uzlů, které odesílají data každý den, budete mít na všech Application Insightsch prostředcích v tomto předplatném povolené 1 GB ve fondu. Nezáleží na tom, jestli některé uzly posílají více dat než jiné uzly, protože zahrnutá data se sdílejí napříč všemi uzly. pokud v daném dni, Application Insights prostředky dostávají více dat, než je zahrnuto do denního přidělení dat pro toto předplatné, platí poplatky za nadlimitní využití dat za GB.
  • Denní povolený objem dat se počítá jako počet hodin v den (pomocí UTC), který každý uzel odesílá telemetrie dělenou 24 vynásobeným 200 MB. Pokud tedy máte čtyři uzly, které odesílají telemetrii během 15 až 24 hodin v den, zahrnutá data pro daný den budou ((4 × 15)/24) × 200 MB = 500 MB. Za cenu 2,30 USD za GB za překročení limitu dat by se poplatek 1,15 USD, pokud uzly odešlou 1 GB dat za den.
  • Denní povolený počet na úrovni uzlu se nesdílí s aplikacemi, pro které jste zvolili úroveň na GB. Nevyužitý příspěvek se neprovádí od dnešního dne.

Příklady určení počtu jedinečných uzlů

• přesné počítání uzlů závisí na tom, kterou sadu SDK Application Insights vaše aplikace používá.
  • v sadě sdk verze 2,2 a novější sestavte Application Insights Core sdk i webová sada sdk jako uzel pro každého hostitele aplikace. Příklady jsou názvy počítačů pro fyzického serveru a hostitele virtuálních počítačů nebo název instance pro cloudové služby. jedinou výjimkou je aplikace, která používá pouze .net core a sadu SDK Application Insights core. V takovém případě je pro všechny hostitele hlášen pouze jeden uzel, protože název hostitele není k dispozici.
  • V případě starších verzí sady SDK se Webová sada SDK chová jako novější verze sady SDK, ale základní sada SDK hlásí pouze jeden uzel, bez ohledu na počet hostitelů aplikace.
  • Pokud vaše aplikace používá sadu SDK k nastavení roleInstance na vlastní hodnotu, je ve výchozím nastavení použita stejná hodnota k určení počtu uzlů.
  • Pokud používáte novou verzi sady SDK s aplikací, která se spouští z klientských počítačů nebo mobilních zařízení, počet uzlů může vracet velký počet (z důvodu velkého počtu klientských počítačů nebo mobilních zařízení).

Automation

Pomocí správy prostředků Azure můžete napsat skript pro nastavení cenové úrovně. Přečtěte si, jak.

Další kroky

• kontrol