Drop-in Prometheus configuration for a Switchyard deployment. Pair with
docs/internal/metrics_reference.md for the
full metric inventory and label semantics.
| File | Purpose |
|---|---|
prometheus.yml |
A single scrape_configs: entry to merge into your existing Prometheus config. Targets Switchyard's /metrics. |
switchyard.rules.yaml |
Alert rule group implementing the operational and success-criterion alerts. Validates with promtool check rules. |
A Grafana dashboard is intentionally not included — dashboard authoring
belongs to whichever team owns observability conventions in your
deployment. The metric catalog in docs/internal/metrics_reference.md is the
input.
Merge the scrape_configs: entry from prometheus.yml into your
Prometheus configuration (adjust the targets: list to point at your
Switchyard pods or hosts). The endpoint is plain GET /metrics over
HTTP, no auth.
If you're running Switchyard on Kubernetes, the example scrape job uses
static targets; a kubernetes_sd_configs variant is a one-step swap for
cluster-native discovery.
cp switchyard.rules.yaml /etc/prometheus/rules/
promtool check rules /etc/prometheus/rules/switchyard.rules.yamlThen reference the file in your Prometheus config's rule_files:
section and reload:
rule_files:
- /etc/prometheus/rules/switchyard.rules.yamlcurl -X POST http://<prometheus>:9090/-/reloadOnce Prometheus has scraped a few cycles, sanity-check the active series:
{__name__=~"switchyard_.*"}
You should see the families documented in metrics_reference.md —
top-line gauges, per-endpoint counters and histograms, and outcome counters.
Default thresholds and for: windows in switchyard.rules.yaml are
conservative — tuned to avoid pages during routine scrape-config rolls
or single-poll blips. Review them against your SLOs before enabling
notifications:
RouterOverheadHighis set at the success-criterion threshold (p99 > 1 ms for 5 m). Check itsalgorithmlabel and/v1/statsclassifier traffic before treating it as a routing-decision regression.