Cloud Observability supports OpenTelemetry as the way to get telemetry data (traces, logs, and metrics) from your app as requests travel through its many services and other infrastructure.
There are two ways to instrument your code:
Auto-instrumentation uses shims or bytecode instrumentation agents to intercept your code at runtime or at compile-time to add tracing and metrics instrumentation to the libraries and frameworks you depend on.
Manual instrumentation uses an SDK and APIs you call from your services to provide observability into the operations within a service. It requires you to manually add spans, context propagation, attributes, etc. to your application code. It is akin to commenting code or writing tests.
Auto-instrumentation is a quick way to start seeing your telemetry data in Cloud Observability. As a general rule of thumb, it is best to start with auto-instrumentation if it’s available. Once that’s in place, you’ll be able to see where the blind spots are in your system and you can start adding manual instrumentation as needed.
For example, auto-instrumentation doesn’t know your business logic—it only knows about frameworks and languages—in which case you’ll want to manually instrument your business logic, so that you get that additional visibility into the inner workings of your services.
The OpenTelemetry launchers were created to provide a way to encapsulate OpenTelemetry setup and configuration. They require fewer lines of code to get started with sending OpenTelemetry data to Lightstep.
Launchers can be used to send telemetry data either directly to Lightstep or to an OpenTelemetry Collector (which then sends the data to Lightstep). They currently support gRPC only.
Launchers are available for:
Ready to send data to Lightstep? Check out the guides below to learn how to Traces to Lightstep:
Remember, Cloud Observability can only display what your system sends it, so instrumentation is key!
Updated Jun 13, 2022