Skip to main content
While this tutorial is written for New Relic, using Prometheus’ remote write is a common pattern for sending metrics to AWS Managed Prometheus, Google Cloud Managed Service for Prometheus, Grafana hosted Prometheus and many other tools. For more information on Prometheus Remote Write and New Relic, see the New Relic documentation on sending Prometheus metric data.

Overview

In this tutorial, we will be using an instance of Prometheus running on a Linux VM to scrape metrics from PlanetScale and then forward them to New Relic using Remote Write. We will make sure that Prometheus stays running by creating a Systemd Unit File. The default configuration we will create will send all PlanetScale metrics to New Relic, and we will cover how to filter to drop certain metrics that may not be desired. In order to proceed, you’ll need:

Prometheus Installation

First, let’s download the latest release of Prometheus and create our user that is going to run it. We’ll be using the latest 3.x release from the GitHub Releases Page. Create a prometheus user:
This has put the Prometheus binary in /opt/prometheus along with the example configuration file that we can use.

Create our Systemd Unit File

Now that we have the binary in place, let’s setup Systemd to run Prometheus by creating a Unit File in /etc/systemd/system/prometheus.service with the following contents:

Configure Prometheus

Now that we’ve got Prometheus installed and a unit file present, let’s configure Prometheus. We will be borrowing some of our configuration from the Prometheus Guide, and adding some New Relic specific configuration. Edit /opt/prometheus/prometheus.yml in your editor of choice so that it contains this, making sure to replace your org name, service token information, and New Relic API key:
This configuration file does the following:
  • Configures Prometheus to discover scraping endpoints from the PlanetScale API using a service token
  • Points Prometheus to write the metrics it scrapes from PlanetScale to the New Relic API

Starting Prometheus

Now that we have a Systemd unit file and a configured Prometheus, let’s run it!
We can also tell Systemd to run Prometheus when my VM boots:
Now, let’s check to make sure everything is running properly:
This reports that prometheus is active (running), and I can see the logs showing that it started successfully. Great!

Querying on New Relic

After a couple of minutes, head over to your New Relic dashboard and we can query for your database metrics. First, let’s get a list of the database branches in the nick organization that I’m using to test:
For this, we’ll use the 7wxuxewx4l0p branch. Using New Relic’s NRQL, we can visualize the memory usage of my VTTablet instances with the following query:
Because my main branch is production, we will see the memory usage for my primary and both my replicas over the last 30 minutes:
New Relic Memory Query

Filtering Metrics

If you don’t want to ingest every metric into New Relic, you can tell Prometheus to drop certain metrics. For more information, see the New Relic Documentation. If we adjust our Prometheus configuration that we have in /opt/prometheus/prometheus.yml we can instruct Prometheus to drop all metrics unless they match a certain naming convention:
If you replace your remote_write block with what’s above, Prometheus will only forward the timeseries that match the planetscale_pods_* name. For a full list of metrics, see our Metric List.

What’s Next?

Now that you have your branch metrics in New Relic, you can create dashboards and alerts for conditions such as high CPU or replication delay.

Need help?

Get help from the PlanetScale Support team, or join our Discord community to see how others are using PlanetScale.