> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

> You can monitor the utilization of hardware resources and also ClickHouse server metrics.

# Monitoring

export const Image = ({img, alt, size = "lg"}) => {
  const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
  return <div className={`ch-image-${normalizedSize}`}>
      <Frame>
        <img src={img} alt={alt} />
      </Frame>
    </div>;
};

<Note>
  The monitoring data outlined in this guide is accessible in ClickHouse Cloud. In addition to being displayed through the built-in dashboard described below, both basic and advanced performance metrics can also be viewed directly in the main service console.
</Note>

You can monitor:

* Utilization of hardware resources.
* ClickHouse server metrics.

<h2 id="built-in-advanced-observability-dashboard">
  Built-in advanced observability dashboard
</h2>

<Image img="https://mintcdn.com/private-7c7dfe99/flZ-Iruiim7eBp5N/images/cloud/manage/monitoring/native_advanced_dashboard.webp?fit=max&auto=format&n=flZ-Iruiim7eBp5N&q=85&s=8218d61b77c6d7e7f6398872def6a423" alt="Native advanced observability dashboard" size="md" width="1600" height="870" data-path="images/cloud/manage/monitoring/native_advanced_dashboard.webp" />

ClickHouse comes with a built-in advanced observability dashboard feature which can be accessed by `$HOST:$PORT/dashboard` (requires user and password) that shows the following metrics:

* Queries/second
* CPU usage (cores)
* Queries running
* Merges running
* Selected bytes/second
* IO wait
* CPU wait
* OS CPU Usage (userspace)
* OS CPU Usage (kernel)
* Read from disk
* Read from filesystem
* Memory (tracked)
* Inserted rows/second
* Total MergeTree parts
* Max parts for partition

<h2 id="resource-utilization">
  Resource utilization
</h2>

ClickHouse also monitors the state of hardware resources by itself such as:

* Load and temperature on processors.
* Utilization of storage system, RAM and network.

This data is collected in the `system.asynchronous_metric_log` table.

<h2 id="clickhouse-server-metrics">
  ClickHouse server metrics
</h2>

ClickHouse server has embedded instruments for self-state monitoring.

To track server events use server logs. See the [logger](/docs/reference/settings/server-settings/settings/other#logger) section of the configuration file.

ClickHouse collects:

* Different metrics of how the server uses computational resources.
* Common statistics on query processing.

You can find metrics in the [system.metrics](/docs/reference/system-tables/metrics), [system.events](/docs/reference/system-tables/events), and [system.asynchronous\_metrics](/docs/reference/system-tables/asynchronous_metrics) tables.

You can configure ClickHouse to export metrics to [Graphite](https://github.com/graphite-project). See the [Graphite section](/docs/reference/settings/server-settings/settings/graphite#graphite) in the ClickHouse server configuration file. Before configuring export of metrics, you should set up Graphite by following their official [guide](https://graphite.readthedocs.io/en/latest/install.html).

You can configure ClickHouse to export metrics to [Prometheus](https://prometheus.io). See the [Prometheus section](/docs/reference/settings/server-settings/settings/other#prometheus) in the ClickHouse server configuration file. Before configuring export of metrics, you should set up Prometheus by following their official [guide](https://prometheus.io/docs/prometheus/latest/installation/).

Additionally, you can monitor server availability through the HTTP API. Send the `HTTP GET` request to `/ping`. If the server is available, it responds with `200 OK`.

To monitor servers in a cluster configuration, you should set the [max\_replica\_delay\_for\_distributed\_queries](/docs/reference/settings/session-settings/max#max_replica_delay_for_distributed_queries) parameter and use the HTTP resource `/replicas_status`. A request to `/replicas_status` returns `200 OK` if the replica is available and is not delayed behind the other replicas. If a replica is delayed, it returns `503 HTTP_SERVICE_UNAVAILABLE` with information about the gap.