Connecting EKB On-Premise to your OpenTelemetry stack

On an EKB On-Premise install (Docker Compose or Kubernetes/Helm), EKB can send its traces, metrics, and logs to any OpenTelemetry-compatible backend you already run, using the standard OpenTelemetry Protocol (OTLP). EKB can also let its agents query your observability platform, so your team can ask questions like "which service is slow right now?" in chat.

This guide covers both:

Part	What it does	Direction
Part 1: Export EKB telemetry	EKB sends traces, metrics, and logs to your collector or backend	EKB → your platform
Part 2: Query your platform from EKB agents	EKB agents read services, traces, logs, metrics, and alerts from your platform	EKB → your platform's API

warning

Telemetry export is off by default. Nothing leaves your environment until you turn it on and point it at an endpoint you control.

How it works

flowchart LR
    subgraph EKB["EKB On-Premise (your network)"]
        API["EKB API\nservice: fast-api-<env>"]
        W["Background workers\nservice: celery-worker-<env>"]
    end
    C["OpenTelemetry Collector\n(recommended)"]
    API -- "OTLP/gRPC\ntraces, metrics, logs" --> C
    W -- "OTLP/gRPC\ntraces, metrics, logs" --> C
    C --> S["SigNoz\n(self-hosted or Cloud)"]
    C --> N["New Relic"]
    C --> O["Any OTLP backend\nGrafana, Datadog, Elastic, Jaeger…"]

Two things to know up front:

EKB exports OTLP over gRPC only (default port 4317). OTLP over HTTP (port 4318) is not supported by EKB itself. If your backend only accepts HTTP, put an OpenTelemetry Collector in between (see Send through a collector).
Two EKB processes export telemetry: the API server and the background workers. They show up as separate services in your backend.

Prerequisites

An OTLP/gRPC endpoint that EKB can reach from the network where it runs. This can be an OpenTelemetry Collector, your observability platform's ingest endpoint, or a vendor agent with OTLP ingest enabled.
Outbound network access from the EKB API and worker containers to that endpoint on the OTLP gRPC port (usually 4317, or 443 for hosted SaaS endpoints).
If the endpoint uses TLS with a private CA, the CA certificate file available to the EKB containers (see TLS and authentication).
Credentials for your backend if it requires them (ingestion key, API key, or token).
Permission to restart the EKB API and worker processes. Telemetry settings are read at process start.

Quick start

Set these environment variables on the EKB API and on every background worker:

OTEL_ENABLED=true
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector.observability.svc:4317
# Only if your endpoint needs authentication:
# OTEL_EXPORTER_OTLP_HEADERS=authorization=Bearer <token>

Restart the API and workers, then verify.

warning

Always set the endpoint explicitly. If OTEL_ENABLED=true and no endpoint is configured, EKB falls back to a built-in default of https://ingest.us.signoz.cloud:443 (SigNoz Cloud, US). In a locked-down on-premise environment that connection will fail, and in a less restricted one it would send telemetry to a destination you did not choose. Setting OTEL_EXPORTER_OTLP_ENDPOINT removes the fallback.

URL format

Always include the scheme:

Endpoint value	Result
`http://host:4317`	gRPC without TLS (plaintext). Use inside a trusted network only.
`https://host:4317` or `https://host:443`	gRPC with TLS
`host:4317` (no scheme)	Not supported. Always use `http://` or `https://`.

Configuration reference

Core settings

Variable	Default	Description
`OTEL_ENABLED`	`false`	Master switch. Must be `true` to export anything.
`OTEL_EXPORTER_OTLP_ENDPOINT`	SigNoz Cloud US (see the warning above)	OTLP/gRPC endpoint, including scheme. Used for traces, metrics, and logs.
`OTEL_EXPORTER_OTLP_HEADERS`	none	Comma-separated `key=value` pairs sent as request headers on every export, for example `signoz-ingestion-key=abc,x-tenant=eng`. Use lowercase header names. Treat the value as a secret.
`OTEL_RESOURCE_ATTRIBUTES`	none	Extra resource attributes added to all telemetry, for example `deployment.environment=prod-onprem,site=dc1`. A `service.name` entry here is ignored; use the service name variables below.
`OTEL_SERVICE_NAME`	`fast-api-<SERVER_ENV>`	Service name for the API only.
`OTEL_CELERY_SERVICE_NAME`	`celery-worker-<SERVER_ENV>`	Service name for background workers.
`SERVER_ENV`	`unknown`	Environment label used to build the default service names (for example `PROD`).
`LOG_LEVEL`	`INFO`	Minimum level of application logs. This also controls which logs are exported over OTLP.

