Monitoring with Grafana

Grafana is the most common way to turn the numbers from Zato's Prometheus endpoint into dashboards - request rates, latencies, error breakdowns and everything else the platform measures, on one screen that the whole team looks at.

The setup has two parts, and the first one is shared with every other monitoring tool - a Prometheus-compatible scraper collects metrics from Zato, and Grafana queries what the scraper collected. If you have not connected a scraper yet, do that first with the Prometheus guide, it takes about 15 minutes.

Self-hosted Grafana

With your own Grafana and your own Prometheus server, the whole integration is one data source:

• In Grafana, go to Connections -> Data sources and add a Prometheus data source
• Point it at your Prometheus server's address, e.g. http://prometheus:9090
• Click Save and test

That is all - every query from the Prometheus guide now works in Grafana panels.

Grafana Cloud

With Grafana Cloud, there is no Prometheus server of your own to run - Grafana Cloud hosts one for you and its collector ships metrics into it. From your Grafana Cloud portal, open the Prometheus service to find the connection details:

The collector - Grafana Alloy - scrapes Zato's /metrics endpoint like any Prometheus would and remote-writes the samples to your cloud stack. The scrape configuration is the same as in the Prometheus guide, plus the remote write block with the URL and credentials from the portal:

prometheus.scrape "zato" {
  targets = [{"__address__" = "zato-server:11223"}]

  metrics_path    = "/metrics"
  scrape_interval = "15s"

  basic_auth {
    username = "metrics"
    password = "your-zato-metrics-password"
  }

  forward_to = [prometheus.remote_write.grafana_cloud.receiver]
}

prometheus.remote_write "grafana_cloud" {
  endpoint {
    url = "https://prometheus-prod-01-eu-west-0.grafana.net/api/prom/push"

    basic_auth {
      username = "123456"
      password = "your-grafana-cloud-token"
    }
  }
}

Once samples arrive, confirm the connection by querying any Zato metric:

Building the dashboard

Create a new dashboard and add panels with the queries you already know. The four below make a complete first screen:

Request rate per channel - a time series panel:

sum by (channel_name) (rate(zato_rest_channel_requests_total[5m]))

p99 latency per channel - a time series panel, with the unit set to seconds:

histogram_quantile(0.99,
  sum by (channel_name, le) (rate(zato_rest_channel_request_duration_seconds_bucket[5m]))
)

Error ratio - a stat panel with thresholds, green below 1%, red above:

sum(rate(zato_rest_channel_requests_total{status_code=~"4xx|5xx"}[5m]))
  /
sum(rate(zato_rest_channel_requests_total[5m]))

Who caused the errors - a time series panel split by the error_source label, which tells you directly whether a spike came from your services, from an external system they call, from authentication or from rate limiting:

sum by (error_source) (rate(zato_rest_channel_requests_total{error_source!="none"}[5m]))

Beyond REST channels, the same pattern extends to everything else the endpoint exposes - service invocations, outgoing connections, pub/sub throughput and scheduler job outcomes. The metric reference lists every metric with its labels and example queries.

Alerting

Grafana's alert rules work on the same queries - the burn-rate SLO alert from the Prometheus guide can be pasted into a Grafana alert rule as it is. Alerts can also stay inside the platform entirely, with the built-in alerting engine and its delivery by email, Slack, Microsoft Teams or webhooks.

Learn more