tidb教程FG111-TiDB监控与告警系统

本文档详细介绍TiDB监控与告警系统，包括监控架构、告警策略、Prometheus配置、Grafana仪表盘等内容。风哥教程参考TiDB官方文档监控指南、Prometheus官方文档等内容，适合DBA进行TiDB集群监控和故障排查。

Part01-基础概念与理论知识

1.1 监控系统概述

TiDB监控系统基于Prometheus和Grafana构建，提供全方位的集群状态监控。监控系统是保证TiDB稳定运行的重要组成部分。

TiDB监控系统特点：

基于Prometheus时序数据库
使用Grafana可视化仪表盘
支持AlertManager告警管理
提供丰富的监控指标
支持自定义监控和告警

1.2 告警系统概述

TiDB告警系统基于AlertManager，提供多渠道告警通知，包括邮件、短信、企业微信等。告警系统可以及时发现和处理集群异常。

# 告警系统组成

# 1. 告警源
# – Prometheus告警规则
# – 自定义告警脚本
# – 第三方监控工具

# 2. 告警管理
# – AlertManager：管理告警、去重、分组、路由
# – 告警静默：临时抑制告警
# – 告警分组：将相关告警分组处理

# 3. 告警通知
# – 邮件通知
# – 短信通知
# – 企业微信通知
# – Slack通知
# – PagerDuty集成

# 4. 告警级别
# – 紧急（Critical）：需要立即处理
# – 警告（Warning）：需要关注
# – 信息（Info）：仅供参考

# 5. 告警生命周期
# – 触发（Firing）：告警被触发
# – 解决（Resolved）：问题已解决
# – 静默（Silenced）：临时抑制
# – 失效（Inactive）：告警规则不再匹配

1.3 监控指标体系

TiDB监控指标体系包括：PD、TiKV、TiDB、TiFlash等组件的各项指标，覆盖性能、可用性、资源使用等多个维度。

风哥提示：监控系统是数据库运维的眼睛，建立完善的监控体系可以提前发现问题，避免故障发生。建议配置全面的监控指标和合理的告警策略。更多视频教程www.fgedu.net.cn

Part02-生产环境规划与建议

2.1 监控架构设计

# 监控架构设计

# 1. 监控层次
# – 基础设施监控：CPU、内存、磁盘、网络
# – 数据库组件监控：PD、TiKV、TiDB、TiFlash
# – 业务监控：QPS、响应时间、错误率

# 2. 监控部署架构
# – 单节点部署：适用于测试环境
# – 高可用部署：适用于生产环境
# – Prometheus高可用
# – Grafana高可用
# – AlertManager高可用

# 3. 监控数据流向
# 数据源 → Prometheus → AlertManager → 通知渠道
# 数据源 → Prometheus → Grafana → 可视化

# 4. 监控组件部署位置
# – 独立服务器：避免影响数据库性能
# – 与数据库同机房：减少网络延迟
# – 跨地域部署：实现异地监控

# 5. 监控系统规模
# – 小规模集群（< 10节点）：单Prometheus实例 # - 中规模集群（10-50节点）：Prometheus分片 # - 大规模集群（> 50节点）：Prometheus联邦集群

# 6. 监控系统配置
# – 采样频率：15-30秒
# – 数据保留：15-30天
# – 存储配置：根据数据量调整
# – 内存配置：根据监控规模调整

2.2 告警策略设计

# 告警策略设计

# 1. 告警分级
# – P0（紧急）：系统不可用，需要立即处理
# – P1（高）：核心功能受影响，4小时内处理
# – P2（中）：性能下降，24小时内处理
# – P3（低）：潜在问题，一周内处理

# 2. 告警规则设计原则
# – 准确性：减少误报
# – 及时性：及时发现问题
# – 可操作性：告警信息清晰明确
# – 分级合理：根据影响程度分级

# 3. 关键告警规则
# – PD告警：集群状态、 leader选举
# – TiKV告警：存储容量、副本状态、性能
# – TiDB告警：连接数、查询性能、错误率
# – TiFlash告警：同步状态、存储容量

# 4. 告警通知策略
# – P0/P1：多渠道通知（邮件+短信+企业微信）
# – P2：邮件通知
# – P3：仅记录，不通知

# 5. 告警抑制策略
# – 主从告警：当主告警触发时，抑制相关从告警
# – 时间抑制：短时间内相同告警只通知一次
# – 维护抑制：维护期间抑制非关键告警

# 6. 告警演练
# 定期测试告警系统
# 确保告警渠道畅通
# 验证告警处理流程

