Sample Vespa Console dashboard

The Vespa Cloud Console has dashboards for insight into performance metrics, use the "monitoring" tab for the zone deployment.

These metrics can also be pulled into external monitoring tools either in native Vespa format or Prometheus. See the Vespa metrics documentation.

Vespa Metrics API

Metrics can be pulled from $ENDPOINT/metrics/v2/values:

$ curl -s --cert data-plane-public-cert.pem --key data-plane-private-key.pem \

Example: use jq to extract relevant metrics:

$ curl -s --cert data-plane-public-cert.pem --key data-plane-private-key.pem \ | \
  jq -r -c '
    .nodes[] |
    .hostname as $h |
    select(.role | test("content/documentation/.*/stateful")) |
    .services[].metrics[] |
    select(.values."") |
    [$h, .dimensions.documenttype, .values.""] |
    @tsv'	doc	432	purchase	20	term	93003	doc	432	purchase	20	term	93003

Prometheus metrics API

Prometheus metrics are found at $ENDPOINT/prometheus/v1/values:

$ curl -s --cert data-plane-public-cert.pem --key data-plane-private-key.pem \

Using Grafana

This section explains how to set up Grafana to consume Vespa metrics using the Prometheus API.

1. Prometheus configuration

Prometheus is configured using prometheus.yml, find sample config in prometheus. See prometheus-cloud.yml, which is designed to be easy to set up with any Vespa Cloud instance. Replace <Endpoint> and <SERVICE_NAME> with the endpoint for the application and the service name, respectively. In addition, the path to the private key and public cert that is used for the data plane to the endpoint need to be provided - refer to security. Then, configure the Prometheus instance to use this configuration file. The Prometheus instance will now start retrieving the metrics from Vespa Cloud. If the Prometheus instance is used for multiple services, append the target configuration for Vespa to scrape_configs.

2. Grafana configuration

Use the provisioning folder as a baseline for further configuration.

In the provisioning folder there are a few different files that all help for configuring Grafana locally. These work as good examples of default configurations, but the most important is the file named Vespa-Engine-Advanced-Metrics-External.json. This is a default dashboard, based upon the metrics the Vespa team use to monitor performance.

Click the + button on the side and go to import. Upload the file to the Grafana instance. This should automatically load in the dashboard for usage. For now, it will not display any data as no data sources are configured yet.

3. Grafana Data Source

The Prometheus data source has to be added to the Grafana instance for the visualisation. Click the cog on the left and then "Data Sources". Click "Add data source" and choose Prometheus from the list. Add the URL for the Prometheus instance with appropriate bindings for connecting. The configuration for the bindings will depend on how the Prometheus instance is hosted. Once the configuration details have been entered, click Save & Test at the bottom and ensure that Grafana says "Data source is working".

To verify the data flow, navigate back to the Vespa Metrics dashboard by clicking the dashboard symbol on the left (4 blocks) and clicking manage and then click Vespa Metrics. Data should now appear in the Grafana dashboard. If no data shows up, edit one of the data sets and ensure that it has the right data source selected. The name of the data source the dashboard is expecting might be different from what your data source is named. If there is still no data appearing, it either means that the Vespa instance is not being used or that some part of the configuration is wrong.

Using AWS Cloudwatch

To pull metrics from your Vespa application into AWS Cloudwatch, refer to the metrics-emitter documentation for how to set up an AWS Lambda.


The Vespa Grafana Terraform template provides a set of dashboards and alerts. If you are using a different monitoring service and want to set up an equivalent alert set, you can follow this table:

Metric name Threshold Dimension aggregation
content_proton_resource_usage_disk_average > 0.9 max by(applicationId, clusterId, zone)
content_proton_resource_usage_memory_average > 0.8 max by(applicationId, zone, clusterId)
cpu_util > 90 max by(applicationId, zone, clusterId)
content_proton_resource_usage_feeding_blocked_last >= 1 N/A
All metrics are from the default metric set. Metrics are using the naming scheme from the Prometheus metrics API. Dimension aggregation is optional, but reduces alerting noise - e.g. in the case where an entire cluster goes bad. It is recommended to filter all alerts on zones in the prod environment.