9 Best NGINX Monitoring Tools (2026): Metrics, Logs and NGINX Plus Support Compared

Your NGINX dashboard shows active connections and requests per second, and both look normal. Meanwhile users are getting 502s and the p99 latency on your API has doubled. The dashboard can't tell you which upstream is failing or how slow it is, because the data it reads was never going to contain that.

Most NGINX monitoring integrations rely on the same few data sources: stub_status, the NGINX Plus API, access logs and tracing instrumentation. Which of those sources a tool actually uses decides what it can show you, more than its dashboards or alerting do. This article compares nine tools on how they collect NGINX data, whether they read the NGINX Plus API, whether they parse access logs into latency and error data, whether they connect NGINX to backend traces, and what they cost. If you used NGINX Amplify, it has been shut down; the NGINX One Console entry covers what replaced it.

Dash0 publishes this comparison and is one of the nine tools. The facts come from each vendor's documentation and pricing pages as of November 2026. We didn't run hands-on tests, so confirm what matters to you during a trial. The order is editorial and grouped by category, not a ranking.

What NGINX exposes (and why it limits every tool)

Open-source NGINX gives monitoring tools seven instance-wide counters through its stub_status page. Anything more detailed, including status codes, request latency and upstream timing, has to come from access logs, from the commercial NGINX Plus API, or from a third-party module. Active upstream health checks are an NGINX Plus feature.

The stub_status module isn't compiled in by default (--with-http_stub_status_module), so check that your build includes it. Its counters cover the whole instance, so a tool that only reads stub_status can't tell you that one virtual host is slow while the rest are fine. Some teams fill that gap on open-source NGINX with the community VTS module, which adds per-virtual-host and per-upstream metrics but has to be compiled into NGINX and isn't supported by F5.

That leaves three questions to ask of any tool. Does it read the NGINX Plus API when you have one? Does it turn access logs into latency and error data? Can it connect an NGINX request to the backend trace behind it? The rest of this article compares tools on those three points.

Whatever you choose, fix your access log format first. The default combined format doesn't include $request_time, so out of the box your logs can't tell you how long requests took. Adding request and upstream timing, ideally as JSON, is the cheapest way to get latency data from open-source NGINX:

log_format json_timing escape=json
  '{"time":"$time_iso8601","status":$status,"method":"$request_method",'
  '"uri":"$request_uri","request_time":$request_time,'
  '"upstream_addr":"$upstream_addr","upstream_status":"$upstream_status",'
  '"upstream_response_time":"$upstream_response_time"}';

access_log /var/log/nginx/access.log json_timing;

$request_uri includes the query string, which can carry tokens or personal data. Use $uri if you don't need the query string, or redact sensitive parameters in your log pipeline.

Check how your tool handles a custom format before you switch. Some tools require a specific format and others auto-detect standard ones, so a custom JSON format may need its own parsing setup. Each tool entry below notes its log format requirements.

If you're setting up collection rather than choosing a vendor, see how to monitor NGINX performance for metrics and alerting, or mastering NGINX logs with JSON and OpenTelemetry for the complete logging pipeline. The comparisons below focus on what each tool actually collects and which NGINX environments it suits.

How we chose and compared these tools

A tool made the list if it documents an NGINX-specific collection path, such as an integration, collector, template or log parser, that is maintained and available today. That rules out NGINX Amplify, which was shut down on January 31, 2026.

Each entry covers the same ground:

• how the tool collects data from open-source NGINX
• whether it reads the NGINX Plus API
• whether it parses access logs, and whether it needs a specific log format
• whether it links NGINX requests to backend traces
• deployment model, pricing unit and starting list price

Tools are grouped by category: observability platforms, self-hosted monitoring, NGINX's own tool, and log analysis. Within each group, the order is editorial.

NGINX monitoring tools at a glance

The table summarizes how each tool collects NGINX data and how it's priced. "Not documented" means we found no first-party documentation for the capability, not that it's impossible.

Quick picks:

• Free metrics for open-source NGINX: Prometheus + Grafana, Zabbix or Netdata
• Free log analytics: GoAccess
• Deep NGINX Plus coverage: Datadog, Zabbix or Netdata
• NGINX logs linked to backend traces: Dash0 or New Relic on OpenTelemetry, or Datadog with its own agent
• Replacing Amplify: NGINX One Console

Observability platforms

