You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Hello all,
the current implementation of the azuremonitorexporter uses "github.com/microsoft/ApplicationInsights-Go/appinsights"
for ingestion of data to Azure Monitor.
If I'm understanding the current Microsoft strategy correctly they rearchitectured Azure Monitor Ingestion around Data Collection Rules and Endpoints Reference.
We would like to use Azure Monitor via DCR (and custom tables defined after the OpenTelementry Logs/Metric/Traces Data Model) with the OpenTelemetry Collector for our applications.
One reason for preferring the DCR-Ingestion is: We're trying to implement OpenTelemetry in various application throughout our IT-stack. And all app teams should use a central system (let's call it OpenTelemetry Backend) for analyzing their app telemetry data. When using this exporter all OTel data gets transformed to the AppInsights Model. This is quite challenging as it's not intuitiv from the OTel perspective. E.g. the signal "logs" is ingested in the app insights table "traces". And signal "trace" data is most times ingested into the app insights table "dependencies". Not very intuitiv as we want to emphasize the Open Telemetry format and protocol throughout our applications and app developers.
Describe the solution you'd like
Are there any thoughts about using the azlogs (= Azure Monitor Ingestion client module for Go) Link in this exporter or another exporter for ingestion via DCRs?
I'm trying to find out the strategy on Microsoft's side and asked our Microsoft contacts but no results yet.
nikolai-fra
changed the title
Use of DataCollectionRule/Endpoint instead of AppInsights
[exporter/azuremonitor] Use of DataCollectionRule/Endpoint instead of AppInsights
Jun 4, 2025
Component(s)
exporter/azuremonitor
Is your feature request related to a problem? Please describe.
Hello all,
the current implementation of the azuremonitorexporter uses
"github.com/microsoft/ApplicationInsights-Go/appinsights"
for ingestion of data to Azure Monitor.
If I'm understanding the current Microsoft strategy correctly they rearchitectured Azure Monitor Ingestion around Data Collection Rules and Endpoints Reference.
We would like to use Azure Monitor via DCR (and custom tables defined after the OpenTelementry Logs/Metric/Traces Data Model) with the OpenTelemetry Collector for our applications.
One reason for preferring the DCR-Ingestion is: We're trying to implement OpenTelemetry in various application throughout our IT-stack. And all app teams should use a central system (let's call it OpenTelemetry Backend) for analyzing their app telemetry data. When using this exporter all OTel data gets transformed to the AppInsights Model. This is quite challenging as it's not intuitiv from the OTel perspective. E.g. the signal "logs" is ingested in the app insights table "traces". And signal "trace" data is most times ingested into the app insights table "dependencies". Not very intuitiv as we want to emphasize the Open Telemetry format and protocol throughout our applications and app developers.
Describe the solution you'd like
Are there any thoughts about using the azlogs (= Azure Monitor Ingestion client module for Go) Link in this exporter or another exporter for ingestion via DCRs?
I'm trying to find out the strategy on Microsoft's side and asked our Microsoft contacts but no results yet.
I did find the "Azure Monitor edge pipeline" preview which is based upon the open telemetry collector and an exporter natively writing to an DCR: https://learn.microsoft.com/en-us/azure/azure-monitor/data-collection/edge-pipeline-configure?tabs=Portal#workflow
But it seems this exporter is not open source. (And deploying this container standalone isn't supported by Microsoft either at this point.)
Does anybody have more information to this topic or is looking for a similar solution?
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: