ZipLogger does not speak the Datadog Agent's protocol. It speaks OpenTelemetry: logs, traces and metrics over OTLP/HTTP, with no collector required for your applications' own telemetry. For Kubernetes clusters, ZipLogger's Helm chart takes over the cluster-monitoring part of the Agent's job. The route depends on what you run today, and Datadog can stay in place until you are sure.
Logs, traces and metrics over OTLP · Datadog alerts into ZipLogger on-call · Run both while you move
Your services use OpenTelemetry SDKs and export to the Datadog Agent or a Collector. Change the
exporter's endpoint and header and you are done: /v1/logs, /v1/traces
and /v1/metrics are the standard paths.
Replace dd-trace with OpenTelemetry instrumentation; every major language has
auto-instrumentation that needs little or no code. To buy time, an OpenTelemetry Collector with
its datadog receiver accepts dd-trace traffic as it is and forwards it to ZipLogger.
Tail the same files with Fluent Bit, Vector or the Collector's filelog receiver and
ship them to ZipLogger's log endpoint.
Shipper setup →
| In Datadog | In ZipLogger |
|---|---|
| APM traces | OTLP traces → APM (services, endpoints, dependencies, an observed service map, release comparison and regression detection) and the Traces page waterfall. Endpoints are named from each span's HTTP method and route, so dd-trace spans converted by the Collector may group differently than they did in Datadog |
| Logs | Fluent Bit, Vector or OTLP logs → Search, with log patterns and the commit that introduced an error |
| Log pipelines (parsing, metrics from logs) | Log pipelines: parse rules (patterns, JSON, key=value) and metric rules that count logs or read a numeric field, applied as logs arrive. Not a full Grok library, and stored logs are not reparsed |
| Custom metrics (DogStatsD) | The Collector's statsd receiver, which reads DogStatsD tags → /v1/metrics |
| Host and container metrics | The Collector's hostmetrics receiver → /v1/metrics, charted on the Metrics page and the Metric dashboard widget |
| Kubernetes (cluster state, events, container logs, node and pod usage) | The ZipLogger Helm chart → the Kubernetes page, with detected problems that open incidents. Setup |
| Monitors | ZipLogger alert rules, including metric monitors (threshold, per-group incidents) and anomaly monitors (daily or weekly seasonality). While you move, Datadog monitors can open ZipLogger incidents through a webhook, so they page through ZipLogger on-call |
| Service level objectives | APM SLOs on availability or latency per service or endpoint, with multi-window burn-rate alerts. SLOs on arbitrary metrics or monitors are not available |
| Dashboards | Rebuilt as ZipLogger dashboards, or in Grafana pointed at ZipLogger's Grafana-compatible data sources |
| Synthetics | Browser automations and health checks |
| On-call (if you pair Datadog with a pager) | Schedules, escalation and SMS and voice paging, built in |
Every OpenTelemetry SDK reads the same variables. The endpoint is the origin only; the exporter
adds /v1/traces, /v1/metrics and /v1/logs itself.
Set metrics to delta temporality. ZipLogger stores a value per interval, and while it converts cumulative counters itself, delta is exact across restarts on both sides.
Histograms arrive as .count, .sum,
.avg, .p95, .p99 and .max series, so
http.server.request.duration is charted as
http.server.request.duration.p95. Values keep the instrument's unit.
OTEL_EXPORTER_OTLP_ENDPOINT=https://app.ziplogger.ai
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
OTEL_EXPORTER_OTLP_HEADERS=X-Api-Key=zk_...
OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=delta
OTEL_SERVICE_NAME=checkout-api
OTEL_RESOURCE_ATTRIBUTES=deployment.environment=productionRun an OpenTelemetry Collector (the contrib distribution) where the Datadog Agent runs today, and
point DD_AGENT_HOST at it. The datadog receiver takes dd-trace spans on
port 8126, the statsd receiver takes DogStatsD on 8125, and both leave as OTLP.
To run both platforms side by side, add the Collector's Datadog exporter to the same pipelines. Every signal then goes to both until you turn one off.
Check the stability level of each Collector component in its own documentation before you depend on it; some of the Datadog-compatible receivers are young.
receivers:
datadog:
endpoint: 0.0.0.0:8126 # dd-trace
statsd:
endpoint: 0.0.0.0:8125 # DogStatsD
otlp:
protocols: { grpc: {}, http: {} }
processors:
batch: {}
exporters:
otlphttp/ziplogger:
endpoint: https://app.ziplogger.ai
headers:
X-Api-Key: zk_...
compression: gzip
service:
pipelines:
traces:
receivers: [datadog, otlp]
processors: [batch]
exporters: [otlphttp/ziplogger]
metrics:
receivers: [statsd, otlp]
processors: [batch]
exporters: [otlphttp/ziplogger]
logs:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/ziplogger]Datadog is a much larger product than ZipLogger, and for some teams that depth is the point. The honest split:
They will out-depth us on infrastructure metrics and integration count. What ZipLogger offers is the same core signals, plus the commit and the pager, at a price a small team can approve.
Not directly. ZipLogger accepts OpenTelemetry (OTLP over HTTP) for logs, traces and metrics, plus its own SDKs and log shippers. To keep dd-trace or DogStatsD while you migrate, run an OpenTelemetry Collector with its datadog and statsd receivers and export to ZipLogger.
Yes, on /v1/metrics, protobuf or JSON. Gauges and counters are stored as values; histograms and summaries become count, sum, average, percentile and maximum series. Cumulative counters are converted to per-interval increases, but delta temporality is recommended.
If you already use OpenTelemetry, no: change the exporter endpoint and header. If you use dd-trace, the long-term route is OpenTelemetry instrumentation, which is mostly configuration in every major language. A Collector with the datadog receiver lets dd-trace keep working in the meantime.
Yes. Add ZipLogger as a webhook in Datadog and monitor alerts open incidents in ZipLogger, with the same on-call schedules, escalation and paging as ZipLogger's own rules. Move the monitors over as ZipLogger alert rules when you are ready.
No. Dashboards are rebuilt, either as ZipLogger dashboards or in Grafana pointed at ZipLogger's Grafana-compatible data sources. Metric names follow OpenTelemetry once you move, so most panels change anyway.