--- title: Observability --- # Observability ## Resources * [Prometheus](https://prometheus.io/) * [Grafana](https://grafana.com/) ### Transcript If you come from a MySQL background, the built-in system for observability is `performance_schema`. There are some secondary observability commands, but in recent MySQL releases, this has become the gold standard. Performance Schema is implemented as a storage engine inside of MySQL. Recent MySQL servers are very well instrumented with Performance Schema too: any time the server is allocating memory, waiting on locks or performing I/O: you can query that with regular SQL and find out! There are a couple of quick drawbacks to it: Performance Schema uses memory, so metrics collected will be lost after server restart. The history retention is also limited, so on a busy server, some key metrics will be cycled out after a few minutes of activity. TiDB does not use `performance_schema`, and not withstanding what was just mentioned, the real key reason is *because* TiDB is a distributed system. Having only a single-server's metrics in isolation is not always enough to observe _the running system_. And thus, TiDB servers send their metrics to a centralized database that is specifically designed for metrics collection. I am of course talking about Prometheus. If you are not yet familiar with Prometheus, it is a popular tool that along with Kubernetes and TiKV is part of the Cloud Native Compute Foundation projects. It is often used in combination with Grafana, which adds a layer of dashboards on top. All of the TiDB Platform components support Prometheus integration, and when you deploy the TiDB Platform with TiDB Operator, they will also be installed and configured out of the box. We even provide built-in Grafana charts. So in our lab, we will be logging into Grafana and observing key metrics about our TiDB Platform while we are performing operations.