Native Observability records what a Drupal site does at runtime: request traces, execution spans, cache and database behavior, metrics aggregated per route, and export to OpenTelemetry, Prometheus and Grafana. It runs inside the application, with no core patches and no external agent.
http_client are recorded without touching them.Installation, configuration, the settings reference with a screenshot of every tab, the data model and the developer surface are documented on the project site. It is built from the repository, so it describes the branch rather than the last release.
The pages an operator reaches for first.
composer require drupal/native_observability, then enable the sub-modules you need. The documentation covers which sub-module does what and the order to turn them on.
zlib PHP extension. The dashboard compresses its record exports itself rather than leaving it to the web server, so the extension is a hard requirement and not an optimization.wikimedia/composer-merge-plugin, configured in the dashboard's composer.libraries.json.Full tracing adds work to every observed request, and most of it is paid before the response is sent. Only the flush of span, cache and database rows is deferred to kernel.terminate. In the run documented under Measuring the overhead, that flush was 6.1% of the module's cost, and the visitor waited for the other 93.9%. Set retention and record limits, and write exclusion rules for the paths you do not want observed, before turning full tracing on in production.
Run drush no:overhead:measure to get that cost for your own installation. A figure measured on someone else's server does not describe yours.
Stable 2.1.x, actively maintained. The dashboard, the exporters and the report are covered by the test module testing_native_observability, which drives the pipeline end to end.