cloudflare / cloudflare/cloudflare-prometheus-exporter

discussion: conservative default metrics for Free-plan zones

Open
#56 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.