Question

基于 Kubernetes 环境部署的 TiDB 集群监控可以大体分为两个部分：对 TiDB 集群本身的监控、对 Kubernetes 集群及 TiDB Operator 的监控。本文将对两者进行简要说明。

TiDB 集群的监控

TiDB 通过 Prometheus 和 Grafana 监控 TiDB 集群。在通过 TiDB Operator 创建新的 TiDB 集群时，可以参考通过 TidbMonitor 监控 TiDB 集群，对于每个 TiDB 集群，创建、配置一套独立的监控系统，与 TiDB 集群运行在同一 Namespace，包括 Prometheus 和 Grafana 两个组件。

可以在 TidbMonitor 中设置 spec.persistent 为 true 来持久化监控数据。开启此选项时应将 spec.storageClassName 设置为一个当前集群中已有的存储，并且此存储应当支持将数据持久化，否则会存在数据丢失的风险。

在 TiDB 集群监控中有一些监控系统配置的细节可供参考。

查看监控面板

可以通过 kubectl port-forward 查看监控面板：

kubectl port-forward -n ${namespace} svc/${cluster_name}-grafana 3000:3000 &>/tmp/portforward-grafana.log &

然后在浏览器中打开 http://localhost:3000，默认用户名和密码都为 admin。

也可以参考通过 TidbMonitor 监控 TiDB 集群，设置 spec.grafana.service.type 为 NodePort 或者 LoadBalancer，通过 NodePort 或者 LoadBalancer 查看监控面板。

如果不需要使用 Grafana，可以在部署时将 TidbMonitor 中的 spec.grafana 部分删除。这一情况下需要使用其他已有或新部署的数据可视化工具直接访问监控数据来完成可视化。

访问监控数据

对于需要直接访问监控数据的情况，可以通过 kubectl port-forward 来访问 Prometheus：

kubectl port-forward -n ${namespace} svc/${cluster_name}-prometheus 9090:9090 &>/tmp/portforward-prometheus.log &

然后在浏览器中打开 http://localhost:9090，或通过客户端工具访问此地址即可。

也可以参考通过 TidbMonitor 监控 TiDB 集群，设置 spec.prometheus.service.type 为 NodePort 或者 LoadBalancer，通过 NodePort 或者 LoadBalancer 访问监控数据。

Kubernetes 的监控

随集群部署的 TiDB 监控只关注 TiDB 本身各组件的运行情况，并不包括对容器资源、宿主机、Kubernetes 组件和 TiDB Operator 等的监控。对于这些组件或资源的监控，需要在整个 Kubernetes 集群维度部署监控系统来实现。

宿主机监控

对宿主机及其资源的监控与传统的服务器物理资源监控相同。

如果在你的现有基础设施中已经有针对物理服务器的监控系统，只需要通过常规方法将 Kubernetes 所在的宿主机添加到现有监控系统中即可；如果没有可用的监控系统，或者希望部署一套独立的监控系统用于监控 Kubernetes 所在的宿主机，也可以使用你熟悉的任意监控系统。

新部署的监控系统可以运行于独立的服务器、直接运行于 Kubernetes 所在的宿主机，或运行于 Kubernetes 集群内，不同部署方式除在安装配置与资源利用上存在少许差异，在使用上并没有重大区别。

常见的可用于监控服务器资源的开源监控系统有：

• CollectD
• Nagios
• Prometheus & node_exporter
• Zabbix

一些云服务商或专门的性能监控服务提供商也有各自的免费或收费的监控解决方案可以选择。

我们推荐通过 Prometheus Operator 在 Kubernetes 集群内部署基于 Node Exporter 和 Prometheus 的宿主机监控系统，这一方案同时可以兼容并用于 Kubernetes 自身组件的监控。

Kubernetes 组件监控

对 Kubernetes 组件的监控可以参考官方文档提供的方案，也可以使用其他兼容 Kubernetes 的监控系统来进行。

一些云服务商可能提供了自己的 Kubernetes 组件监控方案，一些专门的性能监控服务商也有各自的 Kubernetes 集成方案可以选择。

由于 TiDB Operator 实际上是运行于 Kubernetes 中的容器，选择任一可以覆盖对 Kubernetes 容器状态及资源进行监控的监控系统即可覆盖对 TiDB Operator 的监控，无需再额外部署监控组件。

我们推荐通过 Prometheus Operator 部署基于 Node Exporter 和 Prometheus 的宿主机监控系统，这一方案同时可以兼容并用于对宿主机资源的监控。

报警配置

TiDB 集群报警

在随 TiDB 集群部署 Prometheus 时，会自动导入一些默认的报警规则，可以通过浏览器访问 Prometheus 的 Alerts 页面查看当前系统中的所有报警规则和状态。

我们目前支持报警规则的自定义配置，可以参考下面步骤修改报警规则：

1. 参考通过 TidbMonitor 监控 TiDB 集群，在为 TiDB 集群部署监控的过程中，设置 spec.reloader.service.type 为 NodePort 或者 LoadBalancer。
2. 通过 NodePort 或者 LoadBalancer 访问 reloader 服务，点击上方 Files 选择要修改的报警规则文件进行修改，修改完成后 Save。

默认的 Prometheus 和报警配置不能发送报警消息，如需发送报警消息，可以使用任意支持 Prometheus 报警的工具与其集成。推荐通过 AlertManager 管理与发送报警消息。

如果在你的现有基础设施中已经有可用的 AlertManager 服务，可以参考设置 kube-prometheus 与 AlertManager 设置 spec.alertmanagerURL 配置其地址供 Prometheus 使用；如果没有可用的 AlertManager 服务，或者希望部署一套独立的服务，可以参考官方的说明部署。

Kubernetes 报警

如果使用 Prometheus Operator 部署针对 Kubernetes 宿主机和服务的监控，会默认配置一些告警规则，并且会部署一个 AlertManager 服务，具体的设置方法请参阅 kube-prometheus 的说明。

如果使用其他的工具或服务对 Kubernetes 宿主机和服务进行监控，请查阅该工具或服务提供商的对应资料。