Content telemetry

Content telemetry gives publishers and administrators visibility into how deployed content behaves at runtime. When enabled, Posit Connect automatically instruments content processes so they emit OpenTelemetry traces without requiring code changes from publishers.

Enabling content telemetry

Enable OpenTelemetry to make content telemetry available:

/etc/rstudio-connect/rstudio-connect.gcfg
[OpenTelemetry]
Enabled = true

Connect collects content traces only when both server settings allow collection:

  • OpenTelemetry.Enabled = true
  • OpenTelemetry.AllowContentInstrumentation = true, which is the default

Publishers must also enable tracing for each content item.

Enable telemetry for a content item

When the dashboard displays the Traces setting, publishers can enable telemetry from the Monitoring tab of the content settings panel. Publishers can also set otel_enabled to true with the Update Content API. Connect applies the setting when it starts a content process. For R content, enabling telemetry also clears the build status so that the next execution rebuilds the bundle with the required instrumentation package.

Read content traces

Use the Get content traces API to retrieve retained traces for a content item. The endpoint returns newline-delimited JSON (NDJSON), with one OpenTelemetry Protocol (OTLP) JSON object per line. Users need Reviewer or higher access to the content. Administrators can retrieve traces with the view_app_settings permission. Disabling collection does not remove retained traces or prevent authorized users from reading them.

Prevent collection for all content

Set OpenTelemetry.AllowContentInstrumentation = false to prevent Connect from configuring new content processes to emit traces, regardless of each content item setting.

Uses for content telemetry

  • Debugging production issues: Publishers can inspect traces through the API or through the dashboard when the trace interface is available.
  • Performance monitoring: Traces show request latency across database queries, external API calls, data processing, and other parts of application and report lifecycles.

Controlling OpenTelemetry SDK versions

Connect provides the OpenTelemetry SDK that supports Python auto-instrumentation. If Python content declares opentelemetry-sdk in requirements.txt, Connect uses the SDK in the content environment instead.

Administrators can provide a system-installed SDK by using Python.External:

/etc/rstudio-connect/rstudio-connect.gcfg
[Python]
External = opentelemetry-sdk
External = opentelemetry-api

When a package is listed in Python.External:

  • Connect skips installing that package during environment restore.
  • The package must be pre-installed in the system Python library path for every configured Python version.
  • Content that lists the package in its requirements.txt uses the system-installed version instead.

This configuration lets you control the SDK version available to content that explicitly declares the OpenTelemetry dependencies.

Note

Python.External only affects content that explicitly declares OpenTelemetry packages in its requirements.txt. Content that relies on the built-in Connect auto-instrumentation is not affected by this setting.

For R content, the instrumentation package (otelsdk) is managed entirely by Connect and installed into a separate library path. There is no mechanism to pin its version via R.External.

Version matching

By default, Python.External packages match any requested version. If you want Connect to enforce that the system-installed version matches what the content requests:

/etc/rstudio-connect/rstudio-connect.gcfg
[Python]
External = opentelemetry-sdk
ExternalVersionMatching = true

With ExternalVersionMatching = true, Connect compares the requested version with the system version. If they do not match, Connect installs the requested version into the content environment.