The monitoring logic in Whaleal Platform has been rebuilt on a new foundation: collecting, storing and evaluating metrics is handled by Prometheus, while deduplicating, grouping, inhibiting, silencing and routing alerts is handled by Alertmanager. WAP also exposes interfaces so you can plug its metrics and alerts into the monitoring platform you already run, instead of standing up another silo. This post explains how the new pipeline works and the ways you can connect to it.
Illustration of how data and alerts flow · actual deployment shape is per the WAP docs
Prometheus and Alertmanager are the most widely used pairing in cloud-native monitoring. Building WAP's monitoring logic on top of them brings three practical benefits.
Metrics in one standard format, queries in PromQL, dashboards in Grafana. Anyone on your team who already knows these tools has almost nothing new to learn.
"What counts as abnormal" is judged by Prometheus rules; "who to notify, how, and when not to" belongs to Alertmanager. Keep the two apart and you can tune each without disturbing the other.
Both metrics and alerts come out in widely used formats. If your platform can read Prometheus metrics or receive a webhook, it can plug in.
An alert goes through four steps. The one worth understanding best is the lifecycle of an alert inside Prometheus, because it directly determines when you get notified.
The expression isn't matching. All is well.
The condition is true, but hasn't lasted as long as the rule's for yet. Keep watching.
The duration has been met, and the alert is sent to Alertmanager.
The condition no longer holds, and Alertmanager can send a "resolved" notification.
The state of the monitored MongoDB instance is converted into metrics Prometheus can read, served on an HTTP endpoint.
At the configured scrape_interval, Prometheus pulls the metrics and writes them to its time-series storage for querying, charting and rule evaluation.
Every evaluation_interval, Prometheus runs the expressions in the alerting rules. Once one matches and stays matching beyond for, the alert moves to firing and is sent to Alertmanager.
Incoming alerts first pass through deduplication, grouping, inhibition and silencing, then are routed to the right receiver — WAP's built-in notifications, or your own platform.
Noise is an alerting system's worst enemy. Alertmanager turns noise reduction into a handful of explicit mechanisms, all declared in configuration.
Combine similar alerts into a single notification. When a wide outage triggers dozens of alerts, you get one summary rather than dozens of messages.
While certain alerts are firing, suppress notifications for other related ones. For example, when a whole cluster is unreachable, stop notifying about the individual alerts inside it.
Mute matching alerts for a set period — ideal for planned maintenance. Silences are defined with matchers and set in the Alertmanager web interface.
A routing tree decides how alerts are grouped, when they're sent, and which receiver gets them. Different severities and clusters can take different paths.
Alertmanager itself can run as a cluster. The official advice is not to put a load balancer between Prometheus and multiple Alertmanagers, but to point Prometheus directly at the full list of Alertmanagers.
Many teams already have a monitoring and alerting stack and don't want yet another silo. WAP offers two kinds of interface: one where you pull the data, and one where WAP pushes alerts to you.
WAP exposes its monitoring metrics in the Prometheus scrape format. Add it as a scrape target in your own Prometheus and the metrics flow into your stack.
After governance, Alertmanager sends alerts as an HTTP POST to the address you specify, with a uniform JSON payload.
The interface descriptions and code samples in this post are meant to explain the integration approach. Metric names, interface paths, authentication and exact fields are illustrative — when you implement, follow the official WAP documentation.
The configuration syntax below follows the general Prometheus and Alertmanager formats. Parts marked "illustrative" need to be replaced with real values from your environment.
scrape_configs: - job_name: 'wap' scrape_interval: 15s metrics_path: /metrics # illustrative: see docs for the real path static_configs: - targets: ['<WAP address>:<port>']
groups: - name: mongodb-replication rules: - alert: ReplicationLagHigh expr: mongodb_replset_lag_seconds > 10 for: 2m labels: severity: warning annotations: summary: "Replica set {{ $labels.rs }} lag exceeds 10 seconds"
route: receiver: wap-default group_by: ['alertname', 'cluster'] group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - matchers: [ severity="critical" ] receiver: customer-platform receivers: - name: customer-platform webhook_configs: - url: 'https://your-platform.example.com/hooks/wap' send_resolved: true inhibit_rules: - source_matchers: [ severity="critical" ] target_matchers: [ severity="warning" ] equal: ['alertname', 'cluster']
{
"version": "4",
"groupKey": "{}:{alertname=\"ReplicationLagHigh\"}",
"status": "firing",
"receiver": "customer-platform",
"groupLabels": { "alertname": "ReplicationLagHigh" },
"commonLabels": { "alertname": "ReplicationLagHigh", "severity": "warning" },
"commonAnnotations": { "summary": "Replica set rs0 lag exceeds 10 seconds" },
"externalURL": "http://alertmanager:9093",
"alerts": [
{
"status": "firing",
"labels": { "alertname": "ReplicationLagHigh", "rs": "rs0", "severity": "warning" },
"annotations": { "summary": "Replica set rs0 lag exceeds 10 seconds" },
"startsAt": "2026-10-28T02:15:00.000Z",
"endsAt": "0001-01-01T00:00:00Z",
"generatorURL": "http://prometheus:9090/graph?g0.expr=...",
"fingerprint": "a1b2c3d4e5f6"
}
]
}
Return a success status as soon as you've received the request, and do slow processing in the background, so a timeout isn't counted as a failed delivery.
Because of grouping, one request's alerts array can hold several entries. Iterate over the array rather than reading only the first.
With send_resolved on, recovery notices arrive with status: resolved, which you can use to close tickets automatically.
The same alert can be delivered more than once. Use fingerprint and groupKey to deduplicate and avoid creating duplicate tickets.
On the Prometheus stack, the time from "something goes wrong" to "you get notified" is the combined effect of several settings. Understanding them is how you tune the sensitivity you actually want.
for — the largest share, and the key to filtering out momentary blips.Rules have moved from built-in platform thresholds to PromQL expressions. Don't copy numbers over blindly — check them against your own cluster's historical baseline first.
Grouping, inhibition and routing all depend on labels. Agree on conventions such as cluster and severity early, and the governance rules become easy to write.
If you keep your existing alerts, run old and new side by side for a period, compare what each fires, and cut over once you're sure nothing is missing.
The 15 seconds, 2 minutes and 30 seconds in the chart are illustrative values chosen to show the composition — they are not WAP defaults. Use the official Prometheus and Alertmanager documentation for what each setting means, and adjust to your own needs.
Standard components underneath, open interfaces outside. Whether you want to use WAP directly or plug it into your own platform, there's a path for you.