These platforms put NGINX data next to your application metrics, logs and traces. They differ most in how much NGINX Plus data they read and whether they connect NGINX to the backend trace behind a request.

1. Datadog

Datadog's NGINX integration is an Agent check that reads stub_status on open-source NGINX and the NGINX Plus API on Plus R13 and later. The Plus path adds metrics that open-source NGINX can't provide, including 4xx and 5xx counts, upstream health and response codes, cache, SSL and stream metrics. The Agent also tails NGINX access and error logs.

Tracing comes from Datadog's own NGINX module, loaded with load_module, or from OpenTelemetry. For Kubernetes, Datadog has a separate check for the community ingress-nginx controller. For F5's NGINX Ingress Controller, it points you to its Prometheus integration instead.

What's good

• Broad native NGINX Plus coverage, including upstream health, cache and stream metrics.
• Metrics, logs and traces correlate in one platform.
• A free plan for up to five hosts.

The catch

Datadog's default log pipeline expects you to add $request_time to your log format before you get request latency. Autodiscovery templates cover open-source NGINX only, so NGINX Plus in containers needs inline configuration. Datadog also documents an OpenTelemetry Collector path for NGINX metrics, but it carries only a subset of stub_status counters, much less than the Agent check. Infrastructure, logs and APM are billed separately, which makes the total harder to forecast.

Pricing model

Datadog lists Infrastructure Pro at $15 per host per month billed annually ($18 on demand). Log ingestion is $0.10 per GB, and indexing starts at $1.70 per million events for 15-day retention (annual). APM starts at $31 per host per month (annual). The free plan covers five hosts with one-day retention.

The verdict

Worth exploring if: you already run Datadog, or you run NGINX Plus and want its full metric set without assembling your own pipeline.

Give it a pass if: you need a predictable bill for a small NGINX fleet, or you want to standardize on OpenTelemetry.

2. Dash0

Dash0 is an OpenTelemetry-native observability platform. It takes NGINX metrics, logs and traces over OTLP, so all three land in the same place. Metrics come from the OpenTelemetry Collector's nginxreceiver, which scrapes stub_status. Logs come from the Collector's filelog receiver. Traces come from ngx_otel_module.

On the log side, Dash0 parses NGINX access logs natively. It auto-detects four standard text formats (minimal, combined, ingress controller and Kubernetes upstream-info) and maps fields to OpenTelemetry semantic conventions such as http.request.method, http.response.status_code, url.path and client.address, with no parsing rules to write. A custom format, such as the JSON example above or a format with $otel_trace_id added, isn't one of the auto-detected formats. The NGINX logs guide walks through a JSON log setup with $otel_trace_id, which links each access log line to the NGINX trace for that request.

What's good

• NGINX metrics, logs and traces in one OpenTelemetry-native backend.
• Native parsing of standard access log formats, with semantic-convention attributes and severity inferred from status codes.
• Log-to-trace correlation through ngx_otel_module.
• No per-host or per-user fees.

The catch

Dash0's NGINX metrics come from the Collector's nginxreceiver, so you get the same stub_status data as any other OpenTelemetry setup (see Logs, OpenTelemetry and trace correlation). Auto-detection covers standard log formats only, so a custom JSON format isn't parsed automatically. Dash0 doesn't document an NGINX Plus API integration, and there's no prebuilt dashboard for standalone NGINX. You need to run an OpenTelemetry Collector next to NGINX, which is extra setup if you don't already have one.

Pricing model

Dash0 charges $0.02 per million metric data points for ingestion plus $0.18 per million for storage, with 13-month retention. Logs and spans cost $0.06 per million to ingest plus $0.54 per million to store, with 30-day retention. There are no per-host or per-user fees, and a 14-day free trial needs no credit card.

The verdict

Worth exploring if: you want standard NGINX access log formats parsed without writing rules, and NGINX logs linked to backend traces on an OpenTelemetry-based stack.

Give it a pass if: you rely on NGINX Plus API metrics or want a prebuilt NGINX dashboard out of the box.

3. Prometheus and Grafana (self-hosted or Grafana Cloud)

Prometheus and Grafana are the default free path for NGINX metrics, and Grafana Cloud offers the same stack as a hosted service. Both rely on the nginx-prometheus-exporter, which F5 maintains.

