Skip to main content
Version: Next (Private Preview)

Latency profiling

:::info No dedicated profiling endpoint in 0.2.0

Nexo 0.2.0 (Private Preview) does not include a profiling HTTP endpoint, flame-graph endpoint, profiling CLI, persistent histogram store, or request-trace header. Use the Logging, Metrics, and X-Ray components described below to understand pipeline latency today.

:::

Nexo sits between your application and MongoDB. Every request passes through a pipeline of components — each adds a small amount of latency. Three catalog components give you visibility into that overhead without a dedicated profiling API.

Understanding pipeline latency today​

Logging — per-operation duration records​

The Logging component emits a structured JSON record for every MongoDB operation, including a duration field that captures round-trip time through the pipeline. This is the most direct way to answer "how long did this specific operation take?"

Prerequisites: NexoLogger CRD reconciled; Logging step present in the pipeline.

Steps:

  1. Add the Logging component to your NexoPipeline in the Request + Response phases.
  2. Configure the output sink (JSON to stdout, a log aggregator, or a file path).
  3. Query your log system for the duration field, grouped by command or collection to find slow operations.

What you get: per-operation latency, command type, database, and collection — suitable for pinpointing slow individual queries or baseline P50/P99 approximations from real traffic.

Metrics — Prometheus latency histogram​

The Metrics component publishes a Prometheus-compatible histogram (nexo_request_duration_seconds) broken down by command type, database, and collection. Scrape the /metrics endpoint (port 9090) with Prometheus or any OpenMetrics-compatible collector.

Prerequisites: NexoMetrics CRD reconciled; Metrics step present in the pipeline.

Steps:

  1. Add the Metrics component to your NexoPipeline.
  2. Point your Prometheus scrape config at <proxy-host>:9090/metrics.
  3. Build Grafana panels or alerts on nexo_request_duration_seconds histogram buckets to track P50, P95, and P99 latency trends over time.

What you get: aggregate latency distribution across all operations — suitable for dashboards, alerting, and regression detection after pipeline changes.

X-Ray — passive slow-operation sampling​

The X-Ray component passively samples traffic to surface repeated queries, slow operation fingerprints, and burst patterns. It has no dedicated Operator CRD or dashboard catalog entry in 0.2.0 (backend capability only, no supported deployment contract). Confirm availability before relying on it operationally.

What you get: fingerprinted slow-query patterns and workload composition without instrumenting the application — useful for exploratory analysis when you do not yet know where the latency is coming from.

Interpreting results​

  • Proxy overhead vs. upstream latency: compare duration from the Logging component against the MongoDB server's own slowms log entries for the same operation. The difference approximates Nexo's contribution.
  • Pipeline regression: after adding or changing a component, compare the Metrics histogram before and after using a fixed observation window. A rise in P99 that is not explained by upstream change points to a pipeline step.
  • No invented CLI or HTTP commands: do not reference nexo profile, GET /api/profile, or any command not listed in the nexoctl command reference.

Search Nexo documentation

Type to search titles, headings, and page content.