2.3 监控数据存储规划

# 监控数据存储规划

# 1. 存储需求计算
# 计算公式：存储容量 = 节点数 × 指标数 × 采样频率 × 保留时间
# 示例：
# – 10节点TiDB集群
# – 每个节点1000个指标
# – 采样频率30秒
# – 保留30天风哥提示：
# – 存储需求 ≈ 10 × 1000 × 2880 × 30 × 100字节 = 864GB

# 2. 存储方案
# – 本地存储：适用于小规模集群
# – 网络存储：适用于中规模集群
# – 对象存储：适用于大规模集群

# 3. 存储优化
# – 数据压缩：启用Prometheus压缩
# – 数据降采样：长期数据降采样
# – 数据分区：按时间分区
# – 存储策略：热数据本地存储，冷数据迁移到对象存储

# 4. 高可用存储
# – 本地存储+备份
# – 网络存储+冗余
# – 对象存储+多副本

# 5. 备份策略
# – 监控数据备份：每日备份
# – 备份保留：与监控数据保留一致
# – 备份验证：定期验证备份可用性

# 6. 存储监控
# – 监控存储使用率
# – 设置存储容量告警
# – 预测存储增长趋势

生产环境建议：监控系统应独立部署，避免与数据库集群争用资源。建议使用SSD存储以提高Prometheus性能，确保监控数据的可靠性和查询速度。学习交流加群风哥微信: itpux-com

Part03-生产环境项目实施方案

3.1 Prometheus部署与配置

3.1.1 部署Prometheus

# 部署Prometheus

# 1. 使用TiUP部署
[root@fgedu.net.cn ~]# tiup cluster deploy fgedudb-monitor v7.5.0 /tidb/monitor –topology monitor-topology.yaml

# 监控拓扑配置示例
cat > monitor-topology.yaml << EOF global: user: "tidb" ssh_port: 22 deploy_dir: "/tidb/monitor" data_dir: "/tidb/monitor/data" monitors: - host: 192.168.1.20 ssh_port: 22 port: 9090 dashboard_port: 3000 alertmanager_port: 9093 blackbox_exporter_port: 9115 node_exporter_port: 9100 EOF # 2. 启动监控集群 [root@fgedu.net.cn ~]# tiup cluster start fgedudb-monitor # 3. 检查Prometheus状态 [root@fgedu.net.cn ~]# curl http://192.168.1.20:9090/metrics # 4. 配置Prometheus抓取目标 # 编辑prometheus.yml cat > /tidb/monitor/prometheus/prometheus.yml << EOF global: scrape_interval: 15s evaluation_interval: 15s alerting: alertmanagers: - static_configs: - targets: ['192.168.1.20:9093'] rule_files: - "rules/*.yml" scrape_configs: - job_name: 'tidb' static_configs: - targets: ['192.168.1.13:10080', '192.168.1.14:10080'] - job_name: 'tikv' static_configs: - targets: ['192.168.1.10:20180', '192.168.1.11:20180', '192.168.1.12:20180'] - job_name: 'pd' static_configs: - targets: ['192.168.1.10:2379', '192.168.1.11:2379', '192.168.1.12:2379'] - job_name: 'tiflash' static_configs: - targets: ['192.168.1.15:20290'] - job_name: 'node' static_configs: - targets: ['192.168.1.10:9100', '192.168.1.11:9100', '192.168.1.12:9100', '192.168.1.13:9100', '192.168.1.14:9100', '192.168.1.15:9100'] EOF # 5. 重启Prometheus [root@fgedu.net.cn ~]# systemctl restart prometheus 学习交流加群风哥QQ113257174 # 6. 验证抓取状态 # 访问Prometheus UI：http://192.168.1.20:9090/targets # 输出示例 # 状态：UP # 目标： # - tidb: 192.168.1.13:10080 (UP) # - tidb: 192.168.1.14:10080 (UP) # - tikv: 192.168.1.10:20180 (UP) # - tikv: 192.168.1.11:20180 (UP) # - tikv: 192.168.1.12:20180 (UP) # - pd: 192.168.1.10:2379 (UP) # - pd: 192.168.1.11:2379 (UP) # - pd: 192.168.1.12:2379 (UP) # - tiflash: 192.168.1.15:20290 (UP) # - node: 192.168.1.10:9100 (UP) # - node: 192.168.1.11:9100 (UP) # - node: 192.168.1.12:9100 (UP) # - node: 192.168.1.13:9100 (UP) # - node: 192.168.1.14:9100 (UP) # - node: 192.168.1.15:9100 (UP)