Self-hosted. The exporter (v1.5.3 at the time of writing) reads stub_status on open-source NGINX, or the NGINX Plus API when you run it with --nginx.plus. On open-source NGINX it exposes nginx_up, the connection counters and nginx_http_requests_total. In Plus mode it adds server zones, upstream peers with health checks, caches and more. Each exporter process scrapes one NGINX instance. The Grafana dashboard bundled with the exporter is basic: up/down status, connections and requests. You'll need Loki or another log store if you want access-log data.

Grafana Cloud. The Grafana Cloud NGINX integration runs Grafana Alloy to scrape the exporter and tail access logs into Loki, and it ships overview and logs dashboards. It requires a specific JSON access log format (json_analytics), which captures upstream timing, cache status and TLS fields. The integration doesn't mention NGINX Plus. The exporter supports it, but you'd be configuring that yourself.

What's good

• Free and open source, and widely documented.
• The exporter supports both open-source NGINX and NGINX Plus.
• Grafana Cloud's free tier covers a small NGINX setup, logs included.

The catch

Self-hosting means running and maintaining the exporter, Prometheus, Grafana and Alertmanager, plus a log store. The open-source metrics are still only the stub_status counters. On Grafana Cloud, the integration only works with its required log format, and it doesn't document Plus support or trace correlation for NGINX.

Pricing model

Self-hosted is free apart from infrastructure. Grafana Cloud's free tier includes 10,000 active metric series, 50 GB of logs and 50 GB of traces with 14-day retention. Pro has a $19 per month platform fee plus usage: metrics start at $6.50 per 1,000 active series, and logs cost $0.05 per GB processed, $0.40 per GB written and $0.10 per GB retained.

The verdict

Worth exploring if: you want free NGINX metrics and already run, or are happy to run, Prometheus. Choose Grafana Cloud if you want the same stack without operating it.

Give it a pass if: you need NGINX request latency and errors without building the log pipeline yourself.

4. New Relic

New Relic's NGINX integration runs with the infrastructure agent. It can auto-discover the status source or be pointed at stub_status or the NGINX Plus API (ngx_http_api_module). It also collects NGINX configuration as inventory, although it ignores include directives.

New Relic also documents an OpenTelemetry path for NGINX: the Collector's nginxreceiver for metrics plus ngx_otel_module (NGINX 1.25.3 or later) for traces. With this path, NGINX shows up on New Relic's service maps alongside your instrumented services.

What's good

• Supports both stub_status and the NGINX Plus API.
• A documented OpenTelemetry option that connects NGINX to backend services.
• A generous free tier for data ingest.

The catch

On open-source NGINX the agent integration collects little beyond connections and requests per second. Pricing depends on users as well as data, so adding engineers who need full access raises the bill.

Pricing model

New Relic's free tier includes 100 GB of ingest per month and one full-platform user. Beyond that, ingest costs $0.40 per GB ($0.60 with Data Plus). Core users cost $49 per month. Full-platform users on Standard cost $10 for the first and $99 for each additional user, up to five; on Pro they cost $349 per user per month, billed annually.

The verdict

Worth exploring if: you want a hosted platform with a usable free tier, and you might later move NGINX onto OpenTelemetry.

Give it a pass if: you have many engineers who need full-platform access.

5. Elastic Observability

Elastic's NGINX integration runs on Elastic Agent. It reads stub_status and parses access and error logs into Elastic Common Schema fields, and ships five machine-learning anomaly detection jobs for NGINX traffic. It has been tested against NGINX 1.19.5 and 1.28.2.

What's good

• Strong NGINX log parsing and search, with error logs included.
• Built-in anomaly detection jobs.
• Available as a managed service or self-managed.

The catch

The integration doesn't document NGINX Plus API support, so open-source-level metrics are what you can count on. Elastic's reference docs don't cover ngx_otel_module tracing, so connecting NGINX to backend traces is up to you.

Pricing model

On Elastic Cloud Serverless, Logs Essentials starts at $0.07 per GB ingested, and the Complete tier starts at $0.09 per GB ingested. Retention is billed per GB per month. Self-managed deployments follow Elastic's subscription licensing.

The verdict

Worth exploring if: NGINX logs are your main source of truth and you want to search and alert on them.

Give it a pass if: you need NGINX Plus metrics or NGINX-to-backend tracing out of the box.

Self-hosted monitoring

