Replacing Apigee API Analytics with self-hosted open source
If your Apigee API Analytics add-on is expensive, ties your reporting to a managed platform, or sends request data somewhere your data residency rules do not allow, you can rebuild the operational side on your own servers. Traffic, latency and error reporting can be recreated with Apache APISIX as the gateway, feeding metrics into Prometheus and Grafana, or into ClickHouse when you need to keep detailed request logs and query them ad hoc. Developer-level usage and business reporting need additional design work on top of that. All of the core components are Apache-2.0 licensed: Apache APISIX, Prometheus and Grafana's open-source edition, which Grafana Labs moved to AGPLv3 in 2021 and which you should review with your legal team before distribution. The licensing cost is zero, so your budget goes to infrastructure, storage, implementation and the staff who operate the stack. Ask any vendor or implementation partner for a quote that breaks those components out separately, and confirm which Grafana features you need, since SAML and SCIM are limited to Grafana Enterprise and Grafana Cloud.
Plan the metric model before you deploy anything. Prometheus is designed for reliability over precision, so it is not suitable as the system of record for per-request billing, and it stores local data that is not clustered or replicated. Decide early how long you keep metrics, how you will ship long-term data through remote write, and which labels such as consumer, route or API product you need, because high-cardinality labels drive storage cost quickly. Business reporting, including revenue per partner, quota consumption by application and developer onboarding trends, usually requires consumer identity from your identity provider, a database of API products and subscriptions, and reports you build yourself. Apigee bundles that logic, so inventory every report your product owners use today before you retire the add-on.
Which Apigee analytics capabilities map to which open-source components
This table maps the reporting Apigee API Analytics provides to the components that rebuild it in a self-hosted stack. Read each row as a capability, the open-source piece that covers it, and the work that remains. The main takeaway is that operational reporting maps well to APISIX, Prometheus, Grafana and Alertmanager, while billing-grade and business reporting need custom work.
| Analytics capability | Open-source components | What still needs work |
|---|---|---|
| Traffic counts and request rates | APISIX logging and metrics plugins exposing counters to Prometheus, queried in Grafana | Rates are sampled and scraped, so confirm the scrape interval fits your dashboards |
| Latency percentiles | APISIX latency metrics in Prometheus, charted as histogram quantiles in Grafana | Percentiles depend on histogram bucket choices, so agree bucket boundaries before building dashboards |
| Error rates and status codes | Status code labels in APISIX metrics, alerts in Alertmanager | Map upstream versus gateway errors explicitly so alerts do not mix them |
| Per-proxy and per-product views | Route and service labels in metrics, or per-route fields in access logs loaded into ClickHouse | Apigee products have no direct equivalent, so you must define a grouping label per product |
| Developer and app breakdowns | Consumer identity from APISIX authentication plugins written into logs, then aggregated in ClickHouse | Requires consumer naming discipline and a mapping of apps to developers held outside the gateway |
| Alerting on traffic and errors | Prometheus alerting rules routed through Alertmanager grouping, inhibition and silences | Alertmanager should receive from every instance, and notification channels are your responsibility |
| Data retention and history | Prometheus local retention is 15 days by default, with ClickHouse or remote storage for longer history | Long-term query history needs sizing and a retention policy you own |
| Monetization and per-developer billing | Not covered by the metrics stack | Custom work. Prometheus is not suited to 100% accurate per-request billing, so use gateway logs in a billing pipeline |
Which analytics stack fits which team
Apigee's analytics answer two different questions: is the API healthy, and who is consuming it and how much. The three paths below split those questions differently, so the right choice depends on which one your team must answer first and who will run the stack.
Prometheus and Grafana for operations
This path fits platform and SRE teams that need traffic rates, latency percentiles and error ratios on dashboards and alerts. APISIX's Prometheus plugin exposes these as metrics that Prometheus scrapes, and Grafana draws them. Prometheus stores samples in a local time series database with a default retention of 15 days, and its local storage is not clustered or replicated, so plan backups or remote write to long-term storage. Prometheus also values reliability over precision, so do not use it as the source for per-request billing.
Log pipeline into ClickHouse
This path fits teams that need request-level detail, such as which consumer called which route, with status, bytes and timing, and want to query it over months. APISIX's logging plugins can ship access records to a collector that writes to ClickHouse, which handles high-cardinality, wide event tables well. The cost sits mainly in ingestion, storage sizing, schema design and the on-call work of a second data store. Confirm the exact logging plugin and sink configuration against the current APISIX documentation for your version.
Hybrid of metrics and logs
The hybrid path keeps Prometheus for alerting on the health of the gateway and sends per-consumer and per-route records to ClickHouse for reporting. Each store does the job it suits, and an alert can link to the request log for the same window. The trade-off is two pipelines, two retention policies and two sets of access controls to review. Expect the highest staff cost of the three, so it suits teams with a platform group already running both systems.
Grafana high availability needs a database
If Grafana serves dashboards to many operations and business users, run two or more active-active servers behind a load balancer. This requires MySQL or PostgreSQL for configuration, because SQLite does not scale for production. Alerting needs extra configuration to avoid duplicate notifications, and Grafana Live has limits in high availability. Ask your team to size the database as its own service with backups and failover, since it becomes a dependency for every dashboard.
Consumer reporting needs extra work
Apigee's developer and product reports map to a consumer identifier, API product and billing period. Neither Prometheus nor Grafana provides that model, and ClickHouse only stores what the gateway logs. Define the consumer key, the product mapping and the reporting calendar before building dashboards, and confirm whether finance will accept log-derived counts as the record. This work is usually the largest unplanned item in the project.
Access control and audit for dashboards
Grafana's SAML, team sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, while LDAP and generic OAuth work in all editions. If your access review requires group-based provisioning, confirm this before choosing the open-source edition. Apply the security hardening settings, including secure cookies and requiring authentication on the metrics endpoint, and record who can see consumer-level data.
What changes for operations, security and finance teams
Platform engineers take on the monitoring stack that Apigee previously operated as part of its managed or hybrid service. Prometheus pulls metrics from scrape targets it discovers or is configured with, so every APISIX node, etcd member and Grafana instance needs a deliberate entry in the scrape configuration. Prometheus stores data on local disk, and its storage documentation says local storage is not clustered or replicated, so the team must plan for backups, retention and a remote write target for longer history.
- Scrape targets: Confirm every APISIX data plane node is discovered, including nodes added by autoscaling, and that the metrics endpoints are reachable only from the monitoring network.
- Retention: The default local retention is 15 days. Decide whether longer history lives in a remote write system or whether the business requires reports that outlive that window.
- High availability: A single Prometheus server is not highly available. Run a second instance or a long-term store, and check how Alertmanager is configured, since Prometheus should point at every Alertmanager instance rather than a load balancer.
- Grafana state: Store Grafana configuration in MySQL or PostgreSQL for production. The installation docs say SQLite does not scale for production, and high availability needs two or more active-active servers behind a load balancer.
- Upgrade cadence: Prometheus minor releases stop receiving fixes after six weeks, so choose the long-term support line for production and track its end date.
Confirm the scrape list, retention period and HA design against your own traffic volume before signing off on the design.
Security teams should treat API analytics data as sensitive. Access logs and metrics labels can carry client identifiers, consumer names, request paths or header values, depending on what the gateway is configured to log. Apigee kept this data inside its own access model. Once logs are exported to a self-hosted stack, the organization must set access rules on the log store, the Grafana instance and any exported dashboards.
- Field selection: Review the APISIX logging plugins and decide which fields leave the gateway. Strip authorization headers, query parameters carrying tokens and personal data before they reach Prometheus, ClickHouse or any shared dashboard.
- Grafana authentication: All editions support LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, so account lifecycle automation needs a decision.
- Hardening: Apply the Grafana security hardening settings, including secure and SameSite cookies, a Content Security Policy and authentication on the metrics endpoint.
- Prometheus access: The Prometheus security model assumes a trusted network. Put the query and API endpoints behind a proxy that enforces identity.
- Evidence: Record who can query which dashboards and how access reviews are performed, since auditors will ask for it.
Confirm with your identity team which Grafana login methods and provisioning features your edition includes before you design the access model.
Finance and product teams often assume that usage and billing reports will appear automatically once traffic moves. Apigee's analytics and monetization features do not carry over to a gateway plus Prometheus and Grafana. Prometheus is designed for operational monitoring and says it values reliability over precision, so it is not suitable as the source for per-request billing or chargeback. Business reports need a separate data path and a defined owner.
- Report inventory: List every report that Apigee produced for consumers, partners, finance or product, including developer-level usage, quota consumption and error charges. Each one needs a source and an owner.
- Billing-grade data: Build a record-level pipeline into ClickHouse or another analytical store if invoices depend on request counts. Document how dropped or duplicated records are handled.
- Consumer identity: Map API keys or OAuth clients to customers and products in a system of record. The gateway emits identifiers, not commercial entitlements.
- Monetization logic: Quotas, tiers and rate plans must be rebuilt as gateway configuration and reporting logic. Confirm which of these the chosen platform supports natively.
- Cost ownership: The Prometheus project itself carries no license fee, so the recurring costs are infrastructure, storage, and the staff who maintain the pipeline. Request a quote that separates implementation from ongoing operations.
Ask the finance lead to sign off the report list and data sources before any invoice or partner report is switched off.
Why business reporting needs extra work after the switch
Gateway telemetry tells you what traffic passed through, not what a customer was entitled to. APISIX's logging and metrics plugins record requests, status codes, upstream timings and consumer identifiers, which is enough for traffic, latency and error dashboards. They do not know which developer app owns a key, which API product that app subscribed to, what quota or rate plan applies, or how many calls count against it. Apigee's analytics and monetization layers hold those relationships, so the new stack has to rebuild them as data, not as log fields. Before any dashboard is built, confirm with the business owners which of these questions reporting must answer: monthly calls per product, calls per app against quota, and overage per partner.
The team has to design three things, and each is a fixed-scope item to agree in writing. The first is a data model for products, apps, developers, credentials and plans, stored in a system of record that the gateway configuration is generated from or checked against. The second is identity mapping: every consumer key or JWT subject seen in the access logs must resolve to exactly one app and one owner, including keys rotated or revoked during the period. The openid-connect plugin can supply the subject claim, but only if your identity provider's claims are consistent across environments. The third is reconciliation: a scheduled job that compares gateway counts with the system of record, flags unmapped consumers and explains differences. Prometheus documentation states that it is not suited to per-request accuracy, so billing figures should come from the log pipeline or a store such as ClickHouse with a defined loss tolerance, and that tolerance should be signed off before go-live.
How to move analytics without losing history
This sequence keeps Apigee reporting running while APISIX telemetry takes over, so traffic, latency and error history stays available for comparison and audit after cutover. It depends on which Apigee exports and retention settings your team actually has, so the first step is confirming those.
Inventory current Apigee analytics and consumers
The API platform team lists every Apigee analytics dashboard, custom report, scheduled export and alert in use, then asks each consumer (operations, product owners, finance, partners who receive reports) what they read, how often and for which decision. The output is a register that maps each report to its data source, owner and business question. The step is done when every report has a named consumer and a yes or no on whether it must be rebuilt. Confirm with Google or your Apigee administrator which analytics data exports and retention periods your organization has configured, because that determines what history can be recovered later.
Classify reports into technical and business needs
The team separates reports that Prometheus and Grafana can answer, such as request rate, p95 latency, upstream timing and status code distribution, from reports that depend on business context, such as revenue per API product, developer app usage, quota billing or partner SLA reporting. Technical metrics map to APISIX logging and metrics plugins, while business reports usually need a separate data model fed from access logs in ClickHouse or another store. The output is two lists, and the business list gets a named owner. This step is complete when the owners sign off on which items are in scope for the first release.
Enable APISIX telemetry alongside Apigee
The platform engineers deploy APISIX in front of a test or low-risk route set, enable the Prometheus metrics export and the logging plugin that ships access logs to the chosen destination, and configure identical labels for route, service and consumer where the Apigee reports used them. Traffic is mirrored or split so both gateways see the same workload during the agreed parallel period. The step is done when a side by side comparison of request counts and error rates from Apigee exports and APISIX metrics agrees within the tolerance the owners set, and any gaps are logged as known differences.
Run both telemetry paths in parallel
For the parallel period, both reporting paths run and the team checks them against each other every working cycle. They review differences in counting method, time zones, retries, cached responses and failed requests that never reached a policy, since Apigee and APISIX can record these differently. Prometheus is designed to favor reliability over precision, so anything that must be exact for billing stays on a log-based path. The output is a discrepancy log with an explanation for each category. The step closes when the owners accept that the remaining differences are explained and documented.
Rebuild dashboards, alerts and retention in Grafana
Engineers rebuild each approved dashboard in Grafana using provisioned data sources and dashboards stored as code, then recreate alert rules with the same thresholds and notification routes. Prometheus local storage holds data for a configurable retention, so the team sets retention and decides whether long-term history goes to remote storage, which Prometheus supports through remote write. Grafana's production configuration uses MySQL or PostgreSQL rather than SQLite, and alerting needs HA settings to avoid duplicate notifications. The step is done when each rebuilt panel matches its Apigee counterpart on a test window and every alert has been fired once in a controlled test.
Backfill or archive historical Apigee data
Historical Apigee data cannot be replayed into Prometheus in a meaningful way, so the team loads what it exported in the inventory step into an archive that matches its retention needs. Engineers store the export files with their schema, time range and source in a documented location, and load summarized data into ClickHouse or a similar store when reports need to query it. Label the archive clearly as Apigee-sourced so future readers do not mix it with APISIX metrics. The output is a catalog of each archive set with its coverage dates, and the step closes when a sample report reproduces a known historical figure from the archive.
Cut over reports and decommission Apigee analytics
The owners approve the final cutover list, consumers are told which dashboard or export replaces each Apigee report, and the Apigee analytics add-on or scheduled exports are turned off only after the replacement has run through at least one full reporting cycle without open defects. The team keeps the archive and the Apigee export access under the retention rules set by the organization. The step is done when every consumer has confirmed the new reports, the cutover record is filed, and the decommission request is approved by the people who own the Apigee contract.
Questions buyers ask before replacing Apigee analytics
What drives the cost of a self-hosted analytics stack for APISIX?
The software is free to license, so cost comes from four components: infrastructure to run the gateway, Prometheus, Grafana and any log store; the one-time implementation of log formats, dashboards and alert rules; the recurring run effort for upgrades, storage and on-call; and any support contract you choose to buy. Apache APISIX is Apache-2.0 licensed, and Prometheus and Grafana have no paid edition that you must buy to run the core stack, though Grafana Enterprise is a separate commercial option. Storage volume, retention length and the number of metric series are the main levers that move infrastructure spend up or down. Ask any partner for a quote that lists each component separately, with one-time and recurring costs shown apart.
Who pays for implementation and who runs the stack afterward?
Your organization pays for the infrastructure in its own accounts or data centers, and it pays staff or a partner for implementation and ongoing operation. Implementation covers exporting the metrics Apigee reports today, mapping them to APISIX plugin output, building Grafana dashboards and Alertmanager rules, and documenting the result. Running it afterward covers Prometheus storage management, Grafana upgrades, configuration as code and responding to alerts. DeployOpen plans, implements, integrates, backs up, upgrades and supports self-hosted platforms in the client's infrastructure, and ongoing support is available as a retainer. Confirm in the written scope which of these tasks sit with your team.
How long does an analytics migration take, and what sets that time?
The duration depends on how many APIs and environments report traffic, how many dashboards and alerts must be recreated, and how much business reporting is in scope. No timeline is supplied for this work, so ask for one in the written scope rather than relying on a general estimate. Time usually grows with the number of distinct metric definitions your finance or product teams rely on, the number of environments that need parallel running, and the amount of history you must keep. Running Apigee analytics and the new stack side by side for a period is the most reliable way to check that numbers agree before you retire the old reports.
What must our team decide and supply before the work starts?
Three inputs gate the project. First, metric owners: a named person for each traffic, latency and error definition, including how a failed call and a retry are counted. Second, retention decisions: how long raw request logs and aggregated metrics must be kept, since Prometheus local storage defaults to 15 days and is not clustered or replicated, so longer history needs remote write to external storage. Third, identity mapping: how API keys, apps and developers in Apigee map to consumers, routes and identity provider claims, because the openid-connect plugin works with providers such as Keycloak, Entra ID and Okta. Without these decisions, dashboards will look finished but will not match what the business expects.
Can an internal team do this without an outside partner?
Often yes, if the team already runs Prometheus and Grafana and has someone comfortable with PromQL, YAML provisioning and gateway configuration. The gaps usually appear in three places: designing the metric model so it matches Apigee's analytics definitions, hardening Grafana, and building a reliable high availability setup, which the Grafana documentation says needs MySQL or PostgreSQL and two or more active-active servers behind a load balancer. Check your team's capacity against those tasks before deciding. A fixed-scope engagement can cover the parts you choose to hand over, and you can keep the rest in-house.
Can Prometheus replace billing-grade API usage reporting?
Not on its own. The Prometheus documentation says it values reliability over precision and is not a good choice where 100% accuracy is required, such as per-request billing. It is well suited to operational traffic, latency and error trends, and to alerting on them. For invoices, chargeback or partner revenue share, keep a record of every request in a store designed for exact counts, such as ClickHouse, and reconcile it with the gateway logs. Confirm with your finance team which numbers must be exact before you commit to a design.
What should we ask a partner to include in a quote?
Ask for a written scope that lists each deliverable, such as the gateway logging configuration, Prometheus and Grafana deployment, dashboards, alert rules, retention settings and documentation. Ask which items are one-time and which recur, what is excluded, and what you must provide, including metric owners and access. Request the assumptions behind the effort, the timeline and the acceptance criteria for reconciling reports against Apigee output. Also ask who operates the stack after handover and how upgrades are scheduled, since Grafana minor releases are supported for a defined period and Prometheus minor releases receive bug fixes for a limited window. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen scopes and delivers analytics replacement
Every engagement starts with a written scope that names the deliverables before any work begins. For an analytics replacement, that scope usually lists the APISIX logging and metrics plugins to enable on each route, the Prometheus scrape configuration and retention settings, the Grafana dashboards for traffic, latency and error reporting, and, if chosen, the ClickHouse tables and ingestion path for request logs. It should also state which environments are covered, who signs off on dashboards, and what counts as done. DeployOpen implements these components inside your own cloud accounts, data centers or air-gapped networks, so telemetry and logs stay under your control. DeployOpen does not publish a price list. A quote follows from the written scope, so the scope document is the main lever for comparing proposals.
Hardening and documentation are part of the delivered work, not optional extras. Expect the Grafana deployment to move off SQLite to MySQL or PostgreSQL for production and high availability, the metrics endpoint to require authentication, and the security settings from Grafana's hardening guidance to be applied. Prometheus local storage is not clustered or replicated, so the scope should say how long data is kept on each node and whether remote write to long-term storage is in or out. Deliverables typically include an operations runbook, a record of configuration as code, and an upgrade plan tied to the Prometheus and Grafana release cycles. Ask whether the written scope includes these items and who maintains them after handover.
Ongoing support, upgrades and continuous testing are available as retainers, which suit teams that do not want to own Prometheus and Grafana upgrades in-house. Compliance evidence is a separate matter: DeployOpen can prepare systems, configuration and records that an auditor will review, but DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Before you sign, confirm with your assessor which log retention, access review and change records they expect from the analytics stack, and write those requirements into the scope so they are built and documented from the start.
