Instrument OpenTelemetry for Non-Kubernetes Environments in One Simple Step

Observability Courtney Gannon

Since the beginning of our involvement with the OpenTelemetry project, Splunk’s mission has been to make OpenTelemetry accessible and easy to adopt for every organization and every environment. We’re excited to share our latest donation to the project, the OpenTelemetry Injector.

The OpenTelemetry Injector makes implementation incredibly easy and expands OpenTelemetry's reach and ease of use for organizations with diverse infrastructure. It enables zero-code instrumentation for applications running on Linux hosts and significantly reduces the operational burden of implementation. With the OpenTelemetry Injector, you can capture metrics, traces, logs, and profiles from your infrastructure and applications with a single simple step. By making instrumentation easier and less intrusive, the injector encourages wider adoption of OpenTelemetry for organizations with existing applications where code changes might be difficult or impractical.

How the OpenTelemetry Injector Works

The OpenTelemetry injector is a shared library (written in Zig) that is intended to be used via the environment variable LD_PRELOAD, the /etc/ld.so.preload file, or similar mechanisms to inject environment variables into processes at startup.

It serves two main purposes:

The injector can be used to enable automatic zero-touch instrumentation of processes. For this to work, the injector binary needs to be bundled together with the OpenTelemetry auto-instrumentation agents for the target runtimes.

Official RPM and DEB packages that contain the injector as well as the auto-instrumentation agents are available, and can be downloaded from the releases page (once the first release has been published). The OpenTelemetry injector Debian/RPM packages install the OpenTelemetry auto-instrumentation agents, the libotelinject.so shared object library, and a default configuration file to automatically instrument applications and services to capture and report distributed traces and metrics to the OpenTelemetry Collector.

The opentelemetry-injector deb/rpm package installs and supports configuration of the following Auto Instrumentation agents:

Getting Started

The following methods are supported to manually activate and configure Auto Instrumentation after installation of the opentelemetry-injector deb/rpm package (requires root privileges):

Note: To prevent conflicts and duplicate traces/metrics, only one method should be activated on the target system.

Get Involved

Want to learn more or contribute?

💬 Join the conversation in the #otel-injector channel on the OpenTelemetry Slack.
🔗 Check out the opentelemetry-injector repository.

You can read more about the OpenTelemetry Injector and read about Splunk’s other contributions to the OpenTelemetry project in this blog or watch this on-demand webinar, "OTel Demystified: From Community Contributions to Splunk's Enhanced Distribution."

Related Articles

Using Splunk Observability Cloud to Monitor Splunk RUM
Observability
4 Minute Read

Using Splunk Observability Cloud to Monitor Splunk RUM

Discover how the Splunk RUM team used the Splunk Observability Cloud to detect and resolve a critical incident in production.
Tool Consolidation in the O11y World
Observability
11 Minute Read

Tool Consolidation in the O11y World

Ending up with or having too many tools for monitoring is an age-old problem in the monitoring space. It has been around for decades. In fact I would go a step further and argue that it is much worse within the platforms of today then it was in days gone by. There is a direct correlation between the explosion of new, exciting and innovative technologies and services in modern platform development of today and the sheer volume of tooling you can easily end up with to monitor it. In this blog I explore what has driven the expansion of tools, how having too many is creating fundamental challenges in how these platforms are being managed, the negative impact that this has on innovation and, most importantly, what the solution is.
A Pattern for Optimizing Go
Observability
8 Minute Read

A Pattern for Optimizing Go

Pprof is the standard way to profile Go applications that comes built in to go. The pprof package can expose via HTTP both memory and CPU usage across your application, as well as the running command line and contention information.