Loading

Configure EDOT Cloud Forwarder for Azure

Before deploying EDOT Cloud Forwarder for Azure, configure the Bicep template parameters based on your specific requirements. The template uses the following settings to deploy and configure the EDOT Collector Function App.

To provide the required parameters, you can either:

  • Use the --parameters flag when deploying the template.
  • Configure the parameters in the Azure portal when deploying the template.

These parameters are available in the Bicep template. Configure them using the --parameters flag when deploying the template.

Parameter Description
otlpEndpoint OTLP service endpoint obtained from Elastic Cloud Serverless or Elastic Cloud Hosted.
elasticApiKey Elasticsearch API key for authentication.
Parameter Default Description Available options
logsDecoder ds Decoder to decode the logs. ds (diagnostic settings)
metricsDecoder ds Decoder to decode the metrics. ds (diagnostic settings) and dcr (Data Collection Rules)
eventHubPartitionCount 4 Number of partitions in the event hubs.
eventHubMessageRetentionInDays 1 Number of days for the event hub data retention.
functionAppAlwaysReadyInstances 0 Number of always-ready instances for function app. Refer to Always-ready instances. 0 or more
version (see template) EDOT Cloud Forwarder (ECF) for Azure version to deploy. The infra/ecf.bicep contains the latest version available.

Always Ready is an optional number of instances that can be configured to be always enabled and assigned to different triggers and functions of the app. These instances stay pre-warmed so Event Hub–triggered functions can process messages as soon as they arrive, reducing cold start latency and helping ensure predictable processing when traffic arrives.

  • Parameter: functionAppAlwaysReadyInstances (both infra/ecf.bicep and infra/ecf-flex-consumption-vnet.bicep).
  • Default: 0 (no always-ready instances).
Setting Pros Cons
0 (default) Lower cost; you pay only for execution time. Cold starts can add latency when the first messages arrive or when scaling from zero.
1 or more Lower latency; messages can be processed immediately. More predictable behavior under variable or bursty traffic. Higher cost; refer to the Billing section.

You are billed for the total amount of memory provisioned for the baseline while each always-ready instance is idle. For the total amount of memory provisioned for the execution time, each always-ready instance is executing functions, as well as for the total number of executions.

Use always-ready instances when you need better latency or more predictable processing and are willing to pay for pre-warmed capacity. For cost-sensitive or low-traffic scenarios, keep the default of 0.

The Bicep template creates the following resources to process telemetry data:

Resource name Type Description
eventHubNamespace Microsoft.EventHub/namespaces Event Hubs namespace to host the event hubs to stream logs and metrics.
logsEventHub Microsoft.EventHub/namespaces/eventhubs Event hub for the logs.
metricsEventHub Microsoft.EventHub/namespaces/eventhubs Event hub for the metrics.
storageAccount Microsoft.Storage/storageAccounts Storage Account container to store the Event Hubs trigger checkpoint information and the failed messages.
hostingPlan Microsoft.Web/serverfarms Hosting plan that runs the function app.
functionApp Microsoft.Web/sites The function app that runs the EDOT Collector.
applicationInsights Microsoft.Insights/components Application Insights instance to monitor the application.

Note the following:

  • The eventHubNamespace hosts the two event hubs responsible for receiving logs and metrics from Azure services.
  • The storageAccount stores the checkpoint information for the Event Hub triggers, and it also hosts the failed logs and metrics in the logs-error-container and metrics-error-container containers.
  • The functionApp is the core component responsible for running the OTel collector inside the Azure Function.