3.1.2 配置Prometheus告警规则

# 配置Prometheus告警规则

# 1. 创建告警规则文件
cat > /tidb/monitor/prometheus/rules/tidb-alerts.yml << EOF groups: - name: tidb-alerts rules: # TiDB告警 - alert: TiDBServerDown expr: up{job="tidb"} == 0 for: 5m labels: severity: critical annotations: summary: "TiDB服务器宕机" description: "TiDB服务器 {{ $labels.instance }} 已宕机超过5分钟" - alert: TiDBHighConnectionCount expr: tidb_server_connection_count > 5000
for: 5m
labels:
severity: warning
annotations:
summary: “TiDB连接数过高”
description: “TiDB服务器 {{ $labels.instance }} 连接数超过5000，当前值: {{ $value }}”

# TiKV告警
– alert: TiKVServerDown
expr: up{job=”tikv”} == 0
for: 5m
labels:
severity: critical
annotations:
summary: “TiKV服务器宕机”
description: “TiKV服务器 {{ $labels.instance }} 已宕机超过5分钟”

– alert: TiKVHighDiskUsage
expr: (tikv_store_size / tikv_store_capacity) * 100 > 80
for: 10m
labels:
severity: warning
annotations:
summary: “TiKV磁盘使用率过高”
description: “TiKV服务器 {{ $labels.instance }} 磁盘使用率超过80%，当前值: {{ $value | humanizePercentage }}”

# PD告警
– alert: PDServerDown
expr: up{job=”pd”} == 0
for: 5m
labels:
severity: critical
annotations:
summary: “PD服务器宕机”
description: “PD服务器 {{ $labels.instance }} 已宕机超过5分钟”

– alert: PDFewerThanHalfReplicas
expr: count(up{job=”pd”}) < (count by (cluster) (up{job="pd"}) / 2) for: 5m labels: severity: critical annotations: summary: "PD集群副本数不足" description: "PD集群副本数少于半数，当前值: {{ $value }}" # 节点告警 - alert: NodeHighCPUUsage expr: (100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 80
for: 10m
labels:
severity: warning
annotations:
summary: “节点CPU使用率过高”
description: “节点 {{ $labels.instance }} CPU使用率超过80%，当前值: {{ $value | humanizePercentage }}”

