Service performance issues often turn out to be the result of slow database queries. With Pixie, you can easily monitor the performance of your database requests to ensure they do not impact service health.
MySQL requests are featured in this tutorial, but Pixie can trace a number of different database protocols including Cassandra, PostgreSQL, and Redis. See the full list here.
This tutorial will demonstrate how to use Pixie to monitor MySQL:
You will need a Kubernetes cluster with Pixie installed. If you do not have a cluster, you can create a minikube cluster and install Pixie using one of our install guides.
You will need to install the demo microservices application, using Pixie's CLI:
To see MySQL latency, error, and throughput rate for all pods in your cluster, we’ll use the
This script shows latency, error and throughput over time for all MySQL requests in the cluster.
Let’s use the optional
podscript input argument to filter to a particular pod.
px-sock-shop/catalogue, and press Enter to re-run the script.
The graph should update to show stats just for the requests made to/from the
podvalue by selecting the drop-down arrow and pressing Enter.
Pixie can automatically cluster your SQL queries so that you can analyze similar queries as a single group.
For example, the following two queries:
SELECT * FROM Socks WHERE Socks.Color ='Green'
SELECT * FROM Socks WHERE Socks.Color ='Blue'
would be clustered together into the normalized query:
SELECT * FROM Socks WHERE Socks.Color =?
A normalized query means that constants, such as a sock color, have been replaced with placeholders.
Let's see this feature in action for our demo application:
This live view calculates the latency, error, and throughput over time for each normalized SQL query.
Let's examine one of the normalized SQL queries.
For longer queries, it's often easier to view the data in JSON form.
>that appears to expand the row.
Inspect the query and you'll see that the
sock_idvalues have been replaced with the
>to close the row.
Next, let's view latency, error and throughput for the constants passed to this normalized query.
>, click the actual query text (
SELECT sock.sock_id AS...) for the same row.
This script shows latency, error, and throughput for each individual parameter for the given normalized SQL query.
The Summary table shows the individual parameters passed to
sock_idin the normalized query.
Pixie captures all network traffic that passes through your cluster (it supports both server and client-side tracing). For supported protocols, this traffic is parsed into messages that are paired with their responses.
Let's inspect the most recent MySQL requests flowing through your cluster, including the full request and response bodies.
scriptdrop-down menu at the top of the page.
This script shows the most recent MySQL requests flowing through your cluster, including the full request and response bodies.
Pixie is able capture any request that flows through the cluster, as long as at least one endpoint is within the cluster.
For requests with longer message bodies, it's often easier to view the data in JSON form.
Click on a table row to see the row data in JSON format. Scroll through the JSON data to find the
Click the table row again to collapse the JSON view.
Scroll to the last column of the table to see latency data for the individual requests.
Click on the
LATENCY column title to sort the table by descending latency.
This tutorial demonstrated a few of Pixie's community scripts. For more insight into your database queries, check out the following scripts.
px/pgsql_datashows the most recent Postgres requests in the cluster.
px/pgsql_statsshows latency, error, and throughput rate for a pod's PostgreSQL requests.
px/pgsql_flow_graphshows a graph of the PostgreSQL messages in the cluster with latency stats.
px/redis_datashows the most recent Redis requests in the cluster.
px/redis_statsshows latency, error, and throughput rate for a pod's Redis requests.
px/redis_flow_graphshows a graph of the Redis messages in the cluster with latency stats.