Major difference (SSI vs USM)

• Single Step APM Instrumentation (SSI): in-process APM. Datadog Agent loads Datadog APM language SDKs into supported processes to enable distributed tracing “without requiring code changes.” (Datadog Monitoring)
• Universal Service Monitoring (USM): service health metrics for uninstrumented services. USM provides visibility “without having to instrument your code,” relying on a configured Datadog Agent + Unified Service Tagging, and brings performance data into Software Catalog and Service Map. (Datadog Monitoring)

---

Datadog Single Step APM Instrumentation (SSI)

What you get (when it fits)

• Distributed traces collected by loading the Datadog SDK into supported processes, with no code changes required. (Datadog Monitoring)
• Designed to reduce onboarding by automatically installing Datadog SDKs with “no additional configuration required.” (Datadog Monitoring)

Use cases

• You want APM distributed tracing quickly across services in supported languages/environments, without adding SDKs in code. (Datadog Monitoring)
• You’re running on supported environments like Linux hosts, containers (Kubernetes/Docker), or .NET apps in Windows IIS, and want auto-instrumentation without changing app dependencies/images. (Datadog Monitoring)

Not-fit scenarios (from Datadog docs)

• If your app already has custom instrumentation code: SSI requires removing it; SSI is automatically disabled if custom instrumentation is detected. (Datadog Monitoring)
• ECS Fargate is not supported. (Datadog Monitoring)
• Hardened SELinux environments are not supported (listed under limitations). (Datadog Monitoring)
• Very small VM instances (example t2.micro) can hit timeouts; Datadog recommends a larger instance type. (Datadog Monitoring)
• Kubernetes gotcha: SSI does not instrument applications in the namespace where the Datadog Agent is installed. (Datadog Monitoring)

High-level implementation steps

Common prerequisites

1. Remove any custom instrumentation code and restart the app. (Datadog Monitoring)
2. Confirm compatibility (languages / OS / architecture) in the SSI compatibility guide. (Datadog Monitoring)

Linux host / VM (high level)

1. In Datadog’s Linux Agent install flow, turn on APM Instrumentation. (Datadog Monitoring)
2. Install the Datadog Agent using the provided command. (Datadog Monitoring)
3. Restart your applications. (Datadog Monitoring)

Kubernetes (high level)

1. Install the Agent in a separate namespace (SSI won’t instrument apps in the Agent namespace). (Datadog Monitoring)
2. Follow Datadog’s Kubernetes Agent install flow (Helm/Operator), and turn on APM Instrumentation. (Datadog Monitoring)

Supported platforms (what Datadog explicitly states)

• Works for apps on Linux hosts, containers such as Kubernetes and Docker, and .NET applications served by Windows IIS. (Datadog Monitoring)
• Supported languages (SSI) include: Java, Python, Ruby, Node.js, .NET, PHP. (Datadog Monitoring)

---

Datadog Universal Service Monitoring (USM)

What you get (when it fits)

• Visibility into service health metrics across your stack without instrumenting your code. (Datadog Monitoring)
• Depends on Datadog Agent + Unified Service Tagging and shows performance data for uninstrumented services in places like Software Catalog and Service Map. (Datadog Monitoring)

Use cases

• You want broad service health visibility for services that don’t (yet) have APM libraries, and you still want them represented in Service Map / Software Catalog views. (Datadog Monitoring)
• You want monitoring that does not require installing tracing libraries. (Datadog Monitoring)

Not-fit scenarios (from Datadog docs)

• USM requires Datadog system-probe and is not supported on GKE Autopilot. (Datadog Monitoring)
• Platform constraints:
  • Linux: Kernel 4.14+, and (for containerized) CentOS/RHEL 8.0+. (Datadog Monitoring)
  • Windows: Windows 2012 R2+. (Datadog Monitoring)
• Protocol scope: supported application-layer protocols listed are HTTP and HTTPS (OpenSSL). (Datadog Monitoring)
• Service-name detection caveat: USM reads environment variables as they exist when a process starts (Linux /proc/PID/environ, or Windows APIs). Changes after start may not be seen. (Datadog Monitoring)

High-level implementation steps

1. Ensure your Datadog Agent version meets requirements (containerized services: Agent 6.40+ or 7.40+, with some preview features requiring higher). (Datadog Monitoring)
2. Meet prerequisites:
   • Linux: service running in a container (non-containerized Linux is documented as Preview). (Datadog Monitoring)
   • Windows: service running on a virtual machine. (Datadog Monitoring)
   • Tracing library not required. (Datadog Monitoring)
3. Apply Unified Service Tagging at least for env (service/version optional), and ensure env vars are set before the process starts. (Datadog Monitoring)
4. Enable USM in the Agent (examples shown in docs include Helm/Operator toggles and system-probe env vars such as DD_SYSTEM_PROBE_SERVICE_MONITORING_ENABLED=true). (Datadog Monitoring)
5. For non-containerized services on Linux (documented as available): enable in system-probe.yaml under service_monitoring_config and note Agent 7.42+ requirement. (Datadog Monitoring)

Supported platforms (explicit in docs)

• Linux: Kernel 4.14+; (containerized) CentOS/RHEL 8.0+. (Datadog Monitoring)
• Windows: 2012 R2+. (Datadog Monitoring)
• Requires system-probe (with the GKE Autopilot limitation). (Datadog Monitoring)

---

Summary comparison table

Area	SSI (Single Step APM Instrumentation)	USM (Universal Service Monitoring)
Primary outcome	Distributed tracing by loading Datadog SDK into supported processes (no code changes). (Datadog Monitoring)	Service health metrics for uninstrumented services, shown in Software Catalog/Service Map (no code instrumentation). (Datadog Monitoring)
How it works	Agent instruments apps by loading Datadog APM SDKs into processes. (Datadog Monitoring)	Relies on Datadog Agent + Unified Service Tagging; requires system-probe. (Datadog Monitoring)
Best fit	You need full APM traces quickly without adding SDKs in code. (Datadog Monitoring)	You need broad visibility where you can’t/won’t add tracing libraries yet. (Datadog Monitoring)
Not fit (examples)	Custom instrumentation present (SSI disables), ECS Fargate unsupported, hardened SELinux unsupported, very small VMs may timeout. (Datadog Monitoring)	Requires system-probe (not on GKE Autopilot), limited to stated OS/kernel/protocol constraints; env vars must be present at process start. (Datadog Monitoring)
Supported platforms (high level)	Linux hosts, Docker/Kubernetes containers, Windows IIS for .NET; languages include Java/Python/Ruby/Node.js/.NET/PHP. (Datadog Monitoring)	Linux kernel 4.14+ (containerized prereq), Windows 2012 R2+; supports HTTP and HTTPS (OpenSSL). (Datadog Monitoring)
High-level enablement	Enable APM Instrumentation in Agent install/update; restart apps; follow Linux/K8s guides. (Datadog Monitoring)	Ensure Agent version, enable USM in Agent/system-probe; apply Unified Service Tagging (env required) before process start. (Datadog Monitoring)

Table takeaways (quick summary)

• Choose SSI when you need distributed traces/APM with minimal onboarding and supported runtimes. (Datadog Monitoring)
• Choose USM when you need code-free service health visibility across uninstrumented services, and your platform supports system-probe. (Datadog Monitoring)