You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current source documentation already exists as a readme.
Documentation could/should include the following at a minimum:
What is collected: Plain-language explanation of Apollo/the analytics exporter, why it exists, and the signal list (once ratified via the data-contract PR) grouped by category: contractual (PI/DI/TU counts, tenant lifecycle), usage (process/task/incident/definition events), environment (heartbeat, version info). Explicitly restate what's never collected - process variables, payloads, message bodies, or other sensitive data.
How data is handled: Opt-in/disabled-by-default for Self-Managed vs. opt-out/enabled for SaaS, authentication (license key fingerprint + HMAC), where data lands and how long it's retained, and how to disable it.
How to enable it: The config change needed (YAML/env var), and critically the network requirement: outbound access from the cluster to Camunda's collector endpoint. This is the actual adoption blocker currently, so docs must be explicit about exactly what a security team needs to whitelist (host, port, protocol) - this matters more than anything else on this page.
How to inspect what's been sent: Currently, for Self-Managed, this means pointing your own OTel-compatible stack (e.g. Loki) at the exporter and querying it directly. For SaaS there's currently no customer-facing way to see this at all - docs should state this clearly rather than pointing at something that doesn't exist yet.
Documentation required for the Camunda Analytics Exporter in 8.10, as part of an overview of telemetry for Self-Managed.
Relates to: https://github.com/camunda/product-hub/issues/3247.
Current source documentation already exists as a readme.
Documentation could/should include the following at a minimum: