Skip to content
Application Insights reporter for App.Metrics framework.
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
sample/SandboxConsoleApp (more) correctly disposing TelemetryConfiguration Apr 24, 2019
src (more) correctly disposing TelemetryConfiguration Apr 24, 2019
.editorconfig
.gitattributes init & WIP Apr 23, 2019
.gitignore init & WIP Apr 23, 2019
README.md
appmetrics-applicationinsights.sln
build.ps1 relaxed semantic version regex; +XML comments Apr 24, 2019
default.ruleset init & WIP Apr 23, 2019
nuget.config init & WIP Apr 23, 2019
publish.ps1
shared.props init & WIP Apr 23, 2019

README.md

Application Insights reporter for App.Metrics

Usage

  1. Install nuget package: App.Metrics.Reporting.ApplicationInsights
  2. Obtain Application Insights instrumentation key.
  3. Configure App.Metrics like so:
var instrumentationKey = "00000000-0000-0000-0000-000000000000";

var metrics = new MetricsBuilder()
    .Configuration.Configure(metricsOptions)
    .Report.ToApplicationInsights(instrumentationKey)
    .Build();

How it works

App.Metrics pre-aggregates metrics and reporters are responsible for publishing such aggregated data. Application Insights's type MetricTelemetry is used to describe pre-aggregated metrics and method Track(ITelemetry telemetry) of TelemetryClient publishes it.

It just boils down to translating MetricsDataValueSource into IEnumerable<MetricTelemetry> and publishing the collection using TelemetryClient.

Links

Known issues / shortcomings

1. Aggregation scope

With regards to pre-aggregated data statistics (min, max, stddev) there are two types of App.Metric value sources:

  1. Configurable cumulative - (counter), which are indefinately cummulative by default, but can be configured in their respective options using property ResetOnReporting to start new aggregation scope when the last one is reported.
  2. Indefinately cumulative - (meter, histogram, apdex, timer), which means that they will start new aggregation scope only when IMetricsRoot is created (in practice this usually means when application restarts).

AI clearly favors the first approach.
It is what TelemetryClient does when non-pre-aggregation API (.GetMetric("mycounter").TrackValue(2)) is used and therefore aggregation strategy is under its control. I guess mostly because data statistics min, max, stddev are really only useful for describing smaller batches of uploaded data and not the whole "ever recorded" scope.

Bottom line is: when using App.Metric as a facade to Application Insights do not rely on metric properties min, max, stddev as they will contain something else than you would expect (compared to using TelemetryClient alone for example).

2. Metric dimensions in Azure Portal / Applications Insights

"Dimension" is primarily a term used in Application Insights; the App.Metrics synonym is "item" as in Meter.Mark(MeterOptions options, long amount, string item).

MetricTelemetry does not have a way how to explicitly report dimensions, so this reporter reports them as new metric records with names derived for the parent one.

For example: if on the App.Metric side you would have a single metric "fruit_count" with two dimensions "apples" and "pears" than three metrics will be reported to Application Insights: "fruit_count", "fruit_count.apples" and "fruit_count.pears".

You can’t perform that action at this time.