Zabbix and Netdata are free to self-host, and both read the NGINX Plus API. Both focus on metrics and alerting and don't analyze access logs.

6. Zabbix

Zabbix provides three NGINX templates:

• Nginx by Zabbix agent reads stub_status locally and adds NGINX process CPU, memory and count. It doesn't support HTTPS or redirects.
• Nginx by HTTP polls stub_status remotely without an agent.
• NGINX Plus by HTTP reads the Plus API for server zones, upstream peers with response times and health checks, stream zones and resolvers.

What's good

• Free and mature, with strong alerting.
• Agentless option for open-source NGINX.
• Detailed NGINX Plus coverage, including per-upstream-peer state.

The catch

The current templates require Zabbix 8.0, and they were tested against old NGINX releases (1.17.2 and Plus 1.19.10). On a large NGINX Plus deployment, discovering many zones can be expensive, so use the template's filter macros. Zabbix doesn't analyze access logs, so on open-source NGINX you won't get latency or status codes from it. You also run the Zabbix server, database and frontend yourself.

Pricing model

Self-hosted Zabbix is free. Zabbix Cloud is priced by new values per second (NVPS), starting at $50 per month for 50 NVPS.

The verdict

Worth exploring if: you already run Zabbix, or you want free self-hosted monitoring with real NGINX Plus coverage.

Give it a pass if: you need request latency and error data from open-source NGINX.

7. Netdata

Netdata's NGINX collector auto-detects stub_status on localhost and collects at one-second resolution. Separate collectors handle the NGINX Plus API, covering server and location zones, upstream peers, caches, stream and resolvers, and the VTS module.

What's good

• Near-zero setup on open-source NGINX.
• Per-second granularity, useful for short traffic spikes.
• Plus API and VTS collectors for deeper metrics.

The catch

The open-source NGINX collector produces four charts from stub_status and ships with no alerts configured. Setting up collector jobs through the Netdata Cloud UI requires a paid plan; editing configuration files is free. The NGINX Plus collector isn't auto-detected, so you configure it by hand.

Pricing model

Netdata's Community plan is free for up to five nodes. Business starts at $7 per node per month billed annually ($8.75 monthly). The agent is open source under GPLv3+.

The verdict

Worth exploring if: you want high-resolution NGINX metrics on a few servers with almost no setup.

Give it a pass if: you need access-log analysis or trace correlation.

NGINX's own tool

The NGINX One Console is F5's paid successor to Amplify. It monitors both open-source NGINX and NGINX Plus through NGINX Agent v3.

8. NGINX One Console

NGINX Amplify shut down on January 31, 2026, and F5 points Amplify users to the NGINX One Console. Migration means uninstalling the Amplify agent and starting fresh. Amplify's custom dashboards aren't supported in One Console, and F5 says some advanced alerting isn't available yet.

One Console collects data through NGINX Agent v3, which embeds an OpenTelemetry Collector. It reads stub_status on open-source NGINX and the API on NGINX Plus. The Agent's NGINX receiver also reads access logs, so on open-source NGINX it reports response counts by status class (1xx to 5xx), which stub_status alone can't provide. The dashboard covers instance availability, CPU, memory, disk, unsuccessful response codes, network usage, CVEs and certificates. One Console also handles configuration management.

What's good

• The official replacement for Amplify, maintained by F5.
• Monitors open-source NGINX and NGINX Plus.
• Status-class response counts on open-source NGINX via access logs.
• Combines monitoring with configuration, CVE and certificate tracking.

The catch

It's a paid product, and F5 publishes no list price. Amplify's custom dashboards are gone, and some alerting is still missing. The Agent needs network access to the One Console endpoint. You can add your own OpenTelemetry exporters to the Agent's configuration, but F5's docs don't confirm that the Agent works without a connection to One Console.

Pricing model

Pricing is available from F5 NGINX sales. According to F5, existing NGINX customers can add NGINX One at no extra charge through their account manager.

The verdict

Worth exploring if: you're an F5 NGINX customer or a former Amplify user who wants a vendor-supported console.

Give it a pass if: you want a free tool, or NGINX monitoring inside the observability platform you already use.

Log analysis

GoAccess turns NGINX access logs into real-time traffic reports, for free. It covers the log side of NGINX monitoring, not upstream health or alerting.

9. GoAccess

