Skip to main content

​
Overview

Bronto supports several methods for ingesting data from Azure environments. The right choice depends on where your telemetry originates, your infrastructure preferences, and cost constraints. Bronto ingests OpenTelemetry logs, metrics, and traces. Broadly, Azure telemetry falls into two categories:
  • Platform, diagnostic, and activity logs — emitted by Azure services through diagnostic settings. These are streamed to Bronto via the Azure Event Hub Forwarder.
  • Application logs, metrics, and traces — emitted by your own workloads. Send these to Bronto using OpenTelemetry on Azure.

​
Service-to-Method Mapping

Different Azure services suit different ingestion methods. The recommended method is the simplest path that gets the data into Bronto; alternatives may be preferable depending on your existing infrastructure or cost constraints. Each service name in the table below links to a per-source landing page with a short summary of what the service emits and the configuration entry points for that data.
Where the OpenTelemetry SDK supports your runtime, prefer OTel-based instrumentation — it sends logs, metrics, and traces through one Collector and gives you consistent resource identity. OpenTelemetry on Azure covers AKS, Container Apps, Container Instances, VMs, App Service, and Functions.

​
Ingestion Methods

Bronto supports the following Azure ingestion methods:
  • Azure Event Hub Forwarder — A Bronto Function App subscribes to an Event Hub and forwards platform, diagnostic, and activity logs streamed to it via diagnostic settings. It can also receive logs re-exported from a Log Analytics workspace via Data Export.
  • OpenTelemetry on Azure — Application logs, metrics, and traces via a self-managed OpenTelemetry Collector or the OpenTelemetry SDK.
  • Azure Monitor OpenTelemetry Distro — Microsoft’s SDK distro; a convenient option for teams already using Application Insights who want to forward the same data to Bronto.
For assistance or questions, contact support@bronto.io.