If you are using a Datadog, Langfuse, Langchain, or other OTEL target, you do nothing. Just query it. Build alerts, dashboards, and datasets; whatever you normally do with your OTEL collector. A forward OTEL collector deployment is still useful for filtering but the Datadog Agent, for example, already has buffering and filtering built into it.
If you want to deploy your own collector and write your own handler (e.g. put it into a database), you can generate the stubs for the OTEL payloads and convert to domain records.
2. Generate the type/class stubs and endpoints for your platform.
3. I strongly recommend pre-filtering with the open source `opentelemetry-collector` before your custom endpoint handles the inbound telemetry payload. The collector is optimized for performing the filtering and I put it upstream of my custom ingest endpoint on a very small VM just to pre-filter and perform auth checks[0][1] on the inbound channel.
4. Do what you need to with the inbound payloads. Examples below:
I run my backend on Postgres with partitioned tables. You can forward to Elastic or other OLAP-type database targets for querying. You can see examples of what I do with the session telemetry here: https://zeeq.ai/docs/key-features/session-telemetry
alt Hacker News
If you are using a Datadog, Langfuse, Langchain, or other OTEL target, you do nothing. Just query it. Build alerts, dashboards, and datasets; whatever you normally do with your OTEL collector. A forward OTEL collector deployment is still useful for filtering but the Datadog Agent, for example, already has buffering and filtering built into it.
If you want to deploy your own collector and write your own handler (e.g. put it into a database), you can generate the stubs for the OTEL payloads and convert to domain records.
1. Get the protos here: https://github.com/open-telemetry/opentelemetry-proto
2. Generate the type/class stubs and endpoints for your platform.
3. I strongly recommend pre-filtering with the open source `opentelemetry-collector` before your custom endpoint handles the inbound telemetry payload. The collector is optimized for performing the filtering and I put it upstream of my custom ingest endpoint on a very small VM just to pre-filter and perform auth checks[0][1] on the inbound channel.
4. Do what you need to with the inbound payloads. Examples below:
- Ingest endpoint (Codex/Claude -> OTEL collector -> API): https://github.com/zeeq-ai/zeeq-app/blob/main/src/backend/Ze...
- Codex telemetry adapter: https://github.com/zeeq-ai/zeeq-app/blob/main/src/backend/Ze...
- CC telemetry adapter: https://github.com/zeeq-ai/zeeq-app/blob/main/src/backend/Ze...
I run my backend on Postgres with partitioned tables. You can forward to Elastic or other OLAP-type database targets for querying. You can see examples of what I do with the session telemetry here: https://zeeq.ai/docs/key-features/session-telemetry
[0] https://github.com/zeeq-ai/zeeq-app/blob/main/build/otel-col...
[1] https://github.com/open-telemetry/opentelemetry-collector-co...