Skip to content

Instrumentation: Code-based, Zero-code and Library Instrumentation: OTCA practice questions

A system is observable only when its components emit traces, metrics and logs, and the code that produces them is called instrumentation. OpenTelemetry offers two main approaches, and the docs say you can use them together.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Instrumentation: Code-based, Zero-code and Library Instrumentation covers in OTCA

A system is observable only when its components emit traces, metrics and logs, and the code that produces them is called instrumentation. OpenTelemetry offers two main approaches, and the docs say you can use them together.

Zero-code instrumentation is for teams who want telemetry without editing the source, or who are just getting started. It is usually installed as an agent or something similar. Depending on the language, it injects OpenTelemetry API and SDK calls through bytecode manipulation, monkey patching or eBPF. It is available for .NET, Go, Java, JavaScript, PHP and Python. You configure it mainly through environment variables or language-specific options such as system properties, and you only need a service name to get started. Its limit is scope: it instruments the libraries an application uses, so HTTP requests and responses, database calls and message-queue calls show up, but the application's own business logic does not.

Code-based instrumentation fills that gap. You import the API, get a TracerProvider or MeterProvider, and ask it for a tracer or meter. The tracer name should identify what is being instrumented, usually the library's fully qualified name, together with a version. That name and version form the instrumentation scope, which lets backends filter telemetry by its source. A runnable service depends on both the API and the SDK and configures the SDK with exporters. It can export directly from the process or send OTLP to a Collector.

Libraries follow a stricter rule: they depend only on the API. The API is a set of abstractions with non-operational implementations, so instrumentation in a library does nothing and costs nothing until the application installs an SDK. The API also never throws and swallows exceptions, so faulty instrumentation cannot break application logic. Because errors are hidden, instrumentation should be tested, ideally with an in-memory exporter provided by the SDK.

Many libraries are covered by separate instrumentation libraries that use hooks or monkey patching. A library with built-in OpenTelemetry support is called natively instrumented, meaning it is both the instrumented library and the instrumentation library. The docs list the benefits of native instrumentation: no custom hooks to document, telemetry that is correlated with application code, and consistent conventions.

Library authors get practical modelling advice. Create spans for the logical operation, such as one database request, and leave physical network calls to the libraries that make them. Record smaller activities like serialization as span events rather than extra spans. Do not instrument a thin wrapper when OpenTelemetry already covers the underlying network calls and no convention applies; the guidance says that when in doubt, don't instrument. Under head sampling, check whether a span is recording before computing expensive attributes. Finally, follow semantic conventions for attribute names and set the schema URL so consumers know which convention version was used.

Key points

  • Zero-code instrumentation covers the libraries an app uses; code-based instrumentation is needed for the app's own logic.
  • Both approaches can run in the same service at the same time.
  • Libraries depend only on the API, which does nothing and has no cost until an SDK is installed.
  • A tracer should be named after the instrumenting library and given its version, which defines the instrumentation scope.
  • Library guidance favors one span per logical operation, span events for small activities, and not instrumenting thin wrappers.

Three sample questions

13 OTCA questions on Instrumentation: Code-based, Zero-code and Library Instrumentation, 13 with explanations. How practice works

Question 1

An operations team adds zero-code instrumentation to a service they cannot modify. Telemetry now shows incoming HTTP requests, database calls and message-queue calls, but nothing about the service's internal business logic. What explains this?
  1. A.The SDK sampler drops business-logic spans by default, so only spans from libraries are ever exported
  2. B.Zero-code instrumentation typically instruments the libraries used, not the application's own code
  3. C.Business-logic spans require a Collector processor to be generated from the library spans
  4. D.Zero-code instrumentation only works for traces, so business logic shows up only in metrics

Correct answer: B

