Use Moneat with your existing Sentry SDKs and Datadog Agents

I built Moneat partly because changing monitoring providers should not mean replacing instrumentation that already works.

Moneat accepts supported telemetry from Sentry SDKs and the Datadog Agent. For Sentry-compatible error reporting, the main application change is the DSN. For the Datadog Agent, you configure the destination for each telemetry type you use. In both cases, verify the resulting data before moving production alerts or removing the previous destination.

Sentry-compatible SDKs

Keep the official Sentry SDK and replace its DSN with the generated Moneat service DSN:

import * as Sentry from "@sentry/node";
import { nodeProfilingIntegration } from "@sentry/profiling-node";

Sentry.init({
  dsn: process.env.MONEAT_DSN,
  integrations: [nodeProfilingIntegration()],
  tracesSampleRate: 0.1,
  profileSessionSampleRate: 0.1,
  profileLifecycle: "trace",
});

For Node.js profiling, use @sentry/node and @sentry/profiling-node at version 10.70.0 or later, with both packages at exactly the same version.

Find the DSN under Setup → Services & SDKs. The generated value contains the service-specific public key and destination; do not assemble the URL by hand.

The compatibility path covers supported Sentry envelope signals and context such as exceptions, messages, breadcrumbs, tags, users, releases, traces, session replays, and Sentry SDK profiles. Enable profiling with profileSessionSampleRate and profileLifecycle, then verify the result under Profiles → Sentry SDK. Compatibility does not mean that every Sentry product or SDK feature behaves identically.

For new vendor-neutral logs, traces, and metrics, prefer OpenTelemetry. It gives those signals a portable model instead of making a vendor protocol the center of your application.

Datadog Agent

The Agent has several independent destinations. Setting only the API key, or redirecting only an advanced track, does not redirect the main infrastructure, APM, log, and process payloads.

Go to Monitoring → Hosts, select Add Host, choose the signals you need, and use the generated command and datadog.yaml. The generated setup supplies the current API key and configures the required destinations, including:

• the main DD_DD_URL intake;
• DD_APM_DD_URL when APM is enabled;
• the log destination and TLS mode when logs are enabled;
• the process destination when process collection is enabled; and
• source-specific endpoints for enabled tracks such as profiling, database monitoring, containers, network devices, SBOM, and synthetics.

The maintained Datadog Agent setup guide explains which advanced tracks require the generated YAML. Agent keys are managed under Settings → Agent Keys.

Verify before switching

Keep existing instrumentation for supported signals. Review the remaining configuration and workflow differences before switching.

For a Sentry-compatible SDK, trigger a test error and inspect its stack trace, release, environment, tags, breadcrumbs, and user context. If you send traces or replays, test those separately.

For the Datadog Agent, confirm the host, processes, logs, traces, and every enabled advanced track arrive. Then test the alert rules that depend on that telemetry. An agent reporting CPU metrics does not prove its logs or profiles use the same destination.

Read the Sentry migration guide or generate an Agent configuration.