warning

Do not set OTEL_SERVICE_NAME in an env file or secret shared by the API and the workers. Workers ignore it on purpose and use OTEL_CELERY_SERVICE_NAME or their default, so the two always appear as separate services.

Tuning and volume control

Variable	Default	Description
`OTEL_TRACES_SAMPLER`	Default (`parentbased_always_on`, 100% of traces)	Standard OpenTelemetry sampler setting. For example `parentbased_traceidratio`.
`OTEL_TRACES_SAMPLER_ARG`	none	Sampler argument, for example `0.1` to keep 10% of traces.
`OTEL_METRIC_EXPORT_INTERVAL`	`60000`	Metric push interval in milliseconds.
`OTEL_METRIC_EXPORT_TIMEOUT`	`30000`	Metric export timeout in milliseconds.
`OTEL_BSP_SCHEDULE_DELAY`	`5000`	Trace batch interval in milliseconds.
`OTEL_BSP_MAX_QUEUE_SIZE`	`2048`	Trace queue size. Data is dropped when the queue is full.
`OTEL_BSP_MAX_EXPORT_BATCH_SIZE`	`512`	Trace batch size.
`OTEL_BSP_EXPORT_TIMEOUT`	`30000`	Trace export timeout in milliseconds.
`OTEL_BLRP_SCHEDULE_DELAY`	`5000`	Log batch interval in milliseconds.
`OTEL_BLRP_MAX_QUEUE_SIZE`	`2048`	Log queue size.
`OTEL_BLRP_MAX_EXPORT_BATCH_SIZE`	`512`	Log batch size.
`OTEL_BLRP_EXPORT_TIMEOUT`	`30000`	Log export timeout in milliseconds.
`OTEL_ENABLE_HTTP_SIZE_METRICS`	`false`	Set `true` to include HTTP request/response size metrics (dropped by default to reduce volume).
`OTEL_DISABLE_PSYCOPG2`	`false`	Set `true` to turn off PostgreSQL query traces.
`OTEL_ENABLE_CONSOLE_EXPORTER`	`false`	Also print traces to the container's stdout. Useful for short debugging sessions only.

TLS settings

These are standard OpenTelemetry variables.

Variable	Description
`OTEL_EXPORTER_OTLP_CERTIFICATE`	Path (inside the container) to a PEM CA bundle used to verify your endpoint. Needed for private or self-signed CAs.
`OTEL_EXPORTER_OTLP_CLIENT_CERTIFICATE`	Path to the client certificate, for mutual TLS (mTLS).
`OTEL_EXPORTER_OTLP_CLIENT_KEY`	Path to the client private key, for mTLS.

info

OTEL_EXPORTER_OTLP_PROTOCOL appears in some sample configurations but has no effect on EKB. The protocol is always OTLP/gRPC.

Send through a collector

You can point EKB straight at a backend, and for a quick proof of concept that is fine. For production, send through an OpenTelemetry Collector that you run inside your network. It gives you:

One stable internal endpoint. You change backends without touching EKB.
Fan-out. The same data goes to more than one platform during a migration or evaluation.
Protocol bridging. EKB speaks gRPC; the collector can forward over gRPC or HTTP.
Governance. Redact attributes, drop noisy telemetry, add site labels, and apply tail sampling in one place.
Resilience. The collector buffers and retries when a backend is briefly unavailable.

Example collector configuration (OpenTelemetry Collector Contrib):

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 25
  resource/site:
    attributes:
      - key: deployment.environment
        value: prod-onprem
        action: upsert
  batch: {}

exporters:
  # Self-hosted SigNoz in the same network
  otlp/signoz:
    endpoint: signoz-otel-collector.signoz.svc:4317
    tls:
      insecure: true

  # New Relic (EU accounts: otlp.eu01.nr-data.net:4317)
  otlp/newrelic:
    endpoint: otlp.nr-data.net:4317
    headers:
      api-key: ${env:NEW_RELIC_LICENSE_KEY}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, resource/site, batch]
      exporters: [otlp/signoz, otlp/newrelic]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, resource/site, batch]
      exporters: [otlp/signoz, otlp/newrelic]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, resource/site, batch]
      exporters: [otlp/signoz, otlp/newrelic]

