Observability Tools That Can Send Data to Sazabi

Last verified on Nov 8, 2026.

Few teams switch tools in one move. They run a new one next to the old one, compare and then retire what they don't need. The sources in this category are built for that: each takes data an existing observability tool already collects and sends a copy to Sazabi.

What these sources have in common

They fall into three groups.

• Agents and pipelines you already run. The Datadog Agent, the New Relic infrastructure agent and a SigNoz Collector already collect logs. You add or change a destination. See the Datadog and SigNoz pages. New Relic's agent ships logs through a bundled Fluent Bit, so the Fluent Bit page is a close relative.
• Event streams from a product. Sentry and PostHog send events that the product produces, such as issue changes or analytics events. See Sentry and PostHog.
• Metrics through a Collector. Prometheus does not speak OTLP, so a Collector scrapes it and forwards. See Prometheus.

What each one leaves out

The edges matter more than the setup, so read them first.

• Datadog: only the Agent's logs pipeline is forwarded. Metrics, APM traces and other product data are not.
• New Relic: the infrastructure agent's logs go through. Metrics, events and traces are not supported, and APM agents can't send their logs directly. Browser logs and JavaScript errors come in through a separate New Relic Browser source.
• Sentry: the Internal Integration sends issue and comment events, not each error occurrence.
• SigNoz: logs and traces fan out through a second exporter. Metrics are not stored by that source.

Dual-ship or replace

This decision shows up in every one of these setups, and the sources differ.

With the Datadog Agent you can dual-ship, so Datadog keeps receiving logs and Sazabi gets a second copy, or send to Sazabi only through a dedicated Agent. The two approaches must not be combined in one Agent.

With New Relic, the change is a replacement. You change the endpoint of the logging plugin, so the logs go to Sazabi instead of New Relic. If you need both, run a second shipper.

With a Collector-based tool such as SigNoz, fan-out is native, because you add one more exporter beside the existing ones.

Example: following one trace across tools

New Relic APM agents can decorate log lines with trace.id, span.id and entity.guid when local log decorating is on. If your application logs carry those fields and the infrastructure agent forwards the log files, you can search Sazabi by trace ID.

2026-11-08T14:21:09Z ERROR payment declined order=8841
  trace.id=3f9a... span.id=51c2... entity.guid=MTA...

This is an example line with shortened values. Search for that trace.id and you get every line the request produced across services, even if the spans themselves remain in New Relic. The same idea works for Sentry. Log the Sentry event ID in a structured field next to the error, and one search links an issue event to the log lines around it.

What to check before you rely on it

• Overlap. During a trial both tools hold the same logs. Compare counts per service in each for the same hour before you trust either.
• Cost of the extra copy. Dual-shipping sends each log line out twice. Check how your cloud bills egress.
• Credentials. The Datadog Agent still needs a non-empty API key value to start. Sazabi ignores it and authenticates through the intake host.
• Plan limits. PostHog Data Pipeline destinations are a paid PostHog feature, and creating a Sentry Internal Integration needs the org:write scope, which only owners and managers have.

Detections

The detections section below lists what Sazabi runs for production projects today. Everything else in this guide, such as comparing counts or alerting on a missing service, is a query or alert you write on any stack. For the common transport, read about OpenTelemetry with Sazabi.