GoAccess is an open-source access log analyzer. Run it against an NGINX log and it produces a terminal dashboard, a static HTML report, or a real-time HTML report that updates over WebSocket. It handles custom and JSON log formats, GeoIP2 lookups and compressed logs. The current version, 1.12, was released in September 2026.

What's good

• Free, with no agent or backend to run.
• Instant answers to traffic questions: top URLs, status codes, visitors, referrers.
• Works with custom log formats, including timing fields.

The catch

GoAccess only analyzes logs. It doesn't collect metrics, check upstream health, send alerts or keep long-term history in a queryable store, so you'll still want a monitoring tool alongside it.

Pricing model

Free and open source. There's no hosted version.

The verdict

Worth exploring if: you want quick, free visibility into NGINX traffic and errors from the logs you already have.

Give it a pass if: you need alerting or monitoring across many servers.

The NGINX Plus question

Running NGINX Plus only improves your monitoring if your tool reads the Plus API. Several common collection paths read stub_status only and ignore Plus data entirely.

Among the tools above, Datadog, New Relic, Zabbix, Netdata and NGINX One Console document Plus API support, and so does the nginx-prometheus-exporter in Plus mode. The Grafana Cloud integration, Elastic's integration and the Collector's nginxreceiver document stub_status only. To get the most from the Plus API, define status_zone in your server and location blocks, and give upstreams a shared memory zone. Without them, the per-server and per-upstream metrics aren't collected.

On open-source NGINX without Plus, you have two ways past the stub_status limit: parse access logs, or compile in the VTS module. A few free building blocks help with either:

• nginx-prometheus-exporter exposes stub_status or Plus API data in Prometheus format.
• Telegraf has nginx, nginx_plus_api and nginx_vts inputs.
• Fluent Bit and Vector both have nginx_metrics sources for stub_status and can parse NGINX logs.
• The VTS module adds per-virtual-host and per-upstream metrics to open-source NGINX, with a Prometheus output. It needs a rebuild of NGINX and isn't F5-supported.

Logs, OpenTelemetry and trace correlation

On open-source NGINX, access logs are where the latency and error data is. OpenTelemetry adds trace correlation and portability, but its standard NGINX metrics receiver carries less data than vendors' native agents.

Tools differ a lot in how they treat access logs:

• Dash0 auto-detects standard formats.
• Grafana Cloud requires its own JSON format.
• Datadog expects you to add $request_time.
• GoAccess and Elastic parse logs as a core function.
• Zabbix and Netdata's NGINX collectors don't analyze logs at all.

Whichever tool you use, a JSON log format with request and upstream timing gives it the most to work with.

The OpenTelemetry path for NGINX has two parts. For metrics, the Collector's nginxreceiver is beta and scrapes stub_status. It emits four metrics, which together carry all seven stub_status counters: accepted connections, handled connections, current connections by state, and total requests.

For traces, ngx_otel_module creates a span per request and exposes $otel_trace_id and $otel_span_id as variables. Loading the module doesn't turn tracing on: you enable it with otel_trace and use otel_trace_context to propagate W3C trace context to upstreams. Writing $otel_trace_id into your access log then links each log line to its NGINX trace. The link continues to backend spans only if the upstream service is instrumented to accept that context, and your log pipeline maps the trace ID onto the log record.

That makes OpenTelemetry a trade-off for NGINX today. You get portable telemetry and a clean path from an NGINX log line to the backend trace, but less NGINX metric depth than Datadog's Agent check. If NGINX Plus metrics matter to you, check how a tool reads them before you commit to an OpenTelemetry-only pipeline.

Monitoring NGINX on Kubernetes

The community ingress-nginx controller was retired in March 2026. The final release, v1.15.1, shipped on March 19, and the repository was archived on March 24. Existing deployments keep working, but they no longer get bug fixes or security patches. The Kubernetes Steering Committee described it as critical infrastructure for about half of cloud native environments, so many clusters are affected.

ingress-nginx (kubernetes/ingress-nginx) is a different project from F5's NGINX Ingress Controller, and monitoring tools support them separately. Datadog, for example, has a dedicated check for the community controller but sends F5 controller users to its Prometheus integration. We checked this split for Datadog only, so confirm it for any other tool you shortlist. Because the community controller no longer gets security fixes, check monitoring support for the maintained controller you're moving to, not only the one you run today.

How to choose an NGINX monitoring tool