Keep only the exporters you use. Then point EKB at the collector:

OTEL_ENABLED=true
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector.observability.svc:4317

Platform guides

SigNoz (self-hosted)

Find the OTLP gRPC address of your SigNoz OpenTelemetry Collector. In a default SigNoz install this is the signoz-otel-collector service on port 4317.
Set EKB:

OTEL_ENABLED=true
OTEL_EXPORTER_OTLP_ENDPOINT=http://signoz-otel-collector.signoz.svc:4317
OTEL_RESOURCE_ATTRIBUTES=deployment.environment=prod-onprem

Restart the EKB API and workers.
In SigNoz, open Services. You should see fast-api-<SERVER_ENV> and celery-worker-<SERVER_ENV>.

info

Self-hosted SigNoz does not require an ingestion key by default. If you put authentication in front of your collector, add the matching header with OTEL_EXPORTER_OTLP_HEADERS.

Optional: serve the SigNoz UI through the EKB reverse proxy. The EKB nginx proxy can publish SigNoz on its own hostname (SigNoz does not support sub-path routing). Set SIGNOZ_SERVER_NAME to the hostname you want, and the proxy forwards it to the signoz service on port 8080. If the variable is unset, the proxy adds nothing and has no dependency on SigNoz.

SigNoz Cloud

In SigNoz Cloud, go to Settings → Ingestion Settings and create an ingestion key.
Set EKB, using your region's ingest endpoint (us, eu, or in):

OTEL_ENABLED=true
OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.<region>.signoz.cloud:443
OTEL_EXPORTER_OTLP_HEADERS=signoz-ingestion-key=<your-ingestion-key>

Allow outbound HTTPS/gRPC (port 443) from EKB to the ingest host.
Restart the EKB API and workers.

info

EKB also accepts SIGNOZ_INGESTION_KEY as a shortcut. When OTEL_EXPORTER_OTLP_HEADERS is not set, it sends the key as the signoz-ingestion-key header.

New Relic

New Relic accepts OTLP directly, so EKB can send to it with no New Relic agent installed.

Create or copy an ingest license key for your New Relic account.
Set EKB, using the endpoint for your account's region:

OTEL_ENABLED=true
OTEL_EXPORTER_OTLP_ENDPOINT=https://otlp.nr-data.net:4317
OTEL_EXPORTER_OTLP_HEADERS=api-key=<your-ingest-license-key>
# Recommended by New Relic for metrics:
OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=delta

EU accounts use otlp.eu01.nr-data.net:4317.

Allow outbound access to that host on port 4317.
Restart the EKB API and workers. In New Relic, look under APM & Services (OpenTelemetry) for fast-api-<SERVER_ENV> and celery-worker-<SERVER_ENV>.

info

If you prefer not to hold a New Relic key inside the EKB environment, use the collector pattern above. The key then lives only on the collector.

Other platforms

Any backend that ingests OTLP works with EKB. Choose the path that matches what you run:

You run	Recommended path
A collector or gateway you manage	Point `OTEL_EXPORTER_OTLP_ENDPOINT` at it.
Grafana (Tempo, Loki, Mimir) or Grafana Cloud	Collector with the `otlp` exporters for your Grafana endpoints, or Grafana Alloy as the receiver.
Datadog	Datadog Agent with OTLP ingest enabled on gRPC 4317, or the Datadog exporter in a collector. Point EKB at the agent or collector.
Elastic	Elastic's OTLP-compatible APM/EDOT endpoint, or a collector forwarding to it.
Jaeger (traces only)	Jaeger's native OTLP receiver on 4317. EKB also sends metrics and logs, so route those elsewhere or drop them in a collector.

Support summary

Platform	EKB export	Query from EKB agents (Part 2)
SigNoz (self-hosted and Cloud)	Yes, OTLP/gRPC	Yes (SigNoz toolkit)
New Relic	Yes, OTLP/gRPC	Yes (New Relic toolkit)
Datadog	Yes, via Datadog Agent or collector	Yes (Datadog toolkit)
Any other OTLP backend	Yes, directly or via collector	Not available today

TLS and authentication

