From 4e57874861bed6583fc0d06bb8439fcba39fb671 Mon Sep 17 00:00:00 2001 From: ldt1996 Date: Wed, 21 Oct 2026 14:28:29 +0300 Subject: [PATCH 1/4] Document the per-thread event-loop-delay and duration-by-thread metrics, and request-time The analytics overview gains request-time rows in the HTTP table with a section on what it covers, and a Per-Thread Metrics section for event-loop-delay, duration-by-thread and the thread attribute. The 5.4 release notes gain an Analytics entry, which also notes that aggregate memory and transaction-queue-depth rows now carry the aggregation period. Companion to HarperFast/harper#3110. Co-Authored-By: Claude Opus 5.5 --- reference/analytics/overview.md | 63 +++++++++++++++++++++++---------- release-notes/v5-lincoln/5.4.md | 6 ++++ 2 files changed, 50 insertions(+), 19 deletions(-) diff --git a/reference/analytics/overview.md b/reference/analytics/overview.md index 78f4ec2c3..b73112dd4 100644 --- a/reference/analytics/overview.md +++ b/reference/analytics/overview.md @@ -139,25 +139,35 @@ Harper automatically tracks the following metrics for all services. Applications ### HTTP Metrics -| `metric` | `path` | `method` | `type` | Unit | Description | -| ------------------ | ------------- | -------------- | --------------------------- | ----- | ---------------------------------------- | -| `duration` | resource path | request method | `cache-hit` or `cache-miss` | ms | Duration of request handler | -| `duration` | route path | request method | `fastify-route` | ms | Duration of Fastify route handler | -| `duration` | operation | | `operation` | ms | Duration of Operations API operation | -| `success` | resource path | request method | | % | Percentage of successful requests | -| `success` | route path | request method | `fastify-route` | % | | -| `success` | operation | | `operation` | % | | -| `bytes-sent` | resource path | request method | | bytes | Response bytes sent | -| `bytes-sent` | route path | request method | `fastify-route` | bytes | | -| `bytes-sent` | operation | | `operation` | bytes | | -| `transfer` | resource path | request method | `operation` | ms | Duration of response transfer | -| `transfer` | route path | request method | `fastify-route` | ms | | -| `transfer` | operation | | `operation` | ms | | -| `socket-routed` | | | | % | Percentage of sockets immediately routed | -| `tls-handshake` | | | | ms | TLS handshake duration | -| `tls-reused` | | | | % | Percentage of TLS sessions reused | -| `cache-hit` | table name | | | % | Percentage of cache hits | -| `cache-resolution` | table name | | | ms | Duration of resolving uncached entries | +| `metric` | `path` | `method` | `type` | Unit | Description | +| -------------------- | ------------- | -------------- | --------------------------- | ----- | --------------------------------------------------------------------------------------------------------- | +| `duration` | resource path | request method | `cache-hit` or `cache-miss` | ms | Duration of request handler | +| `duration` | route path | request method | `fastify-route` | ms | Duration of Fastify route handler | +| `duration` | operation | | `operation` | ms | Duration of Operations API operation | +| `request-time` | resource path | request method | `cache-hit` or `cache-miss` | ms | Time from dispatch to response ready, request queue wait included (see [`request-time`](#request-time)) | +| `request-time` | route path | request method | `fastify-route` | ms | | +| `request-time` | operation | | `operation` | ms | | +| `duration-by-thread` | as `duration` | as `duration` | as `duration` | ms | `duration` for one worker thread, in `hdb_analytics` only (see [per-thread metrics](#per-thread-metrics)) | +| `success` | resource path | request method | | % | Percentage of successful requests | +| `success` | route path | request method | `fastify-route` | % | | +| `success` | operation | | `operation` | % | | +| `bytes-sent` | resource path | request method | | bytes | Response bytes sent | +| `bytes-sent` | route path | request method | `fastify-route` | bytes | | +| `bytes-sent` | operation | | `operation` | bytes | | +| `transfer` | resource path | request method | `operation` | ms | Duration of response transfer | +| `transfer` | route path | request method | `fastify-route` | ms | | +| `transfer` | operation | | `operation` | ms | | +| `socket-routed` | | | | % | Percentage of sockets immediately routed | +| `tls-handshake` | | | | ms | TLS handshake duration | +| `tls-reused` | | | | % | Percentage of TLS sessions reused | +| `cache-hit` | table name | | | % | Percentage of cache hits | +| `cache-resolution` | table name | | | ms | Duration of resolving uncached entries | + +#### `request-time` + + + +`request-time` measures from when Harper dispatches a request to when its response is ready, before the body is sent: the handler time that `duration` records, plus any wait in the HTTP request queue that [`http.requestQueueLimit`](../http/configuration.md#httprequestqueuelimit) bounds. It is recorded only for requests that pass through that queue, which are those with a method other than `GET`, `HEAD`, and `OPTIONS`, and only when analytics is enabled as the request arrives. It does not include the TLS handshake, request parsing, or any wait for the event loop before dispatch; [`event-loop-delay`](#per-thread-metrics) covers that wait. For a request handed to a Fastify route, it also includes the Harper request chain that ran first, such as authentication. Raw entries carry `mean`, `distribution`, and `count`, all in milliseconds, and aggregate rows add percentiles. It is not recorded on Bun. ### MQTT / WebSocket Metrics @@ -224,6 +234,21 @@ write load. However, a wedged commit contributes no sample until it settles — distribution with the server log: the "Rejecting writes on this thread" error is the authoritative signal when the guard trips. Tune the threshold against a baseline for your workload. +### Per-Thread Metrics + + + +| `metric` | Key attributes | Other | Unit | Description | +| -------------------- | --------------------------- | ---------------------------------- | ---- | ------------------------------------------------------------------------------ | +| `event-loop-delay` | `mean`, `maxDelay`, `count` | `thread` | ms | How late the thread's event loop ran a 20 ms timer, on average and at worst | +| `duration-by-thread` | `mean`, `count` | `path`, `method`, `type`, `thread` | ms | `duration` for the requests one worker thread handled, in `hdb_analytics` only | + +Each row names its thread in `thread`, the thread's `worker_threads` `threadId`, which changes when a worker is replaced. In `hdb_raw_analytics` the same id is the entry's `threadId`. + +`event-loop-delay` comes from Node's [`monitorEventLoopDelay`](https://nodejs.org/api/perf_hooks.html#perf_hooksmonitoreventloopdelayoptions), which fires a timer every 20 ms. `mean` and `maxDelay` are the milliseconds by which it fired late, so an idle thread reads about 0, and `count` is the number of timer firings, not requests. A thread writes an entry only in a second in which it recorded other analytics, and the measurement restarts when such a second begins, so a stall during a quiet gap is not reported. It is not recorded on Bun. + +`duration-by-thread` exists only in `hdb_analytics`: aggregation splits each `duration` entry by the thread that recorded it, and its percentiles are not kept. The `duration` rows are unchanged, so do not add the two together. + ### Resource Usage Metrics | `metric` | Key attributes | Other | Unit | Description | diff --git a/release-notes/v5-lincoln/5.4.md b/release-notes/v5-lincoln/5.4.md index ad0d66d61..ab0587f17 100644 --- a/release-notes/v5-lincoln/5.4.md +++ b/release-notes/v5-lincoln/5.4.md @@ -63,3 +63,9 @@ The new `threads.v8Flags` setting takes a V8 flag, or a list of them, and applie ### Restore Checks a Backup Before Deleting the Database `restore_backup` no longer deletes a database before checking that the backup can be read. It first verifies the checksum of every database file in the backup, checks its transaction logs, opens each table file to confirm this version can read its format and compression, and, for a backup that captured blobs, checks that the blob snapshot is present. A backup that fails is refused and the database is left as it was (one an earlier restore left incomplete stays blocked); previously the restore deleted the database first and then failed, so a backup taken by a newer version, or one with a corrupt file, destroyed the database it was meant to restore. The check reads the whole backup once, so a restore takes longer, and an online restore keeps the database unavailable while it runs; it needs no extra disk space. A restore interrupted while it is still checking the backup leaves the destination's files and any preexisting incomplete-restore marker unchanged; a previously healthy database loads normally on the next start. Blob file contents are not checked. See [`restore_backup`](/reference/v5/backups/operations#restore_backup). + +## Analytics + +### Per-Thread Event-Loop Delay and Request Time + +Three built-in metrics are new. `event-loop-delay` reports how late each thread's event loop runs. `duration-by-thread` splits handler `duration` by worker thread in `hdb_analytics`. `request-time` adds the HTTP request queue's wait to handler time for requests with a method other than `GET`, `HEAD`, and `OPTIONS`. Aggregate `memory`, `read-transaction-queue-depth`, and `write-transaction-queue-depth` rows now carry the aggregation `period`, and no `threadId`. See [Per-Thread Metrics](/reference/v5/analytics/overview#per-thread-metrics) and [`request-time`](/reference/v5/analytics/overview#request-time). From 2b7999f075d29698057febcc43707d830572cff7 Mon Sep 17 00:00:00 2001 From: ldt1996 Date: Wed, 21 Oct 2026 14:35:10 +0300 Subject: [PATCH 2/4] Answer the review on the analytics docs Say that a uWS request handed to Fastify records no request-time, that count is requests rather than milliseconds, and that a stall in the same loop turn as the sampler's restart is missed. The aggregate-analytics section now notes, with a v5.4.0 badge, that gauges summed across threads carry the aggregation period and no summed threadId. Co-Authored-By: Claude Opus 5.5 --- reference/analytics/overview.md | 8 ++++++-- release-notes/v5-lincoln/5.4.md | 2 +- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/reference/analytics/overview.md b/reference/analytics/overview.md index b73112dd4..9d73dc7cb 100644 --- a/reference/analytics/overview.md +++ b/reference/analytics/overview.md @@ -133,6 +133,10 @@ Example aggregate entry: } ``` + + +Gauges that each thread reports and aggregation sums across threads (`memory`, `read-transaction-queue-depth`, `write-transaction-queue-depth`, `mqtt-connections`, and `ws-connections`) carry the aggregation `period` on their aggregate rows; before v5.4.0 it read `0`. Aggregate `memory` and queue-depth rows also no longer carry `threadId`, which held the sum of the reporting threads' ids. Raw entries keep their `threadId`. + ## Standard Metrics Harper automatically tracks the following metrics for all services. Applications can also define custom metrics via [`server.recordAnalytics()`](../http/api.md#serverrecordanalyticsvalue-metric-path-method-type). @@ -167,7 +171,7 @@ Harper automatically tracks the following metrics for all services. Applications -`request-time` measures from when Harper dispatches a request to when its response is ready, before the body is sent: the handler time that `duration` records, plus any wait in the HTTP request queue that [`http.requestQueueLimit`](../http/configuration.md#httprequestqueuelimit) bounds. It is recorded only for requests that pass through that queue, which are those with a method other than `GET`, `HEAD`, and `OPTIONS`, and only when analytics is enabled as the request arrives. It does not include the TLS handshake, request parsing, or any wait for the event loop before dispatch; [`event-loop-delay`](#per-thread-metrics) covers that wait. For a request handed to a Fastify route, it also includes the Harper request chain that ran first, such as authentication. Raw entries carry `mean`, `distribution`, and `count`, all in milliseconds, and aggregate rows add percentiles. It is not recorded on Bun. +`request-time` measures from when Harper dispatches a request to when its response is ready, before the body is sent: the handler time that `duration` records, plus any wait in the HTTP request queue that [`http.requestQueueLimit`](../http/configuration.md#httprequestqueuelimit) bounds. It is recorded only for requests that pass through that queue, which are those with a method other than `GET`, `HEAD`, and `OPTIONS`, and only when analytics is enabled as the request arrives. It does not include the TLS handshake, request parsing, or any wait for the event loop before dispatch; [`event-loop-delay`](#per-thread-metrics) covers that wait. For a request that Node's HTTP server hands to a Fastify route, it also includes the Harper request chain that ran first, such as authentication; a request the uWS backend hands to Fastify records no `request-time`. Raw entries carry `mean` and `distribution` in milliseconds and a `count` of requests, and aggregate rows add percentiles. It is not recorded on Bun. ### MQTT / WebSocket Metrics @@ -245,7 +249,7 @@ signal when the guard trips. Tune the threshold against a baseline for your work Each row names its thread in `thread`, the thread's `worker_threads` `threadId`, which changes when a worker is replaced. In `hdb_raw_analytics` the same id is the entry's `threadId`. -`event-loop-delay` comes from Node's [`monitorEventLoopDelay`](https://nodejs.org/api/perf_hooks.html#perf_hooksmonitoreventloopdelayoptions), which fires a timer every 20 ms. `mean` and `maxDelay` are the milliseconds by which it fired late, so an idle thread reads about 0, and `count` is the number of timer firings, not requests. A thread writes an entry only in a second in which it recorded other analytics, and the measurement restarts when such a second begins, so a stall during a quiet gap is not reported. It is not recorded on Bun. +`event-loop-delay` comes from Node's [`monitorEventLoopDelay`](https://nodejs.org/api/perf_hooks.html#perf_hooksmonitoreventloopdelayoptions), which fires a timer every 20 ms. `mean` and `maxDelay` are the milliseconds by which it fired late, so an idle thread reads about 0, and `count` is the number of timer firings, not requests. A thread writes an entry only in a second in which it recorded other analytics, and the measurement restarts when such a second begins, so a stall during a quiet gap is not reported. A stall that begins in the same loop turn as that restart, or as a report's flush, is not measured either. It is not recorded on Bun. `duration-by-thread` exists only in `hdb_analytics`: aggregation splits each `duration` entry by the thread that recorded it, and its percentiles are not kept. The `duration` rows are unchanged, so do not add the two together. diff --git a/release-notes/v5-lincoln/5.4.md b/release-notes/v5-lincoln/5.4.md index ab0587f17..74c9ca2d2 100644 --- a/release-notes/v5-lincoln/5.4.md +++ b/release-notes/v5-lincoln/5.4.md @@ -68,4 +68,4 @@ The new `threads.v8Flags` setting takes a V8 flag, or a list of them, and applie ### Per-Thread Event-Loop Delay and Request Time -Three built-in metrics are new. `event-loop-delay` reports how late each thread's event loop runs. `duration-by-thread` splits handler `duration` by worker thread in `hdb_analytics`. `request-time` adds the HTTP request queue's wait to handler time for requests with a method other than `GET`, `HEAD`, and `OPTIONS`. Aggregate `memory`, `read-transaction-queue-depth`, and `write-transaction-queue-depth` rows now carry the aggregation `period`, and no `threadId`. See [Per-Thread Metrics](/reference/v5/analytics/overview#per-thread-metrics) and [`request-time`](/reference/v5/analytics/overview#request-time). +Three built-in metrics are new. `event-loop-delay` reports how late each thread's event loop runs. `duration-by-thread` splits handler `duration` by worker thread in `hdb_analytics`. `request-time` adds the HTTP request queue's wait to handler time for requests with a method other than `GET`, `HEAD`, and `OPTIONS`. Aggregate rows for gauges summed across threads, such as `memory`, now carry the aggregation `period` instead of `0`, and `memory` and queue-depth rows no longer carry a summed `threadId`. See [Per-Thread Metrics](/reference/v5/analytics/overview#per-thread-metrics) and [`request-time`](/reference/v5/analytics/overview#request-time). From 1a84317576680cca3ef851a640f94e95d0eaeb11 Mon Sep 17 00:00:00 2001 From: ldt1996 Date: Wed, 21 Oct 2026 15:42:12 +0300 Subject: [PATCH 3/4] Document duration-by-thread as one row per thread, and the histogram's restart after a quiet gap Follows HarperFast/harper#3110 at 6639a076a: duration-by-thread is now one row per worker thread with the count and count-weighted mean of all its duration entries, and the event-loop histogram restarts with each report and again only when activity resumes after a gap of more than a second. Co-Authored-By: Claude Opus 5.5 --- reference/analytics/overview.md | 58 ++++++++++++++++----------------- release-notes/v5-lincoln/5.4.md | 2 +- 2 files changed, 30 insertions(+), 30 deletions(-) diff --git a/reference/analytics/overview.md b/reference/analytics/overview.md index 9d73dc7cb..d86cbd095 100644 --- a/reference/analytics/overview.md +++ b/reference/analytics/overview.md @@ -143,29 +143,29 @@ Harper automatically tracks the following metrics for all services. Applications ### HTTP Metrics -| `metric` | `path` | `method` | `type` | Unit | Description | -| -------------------- | ------------- | -------------- | --------------------------- | ----- | --------------------------------------------------------------------------------------------------------- | -| `duration` | resource path | request method | `cache-hit` or `cache-miss` | ms | Duration of request handler | -| `duration` | route path | request method | `fastify-route` | ms | Duration of Fastify route handler | -| `duration` | operation | | `operation` | ms | Duration of Operations API operation | -| `request-time` | resource path | request method | `cache-hit` or `cache-miss` | ms | Time from dispatch to response ready, request queue wait included (see [`request-time`](#request-time)) | -| `request-time` | route path | request method | `fastify-route` | ms | | -| `request-time` | operation | | `operation` | ms | | -| `duration-by-thread` | as `duration` | as `duration` | as `duration` | ms | `duration` for one worker thread, in `hdb_analytics` only (see [per-thread metrics](#per-thread-metrics)) | -| `success` | resource path | request method | | % | Percentage of successful requests | -| `success` | route path | request method | `fastify-route` | % | | -| `success` | operation | | `operation` | % | | -| `bytes-sent` | resource path | request method | | bytes | Response bytes sent | -| `bytes-sent` | route path | request method | `fastify-route` | bytes | | -| `bytes-sent` | operation | | `operation` | bytes | | -| `transfer` | resource path | request method | `operation` | ms | Duration of response transfer | -| `transfer` | route path | request method | `fastify-route` | ms | | -| `transfer` | operation | | `operation` | ms | | -| `socket-routed` | | | | % | Percentage of sockets immediately routed | -| `tls-handshake` | | | | ms | TLS handshake duration | -| `tls-reused` | | | | % | Percentage of TLS sessions reused | -| `cache-hit` | table name | | | % | Percentage of cache hits | -| `cache-resolution` | table name | | | ms | Duration of resolving uncached entries | +| `metric` | `path` | `method` | `type` | Unit | Description | +| -------------------- | ------------- | -------------- | --------------------------- | ----- | ------------------------------------------------------------------------------------------------------------ | +| `duration` | resource path | request method | `cache-hit` or `cache-miss` | ms | Duration of request handler | +| `duration` | route path | request method | `fastify-route` | ms | Duration of Fastify route handler | +| `duration` | operation | | `operation` | ms | Duration of Operations API operation | +| `request-time` | resource path | request method | `cache-hit` or `cache-miss` | ms | Time from dispatch to response ready, request queue wait included (see [`request-time`](#request-time)) | +| `request-time` | route path | request method | `fastify-route` | ms | | +| `request-time` | operation | | `operation` | ms | | +| `duration-by-thread` | | | | ms | `duration` summed per worker thread, in `hdb_analytics` only (see [per-thread metrics](#per-thread-metrics)) | +| `success` | resource path | request method | | % | Percentage of successful requests | +| `success` | route path | request method | `fastify-route` | % | | +| `success` | operation | | `operation` | % | | +| `bytes-sent` | resource path | request method | | bytes | Response bytes sent | +| `bytes-sent` | route path | request method | `fastify-route` | bytes | | +| `bytes-sent` | operation | | `operation` | bytes | | +| `transfer` | resource path | request method | `operation` | ms | Duration of response transfer | +| `transfer` | route path | request method | `fastify-route` | ms | | +| `transfer` | operation | | `operation` | ms | | +| `socket-routed` | | | | % | Percentage of sockets immediately routed | +| `tls-handshake` | | | | ms | TLS handshake duration | +| `tls-reused` | | | | % | Percentage of TLS sessions reused | +| `cache-hit` | table name | | | % | Percentage of cache hits | +| `cache-resolution` | table name | | | ms | Duration of resolving uncached entries | #### `request-time` @@ -242,16 +242,16 @@ signal when the guard trips. Tune the threshold against a baseline for your work -| `metric` | Key attributes | Other | Unit | Description | -| -------------------- | --------------------------- | ---------------------------------- | ---- | ------------------------------------------------------------------------------ | -| `event-loop-delay` | `mean`, `maxDelay`, `count` | `thread` | ms | How late the thread's event loop ran a 20 ms timer, on average and at worst | -| `duration-by-thread` | `mean`, `count` | `path`, `method`, `type`, `thread` | ms | `duration` for the requests one worker thread handled, in `hdb_analytics` only | +| `metric` | Key attributes | Other | Unit | Description | +| -------------------- | --------------------------- | -------- | ---- | ------------------------------------------------------------------------------------------ | +| `event-loop-delay` | `mean`, `maxDelay`, `count` | `thread` | ms | How late the thread's event loop ran a 20 ms timer, on average and at worst | +| `duration-by-thread` | `mean`, `count` | `thread` | ms | Handler `duration` across every request one worker thread handled, in `hdb_analytics` only | Each row names its thread in `thread`, the thread's `worker_threads` `threadId`, which changes when a worker is replaced. In `hdb_raw_analytics` the same id is the entry's `threadId`. -`event-loop-delay` comes from Node's [`monitorEventLoopDelay`](https://nodejs.org/api/perf_hooks.html#perf_hooksmonitoreventloopdelayoptions), which fires a timer every 20 ms. `mean` and `maxDelay` are the milliseconds by which it fired late, so an idle thread reads about 0, and `count` is the number of timer firings, not requests. A thread writes an entry only in a second in which it recorded other analytics, and the measurement restarts when such a second begins, so a stall during a quiet gap is not reported. A stall that begins in the same loop turn as that restart, or as a report's flush, is not measured either. It is not recorded on Bun. +`event-loop-delay` comes from Node's [`monitorEventLoopDelay`](https://nodejs.org/api/perf_hooks.html#perf_hooksmonitoreventloopdelayoptions), which fires a timer every 20 ms. `mean` and `maxDelay` are the milliseconds by which it fired late, so an idle thread reads about 0, and `count` is the number of timer firings, not requests. A thread writes an entry only in a second in which it recorded other analytics. The measurement restarts with each report, and again when activity resumes after a quiet gap of more than a second, so a stall during that gap is not reported. A stall that begins in the same loop turn as that restart, or as a report's flush, is not measured either. It is not recorded on Bun. -`duration-by-thread` exists only in `hdb_analytics`: aggregation splits each `duration` entry by the thread that recorded it, and its percentiles are not kept. The `duration` rows are unchanged, so do not add the two together. +`duration-by-thread` exists only in `hdb_analytics`: aggregation combines every `duration` entry a thread recorded in the period into one row for that thread, with the total `count` and the count-weighted `mean`, and keeps no percentiles. The per-path detail for each thread stays in `hdb_raw_analytics`, whose raw entries carry their `threadId`. The `duration` rows are unchanged, so do not add the two together. ### Resource Usage Metrics diff --git a/release-notes/v5-lincoln/5.4.md b/release-notes/v5-lincoln/5.4.md index 74c9ca2d2..6be8b2a05 100644 --- a/release-notes/v5-lincoln/5.4.md +++ b/release-notes/v5-lincoln/5.4.md @@ -68,4 +68,4 @@ The new `threads.v8Flags` setting takes a V8 flag, or a list of them, and applie ### Per-Thread Event-Loop Delay and Request Time -Three built-in metrics are new. `event-loop-delay` reports how late each thread's event loop runs. `duration-by-thread` splits handler `duration` by worker thread in `hdb_analytics`. `request-time` adds the HTTP request queue's wait to handler time for requests with a method other than `GET`, `HEAD`, and `OPTIONS`. Aggregate rows for gauges summed across threads, such as `memory`, now carry the aggregation `period` instead of `0`, and `memory` and queue-depth rows no longer carry a summed `threadId`. See [Per-Thread Metrics](/reference/v5/analytics/overview#per-thread-metrics) and [`request-time`](/reference/v5/analytics/overview#request-time). +Three built-in metrics are new. `event-loop-delay` reports how late each thread's event loop runs. `duration-by-thread` reports each worker thread's handler `duration` in `hdb_analytics`, one row per thread. `request-time` adds the HTTP request queue's wait to handler time for requests with a method other than `GET`, `HEAD`, and `OPTIONS`. Aggregate rows for gauges summed across threads, such as `memory`, now carry the aggregation `period` instead of `0`, and `memory` and queue-depth rows no longer carry a summed `threadId`. See [Per-Thread Metrics](/reference/v5/analytics/overview#per-thread-metrics) and [`request-time`](/reference/v5/analytics/overview#request-time). From fffdd86ca0ac8674b170a5ba401d50c8391677dd Mon Sep 17 00:00:00 2001 From: ldt1996 Date: Wed, 21 Oct 2026 15:48:07 +0300 Subject: [PATCH 4/4] Describe the duration-by-thread table row as per thread, not summed Co-Authored-By: Claude Opus 5.5 --- reference/analytics/overview.md | 46 ++++++++++++++++----------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/reference/analytics/overview.md b/reference/analytics/overview.md index d86cbd095..dff99256e 100644 --- a/reference/analytics/overview.md +++ b/reference/analytics/overview.md @@ -143,29 +143,29 @@ Harper automatically tracks the following metrics for all services. Applications ### HTTP Metrics -| `metric` | `path` | `method` | `type` | Unit | Description | -| -------------------- | ------------- | -------------- | --------------------------- | ----- | ------------------------------------------------------------------------------------------------------------ | -| `duration` | resource path | request method | `cache-hit` or `cache-miss` | ms | Duration of request handler | -| `duration` | route path | request method | `fastify-route` | ms | Duration of Fastify route handler | -| `duration` | operation | | `operation` | ms | Duration of Operations API operation | -| `request-time` | resource path | request method | `cache-hit` or `cache-miss` | ms | Time from dispatch to response ready, request queue wait included (see [`request-time`](#request-time)) | -| `request-time` | route path | request method | `fastify-route` | ms | | -| `request-time` | operation | | `operation` | ms | | -| `duration-by-thread` | | | | ms | `duration` summed per worker thread, in `hdb_analytics` only (see [per-thread metrics](#per-thread-metrics)) | -| `success` | resource path | request method | | % | Percentage of successful requests | -| `success` | route path | request method | `fastify-route` | % | | -| `success` | operation | | `operation` | % | | -| `bytes-sent` | resource path | request method | | bytes | Response bytes sent | -| `bytes-sent` | route path | request method | `fastify-route` | bytes | | -| `bytes-sent` | operation | | `operation` | bytes | | -| `transfer` | resource path | request method | `operation` | ms | Duration of response transfer | -| `transfer` | route path | request method | `fastify-route` | ms | | -| `transfer` | operation | | `operation` | ms | | -| `socket-routed` | | | | % | Percentage of sockets immediately routed | -| `tls-handshake` | | | | ms | TLS handshake duration | -| `tls-reused` | | | | % | Percentage of TLS sessions reused | -| `cache-hit` | table name | | | % | Percentage of cache hits | -| `cache-resolution` | table name | | | ms | Duration of resolving uncached entries | +| `metric` | `path` | `method` | `type` | Unit | Description | +| -------------------- | ------------- | -------------- | --------------------------- | ----- | ----------------------------------------------------------------------------------------------------------------------------- | +| `duration` | resource path | request method | `cache-hit` or `cache-miss` | ms | Duration of request handler | +| `duration` | route path | request method | `fastify-route` | ms | Duration of Fastify route handler | +| `duration` | operation | | `operation` | ms | Duration of Operations API operation | +| `request-time` | resource path | request method | `cache-hit` or `cache-miss` | ms | Time from dispatch to response ready, request queue wait included (see [`request-time`](#request-time)) | +| `request-time` | route path | request method | `fastify-route` | ms | | +| `request-time` | operation | | `operation` | ms | | +| `duration-by-thread` | | | | ms | `duration` per worker thread across all its requests, in `hdb_analytics` only (see [per-thread metrics](#per-thread-metrics)) | +| `success` | resource path | request method | | % | Percentage of successful requests | +| `success` | route path | request method | `fastify-route` | % | | +| `success` | operation | | `operation` | % | | +| `bytes-sent` | resource path | request method | | bytes | Response bytes sent | +| `bytes-sent` | route path | request method | `fastify-route` | bytes | | +| `bytes-sent` | operation | | `operation` | bytes | | +| `transfer` | resource path | request method | `operation` | ms | Duration of response transfer | +| `transfer` | route path | request method | `fastify-route` | ms | | +| `transfer` | operation | | `operation` | ms | | +| `socket-routed` | | | | % | Percentage of sockets immediately routed | +| `tls-handshake` | | | | ms | TLS handshake duration | +| `tls-reused` | | | | % | Percentage of TLS sessions reused | +| `cache-hit` | table name | | | % | Percentage of cache hits | +| `cache-resolution` | table name | | | ms | Duration of resolving uncached entries | #### `request-time`