Start from your NGINX edition and what you need to see, then pick a category, then a tool.

• Open-source NGINX, free: Prometheus + Grafana with the exporter, Zabbix, or Netdata for metrics. Add GoAccess for log-based traffic and error analysis.
• Open-source NGINX, you need latency and errors: add timing fields to your access log and send it to a log-capable backend. Dash0, Elastic, Datadog and Grafana Cloud all parse NGINX access logs.
• NGINX Plus: pick a tool that reads the Plus API. Datadog, Zabbix and Netdata have the most detailed documented coverage.
• You need NGINX linked to backend traces: use ngx_otel_module with an OpenTelemetry backend such as Dash0 or New Relic, or Datadog's own tracing module.
• Kubernetes ingress: confirm which controller the tool supports. Community ingress-nginx no longer gets security fixes, so check support for the maintained controller you're moving to.
• Former Amplify user: NGINX One Console is the vendor path. Any tool above can replace Amplify's metrics.
• Already standardized on a platform: use that platform's NGINX integration, and check whether it reads the Plus API and parses your log format.

If no single tool covers what you need, pair a metrics tool with a log tool, or use one platform that handles both.

Also considered

These tools also monitor NGINX but didn't get a full entry:

• Sematext offers agent-based NGINX and NGINX Plus metrics with log reports. It overlaps with the platforms above and doesn't document trace correlation.
• Better Stack collects NGINX logs and stub_status metrics. We found no NGINX Plus support.
• SigNoz is OpenTelemetry-based, using the same nginxreceiver and filelog path. Its log parsing covers the combined and main formats only.
• Checkmk reads stub_status per server and port. We found no first-party NGINX Plus integration.
• Site24x7 has an NGINX plugin for open-source and Plus, but its NGINX log type uses a fixed pattern without request timing.
• SolarWinds Observability has stub_status-based NGINX monitoring, with Plus handled by a separate Telegraf-based integration.
• ManageEngine Applications Manager polls stub_status without an agent. We found no NGINX log or trace support.
• Coroot uses eBPF to see HTTP traffic from any process, but has no dedicated NGINX integration.

FAQ

What is the best free NGINX monitoring tool?

For metrics, Prometheus and Grafana with the nginx-prometheus-exporter, Zabbix and Netdata are all free to self-host. For log-based traffic and error analysis, GoAccess is free and needs no backend. On open-source NGINX, a free metrics tool reading the built-in stub_status counters can't show latency or status codes, so pair it with log analysis or the VTS module if you need them.

Do I need NGINX Plus to monitor NGINX?

No. Open-source NGINX gives you stub_status counters, and access logs give you status codes, request latency and upstream timing. NGINX Plus adds a real-time API with per-zone, per-upstream and cache metrics plus active health checks, but only tools that read the Plus API benefit from it.

What replaced NGINX Amplify?

F5 shut down Amplify on January 31, 2026, and recommends the NGINX One Console. It's a paid service, it doesn't support Amplify's custom dashboards, and some advanced alerting isn't available yet. Any tool in this list can replace Amplify's NGINX metrics.

How do I get latency and status codes from open-source NGINX?

From access logs. Add $request_time and $upstream_response_time to your log_format (the default combined format has neither) and send the logs to a tool that parses them. See what NGINX exposes for an example format.

Is NGINX still used in 2026?

Yes. W3Techs reports NGINX on 30.0% of websites with a known web server as of November 2026, second only to Cloudflare Server at 33.7% and ahead of Apache at 20.9%.

How do I monitor an NGINX ingress controller?

First, check which controller you run. The community ingress-nginx controller was retired in March 2026, and it's separate from F5's NGINX Ingress Controller. Monitoring tools support the two separately. See monitoring NGINX on Kubernetes.

Final thoughts

The right NGINX monitoring tool depends on what your NGINX setup exposes more than on any dashboard. A stub_status-only setup can't tell you which upstream is behind a burst of 502s, however good its dashboard looks. Get the access log format right first, with request and upstream timing, then shortlist tools on the three questions above: Plus API support, log parsing and trace correlation.

If you want NGINX metrics, parsed access logs and ngx_otel_module traces in one OpenTelemetry-native backend, follow the NGINX logs guide to connect them. If you're comparing platforms more broadly, see our comparison of all-in-one observability platforms for logs, metrics and traces. You can also try Dash0 free for 14 days. No credit card required.