Use TLS outside a trusted network. Use an https:// endpoint. For plaintext inside a closed network, use http://.
Private CA: mount your CA bundle into the API and worker containers and set OTEL_EXPORTER_OTLP_CERTIFICATE=/path/to/ca.pem.
Mutual TLS: also set OTEL_EXPORTER_OTLP_CLIENT_CERTIFICATE and OTEL_EXPORTER_OTLP_CLIENT_KEY.
Header authentication: use OTEL_EXPORTER_OTLP_HEADERS with lowercase header names (gRPC requires lowercase metadata keys). Header values are credentials. Do not commit them to source control or put them in plain-text Helm values.

Deployment recipes

Docker Compose

Add the variables to the env file that both your EKB API service (app) and worker service (celery) load:

# .env (loaded by the API and worker services)
OTEL_ENABLED=true
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317
OTEL_RESOURCE_ATTRIBUTES=deployment.environment=prod-onprem
SERVER_ENV=PROD

Make sure the EKB services and the collector share a Docker network (or the endpoint is reachable from it), then recreate the services:

docker compose up -d app celery

Kubernetes / Helm

The EKB Helm chart lets you add environment variables to the API and worker deployments through extraEnv. Keep credentials in a Kubernetes Secret and reference them with secretKeyRef:

kubectl create secret generic ekb-otel-headers \
  --namespace <ekb-namespace> \
  --from-literal=OTEL_EXPORTER_OTLP_HEADERS='api-key=<your-key>'

# values-otel.yaml
fastapiBackend:
  extraEnv:
    - name: OTEL_ENABLED
      value: "true"
    - name: OTEL_EXPORTER_OTLP_ENDPOINT
      value: "http://otel-collector.observability.svc:4317"
    - name: OTEL_RESOURCE_ATTRIBUTES
      value: "deployment.environment=prod-onprem"
    - name: OTEL_EXPORTER_OTLP_HEADERS
      valueFrom:
        secretKeyRef:
          name: ekb-otel-headers
          key: OTEL_EXPORTER_OTLP_HEADERS

celeryWorker:
  extraEnv:
    - name: OTEL_ENABLED
      value: "true"
    - name: OTEL_EXPORTER_OTLP_ENDPOINT
      value: "http://otel-collector.observability.svc:4317"
    - name: OTEL_RESOURCE_ATTRIBUTES
      value: "deployment.environment=prod-onprem"
    - name: OTEL_EXPORTER_OTLP_HEADERS
      valueFrom:
        secretKeyRef:
          name: ekb-otel-headers
          key: OTEL_EXPORTER_OTLP_HEADERS

helm upgrade <release> <chart> -n <ekb-namespace> -f <your-existing-values>.yaml -f values-otel.yaml

warning

Helm replaces lists, it does not merge them. If your existing values already define extraEnv for fastapiBackend or celeryWorker (for example, settings added by your on-premise installation overlay), copy those entries into your extraEnv list as well, or they will be removed.

extraEnv is also available for the billing and KB-retention worker deployments, if you run them.
All EKB backend workloads read the server-secrets Secret. If your installation manages that Secret outside the chart, you can add the OTEL_* keys there instead, and every backend workload picks them up.
The pods restart on helm upgrade, which applies the new settings.

Verify the integration

Confirm EKB initialised telemetry. At startup EKB logs the exporter configuration (header values are never logged):

# Docker Compose
docker compose logs app | grep -iE "OpenTelemetry|OTLP"

# Kubernetes
kubectl logs deploy/fastapi-backend -n <ekb-namespace> | grep -iE "OpenTelemetry|OTLP"

Expected lines include:

Initializing OpenTelemetry for service: fast-api-PROD
OTLP endpoint: http://otel-collector.observability.svc:4317
OTLP headers configured: True
OTLP log export configured

If you see OpenTelemetry is disabled, OTEL_ENABLED is not true in that process.

Check connectivity from the EKB network to the endpoint:

nc -zv otel-collector.observability.svc 4317

Generate some traffic. Open EKB and send a chat message or run a workflow.
Look in your backend.
- Traces: services fast-api-<SERVER_ENV> and celery-worker-<SERVER_ENV>.
- Logs: application logs with trace_id and span_id populated, so you can jump from a log line to its trace.
- Metrics: HTTP server and client metrics, process CPU and memory, and EKB application metrics. Metrics can take up to one export interval (60 seconds by default) to appear.

