cloudflare / cloudflare/cloudflare-prometheus-exporter
discussion: conservative default metrics for Free-plan zones
- Dominant language
- TypeScript
- Stars
- 181
- Forks
- 39
- Avg merge
- 11h 28m
- Merged PRs (30d)
- 3
Description
## Summary
The exporter currently treats Free-plan zones as having no usable GraphQL Analytics access. That appears broader than necessary for at least some zones.
Cloudflare documentation describes `httpRequestsAdaptiveGroups` as an essential dataset available across plans, while noting that field availability and limits vary by zone and account. The exporter already has several query families built on that dataset.
## Potential Free-plan default set
Would it make sense to enable a conservative subset of the existing query families for Free zones? Candidate metrics include:
- `adaptive-metrics` — origin 4xx/5xx counts, origin duration, origin error rate
- `request-method-metrics` — requests by HTTP method
- `origin-status-metrics` — requests by origin status/country/host
- `cache-miss-metrics` — cache-miss origin duration by country/host
- `edge-country-metrics` — edge status by country/host and edge error rate
The exact default set is open for discussion.
## Cardinality concern
Some existing queries include host, country, status, or colo dimensions. In particular, `colo-metrics` and `colo-error-metrics` may create substantial `zone × colo × host` series, and high-cardinality colo metrics have already been associated with Durable Object storage pressure in [#28](https://github.com/cloudflare/cloudflare-prometheus-exporter/issues/28).
Because Free-zone support would create additional per-query Durable Objects and refresh requests, it may be better to start with a low-cardinality default set and leave colo-heavy metrics out unless explicitly enabled or otherwise bounded.
## Other considerations
- Keep legacy `http-metrics` (`httpRequests1mGroups`) excluded.
- Keep the current hostname query excluded unless its unavailable TTFB/quantile fields are split from its basic request metrics.
- Keep health-check, load-balancing analytics, zone Logpush, and unverified firewall/security datasets excluded by default.
- Consider allowing the existing REST-based SSL certificate exporter independently of the GraphQL Free-tier filter.
- Preserve correct behavior for accounts containing both paid and Free zones.
- Handle zone-specific 403 responses without repeated noisy refresh failures.
## Question
Would maintainers be open to replacing the blanket Free-zone GraphQL exclusion with a small, documented default set of adaptive HTTP metrics, while keeping higher-cardinality and product-specific query families excluded?
References:
- [Cloudflare Zone Analytics](https://developers.cloudflare.com/analytics/account-and-zone-analytics/zone-analytics/)
- [GraphQL Analytics settings/discovery](https://developers.cloudflare.com/analytics/graphql-api/features/discovery/settings/)
- [GraphQL Analytics limits](https://developers.cloudflare.com/analytics/graphql-api/limits/)
- [Cache Analytics availability](https://developers.cloudflare.com/cache/performance-review/cache-analytics/)
Contributor guide
Research direction
No source files or tests are named. Start by tracing the Free-plan GraphQL exclusion and the existing query families, then review the referenced Cloudflare availability and limits documentation and issue #28. Done means a decided, documented low-cardinality default set, with the listed exclusions, mixed-plan behavior, SSL independence, and zone-specific 403 handling specified and tested.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- graphql, prometheus, typescript
- Domain
- cloud, observability
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 28/100