Docs/Understand
Fleet Analytics
Roll up bounded operational telemetry across clouds without centralizing realm identity data or making authentication depend on Fleet.Paired realms project five-minute snapshots locally, retain 24 hours in a durable SableDB outbox and export complete revisions over the authenticated gRPC connector. Fleet persists canonical and materialized GreptimeDB facts, serves delegated hierarchy queries with explicit coverage, and supports signed Parquet recovery. This V1 tier is supported in 1.0.0; extended scale, independent assessment and organization-policy canaries continue as assurance.
What the program delivers
An authorized Fleet operator can drill through realm, environment, project, organization and authorized fleet scope. Every result carries metric-family coverage, so zero activity is never confused with a realm that is stale, disabled or unsupported.
The V1 contract carries operational aggregates: authentication outcomes and latency, registration progress, session and token issuance, service-account activity, webhook delivery, platform health, backup age, signing-key age and connector lag. No supported path copies user records, credentials, sessions, tokens or raw identity events into Fleet.
Cross-cloud data path
- The realm projects local ordered events and request telemetry into complete five-minute UTC snapshots.
- It atomically stores each snapshot, source watermark and retry record in its own SableDB.
- The realm initiates an authenticated connection and retries full snapshots until Fleet acknowledges the exact bucket revision.
- The Fleet gateway resolves the connection in its registry and stamps the trusted environment, project, organization and assignment epoch.
- An internal adapter writes one canonical row per realm bucket. Higher scopes are always derived from those canonical realm facts.
- A role-authorized Analytics RPC returns bounded series, breakdowns and coverage to Dioxus; the client never sends SQL.
gRPC first, Parquet for recovery
| Path | Boundary | Purpose |
|---|---|---|
| Live rollups | Realm-initiated authenticated gRPC | Normal delivery of complete, closed five-minute snapshots with exact revision acknowledgements |
| Archive repair | Signed manifest + Zstandard Parquet | Audited replay, backfill and portability from an explicitly approved project or central bucket |
Fleet does not continuously introspect arbitrary customer buckets. The cold path is manifest-driven: an operator first approves a bucket binding, then the importer verifies the realm signature, object digest, size, row count, schema, time range and sequence range before accepting immutable metric-bucket rows. Bucket credentials and presigned URLs never appear in a telemetry payload.
That separation keeps object storage useful for disconnection recovery, migration and residency without turning every dashboard query into a cross-cloud object scan. Live product reads use the central analytical store.
Hierarchy and deterministic rollup
Counts are summed, rates are calculated from summed numerators and denominators, and percentile latency is calculated after merging compatible cumulative histograms. Fleet never averages child rates or cascades rounded organization totals into a fleet total. Corrections replace the accepted realm revision and recompute the affected scopes.
A realm cannot claim that it belongs to a different environment or organization. Re-parenting creates a new assignment epoch; historical facts retain the attribution under which they were accepted.
GreptimeDB is an internal adapter
GreptimeDB is the private central analytical adapter because this workload is time-series heavy and benefits from a Rust implementation. The pinned adapter has passed schema, correction, TTL, isolation/purge, medium-performance and recovery gates. GreptimeDB SQL, tables and credentials are not public product contracts.
Fleet SableDB remains authoritative for organizations, projects, environments, role bindings, realm connections, accepted revisions, ingestion cursors and archive coordination. Losing analytics storage may make charts stale or partial; it must never alter passkey sign-in, token issuance or realm recovery.
Coverage and failure isolation
expected_realms = reporting_realms + stale_realms
total_realms = expected_realms + disabled_realms + unsupported_realms
partial = reporting_realms < expected_realmsCoverage is metric-family-specific and accompanies every scope result. A realm may report authentication metrics while not supporting webhook metrics. The UI must show the last complete common window and contributing children rather than silently filling missing data with zero.
- A Fleet or GreptimeDB outage never blocks realm authentication.
- A disconnected realm retains bounded local snapshots and retries after reconnecting.
- Duplicate delivery and ambiguous acknowledgement converge through full-snapshot revisions.
- Disabling telemetry leaves the Fleet management plane and every realm fully functional.
Delivery roadmap
| Milestone | Status | Exit focus |
|---|---|---|
| M9 | Complete | V1 semantics, Protobuf, Parquet schema and compatibility fixtures |
| M10 | Complete | Local projection, durable SableDB outbox and authenticated outbound export |
| M11 | Complete | Trusted ingestion coordination and canonical GreptimeDB storage |
| M12 | Complete | Role-authorized Analytics RPC and Dioxus drill-down |
| M13 | Complete | Hourly/daily materialization, archive import and residency modes |
| M14 | Complete | Supported V1 tier; extended assurance continues |
| M15 | Later | Separately reviewed anomaly detection, alerts and approved exports |
M14 is the first point at which Fleet Analytics may be described as production-qualified. M15 insights, cross-customer benchmarks and unrestricted raw-event search are not part of V1; benchmarking would require a separate accepted privacy decision.
Continue to the contracts
- Fleet Analytics V1 semantics for buckets, metrics, histograms, privacy, coverage and archives.
- Complete delivery program for qualification targets, workstreams, rollback and definition of done.
- ADR 0004 for the controlling architecture decision.