What EKB sends

Signals

Signal	Source	Notes
Traces	API requests, outbound HTTP calls, PostgreSQL queries, background task execution	Collected automatically. No changes to your workflows or agents are needed.
Metrics	HTTP server and client metrics, process CPU and memory (workers), EKB application metrics	HTTP request and response size metrics are dropped by default.
Logs	Application logs from the API and workers	Exported with `trace_id` and `span_id`. Level follows `LOG_LEVEL`.

Services and attributes

Item	Value
API service name	`fast-api-<SERVER_ENV>`
Worker service name	`celery-worker-<SERVER_ENV>`
Resource attributes	`service.name`, `worker.id`, plus anything you set in `OTEL_RESOURCE_ATTRIBUTES`
LLM calls	Model name, provider, and endpoint host (standard OpenTelemetry `gen_ai.*` attributes), plus the model that was requested, the model that served the call, and whether they differ

Recording the requested and the serving model is useful for reconciling LLM provider usage with EKB activity.

Data governance

Telemetry describes how the system behaves. Review it as you would any operational data store:

Background task inputs are redacted. Task arguments are replaced with [REDACTED] before export. Only the task name and ID remain.
LLM attributes record model, provider, and endpoint host. They do not record prompt text.
Database traces and application logs can contain operational identifiers, such as table names, query shapes, IDs, and error messages. Application logs are exported at your configured LOG_LEVEL.
To remove or mask attributes before they reach a backend, use the collector's attributes, redaction, or filter processors (see Send through a collector).
To reduce volume or cost, lower OTEL_TRACES_SAMPLER_ARG, raise LOG_LEVEL to WARNING, or filter in the collector.

Query your platform from EKB agents

EKB agents can read from your observability platform through built-in toolkits. Add a toolkit to an agent in the agent builder, enter the connection details, and choose which tools the agent may use. Credentials are stored in EKB's encrypted toolkit configuration.

Toolkit	Connection details	What agents can do
SigNoz	SigNoz instance URL and API key	List services and get a service overview, search traces and read trace detail, query logs and log attribute values, list and query metrics, list alert rules and read alert rule detail
New Relic	User API key, default account ID, region (US or EU)	Run NRQL queries, list and inspect entities, list alert policies and conditions, list active incidents
Datadog	API key, application key, site	Search and read monitors, dashboards, hosts, metrics, and logs; list, search, and read incidents; create or update incidents; mute or unmute monitors

SigNoz