– alert: NodeHighMemoryUsage
expr: (node_memory_MemTotal_bytes – node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 80
for: 10m
labels:
severity: warning
annotations:
summary: “节点内存使用率过高”
description: “节点 {{ $labels.instance }} 内存使用率超过80%，当前值: {{ $value | humanizePercentage }}”
EOF

# 2. 重新加载Prometheus配置
[root@fgedu.net.cn ~]# curl -X POST http://192.168.1.20:9090/-/reload

# 3. 验证告警规则
# 访问Prometheus UI：http://192.168.1.20:9090/rules

# 4. 测试告警规则
# 手动触发一个告警
[root@fgedu.net.cn ~]# curl -X POST http://192.168.1.20:9093/api/v2/alerts -H “Content-Type: application/json” -d ‘[{“labels”:{“alertname”:”TestAlert”,”severity”:”critical”},”annotations”:{“summary”:”测试告警”,”description”:”这是一个测试告警”}}]’

# 5. 查看告警状态
# 访问Prometheus UI：http://192.168.1.20:9090/alerts

3.2 Grafana配置与仪表盘

3.2.1 配置Grafana

# 配置Grafana

# 1. 访问Grafana UI
# http://192.168.1.20:3000
# 默认用户名：admin
# 默认密码：admin

# 2. 添加Prometheus数据源
# 步骤：
# 1. 登录Grafana
# 2. 点击左侧菜单 “Configuration” → “Data sources”
# 3. 点击 “Add data source”
# 4. 选择 “Prometheus”
# 5. 配置URL：http://localhost:9090
# 6. 点击 “Save & Test”

# 3. 导入TiDB仪表盘
# 步骤：
# 1. 点击左侧菜单 “Create” → “Import”
# 2. 输入仪表盘ID：
# – TiDB Overview: 12060
# – TiKV Overview: 12061
# – PD Overview: 12062
# – TiFlash Overview: 12063
# – Node Exporter Full: 1860
# 3. 选择Prometheus数据源
# 4. 点击 “Import”

# 4. 自定义仪表盘
# 步骤：
# 1. 点击左侧菜单 “Create” → “Dashboard”
# 2. 点击 “Add new panel”
# 3. 配置查询语句
# 4. 调整面板设置
# 5. 点击 “Save”

# 5. 配置仪表盘变量
# 步骤：
# 1. 进入仪表盘设置
# 2. 点击 “Variables”
# 3. 添加变量，如：instance、job等
# 4. 保存变量配置

# 6. 配置自动刷新
# 步骤：
# 1. 进入仪表盘设置
# 2. 点击 “Time options”
# 3. 设置 “Refresh” 为适当的时间间隔
# 4. 保存设置

# 7. 配置告警通知
# 步骤：
# 1. 点击左侧菜单 “Alerting” → “Notification channels”
# 2. 点击 “Add channel”
# 3. 配置通知渠道（邮件、企业微信等）
# 4. 点击 “Save”

# 8. 导出仪表盘
# 步骤：
# 1. 进入仪表盘
# 2. 点击右上角 “Share”
# 3. 选择 “Export”
# 4. 下载JSON文件

# 9. 导入仪表盘
# 步骤：
# 1. 点击左侧菜单 “Create” → “Import”
# 2. 上传JSON文件
# 3. 选择Prometheus数据源
# 4. 点击 “Import”

# 10. 验证Grafana状态
[root@fgedu.net.cn ~]# curl http://192.168.1.20:3000/api/health
{“status”:”ok”}

3.2.2 常用Grafana仪表盘

# 常用Grafana仪表盘

# 1. TiDB Overview
# 面板：
# – QPS和连接数
# – 执行时间分布
# – 错误率
# – 慢查询
# – 事务信息

# 2. TiKV Overview
# 面板：
# – 存储容量
# – 读写吞吐量
# – 延迟
# – 副本状态
# – RocksDB指标

# 3. PD Overview
# 面板：
# – 集群状态
# – 调度信息
# – leader选举
# – 存储统计

# 4. TiFlash Overview
# 面板：
# – 同步状态
# – 存储容量
# – 读写性能
# – 错误信息

# 5. Node Exporter Full
# 面板：
# – CPU使用率
# – 内存使用率
# – 磁盘使用率
# – 网络流量
# – 负载情况

# 6. 自定义业务仪表盘
# 面板：
# – 业务QPS
# – 响应时间
# – 错误率
# – 关键业务指标

# 7. 告警仪表盘
# 面板：
# – 告警统计
# – 告警趋势
# – 告警分布
# – 告警处理状态

# 8. 性能对比仪表盘
# 面板：
# – 不同版本性能对比
# – 不同配置性能对比
# – 历史性能趋势

# 9. 容量规划仪表盘
# 面板：
# – 存储增长趋势
# – 内存使用趋势
# – CPU使用趋势
# – 预测容量需求

# 10. 集群健康仪表盘
# 面板：
# – 集群整体状态
# – 各组件健康状态
# – 关键指标监控
# – 告警汇总

3.3 AlertManager配置与告警

3.3.1 配置AlertManager

# 配置AlertManager

# 1. 创建AlertManager配置文件
cat > /tidb/monitor/alertmanager/alertmanager.yml << EOF global: resolve_timeout: 5m smtp_smarthost: 'smtp.example.com:587' smtp_from: 'tidb-alert@example.com' smtp_auth_username: 'tidb-alert@example.com' smtp_auth_password: 'password' smtp_require_tls: true route: group_by: ['alertname', 'cluster', 'service'] group_wait: 30s group_interval: 5m repeat_interval: 1h receiver: 'email' routes: - match: severity: critical receiver: 'email-sms' receivers: - name: 'email' email_configs: - to: 'admin@example.com' send_resolved: true - name: 'email-sms' email_configs: - to: 'admin@example.com' send_resolved: true webhook_configs: - url: 'http://localhost:8080/sms' send_resolved: true inhibit_rules: - source_match: severity: 'critical' target_match: severity: 'warning' equal: ['alertname', 'cluster', 'service'] EOF # 2. 重启AlertManager [root@fgedu.net.cn ~]# systemctl restart alertmanager # 3. 验证AlertManager状态 [root@fgedu.net.cn ~]# curl http://192.168.1.20:9093/api/v2/status # 4. 测试告警通知 # 手动触发一个告警 [root@fgedu.net.cn ~]# curl -X POST http://192.168.1.20:9093/api/v2/alerts -H "Content-Type: application/json" -d '[{"labels":{"alertname":"TestAlert","severity":"critical","cluster":"fgedudb","service":"tidb"},"annotations":{"summary":"测试告警","description":"这是一个测试告警"}}]' # 5. 查看告警状态 # 访问AlertManager UI：http://192.168.1.20:9093 # 6. 配置告警静默 # 步骤： # 1. 访问AlertManager UI # 2. 点击 "Silences" # 3. 点击 "New Silence" # 4. 配置静默规则 # 5. 点击 "Create" # 7. 配置告警分组 # 在alertmanager.yml中配置group_by # 8. 配置告警路由 # 在alertmanager.yml中配置routes # 9. 配置告警抑制 # 在alertmanager.yml中配置inhibit_rules # 10. 监控AlertManager # 添加AlertManager到Prometheus抓取目标 - job_name: 'alertmanager' static_configs: - targets: ['192.168.1.20:9093']

3.3.2 告警通知渠道配置

# 告警通知渠道配置

# 1. 邮件通知配置
# 在alertmanager.yml中配置
email_configs:
– to: ‘admin@example.com’
send_resolved: true
html: ‘{{ template “email.default.html” . }}’

# 2. 企业微信通知配置
# 安装企业微信webhook
cat > /tidb/monitor/wechat-webhook.py << EOF #!/usr/bin/env python3 import json import requests from flask import Flask, request app = Flask(__name__) WECHAT_WEBHOOK_URL = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY" @app.route('/wechat', methods=['POST']) def wechat(): data = request.json alerts = data.get('alerts', []) for alert in alerts: status = alert.get('status') labels = alert.get('labels', {}) annotations = alert.get('annotations', {}) message = f"【{status.upper()}】{labels.get('alertname')}\n" message += f"{annotations.get('description', '')}\n" message += f"实例: {labels.get('instance', '')}\n" message += f"服务: {labels.get('service', '')}\n" payload = { "msgtype": "text", "text": { "content": message } } response = requests.post(WECHAT_WEBHOOK_URL, json=payload) print(response.text) return "ok" if __name__ == '__main__': app.run(host='0.0.0.0', port=8081) EOF # 启动企业微信webhook [root@fgedu.net.cn ~]# python3 /tidb/monitor/wechat-webhook.py & # 配置企业微信通知 webhook_configs: - url: 'http://localhost:8081/wechat' send_resolved: true # 3. 短信通知配置 # 安装短信webhook cat > /tidb/monitor/sms-webhook.py << EOF #!/usr/bin/env python3 import json import requests from flask import Flask, request app = Flask(__name__) SMS_API_URL = "https://api.example.com/sms/send" SMS_API_KEY = "YOUR_API_KEY" @app.route('/sms', methods=['POST']) def sms(): data = request.json alerts = data.get('alerts', []) for alert in alerts: status = alert.get('status') labels = alert.get('labels', {}) annotations = alert.get('annotations', {}) message = f"【{status.upper()}】{labels.get('alertname')}: {annotations.get('description', '')}" payload = { "api_key": SMS_API_KEY, "phone": "13800138000", "message": message } response = requests.post(SMS_API_URL, json=payload) print(response.text) return "ok" if __name__ == '__main__': app.run(host='0.0.0.0', port=8080) EOF # 启动短信webhook [root@fgedu.net.cn ~]# python3 /tidb/monitor/sms-webhook.py & # 配置短信通知 webhook_configs: - url: 'http://localhost:8080/sms' send_resolved: true # 4. Slack通知配置 slack_configs: - api_url: 'https://hooks.slack.com/services/YOUR/WEBHOOK/URL' channel: '#tidb-alerts' send_resolved: true # 5. PagerDuty集成 pagerduty_configs: - service_key: 'YOUR_SERVICE_KEY' send_resolved: true # 6. 验证通知渠道 # 手动触发告警测试各通知渠道 [root@fgedu.net.cn ~]# curl -X POST http://192.168.1.20:9093/api/v2/alerts -H "Content-Type: application/json" -d '[{"labels":{"alertname":"TestAlert","severity":"critical","cluster":"fgedudb","service":"tidb"},"annotations":{"summary":"测试告警","description":"这是一个测试告警"}}]' # 7. 监控通知渠道 # 添加通知渠道状态监控 - job_name: 'webhook' static_configs: - targets: ['192.168.1.20:8080', '192.168.1.20:8081']

风哥提示：监控和告警系统是数据库运维的重要组成部分。配置合理的监控指标和告警策略，可以及时发现和处理问题，保证系统的稳定运行。学习交流加群风哥QQ113257174

Part04-生产案例与实战讲解

4.1 监控实战案例

# 监控实战案例：性能问题排查

# 场景：TiDB集群QPS突然下降，响应时间变长

# 1. 监控分析
# 步骤1：查看TiDB Overview仪表盘
# – QPS曲线：发现QPS从10000下降到2000
# – 响应时间：从5ms上升到50ms
# – 连接数：正常，无异常增长

# 步骤2：查看TiKV Overview仪表盘
# – 读写吞吐量：写吞吐量异常增加
# – 延迟：写延迟从1ms上升到20ms
# – RocksDB指标：写放大率增加

# 步骤3：查看PD Overview仪表盘
# – 调度信息：发现大量调度操作
# – leader分布：不均匀

# 步骤4：查看Node Exporter Full仪表盘
# – CPU使用率：TiKV节点CPU使用率达到90%
# – 内存使用率：正常
# – 磁盘I/O：写IOPS达到磁盘上限

# 2. 问题定位
# 原因：
# – 业务突发写入流量
# – TiKV节点磁盘I/O瓶颈
# – 调度操作增加了额外开销

# 3. 解决方案
# – 优化业务写入模式，避免突发流量
# – 增加TiKV节点，分担负载
# – 调整PD调度策略，减少调度频率
# – 优化TiKV参数，提高写入性能

# 4. 验证结果
# – QPS恢复到10000
# – 响应时间恢复到5ms
# – 磁盘I/O使用率降低到60%

# 5. 经验总结
# – 监控系统能够及时发现性能异常
# – 多维度监控有助于快速定位问题
# – 提前规划容量，避免资源瓶颈

# 6. 监控优化
# – 增加业务写入流量监控
# – 设置磁盘I/O告警阈值
# – 配置调度操作监控
# – 建立性能基准线

4.2 告警实战案例

# 告警实战案例：TiKV节点故障

# 场景：TiKV节点宕机，触发告警

# 1. 告警流程
# 时间线：
# 00:00: TiKV节点192.168.1.10宕机
# 00:05: Prometheus检测到节点宕机，触发告警
# 00:06: AlertManager收到告警，发送邮件和短信通知
# 00:07: 运维人员收到告警通知
# 00:10: 运维人员开始排查
# 00:15: 发现节点硬件故障
# 00:20: 启动备用节点
# 00:30: 集群恢复正常
# 00:31: 告警自动解决

# 2. 告警信息
# 告警名称：TiKVServerDown
# 严重程度：critical
# 告警描述：TiKV服务器 192.168.1.10:20180 已宕机超过5分钟
# 影响范围：集群写入性能下降，副本数减少

# 3. 故障处理
# 步骤1：确认告警真实性
# – 登录监控系统查看节点状态
# – 尝试SSH连接节点
# – 检查节点硬件状态

# 步骤2：评估影响
# – 查看集群状态：tiup cluster status fgedudb
# – 检查副本状态：pd-ctl -u http://192.168.1.11:2379 store
# – 监控业务影响：查看应用错误率

# 步骤3：实施恢复
# – 启动备用节点
# – 等待集群重新平衡
# – 验证数据完整性

# 步骤4：告警处理
# – 确认告警已解决
# – 记录故障原因
# – 制定预防措施

# 4. 告警优化
# – 调整告警阈值：将告警触发时间从5分钟改为3分钟
# – 增加告警信息：添加节点位置、负责人等信息
# – 优化通知渠道：对于critical告警，同时发送邮件、短信和企业微信
# – 建立告警升级机制：如果30分钟未处理，自动升级到更高层级

# 5. 经验总结
# – 告警系统能够及时发现节点故障
# – 快速响应和处理可以减少故障影响
# – 建立完善的故障处理流程至关重要
# – 定期演练故障处理流程，提高响应速度

4.3 监控告警故障排查

# 监控告警故障排查

# 场景1：监控数据丢失

# 1. 问题现象
# – Grafana仪表盘显示数据空白
# – Prometheus抓取目标显示DOWN

# 2. 排查步骤
# – 检查Prometheus状态：systemctl status prometheus
# – 检查网络连接：ping 192.168.1.10
# – 检查防火墙：iptables -L
# – 检查目标服务：curl http://192.168.1.10:10080/metrics

# 3. 解决方案
# – 重启Prometheus：systemctl restart prometheus
# – 检查网络配置：修复网络连接
# – 调整防火墙规则：开放监控端口
# – 重启目标服务：修复服务异常

# 场景2：告警未触发

# 1. 问题现象
# – 节点CPU使用率达到95%，但未触发告警

# 2. 排查步骤
# – 检查告警规则：promtool check rules /tidb/monitor/prometheus/rules/tidb-alerts.yml
# – 检查Prometheus配置：promtool check config /tidb/monitor/prometheus/prometheus.yml
# – 手动执行告警表达式：在Prometheus UI中执行
# – 检查AlertManager状态：systemctl status alertmanager

# 3. 解决方案
# – 修复告警规则：调整阈值或表达式
# – 重新加载配置：curl -X POST http://192.168.1.20:9090/-/reload
# – 重启AlertManager：systemctl restart alertmanager
# – 检查告警抑制规则：是否被其他告警抑制

# 场景3：告警风暴

# 1. 问题现象
# – 短时间内收到大量相同告警
# – 告警通知渠道被淹没

# 2. 排查步骤
# – 检查集群状态：tiup cluster status fgedudb
# – 分析告警原因：是否有系统性故障
# – 检查告警规则：是否存在逻辑问题
# – 检查告警抑制：是否配置了抑制规则

# 3. 解决方案
# – 配置告警分组：group_by: [‘alertname’, ‘cluster’]
# – 配置告警抑制：inhibit_rules
# – 调整告警阈值：避免过于敏感
# – 实施告警静默：临时抑制非关键告警

# 场景4：监控系统性能问题

# 1. 问题现象
# – Prometheus CPU使用率高
# – Grafana查询响应慢
# – 监控数据延迟

# 2. 排查步骤
# – 检查Prometheus配置：采样频率、存储配置
# – 检查服务器资源：CPU、内存、磁盘
# – 分析查询负载：topqueries
# – 检查数据量：存储使用情况

# 3. 解决方案
# – 调整采样频率：从15s改为30s
# – 增加服务器资源：升级CPU、内存
# – 优化查询：减少复杂查询
# – 配置数据降采样：长期数据降采样
# – 实施Prometheus分片：大规模集群

# 场景5：告警通知失败

# 1. 问题现象
# – 告警已触发，但未收到通知

# 2. 排查步骤
# – 检查AlertManager状态：systemctl status alertmanager
# – 检查通知渠道配置：alertmanager.yml
# – 测试通知渠道：手动触发测试告警
# – 检查网络连接：ping smtp服务器

# 3. 解决方案
# – 修复通知渠道配置：检查邮箱、webhook地址
# – 重启AlertManager：systemctl restart alertmanager
# – 检查网络连接：修复网络问题
# – 配置备用通知渠道：确保通知可靠性

风哥提示：监控告警系统本身也需要监控。建立监控系统的健康检查机制，确保监控系统的可靠性。更多学习教程公众号风哥教程itpux_com

Part05-风哥经验总结与分享

5.1 监控告警最佳实践

监控覆盖全面：覆盖基础设施、数据库组件、业务指标等多个维度
告警策略合理：根据影响程度分级，减少误报和漏报
监控系统高可用：确保监控系统本身的可靠性
监控数据存储：合理规划存储，确保数据可靠性和查询性能
告警通知及时：多渠道通知，确保运维人员及时收到告警
定期演练：定期测试监控告警系统，确保其正常运行
持续优化：根据实际运行情况，持续优化监控告警策略
文档完善：建立监控告警文档，包括配置、规则、处理流程等

5.2 常见问题与解决方案

# 常见监控告警问题及解决方案

# 问题1：监控数据不准确
# 原因：
# – 采样频率不合理
# – 指标计算错误
# – 数据传输延迟
# 解决方案：
# – 调整采样频率：根据指标重要性调整
# – 验证指标计算：确保指标计算逻辑正确
# – 优化网络传输：减少数据传输延迟

# 问题2：告警误报
# 原因：
# – 告警阈值设置不合理
# – 告警规则逻辑错误
# – 网络波动导致的临时异常
# 解决方案：
# – 调整告警阈值：根据实际情况调整
# – 优化告警规则：增加持续时间条件
# – 配置告警抑制：避免网络波动导致的误报

# 问题3：告警漏报
# 原因：
# – 告警规则未覆盖所有场景
# – 监控系统故障
# – 告警通知渠道故障
# 解决方案：
# – 完善告警规则：覆盖所有关键场景
# – 监控监控系统：确保监控系统本身正常
# – 配置多通知渠道：提高通知可靠性

# 问题4：监控系统性能差
# 原因：
# – 服务器资源不足
# – 配置不合理
# – 数据量过大
# 解决方案：
# – 增加服务器资源：升级CPU、内存
# – 优化配置：调整采样频率、存储策略
# – 实施数据降采样：减少存储压力
# – 部署Prometheus分片：大规模集群

# 问题5：告警处理效率低
# 原因：
# – 告警信息不清晰
# – 处理流程不明确
# – 缺乏自动化处理
# 解决方案：
# – 优化告警信息：包含关键信息，便于快速定位
# – 建立处理流程：明确告警处理步骤
# – 实施自动化处理：对于常见问题自动处理

# 问题6：监控系统维护困难
# 原因：
# – 配置管理混乱
# – 文档不完善
# – 缺乏版本控制
# 解决方案：
# – 使用配置管理工具：如Ansible、Terraform
# – 完善文档：记录配置、规则、处理流程
# – 实施版本控制：对配置文件进行版本管理

# 问题7：跨地域监控困难
# 原因：
# – 网络延迟
# – 数据传输成本
# – 权限管理复杂
# 解决方案：
# – 部署本地监控：每个地域部署监控系统
# – 使用Prometheus联邦集群：汇总监控数据
# – 配置合理的网络策略：确保数据传输安全

# 问题8：监控数据安全
# 原因：
# – 未加密传输
# – 权限控制不严
# – 数据泄露风险
# 解决方案：
# – 启用HTTPS：加密数据传输
# – 配置认证和授权：严格控制访问权限
# – 数据脱敏：敏感数据脱敏处理
# – 定期安全审计：检查监控系统安全

5.3 监控告警检查清单

#!/bin/bash
# tidb-monitoring-checklist.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: `http://www.fgedu.net.cn`

# TiDB监控告警检查清单

echo “=== TiDB监控告警检查清单 ===”

# 1. 监控系统部署检查
echo “[ ] Prometheus是否正常运行？”
echo “[ ] Grafana是否正常运行？”
echo “[ ] AlertManager是否正常运行？”
echo “[ ] 所有监控目标是否UP？”

# 2. 监控配置检查
echo “[ ] 监控指标是否全面？”
echo “[ ] 采样频率是否合理？”
echo “[ ] 存储配置是否适当？”
echo “[ ] 监控数据是否完整？”

# 3. 告警配置检查
echo “[ ] 告警规则是否覆盖所有关键场景？”
echo “[ ] 告警阈值是否合理？”
echo “[ ] 告警分级是否清晰？”
echo “[ ] 告警通知渠道是否配置正确？”

# 4. 告警通知检查
echo “[ ] 邮件通知是否正常？”
echo “[ ] 短信通知是否正常？”
echo “[ ] 企业微信通知是否正常？”
echo “[ ] 告警抑制规则是否配置？”

# 5. 监控仪表盘检查
echo “[ ] 关键仪表盘是否配置？”
echo “[ ] 仪表盘显示是否正常？”
echo “[ ] 仪表盘自动刷新是否配置？”
echo “[ ] 自定义仪表盘是否符合业务需求？”

# 6. 监控系统性能检查
echo “[ ] Prometheus CPU使用率是否正常？”
echo “[ ] Prometheus内存使用率是否正常？”
echo “[ ] 监控数据查询是否响应及时？”
echo “[ ] 存储使用率是否在合理范围？”

# 7. 故障演练检查
echo “[ ] 是否定期进行故障演练？”
echo “[ ] 告警触发是否及时？”
echo “[ ] 告警处理流程是否顺畅？”
echo “[ ] 故障恢复是否及时？”

# 8. 文档和流程检查
echo “[ ] 监控配置是否有文档？”
echo “[ ] 告警规则是否有文档？”
echo “[ ] 故障处理流程是否有文档？”
echo “[ ] 监控系统维护计划是否制定？”

echo “=== 检查完成 ===”

# 执行检查示例
# 检查监控系统状态
[root@fgedu.net.cn ~]# systemctl status prometheus grafana-server alertmanager

# 检查监控目标
[root@fgedu.net.cn ~]# curl -s http://192.168.1.20:9090/api/v1/targets | jq ‘.data.activeTargets[].health’

# 检查告警规则
[root@fgedu.net.cn ~]# curl -s http://192.168.1.20:9090/api/v1/rules | jq ‘.data.groups[].rules[].alert’

# 检查存储使用情况
[root@fgedu.net.cn ~]# df -h /tidb/monitor/data

# 测试告警通知
[root@fgedu.net.cn ~]# curl -X POST http://192.168.1.20:9093/api/v2/alerts -H “Content-Type: application/json” -d ‘[{“labels”:{“alertname”:”TestAlert”,”severity”:”critical”},”annotations”:{“summary”:”测试告警”,”description”:”这是一个测试告警”}}]’

风哥提示：监控告警系统是数据库运维的重要工具，建立完善的监控体系可以提前发现问题，避免故障发生。定期检查和优化监控告警系统，确保其正常运行。from tidb视频:www.itpux.com

本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html