Vlastní kolekce metrik v .NET a .NET Core
Sady AZURE Monitor Application Insights .NET a .NET Core SDK mají dvě různé metody shromažďování vlastních metrik: TrackMetric()
a GetMetric()
. Klíčovým rozdílem mezi těmito dvěma metodami je místní agregace. Metoda TrackMetric()
nemá preaggregaci. Metoda GetMetric()
má preaggregaci. Doporučujeme použít agregaci, takže TrackMetric()
už není upřednostňovanou metodou shromažďování vlastních metrik. Tento článek vás provede použitím GetMetric()
metody a některých důvodů, jak funguje.
Upozornění
Pro nové aplikace nebo zákazníky doporučujeme , aby služba Azure Monitor OpenTelemetry distro vysílala služby Azure Monitor Application Insights. Distribuce OpenTelemetry služby Azure Monitor poskytuje podobné funkce a prostředí jako sada Application Insights SDK. Ze sady Application Insights SDK je možné migrovat pomocí průvodců migrací pro .NET, Node.js a Python, ale stále pracujeme na přidání několika dalších funkcí pro zpětnou kompatibilitu.
Předběžné agregace vs. nespravující rozhraní API
Metoda TrackMetric()
odesílá nezpracovanou telemetrii označující metriku. Odeslání jedné položky telemetrie pro každou hodnotu je neefektivní. Metoda TrackMetric()
je také neefektivní z hlediska výkonu, protože každá TrackMetric(item)
prochází celým kanálem sady SDK inicializátorů telemetrie a procesorů.
Na rozdíl od TrackMetric()
, GetMetric()
zpracovává místní předagregace za vás a pak odešle agregovanou souhrnnou metriku pouze v pevném intervalu jedné minuty. Pokud potřebujete pečlivě monitorovat určitou vlastní metriku na druhé nebo dokonce milisekundové úrovni, můžete to udělat, zatímco náklady na úložiště a síťový provoz se budou monitorovat jenom každou minutu. Toto chování také výrazně snižuje riziko omezování, protože celkový počet položek telemetrie, které je potřeba odeslat pro agregovanou metriku, se výrazně sníží.
Ve službě Application Insights se na vlastní metriky shromážděné prostřednictvím TrackMetric()
GetMetric()
vzorkování neshromažďuje vzorkování. Vzorkování důležitých metrik může vést ke scénářům, ve kterých by mohlo dojít k nespolehlivému upozorňování na tyto metriky. Díky tomu, že nikdy neodejdete vlastní metriky, můžete mít obecně jistotu, že když dojde k porušení prahových hodnot upozornění, aktivuje se upozornění. Vzhledem k tomu, že vlastní metriky nejsou vzorkovány, existuje několik potenciálních obav.
Sledování trendu v metrikách každou sekundu nebo v ještě podrobnějším intervalu může vést k:
- Zvýšení nákladů na úložiště dat Náklady jsou spojené s objemem dat, která odesíláte do služby Azure Monitor. Čím více dat odesíláte, tím větší jsou celkové náklady na monitorování.
- Zvýšení síťového provozu nebo režijního výkonu V některých scénářích by tato režie mohla mít peněžní i aplikační náklady na výkon.
- Riziko omezování příjmu dat Když vaše aplikace během krátkého časového intervalu odesílá vysokou míru telemetrie, azure Monitor zahodí datové body ("omezení").
Omezování je problém, protože může vést k zmeškaným výstrahám. Podmínka, která aktivuje výstrahu, může nastat místně a pak se v koncovém bodu příjmu dat zahodí kvůli příliš velkému množství dat. Nedoporučujeme používat TrackMetric()
pro .NET a .NET Core, pokud jste neimplementovali vlastní místní agregační logiku. Pokud se pokoušíte sledovat každou instanci, ke které dojde v daném časovém období, můžete zjistit, že TrackEvent()
je to vhodnější. Mějte na paměti, že na rozdíl od vlastních metrik podléhají vlastní události vzorkování. Stále můžete používat TrackMetric()
i bez psaní vlastní místní preaggregace. Ale pokud to uděláte, mějte na paměti úskalí.
V souhrnu doporučujeme GetMetric()
, protože provádí předběžné agregace, shromažďuje hodnoty ze všech Track()
volání a odesílá souhrn/agregaci jednou za minutu. Metoda GetMetric()
může výrazně snížit náklady a režijní náklady tím, že odesílá méně datových bodů a přitom shromažďuje všechny relevantní informace.
Poznámka:
Pouze sady .NET a .NET Core SDK mají metodu GetMetric()
. Pokud používáte Javu, přečtěte si téma Odesílání vlastních metrik pomocí mikrometru. Pro JavaScript a Node.js byste stále používali TrackMetric()
, ale mějte na paměti upozornění, které byly popsány v předchozí části. V Pythonu můžete k odesílání vlastních metrik použít OpenCensus.stats , ale implementace metrik se liší.
Začínáme s GetMetric
V našich příkladech použijeme základní aplikaci pracovních služeb .NET Core 3.1. Pokud chcete replikovat testovací prostředí použité s těmito příklady, postupujte podle kroků 1 až 6 v článku o monitorovací pracovní službě. Tento postup přidá Application Insights do šablony projektu základní pracovní služby. Tyto koncepty platí pro jakoukoli obecnou aplikaci, ve které je možné sadu SDK použít, včetně webových aplikací a konzolových aplikací.
Odesílání metrik
Obsah souboru worker.cs
nahraďte následujícím kódem:
using System;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using Microsoft.ApplicationInsights;
namespace WorkerService3
{
public class Worker : BackgroundService
{
private readonly ILogger<Worker> _logger;
private TelemetryClient _telemetryClient;
public Worker(ILogger<Worker> logger, TelemetryClient tc)
{
_logger = logger;
_telemetryClient = tc;
}
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{ // The following line demonstrates usages of GetMetric API.
// Here "computersSold", a custom metric name, is being tracked with a value of 42 every second.
while (!stoppingToken.IsCancellationRequested)
{
_telemetryClient.GetMetric("ComputersSold").TrackValue(42);
_logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
await Task.Delay(1000, stoppingToken);
}
}
}
}
Při spuštění ukázkového kódu se smyčka while
opakovaně spouští bez odesílání telemetrie v okně výstupu sady Visual Studio. Jedna položka telemetrie se odesílá kolem 60sekundové značky, která v našem testu vypadá takto:
Application Insights Telemetry: {"name":"Microsoft.ApplicationInsights.Dev.00000000-0000-0000-0000-000000000000.Metric", "time":"2019-12-28T00:54:19.0000000Z",
"ikey":"00000000-0000-0000-0000-000000000000",
"tags":{"ai.application.ver":"1.0.0.0",
"ai.cloud.roleInstance":"Test-Computer-Name",
"ai.internal.sdkVersion":"m-agg2c:2.12.0-21496",
"ai.internal.nodeName":"Test-Computer-Name"},
"data":{"baseType":"MetricData",
"baseData":{"ver":2,"metrics":[{"name":"ComputersSold",
"kind":"Aggregation",
"value":1722,
"count":41,
"min":42,
"max":42,
"stdDev":0}],
"properties":{"_MS.AggregationIntervalMs":"42000",
"DeveloperMode":"true"}}}}
Tato jedna položka telemetrie představuje agregaci 41 různých měření metrik. Vzhledem k tomu, že jsme odeslali stejnou hodnotu znovu a znovu, máme směrodatnou odchylku (stDev
) 0
s identickými maximálními (max
) a minimálními (min
) hodnotami. Vlastnost value
představuje součet všech jednotlivých hodnot, které byly agregovány.
Poznámka:
Metoda GetMetric
nepodporuje sledování poslední hodnoty (například gauge
) nebo sledování histogramů nebo distribucí.
Pokud prozkoumáme prostředek Application Insights v prostředí protokolů (Analytics), jednotlivé položky telemetrie by vypadaly jako na následujícím snímku obrazovky.
Poznámka:
I když nezpracovaná položka telemetrie po ingestování neobsahovala explicitní vlastnost součtu nebo pole, vytvoříme ji pro vás. V tomto případě obě vlastnosti value
valueSum
představují stejnou věc.
Ke své vlastní telemetrii metrik můžete přistupovat také v části Metriky na portálu jako na základě protokolů i k vlastní metrice. Následující snímek obrazovky je příkladem metriky založené na protokolu.
Referenční informace o metrikách mezipaměti pro využití s vysokou propustností
Hodnoty metrik můžou být v některých případech často pozorovány. Například služba s vysokou propustností, která zpracovává 500 požadavků za sekundu, může pro každý požadavek generovat 20 metrik telemetrie. Výsledek znamená sledování 10 000 hodnot za sekundu. V takových scénářích s vysokou propustností můžou uživatelé potřebovat pomoct sadě SDK tím, že se vyhnete některým vyhledáváním.
Například předchozí příklad provedl vyhledávání popisovače metriky ComputersSold
a pak sledoval pozorovanou hodnotu 42
. Místo toho může být popisovač uložen v mezipaměti pro více volání sledování:
//...
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
// This is where the cache is stored to handle faster lookup
Metric computersSold = _telemetryClient.GetMetric("ComputersSold");
while (!stoppingToken.IsCancellationRequested)
{
computersSold.TrackValue(42);
computersSold.TrackValue(142);
_logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
await Task.Delay(50, stoppingToken);
}
}
Kromě ukládání popisovače metriky do mezipaměti se předchozí příklad snížil Task.Delay
také na 50 milisekund, aby se smyčka spustila častěji. Výsledkem je 772 TrackValue()
vyvolání.
Multidimenzionální metriky
Příklady v předchozí části zobrazují nulové metriky. Metriky navíc můžou být multidimenzionální. V současné době podporujeme až 10 dimenzí.
Tady je příklad vytvoření jednorozměrné metriky:
//...
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
// This is an example of a metric with a single dimension.
// FormFactor is the name of the dimension.
Metric computersSold= _telemetryClient.GetMetric("ComputersSold", "FormFactor");
while (!stoppingToken.IsCancellationRequested)
{
// The number of arguments (dimension values)
// must match the number of dimensions specified while GetMetric.
// Laptop, Tablet, etc are values for the dimension "FormFactor"
computersSold.TrackValue(42, "Laptop");
computersSold.TrackValue(20, "Tablet");
computersSold.TrackValue(126, "Desktop");
_logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
await Task.Delay(50, stoppingToken);
}
}
Spuštění ukázkového kódu po dobu nejméně 60 sekund způsobí, že se do Azure odesílají tři různé položky telemetrie. Každá položka představuje agregaci jednoho ze tří faktorů formuláře. Stejně jako předtím můžete v zobrazení Protokolů (Analytics) podrobněji prozkoumat.
V Průzkumníku metrik:
Všimněte si, že metriku nemůžete rozdělit podle nové vlastní dimenze nebo zobrazit vlastní dimenzi pomocí zobrazení metrik.
Ve výchozím nastavení nejsou v prostředcích Application Insights zapnuté multidimenzionální metriky v průzkumníku metrik.
Povolení multidimenzionálních metrik
Pokud chcete povolit multidimenzionální metriky pro prostředek Application Insights, vyberte Možnost Využití a odhadované náklady>– Vlastní metriky>Umožňují upozorňovat na vlastní dimenze>metrik v pořádku. Další informace najdete v tématu Vlastní dimenze metrik a před agregace.
Po provedení této změny a odeslání nové multidimenzionální telemetrie můžete vybrat Použít rozdělení.
Poznámka:
Pouze nově odeslané metriky po zapnutí funkce na portálu budou mít uložené dimenze.
Zobrazte agregace metrik pro každou FormFactor
dimenzi.
Použití MetricIdentifier, pokud je více než tři dimenze
V současné době se podporuje 10 dimenzí. Použití více než tří dimenzí vyžaduje:MetricIdentifier
// Add "using Microsoft.ApplicationInsights.Metrics;" to use MetricIdentifier
// MetricIdentifier id = new MetricIdentifier("[metricNamespace]","[metricId],"[dim1]","[dim2]","[dim3]","[dim4]","[dim5]");
MetricIdentifier id = new MetricIdentifier("CustomMetricNamespace","ComputerSold", "FormFactor", "GraphicsCard", "MemorySpeed", "BatteryCapacity", "StorageCapacity");
Metric computersSold = _telemetryClient.GetMetric(id);
computersSold.TrackValue(110,"Laptop", "Nvidia", "DDR4", "39Wh", "1TB");
Vlastní konfigurace metriky
Pokud chcete změnit konfiguraci metriky, musíte provést změny v místě, kde je metrika inicializována.
Speciální názvy dimenzí
Metriky nepoužívají kontext telemetrie použitého TelemetryClient
pro přístup k nim. Použití speciálních názvů dimenzí dostupných jako konstant ve MetricDimensionNames
třídě je nejlepším alternativním řešením pro toto omezení.
Agregace metrik odesílané pomocí následující Special Operation Request Size
metriky nebudou nastaveny Context.Operation.Name
na Special Operation
hodnotu . Metoda TrackMetric()
nebo jakákoli jiná TrackXXX()
metoda bude OperationName
správně nastavena na Special Operation
.
//...
TelemetryClient specialClient;
private static int GetCurrentRequestSize()
{
// Do stuff
return 1100;
}
int requestSize = GetCurrentRequestSize()
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
while (!stoppingToken.IsCancellationRequested)
{
//...
specialClient.Context.Operation.Name = "Special Operation";
specialClient.GetMetric("Special Operation Request Size").TrackValue(requestSize);
//...
}
}
V tomto případě použijte speciální názvy dimenzí uvedené ve MetricDimensionNames
třídě k určení TelemetryContext
hodnot.
Když se například do koncového bodu cloudu Application Insights odešle agregace metriky, která je výsledkem dalšího příkazu, nastaví se jeho Context.Operation.Name
datové pole na Special Operation
:
_telemetryClient.GetMetric("Request Size", MetricDimensionNames.TelemetryContext.Operation.Name).TrackValue(requestSize, "Special Operation");
Hodnoty této zvláštní dimenze se zkopírují a TelemetryContext
nebudou použity jako normální dimenze. Pokud chcete zachovat také dimenzi operace pro normální zkoumání metrik, musíte pro tento účel vytvořit samostatnou dimenzi:
_telemetryClient.GetMetric("Request Size", "Operation Name", MetricDimensionNames.TelemetryContext.Operation.Name).TrackValue(requestSize, "Special Operation", "Special Operation");
Omezení dimenzí a časových řad
Pokud chcete zabránit náhodnému používání telemetrického subsystému, můžete řídit maximální počet datových řad na metriku. Výchozí limity nejsou větší než 1 000 celkových datových řad na metriku a ne více než 100 různých hodnot na dimenzi.
Důležité
Pro dimenze používejte nízké hodnoty kardinality, abyste se vyhnuli omezování.
V kontextu omezování dimenzí a časových řad používáme Metric.TrackValue(..)
k zajištění toho, aby se limity sledovaly. Pokud už jsou limity dosaženy, Metric.TrackValue(..)
vrátí False
se a hodnota se nesleduje. V opačném případě se vrátí True
. Toto chování je užitečné, pokud data metriky pocházejí ze vstupu uživatele.
Konstruktor MetricConfiguration
má několik možností, jak spravovat různé řady v rámci příslušné metriky a objekt třídy implementuje IMetricSeriesConfiguration
, který určuje chování agregace pro jednotlivé řady metriky:
var metConfig = new MetricConfiguration(seriesCountLimit: 100, valuesPerDimensionLimit:2,
new MetricSeriesConfigurationForMeasurement(restrictToUInt32Values: false));
Metric computersSold = _telemetryClient.GetMetric("ComputersSold", "Dimension1", "Dimension2", metConfig);
// Start tracking.
computersSold.TrackValue(100, "Dim1Value1", "Dim2Value1");
computersSold.TrackValue(100, "Dim1Value1", "Dim2Value2");
// The following call gives 3rd unique value for dimension2, which is above the limit of 2.
computersSold.TrackValue(100, "Dim1Value1", "Dim2Value3");
// The above call does not track the metric, and returns false.
seriesCountLimit
je maximální počet datových časových řad, které může metrika obsahovat. Když dosáhnete tohoto limitu, voláníTrackValue()
, která by normálně způsobovala vrácenífalse
nové řady .valuesPerDimensionLimit
omezuje počet jedinečných hodnot na dimenzi podobným způsobem.restrictToUInt32Values
určuje, zda mají být sledovány pouze nezáporné celočíselné hodnoty.
Tady je příklad, jak odeslat zprávu s informacemi o překročení limitů limitu:
if (! computersSold.TrackValue(100, "Dim1Value1", "Dim2Value3"))
{
// Add "using Microsoft.ApplicationInsights.DataContract;" to use SeverityLevel.Error
_telemetryClient.TrackTrace("Metric value not tracked as value of one of the dimension exceeded the cap. Revisit the dimensions to ensure they are within the limits",
SeverityLevel.Error);
}
Další kroky
- Metriky – Získání – REST API
- Rozhraní API Application Insights pro vlastní události a metriky
- Přečtěte si další informace o monitorování aplikací pracovních služeb.
- Použijte metriky založené na protokolech a předem agregované metriky.
- Analýza metrik pomocí Průzkumníka metrik
- Zjistěte, jak povolit Application Insights pro aplikace ASP.NET Core.
- Zjistěte, jak povolit Application Insights pro ASP.NET aplikace.