Why Apache Superset monitoring with StatsD and Prometheus matters before users complain
Without metrics, slow dashboards and failed scheduled reports usually reach you through analysts, not through your own systems. This page explains how to export Superset and Gunicorn metrics through StatsD, which backend to send them to (Prometheus is one option among several), which endpoints and events are worth alerting on, and how to build dashboards for the web and worker tiers. A self-hosted Superset serving analysts has more moving parts than a single web process. A running installation combines the Flask and React application, a metadata database, an optional caching layer and optional Celery worker and beat processes, according to the Superset architecture documentation. Failures in the web tier look like slow pages. Failures in the worker tier look like silence.
That silence matters most. The architecture documentation states that alerts and reports, async queries and dashboard thumbnails depend on the caching layer and worker components, and most installations run Redis and Celery for them. A worker that stops consuming its queue, or a beat process that stops scheduling, produces no error in the browser. Analysts simply stop receiving reports. Before you choose a metrics path, confirm which of these features your deployment actually uses, because that list defines what must be measured and alerted on.
StatsD is the export path this page assumes. Superset and Gunicorn emit counters and timers over StatsD, a lightweight UDP protocol, and a StatsD-compatible receiver converts them for a time series backend. Teams usually need this path when they already run a StatsD receiver, when they want one metrics pipeline across several services, or when they want alerts on worker health rather than only on web response times. Prometheus is a common destination, but it is not the only one. Confirm with your monitoring team which backend already holds operational alerts, who is on call for it, and how long metric data must be kept before you commit to a design.
Which metrics pipeline fits your team
This path sends Superset and Gunicorn metrics as StatsD datagrams to a translator, which exposes them in a form Prometheus can scrape. It suits teams that already run StatsD-style instrumentation elsewhere and want one collector for several applications. The translator becomes another component your team owns, with its own configuration, version updates and failure modes.
- Who runs it: Your platform team runs the StatsD receiver or exporter, Prometheus and Alertmanager. The Superset team still owns the metric configuration in Superset.
- Ownership cost: Every hop is a moving part. A dropped UDP datagram or a mapping rule that renames a metric can silently break a dashboard.
- Cardinality: StatsD carries names and tags in a flat form, so a poorly designed mapping can turn labels such as user or dashboard identifiers into high-cardinality series in Prometheus.
- Alert quality: Metric type is lost or altered in translation, so counters and timers may need rules written against the translated names rather than the originals.
Confirm Superset's exact metric names and types for your version before writing any mapping, and check which StatsD options your Superset release supports.
This path exposes a metrics endpoint that Prometheus pulls over HTTP from each target, discovered through service discovery or static configuration. It removes the translation layer and keeps metric types intact, which usually makes alert rules simpler to write and review. The trade-off is that the endpoint must be reachable from Prometheus and protected from anyone else.
- Who runs it: Your platform team runs Prometheus and the scrape configuration. Superset and Gunicorn must expose a compatible endpoint, which your team has to verify for its version.
- Ownership cost: Fewer components to patch, but scrape targets must be kept in sync with web and worker replicas as they scale.
- Access control: The Prometheus security model assumes trusted network access to endpoints, so restrict the metrics path with network policy or authentication.
- Alert quality: Native types let you use rate and histogram functions in PromQL, which is usually the clearest route to latency and error-rate alerts.
- Accuracy: Prometheus values reliability over precision, so treat alert thresholds as signals for investigation rather than exact billing or audit figures.
Confirm with your Superset version whether a metrics endpoint is available out of the box or needs an exporter, and test that every web and worker process is discoverable.
Many organizations already run a monitoring backend, such as a Grafana-based stack, or use a managed service that accepts Prometheus-format data. Reusing that backend avoids a new on-call surface and keeps dashboards in one place. Ownership moves to whichever team operates the existing platform, and that team's standards for retention, access and alerting usually apply.
- Who runs it: Your existing observability team operates storage, query and alerting. Superset owners supply the metric definitions and the alert intent.
- Licensing: Grafana Labs relicensed Grafana, Loki and Tempo from Apache License 2.0 to AGPLv3 on April 20, 2021, and offers Grafana Enterprise as a commercial option. Check which edition and license terms your organization has adopted.
- Cost model: Managed tiers charge by usage or commitment. Grafana Cloud's published pricing includes a free tier, a Pro tier with a platform fee plus usage, and an Enterprise tier with a minimum annual commitment. Ask any provider for a quote based on your series count and retention.
- Cardinality: A shared backend may enforce series limits. Agree label rules with that team before Superset metrics arrive.
- Alert quality: Shared alerting can produce duplicate notifications in high-availability setups, so confirm routing and deduplication.
Confirm that your backend accepts the metric format you choose and that its retention and access rules meet your audit needs.
The three paths differ less in features than in who carries the operating load. A small team with one Superset instance may prefer the fewest components, while a platform team running many services may want one collector and shared alerting. Decide based on who will answer alerts at 2 a.m., how much series growth the team will tolerate and whether an existing backend already meets the requirement.
- Fewest components: Direct scraping, when your Superset version exposes a usable endpoint.
- Shared standard: StatsD or an existing backend, when other applications already emit into it.
- Single-node limits: Prometheus local storage is not clustered or replicated and defaults to 15 days of retention, so plan remote write or long-term storage if you need more history.
- Alertmanager: Point Prometheus at every Alertmanager instance rather than a load balancer when running in high availability.
- Scope of ownership: Write down which team owns each component, dashboard and alert rule before the build starts.
Before choosing, ask your team to list the components they already operate and confirm Superset's metric names and endpoint behavior for the version you plan to run.
How to wire StatsD into Prometheus step by step
This sequence takes Superset and Gunicorn metrics from the web and worker tiers through a StatsD path into Prometheus, with Prometheus pointed at every Alertmanager instance. Each hop is checked with a known test event before the next one is added.
Confirm metrics settings for your Superset version
Before changing anything, the platform owner checks the metrics configuration keys in the Superset configuration documentation for the exact version you run, since names and defaults can change between releases. Record the StatsD host, port and prefix you intend to use, and confirm which Gunicorn metrics your web image exposes. Done means you have a short written list of keys, their values and the version they were checked against, reviewed by the person who owns the Superset configuration file.
Enable StatsD emission in the web tier
Set the metrics keys in the Superset configuration for the web containers, and set the Gunicorn StatsD options in the web server startup so both application and server metrics leave the process. Roll this out to one replica first. The check is a single UDP packet or a StatsD debug listener receiving lines with your configured prefix after a page load, such as a dashboard open, which you trigger yourself as a known test event.
Enable StatsD emission in the worker tier
Repeat the configuration for the Celery worker containers that run alerts, reports and async queries, and confirm the worker startup includes the same prefix and host so both tiers are distinguishable. Trigger a known test event, such as a manual dry-run report in a non-production workspace, and confirm a worker-tagged metric line appears at the StatsD listener. Keep the worker and web prefixes separate in the written list so dashboards can filter by tier later.
Deploy a StatsD to Prometheus exporter
The platform team deploys a StatsD-to-Prometheus exporter or bridge in the same network zone as Superset, and points the StatsD output of both tiers at it. Choose the exporter in agreement with your standards for open-source licensing and support, and confirm its own release line and security patch cadence before adoption. The check is that the exporter's metrics endpoint responds locally and shows the test metric from the previous step, translated into Prometheus naming.
Add scrape jobs for the exporter
Add a scrape job in the Prometheus configuration that targets the exporter, either as a static target or through the service discovery mechanism your platform already uses. Use separate job labels for web and worker tiers if the exporter does not already separate them. Reload Prometheus, then open its targets page to confirm the job is up. The check is that the test metric is queryable in the Prometheus expression browser after one scrape interval.
Point Prometheus at every Alertmanager
In the Prometheus alerting configuration, list every Alertmanager instance as a target rather than placing a load balancer in front of them, as the Alertmanager documentation recommends for clustered deployments. Confirm each instance is part of the cluster using its status view. The check is a deliberately firing test alert, routed through Alertmanager to the receiver you chose, arriving once at the intended destination.
Verify each hop with a known test event
Walk the path end to end: Superset emits a metric, the exporter receives it, Prometheus scrapes it, a PromQL query returns it, and a test alert reaches a receiver. Record the timestamp of the triggering action and the time each hop shows it, so a gap points to one component. Keep the test event and its expected results in your runbook so the same check can be repeated after upgrades or changes to the exporter or Alertmanager.
Which endpoints and worker events to alert on first
A first alerting set for Superset should cover the user-facing path, the background work that reports and alerts depend on, and the stores both tiers rely on. Each signal below points at a different failure, so a single noisy threshold should not stand in for all of them. Set every threshold from your own baseline over normal dashboard traffic and scheduled report runs before you page anyone.
Web error rate and latency
Track the share of 5xx responses and the latency percentiles on dashboard and chart endpoints, since these are what analysts feel first. Watch the chart data path separately from dashboard page loads, because a slow warehouse query shows up there while a broken web tier shows up everywhere. Compare each endpoint against its own history, and check whether spikes line up with deployments or with heavy scheduled refreshes.
Gunicorn worker saturation
Measure how many Gunicorn workers are busy at once and how long requests queue before a worker picks them up. A tier that stays near full capacity will time out requests even when the code and the database are healthy. Pair this signal with the worker count and timeout values in your configuration, so a saturation alert points to a specific setting rather than a generic overload.
Celery worker availability
Alert when the number of online Celery workers drops below the count you deployed, or when a queue has no consumer. Alerts, reports, async queries and thumbnails all depend on these workers, so a missing worker can leave work silently unprocessed. Confirm which queues each worker consumes so the alert covers the queues that matter to your reports.
Beat scheduling gaps
Celery beat enqueues scheduled report and alert runs, so a beat process that stops or restarts will leave gaps in the schedule. Alert on the age of the last beat heartbeat or on a scheduled job that has not run within its expected window. Only one beat process should be active, so also alert if more than one is detected.
Async query and task backlog
Watch the depth of the Celery queues that carry async queries, thumbnails and report work, along with the age of the oldest waiting task. A growing backlog usually means too few workers, slow upstream databases or long-running jobs holding slots. Set the threshold on wait time for your users rather than on queue length alone, since a short queue of slow jobs can be worse than a long queue of quick ones.
Failed reports, cache and metadata database
Count failed alert and report runs, and alert on connection failures to the metadata database and the caching layer. Failed runs often trace to SMTP, Slack or browser screenshot problems that the web tier never logs, so the run status is the signal to watch. Connection failures to Redis or the metadata database usually affect every user at once, so route them to the on-call team with higher priority.
What the web and worker dashboards should show
Split the monitoring set into two views that answer different questions. The web tier view answers whether users can load dashboards and run queries: request rate, error rate by status class, and latency percentiles for the Gunicorn workers that serve the Flask and React application. The worker tier view answers whether scheduled and asynchronous work is moving: queue depth and task outcomes for the Celery workers and beat process that handle alerts and reports, async queries and thumbnails. Both views should also show the metadata database and caching layer that the tiers depend on, because a slow metadata database often looks like a slow web tier. The exact metric names depend on how your StatsD mapping is configured, so confirm them against your own exporter output before building panels.
Use PromQL at a conceptual level. Rates turn ever-increasing counters into per-second values, so a request rate panel is a rate over a short window, and an error ratio is the rate of error responses divided by the rate of all responses. Percentiles come from histogram or summary buckets, so a p95 latency panel is only as good as the bucket boundaries the exporter emits. Prometheus values reliability over precision and is not suited to 100 percent accurate per-request billing, so use it for trends, alerting and capacity planning, and take billing or chargeback figures from the application's own logs or audit trail. Also avoid putting raw user names, dashboard IDs, or chart IDs into metric labels. Each unique label combination creates a new time series, so per-user or per-dashboard labels grow storage and query cost without limit. Aggregate by tier, endpoint group or status class instead, and keep per-user detail in logs.
Protecting metrics endpoints and retention data
Metrics are quiet but sensitive: they reveal query volumes, user activity patterns and infrastructure layout. The controls below cover who can reach the scrape and UDP paths, how long data survives on a single Prometheus server, and how the dashboard layer is hardened, so the monitoring stack does not become its own weak point.
Restrict scrape endpoint access
Prometheus pulls metrics over HTTP from each target, so every Superset web, worker and Gunicorn exporter endpoint is a readable surface. Limit scrape access with network policy or firewall rules that allow only the Prometheus servers, and confirm that no metrics path is exposed through the public load balancer or ingress. Ask your platform team which paths the proxy forwards before go-live.
Scope StatsD UDP traffic
StatsD metrics travel as UDP datagrams, which carry no built-in authentication or delivery guarantee. Bind the StatsD listener to the internal interface, restrict the source addresses that can send to it, and keep it off any network segment that users or untrusted workloads can reach. Verify the path with a test metric from an allowed host and a blocked one.
Treat local storage as single-node
Prometheus local storage is not clustered or replicated, so one server is one point of failure for your history. Plan for the loss of that server by documenting how you rebuild it and which dashboards and alert rules live in version control. Ask whether losing a month of history is acceptable for capacity and incident reviews.
Set retention and remote write
Retention defaults to 15 days and can be set by time or size, so a long-term audit or capacity question will fail unless you change it. If history must outlast the local disk, use remote write to an external long-term storage system and confirm the backend's access controls, encryption and cost before sending Superset series there.
Harden the Grafana dashboard layer
When Grafana is the dashboard layer, its security hardening guidance applies to the Superset views you build there. Require authentication on the metrics endpoint, use secure and SameSite cookies, set a Content Security Policy and enable domain verification against DNS rebinding. Confirm which of these settings your Grafana edition and version support before enabling them.
Review access to dashboards and alerts
Dashboards and alert rules can expose operational detail to people who should not see it, and Grafana edition determines which identity features are available. Map viewer, editor and admin roles to your identity groups, and keep changes to alert rules under review. Ask your identity team which group sync and provisioning features your Grafana edition includes.
Configuration options and when each fits
This table compares the main choices for getting Superset and Gunicorn metrics into a monitoring backend, with the fit and cost driver for each. Read each row against your team's operating capacity, retention needs and whether you already run Prometheus or Grafana.
| Choice | Fits when | Cost and effort driver |
|---|---|---|
| StatsD exporter | Superset emits StatsD metrics and you want a translation layer in front of Prometheus | One more component to deploy, version and monitor. Mapping rules need review whenever metric names change between Superset releases. |
| Direct scrape | You can expose a Prometheus-compatible endpoint from the workers and web tier and want fewer moving parts | Confirm which exposition format your Superset version and Gunicorn setup support before choosing. Fewer components, but less translation control. |
| Local Prometheus retention | Short operational history is enough for alerting and day-to-day troubleshooting | Default retention is 15 days (Prometheus storage docs), configurable by time or size. Local storage is single-node, so plan disk capacity and backups yourself. |
| Remote write to long-term storage | Audits, capacity planning or incident reviews need months of history or a second copy of the data | Adds an external storage system to run or buy. Ask the vendor or operator for its licensing and storage cost model before committing. |
| Prometheus | You want open-source time-series storage, PromQL alerting and a large body of community exporters | Apache-2.0 licensed with no paid enterprise edition (Prometheus). Costs are infrastructure, storage and the people who run it. Plan for one-year LTS or 6-week minor upgrades. |
| Another metrics backend | Your organization already standardizes on a commercial or hosted metrics platform | Confirm whether it ingests StatsD or Prometheus formats directly. Licensing and per-series or per-host fees come from that vendor, not from this project. |
| Single Alertmanager instance | A small team accepts a single point of failure for notifications and wants the simplest setup | Lower operating effort. Missed or delayed pages during an outage are the main risk, so document a fallback route. |
| Clustered Alertmanager | Alert delivery must survive a node failure and you can run several instances | Needs the cluster flags and Prometheus configured to reach every instance, not a load balancer. Extra nodes and testing effort recur. |
| Self-hosted Grafana | You want dashboards for the web and worker tiers inside your own infrastructure, with self-managed authentication | Software is AGPLv3 since the 2021 relicensing (Grafana Labs licensing). Costs are hosting, database and upgrade effort. SAML and SCIM need Grafana Enterprise. |
| Grafana Cloud tiers | You prefer a managed service and metric data may leave your network under your data policy | Pro starts with a 19 US dollar monthly platform fee plus usage. Enterprise has a 25,000 US dollar yearly minimum (Grafana pricing). Confirm data residency first. |
Limits to confirm in your environment
The monitoring design for Superset depends on versions and support windows that change between releases. The cards below list the items to confirm with your own team before you commit to dashboards, alert rules and an HA layout.
Superset and Gunicorn metric names
Metric names exported through StatsD depend on the Superset version, the StatsD backend and the Gunicorn settings in your image. Alert rules written against one name will silently fail to fire after an upgrade if the name changed. Confirm the exact metric names your running version emits by scraping a test instance before you write any rule, and keep a small test that checks each alert still has data.
Prometheus LTS line and support dates
Prometheus minor releases stop receiving bug fixes after about six weeks, so a standard minor line needs regular upgrades. A long-term support line receives fixes for one year. Choose the line deliberately and confirm its end-of-support date against your change calendar, since the current LTS line and its end dates may move before your rollout.
Grafana database for high availability
Grafana keeps configuration in SQLite by default, and the installation docs say SQLite does not scale for production. High availability needs a shared MySQL or PostgreSQL database behind a load balancer. Confirm the supported database versions for the Grafana release you pick, and confirm that your existing database service can meet your backup and failover requirements.
Alpha Superset Kubernetes Operator
If your team plans to run Superset on Kubernetes with the Apache Superset Kubernetes Operator, note that it is in alpha with a v1alpha1 API. Custom resource schemas may change between releases, so manifests written today can break on upgrade. Treat the operator as a moving dependency and confirm its current status, schema version and upgrade notes before choosing it over the Helm chart or plain manifests.
Alert deduplication in HA Grafana
Running two or more active Grafana servers can send duplicate alert notifications unless alerting is configured to avoid it. The high availability docs call for additional configuration, and Grafana Live has its own limits in HA. Test that a single alert produces one notification on a multi-node setup, and confirm which Grafana alerting mode and notification path your team will run.
Retention and single-node storage limits
Prometheus local storage is not clustered or replicated, and default retention is 15 days. Dashboards that compare weekly or monthly trends need longer retention or a remote write target. Confirm your retention window, disk sizing and backup approach for the Prometheus server, and decide whether a remote storage system will hold the long-term series.
What does Superset monitoring cost and take to build?
What drives the effort to build Superset monitoring with StatsD and Prometheus?
The effort rises with the number of tiers you monitor, how many Gunicorn and Celery worker processes you run, how much history you keep, and how many alerts you need to route to people who act on them. A single web tier with one worker pool and a short retention window is a smaller job than several web replicas, separate worker queues for reports and async queries, and a long retention period. Alert design usually takes the most review time, because each rule needs a threshold, a severity, a runbook and an owner. Ask any partner to break the scope down by tier, exporter, storage and alert set so you can see which items move the price.
Can our in-house team build Superset monitoring without a partner?
Yes, if you already run Prometheus or a comparable backend and have engineers who know Gunicorn, Celery and StatsD. The work is mostly configuration, exporter wiring and dashboard and alert authoring, which a platform team can handle. A partner is useful when the team lacks time, when the monitoring must match a regulated change process, or when no one has tested alerts against real failure modes such as stalled report workers. Be honest about the skills gap before you decide, and compare your internal estimate with a written scope rather than a verbal one.
What access and decisions do we need to provide before monitoring work starts?
The implementer needs access to the clusters, hosts or containers that run the Superset web and worker tiers, plus the metadata and Prometheus environments where metrics will land. You also need to name an alert routing owner who decides where pages and tickets go, who is on call, and which alerts are severe enough to wake someone. Agree on the StatsD or exporter path, the retention target and the network rules for scraping. Without a named owner, alerts tend to fire into a channel nobody reads, so settle that question early in the scope.
What recurs after launch for Superset monitoring, and what is a one-time build?
The build itself is one-time: exporter configuration, dashboards, initial alert rules and the first round of threshold tuning. Recurring work includes storage for metrics, since Prometheus local storage is single-node and needs managed disk and backups, plus alert review, dashboard upkeep and maintenance of the exporter setup. Upgrades recur too. Prometheus minor releases stop receiving bug fixes about six weeks after their cycle begins, and long-term support lines receive fixes for one year, so plan a regular patch cadence. Superset upgrades also change metric names and config, so each upgrade needs a check of the dashboards.
How long does Prometheus keep Superset metrics by default, and does that change cost?
Prometheus keeps data in a local time series database with a default retention of 15 days, and you can configure retention by time or by size. Longer retention increases disk use roughly in proportion to the amount of data kept, so the storage bill grows with both series count and retention. If you need history beyond local storage, Prometheus supports remote write to external long-term storage systems, which adds its own platform and cost. Decide the retention target with your compliance and capacity owners before sizing the disks, because changing it later means rebuilding storage.
Does the Prometheus stack carry a license cost for Superset monitoring?
Prometheus is licensed under Apache-2.0 and has no paid enterprise edition, so the software itself adds no license fee. Costs come from the infrastructure that runs it, the storage it uses, the implementation work and the people who operate it. If you add Grafana for dashboards, check the licensing terms that apply to the edition and version you choose, because Grafana Labs changed the license of Grafana in 2021 and offers a commercial Enterprise option. Confirm the exact license of every component in your written scope before you commit.
What should a written scope for Superset monitoring include?
A useful written scope lists the tiers covered, such as web, Gunicorn workers and Celery worker and beat processes, and the exporter path through StatsD or another backend. It names the storage target, retention period and any remote write destination, and it lists the dashboards and the alert set with the owner for each alert. It states what you provide, including access, the routing owner and test windows, and what you receive, including dashboard files, rule files, a runbook and handover notes. Ask how alerts will be tested against failure cases, how changes are tracked, and what support follows the handover. Fixed-scope work is agreed in writing before it begins, so you can compare quotes on the same deliverables.
Is ongoing support for Superset monitoring available after the build?
Yes. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which can cover alert review, dashboard upkeep and patching the monitoring stack after handover. The right choice depends on how much change you expect, how many alerts you run and whether your own team has capacity to take those tasks back. Ask for the response expectations and the upgrade approach in writing so that routine Prometheus and Superset changes are covered in the retainer scope rather than handled as surprise work.
How the scope for a Superset monitoring build is agreed
DeployOpen agrees a fixed written scope before any monitoring work starts. The scope names the tiers to be instrumented, the web tier (Gunicorn serving the Flask and React application) and the Celery worker and beat tier, along with the metrics backend, the alert set, and the dashboards. For each tier, the written scope should say where StatsD metrics are emitted, how they are translated into Prometheus series, which Alertmanager instances receive alerts, and who owns each alert route. Agreeing these items up front keeps the build to a defined set of deliverables with a timeline that both sides sign off.
The decisions that most change the scope are the backend and the retention model. If the team already runs Prometheus, or prefers Grafana for dashboards, the scope should state whether that stack is reused or new, and whether the Prometheus local storage is treated as a single-node database with a planned remote write target for long-term data. Confirm with your own team which of the tiers and alert routes already have an on-call owner, since an alert with no owner is usually the first item to be removed in review. Ask for the scope to list the Superset version it targets, so that metric names and dashboards are validated against the release you actually run.
Ongoing tuning is handled separately from the build. Alert thresholds, dashboard changes after a Superset or Prometheus upgrade, and new worker queues are commonly placed under a retainer rather than priced into the original delivery. When requesting a quote, ask which items are one-time (initial configuration, dashboard build, handover) and which recur (rule review, upgrade validation, on-call support), and ask how changes raised after sign-off are estimated and approved. DeployOpen does not publish a price list, so the written scope is the basis for any quote.
How DeployOpen delivers Superset monitoring
DeployOpen plans and builds Superset monitoring inside your own infrastructure, from the StatsD export and Gunicorn metrics through to Prometheus, alert rules and dashboards for the web and worker tiers. Each engagement starts with a written scope that names the components, endpoints and alerts covered, so your team knows what it receives before work begins.
How we scope
- Inventory the Superset web, worker, beat and caching components that need metrics in your environment
- Agree in writing which StatsD metrics, Gunicorn metrics and endpoints the monitoring covers
- Confirm your Prometheus, Alertmanager and Grafana setup, storage retention and who receives alerts
How we build
- Configure the StatsD export path and the metrics mapping into your chosen Prometheus or backend
- Write alert rules for web availability, queue backlog and failed report or alert tasks
- Build web and worker tier dashboards and test each alert against a controlled failure before handover
How we hand over
- Document the metric names, label meanings, alert thresholds and the reason behind each one
- Provide configuration files and dashboard definitions stored in your own version control
- Walk your operations team through alert routing, silences and the runbook for each alert
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer
- Retainer reviews can cover monitoring changes that follow a Superset or Prometheus version upgrade