The Zero-code page says it "typically adds instrumentation for the libraries you're using. This means that requests and responses, database calls, message queue calls, and so forth are what are instrumented. Your application's code, however, is not typically instrumented. To instrument your code, you'll need to use code-based instrumentation." The Instrumentation page describes zero-code as providing information about "the edges of your application". Why the other options are wrong. "The SDK sampler drops business-logic spans by defa…": samplers decide whether traces are sampled; the docs attribute the missing business logic to what zero-code instruments, not to a default sampler filtering spans by type. "Business-logic spans require a Collector processor…": the Collector receives, processes and exports telemetry; it cannot create spans for application code that was never instrumented. "Zero-code instrumentation only works for traces, s…": zero-code instrumentation is not trace-only, and the reason business logic is missing is that application code is not instrumented at all, in any signal.

Sources: OpenTelemetry docs: Zero-code instrumentation, OpenTelemetry docs: Instrumentation

Question 2

In a trace, three spans created by a tracer obtained with the name CheckoutService appear alongside spans from an HTTP framework and a DB library. How does the OpenTelemetry Instrumentation scope page say scopes help during analysis?
  1. A.Each span gets its own unique scope, so the scope works as a second span ID for lookups
  2. B.The scope sets the sampling probability per library, so noisy libraries can be thinned out
  3. C.The scope replaces the resource, identifying the pod and host that produced the spans
  4. D.Backends can filter, group and compare telemetry by scope, e.g. by library version

Correct answer: D

The Instrumentation scope page says a scope is identified by a (name, version, schema_url, attributes) tuple given when obtaining a tracer, meter or logger, and every span, metric and log record from that instance is tagged with it. "In your observability backend, you can filter, group, and compare telemetry by scope. This makes it possible to identify which library version is causing latency, isolate signals from a specific module, or compare behavior across versions of the same component." Why the other options are wrong. "Each span gets its own unique scope, so the scope…": the page's own example says the three CheckoutService spans "share the same instrumentation scope because they are created by the same tracer instance"; scopes are per tracer, not per span. "The scope sets the sampling probability per librar…": the scope identifies the logical unit of software that emitted telemetry; sampling decisions are made by samplers, not by the instrumentation scope. "The scope replaces the resource, identifying the p…": the Metrics concepts page distinguishes them: a Resource describes the entity producing telemetry, while instrumentation scope describes the instrumenting library.

Sources: OpenTelemetry docs: Instrumentation scope, OpenTelemetry docs: Metrics

Question 3

What does the OpenTelemetry glossary mean when a library is described as having built-in (native) OpenTelemetry instrumentation?
  1. A.The instrumented library and the instrumentation library are the same library
  2. B.A separate contrib package monkey-patches the library's code when the application starts
  3. C.An eBPF agent attaches to the library's process from outside
  4. D.The library bundles the OpenTelemetry SDK and exports data by itself

Correct answer: A

The glossary defines the instrumented library as the library for which telemetry is gathered and the instrumentation library as the one that provides the instrumentation, and says they "can be the same Library if it has built-in OpenTelemetry instrumentation." The Libraries page explains that native instrumentation removes the need for libraries to expose and document hooks. Why the other options are wrong. "A separate contrib package monkey-patches the libr…": monkey-patching from a separate package is how many non-native instrumentation libraries work ("typically done through library hooks or monkey-patching"), which is the opposite of native instrumentation. "An eBPF agent attaches to the library's process fr…": eBPF is one of the zero-code injection mechanisms; it is not what makes instrumentation native to a library. "The library bundles the OpenTelemetry SDK and expo…": libraries should only use the OpenTelemetry API; the SDK and exporters are configured by the application, not bundled inside a library.

Sources: OpenTelemetry docs: Glossary, OpenTelemetry docs: Instrumenting libraries

Practice this topic

Focus mode keeps every question on Instrumentation: Code-based, Zero-code and Library Instrumentation until you leave it. 10 free guest answers, then a free account; no credit card.

Or open OTCA practice across all topics.

Sources

The explanation above was checked against these official documents.

Frequently asked questions

Why does my zero-code agent not show my business logic?

Zero-code instrumentation typically instruments libraries such as HTTP, database and messaging clients. To see your own code paths, add code-based instrumentation with the OpenTelemetry API.

Will adding the OpenTelemetry API to my library slow down users who do not use OpenTelemetry?

No. Without an SDK the API is non-operational, so the instrumentation does nothing and has no performance impact.