Privacy gateway metrics#29266
Privacy gateway metrics#29266danish-m-qureshi wants to merge 12 commits intocloudflare:productionfrom
Conversation
…, metrics section to Observability, nest Schema expandables, make limit optional
…move endpoint variable from all queries
| POST https://api.cloudflare.com/client/v4/graphql | ||
| ``` | ||
|
|
||
| To access your metrics, you need a Cloudflare API token. Contact your Cloudflare point of contact to obtain one. |
There was a problem hiding this comment.
is there other documentation you can reference here?
There was a problem hiding this comment.
regarding this point, I initially added the following documentation: https://developers.cloudflare.com/fundamentals/api/get-started/create-token/.
However, after consulting with Andre, he informed me that we manage the clients' dashboard accounts and provide them with the API tokens instead. Given this, what are your thoughts on adding this documentation?
mgalicer
left a comment
mgalicer
left a comment
There was a problem hiding this comment.
great start – added a few comments
|
|
||
| <Details header="Protocol distribution"> | ||
|
|
||
| Monitor HTTP and TLS version adoption across your connections over time. Each row in the result represents a distinct combination of `httpVersion` and `tlsVersion` observed in the selected time window. |
There was a problem hiding this comment.
hmm – not sure this came up in any of our customer conversations... why should we include it?
There was a problem hiding this comment.
No this did not come up with any of our customer conversations. This is something extra.
We should include it for the following reasons,
1- Knowing which TLS versions are in use lets customers verify that all traffic meets their minimum security requirements (for example, confirming no clients are still on TLS 1.0/1.1).
2- if a customer plans to drop support for an older HTTP or TLS version, this query gives them concrete data on how much traffic would be affected before they make the change.
3- if a customer sees unexpected errors or latency, checking protocol distribution can quickly reveal whether a subset of clients is using an unsupported or suboptimal protocol version.
i'd suggest lets keep it. What are your thoughts on it @mgalicer?
- Revert unrelated table.css and PageTitle.astro changes (keep only slug fallback fix) - Replace all 2025 example dates with 2026 - Remove GraphiQL tab and setup instructions to stay client-agnostic - Simplify adaptive sampling note - Rewrite 'connection volume' in plain language - Add justification for protocol distribution query - Simplify proxy status codes intro - Fix destination_not_found description - Add prerequisites section with links to API token and account ID docs
4 participants
Summary
Rewrites the Privacy Gateway observability reference page based on the OHTTP relay GraphQL nodes, replacing placeholder content with a full schema reference, 10 sample queries, and a three-tier status code reference covering relay, gateway, and proxy-level errors.
Changes
reference/metrics.mdxto document the threeohttpRelay*AdaptiveGroupsnodes with full schema (sum fields, quantile fields, dimensions) and sample queries.relayStatusCode,gatewayStatusCodeandproxyStatus(24 named error values).src/content/docs/privacy-gateway/reference/metrics.mdx