In SigNoz, create a service account API key (Settings → Service Accounts). Use a read-only role. This key is separate from the ingestion key used in Part 1 and cannot be used for ingestion.
In EKB, add the SigNoz toolkit to your agent. Enter the SigNoz instance URL (for example https://signoz.example.com) and the API key.
Keep all tools selected, or choose a subset.

info

The URL can be an internal address. It only needs to be reachable from the EKB API and worker containers. If it is served with a private CA, make sure those containers trust that CA.

New Relic

In New Relic, create a User API key (not an ingest license key).
In EKB, add the New Relic toolkit. Enter the API key, your account ID, and your region.
Allow outbound HTTPS from EKB to api.newrelic.com (US) or api.eu.newrelic.com (EU).

Datadog

In Datadog, create an API key and an Application key.
In EKB, add the Datadog toolkit. Enter both keys and your Datadog site (for example datadoghq.com or datadoghq.eu).
Allow outbound HTTPS from EKB to the matching api.<site> host.

warning

The Datadog toolkit includes tools that change state (creating and updating incidents, muting monitors). Enable only the tools an agent needs, and use credentials scoped to the same access.

info

The New Relic and Datadog toolkits call those vendors' public SaaS APIs, so your EKB egress rules must allow them. The SigNoz toolkit calls whatever URL you enter, so it works against a SigNoz instance that is only reachable inside your network.

Part 1 and Part 2 are independent. You can export telemetry to one platform and query another, or use only one of the two.

Troubleshooting

warning

Export failures are silent in the EKB logs. To avoid error noise, EKB lowers the log level of the OpenTelemetry exporter libraries. A refused connection or a rejected key will not show up as an error in EKB's logs. Check the collector or backend logs and the network path first.

Symptom	Likely cause	Fix
Startup log says OpenTelemetry is disabled	`OTEL_ENABLED` is not `true` in that process	Set `OTEL_ENABLED=true` on the API and the workers, then restart.
No data in the backend, startup log looks correct	Wrong endpoint, port, or firewall rule	Run `nc -zv <host> 4317` from the EKB network. Confirm the endpoint, port, and scheme.
Data goes to SigNoz Cloud, or fails with a connection error to `ingest.us.signoz.cloud`	`OTEL_EXPORTER_OTLP_ENDPOINT` is not set, so the built-in default is used	Set the endpoint explicitly.
Works with `http://` but not `https://` (or the reverse)	Scheme does not match the listener	Use `https://` for TLS endpoints and `http://` for plaintext.
TLS handshake or certificate errors in the collector or backend	Private CA not trusted, or mTLS expected	Set `OTEL_EXPORTER_OTLP_CERTIFICATE` (and the client cert and key for mTLS).
Endpoint on port 4318, or a backend that only accepts OTLP/HTTP	EKB exports gRPC only	Use port 4317, or send through a collector that bridges to HTTP.
`unauthenticated` or permission denied at the backend	Wrong key, wrong header name, or the key has the wrong scope	Confirm the header name and value. Use lowercase names. Make sure it is an ingest key, not a query key.
API data present, but no worker data	Workers do not have the `OTEL_*` variables	Add them to the background worker deployments.
API and worker data appear under one service name	`OTEL_SERVICE_NAME` is set in a file shared by both	Remove it from the shared file. Use `OTEL_CELERY_SERVICE_NAME` to rename workers.
Settings changed but nothing changed	Telemetry is configured at process start	Restart the API and workers.
Traces appear but logs do not, or the reverse	Collector pipeline is missing a signal	Add `traces`, `metrics`, and `logs` pipelines. Make sure each has an exporter.
High volume or cost	100% trace sampling and INFO logs	Set `OTEL_TRACES_SAMPLER` and `OTEL_TRACES_SAMPLER_ARG`, raise `LOG_LEVEL`, or filter in the collector.
An agent's observability toolkit returns authentication errors	Wrong key type	SigNoz needs a service account (query) key. New Relic needs a User key. Datadog needs both an API key and an application key.

Telemetry export runs in the background and never blocks user requests. If the endpoint is down, EKB keeps working, and data that cannot be delivered after the queue fills is dropped.

Quick checklist

Endpoint decided and reachable from the EKB network (OTLP/gRPC, port 4317 or 443)
Collector deployed (recommended for production)
OTEL_ENABLED=true and OTEL_EXPORTER_OTLP_ENDPOINT set explicitly on the API and the workers
Credentials stored as secrets, not in plain-text configuration
TLS configured (https://, plus a CA bundle if private)
OTEL_SERVICE_NAME not set in files shared with workers
Sampling and LOG_LEVEL chosen for your volume and budget
API and workers restarted, and both services visible in your backend
(Optional) Observability toolkit added to an agent for Part 2, with least-privilege credentials

Getting help

If something is not working after the checks above, contact Automation Anywhere support and include:

Your deployment type (Docker Compose or Kubernetes) and the EKB version
The OTEL_* variables you set (with header values removed)
The startup log lines from Verify the integration
The collector or backend logs from the same time window

How it works​

Prerequisites​

Quick start​

URL format​

Configuration reference​

Core settings​

Tuning and volume control​

TLS settings​

Send through a collector​

Platform guides​

SigNoz (self-hosted)​

SigNoz Cloud​

New Relic​

Other platforms​

Support summary​

TLS and authentication​

Deployment recipes​

Docker Compose​

Kubernetes / Helm​

Verify the integration​

What EKB sends​

Signals​

Services and attributes​

Data governance​

Query your platform from EKB agents​

SigNoz​

New Relic​

Datadog​

Troubleshooting​

Quick checklist​

Getting help​

How it works

Prerequisites

Quick start

URL format

Configuration reference

Core settings

Tuning and volume control

TLS settings

Send through a collector

Platform guides

SigNoz (self-hosted)

SigNoz Cloud

New Relic

Other platforms

Support summary

TLS and authentication

Deployment recipes

Docker Compose

Kubernetes / Helm

Verify the integration

What EKB sends

Signals

Services and attributes

Data governance

Query your platform from EKB agents

SigNoz

New Relic

Datadog

Troubleshooting

Quick checklist

Getting help