SDK Integrations
The SDK integrations provision runtime dashboards and alert rules for applications instrumented with OpenTelemetry. Install one, instrument your application, and you have runtime monitoring in place without building it yourself.
Navigate to Integrations from the left-hand sidebar and open the SDKs tab.
What they provision
Each SDK integration installs one runtime dashboard per upstream metric-set version, plus a handful of runtime alert rules.
| SDK | Dashboards | Alert rules | Alert group |
|---|---|---|---|
| Java | 26 | 4 | java_runtime_alerts |
| .NET | 8 | 4 | dotnet_runtime_alerts |
| Go | 6 | 4 | go_runtime_alerts |
| Node.js | 9 | 3 | nodejs_runtime_alerts |
| Python | 5 | 5 | python_runtime_alerts |
The dashboard counts differ because each covers that language's full range of upstream metric-set versions. Java's 26 span thirteen Java-agent eras from v0.11.0 and thirteen semantic-convention sets from 1.9.0.
Ruby
The Ruby OpenTelemetry SDK does not officially support metrics, so a Ruby integration cannot provide runtime dashboards. Ruby applications still send traces and span metrics, which Coworker can analyse.
Alerts ship paused
The alert rules are installed paused. You opt in per rule rather than being alerted on everything from the moment you install, and once you enable a rule that choice persists across integration upgrades.
Each SDK's rules sit in their own alert group, named in the table above, so you can find them together in Alerting.
Every threshold is either scale-free or derived from the runtime itself, so the same rules apply unchanged whatever the size of your service. Go's four rules, for instance, cover heap usage against GOMEMLIMIT, goroutine count, GC pause overhead, and scheduler latency.
Dashboards and data sources
Provisioned dashboards are tagged integration along with a tag for the language, such as go, so you can find everything an integration added.
The SDK integrations bind to your account's existing shared metrics data source rather than creating their own, so you keep a single Prometheus source for all metrics. That source is adopted, not owned - uninstalling the integration leaves it in place.
Installing
SDK integrations run Read-only, which is the default and requires nothing: the metrics endpoint and signing key come from the service environment. There is no configuration to complete during the install itself.
Once installed, the Installation guide tab on the integration's detail view walks through instrumenting your application and points you to the dashboard to open. See Integrations for the install flow and how to manage an installation afterwards.
Instrumenting your application
These dashboards are built on runtime metrics - the heap, garbage collector, threads and scheduler your language exposes about itself. Your application has to emit them, which takes the runtime instrumentation for that language: the Go integration wants go.opentelemetry.io/contrib/instrumentation/runtime registered at startup, and each of the others has its equivalent.
The per-language steps live in the Installation guide tab on each integration, which is written against the metric sets these dashboards expect. Follow that first.
The OpenTelemetry instrumentation guides cover general instrumentation - exporting metrics, traces and logs to OpsPilot - and are worth reading alongside, but most of them do not set up runtime instrumentation, so they will not fill these dashboards on their own.
Need more help?
Contact support in the chat bubble and let us know how we can assist.