1. 首页 > 国产数据库教程 > TiDB教程 > 正文

tidb教程FG169-TiDB监控与可观测性

本文档风哥主要介绍TiDB监控与可观测性相关知识,包括监控基础、TiDB监控特性、可观测性基础、监控策略、可观测性策略、监控架构、监控实施方案、可观测性实施方案、告警实施方案等内容,风哥教程参考TiDB官方文档监控章节,适合DBA人员在学习和测试中使用,如果要应用于生产环境则需要自行确认。

Part01-基础概念与理论知识

1.1 监控基础

监控的核心概念:

  • 监控:收集、分析和展示系统运行状态的过程。
  • 指标:系统运行状态的量化数据,如CPU使用率、内存使用率等。
  • 告警:当指标超过阈值时触发的通知。
  • 仪表盘:可视化展示监控指标的界面。
  • 监控系统:用于收集、存储和分析监控数据的系统。
  • 监控目标:被监控的系统或服务。
监控的作用:

  • 及时发现系统异常
  • 提前预警潜在问题
  • 优化系统性能
  • 确保业务连续性
  • 辅助故障排查

1.2 TiDB监控特性

TiDB的监控特性:

# TiDB监控特性

## 1. 内置监控
– 集成Prometheus和Grafana
– 预配置监控仪表盘
– 实时监控集群状态
– 支持自定义监控指标

## 2. 多维度监控
– 集群级别监控:整体集群状态
– 节点级别监控:单个节点状态
– 组件级别监控:TiDB、TiKV、PD等组件状态
– 业务级别监控:SQL执行、事务处理等

## 3. 丰富的监控指标
– 系统指标:CPU、内存、磁盘、网络等
– 数据库指标:QPS、TPS、响应时间等
– 存储指标:存储使用、IOPS、延迟等
– 集群指标:节点状态、数据分布等
风哥提示:
## 4. 告警系统
– 预配置告警规则
– 支持多种告警渠道
– 告警级别管理
– 告警抑制和聚合

## 5. 可视化界面
– TiDB Dashboard:集群管理和监控
– Grafana:自定义监控仪表盘
– Prometheus:指标查询和分析

## 6. 日志管理
– 统一日志收集
– 日志分析和搜索
– 日志存储和归档
– 日志告警

1.3 可观测性基础

可观测性的核心概念:

# 可观测性基础

## 1. 可观测性:
– 了解系统内部状态的能力
– 通过外部输出推断系统内部状态
– 包含监控、日志和追踪

## 2. 三大支柱:
– 指标(Metrics):系统运行状态的量化数据
– 日志(Logs):系统事件的记录
– 追踪(Traces):请求的完整执行路径

## 3. 指标(Metrics):
– 时间序列数据
– 用于监控系统健康状态
– 支持聚合和分析

## 4. 日志(Logs):
– 事件的详细记录
– 用于故障排查和审计
– 支持结构化和非结构化数据

## 5. 追踪(Traces):
– 分布式系统中的请求路径
– 用于性能分析和故障定位
– 支持跨服务追踪

## 6. 可观测性平台:
– 集成指标、日志和追踪
– 提供统一的查询和分析界面
– 支持告警和自动化响应

风哥提示:监控与可观测性是TiDB运维的重要组成部分,需要充分了解监控的基础概念和TiDB的监控特性,才能制定有效的监控策略和可观测性方案。更多视频教程www.fgedu.net.cn

Part02-生产环境规划与建议

2.1 监控策略

监控策略:

# 监控策略

## 1. 监控目标
– 系统健康状态:CPU、内存、磁盘、网络等
– 数据库性能:QPS、TPS、响应时间等
– 存储状态:存储使用、IOPS、延迟等
– 集群状态:节点状态、数据分布等
– 业务指标:订单量、交易量等

## 2. 监控频率
– 系统指标:每10秒采集一次
– 数据库指标:每5秒采集一次
– 存储指标:每10秒采集一次
– 集群指标:每30秒采集一次
– 业务指标:每1分钟采集一次

## 3. 监控指标
– 核心指标:必须监控的指标
– 重要指标:需要重点监控的指标
– 一般指标:常规监控的指标
– 自定义指标:根据业务需求定义的指标

## 4. 告警策略
– 告警级别:紧急、重要、警告、信息
– 告警阈值:根据历史数据和业务需求设置
– 告警渠道:邮件、短信、微信、电话
– 告警抑制:避免告警风暴
– 告警升级:确保告警得到及时处理

## 5. 监控工具
– 监控系统:Prometheus、Grafana
– 日志系统:ELK Stack、Loki
– 追踪系统:Jaeger、Zipkin
– 告警系统:Alertmanager
学习交流加群风哥QQ113257174
## 6. 监控管理
– 监控配置管理:版本控制、变更管理
– 监控数据管理:存储、归档、清理
– 监控权限管理:角色和权限控制
– 监控文档:监控指标说明、告警规则说明

2.2 可观测性策略

可观测性策略:

# 可观测性策略

## 1. 可观测性目标
– 全面了解系统状态
– 快速定位故障
– 优化系统性能
– 预测潜在问题

## 2. 数据收集策略
– 指标收集:使用Prometheus收集时间序列数据
– 日志收集:使用ELK Stack或Loki收集日志
– 追踪收集:使用Jaeger或Zipkin收集分布式追踪数据
– 数据集成:将指标、日志和追踪数据集成到统一平台

## 3. 数据存储策略
– 指标存储:使用Prometheus TSDB或远程存储
– 日志存储:使用Elasticsearch或对象存储
– 追踪存储:使用Jaeger存储或对象存储
– 数据保留:根据业务需求设置数据保留期

## 4. 数据分析策略
– 指标分析:使用PromQL进行查询和分析
– 日志分析:使用ELK Stack进行搜索和分析
– 追踪分析:使用Jaeger UI进行追踪分析
– 关联分析:将指标、日志和追踪数据关联分析

## 5. 可视化策略
– 指标可视化:使用Grafana创建仪表盘
– 日志可视化:使用Kibana创建仪表盘
– 追踪可视化:使用Jaeger UI查看追踪
– 统一可视化:将所有数据集成到统一界面

## 6. 自动化策略
– 自动告警:基于阈值自动触发告警
– 自动响应:基于告警自动执行响应操作
– 自动修复:基于规则自动修复常见问题
– 自动扩缩容:基于指标自动调整资源

2.3 监控架构

监控架构:

# 监控架构

## 1. 分层架构
– 数据采集层:收集指标、日志和追踪数据
– 数据存储层:存储监控数据
– 数据分析层:分析监控数据
– 可视化层:展示监控数据
– 告警层:处理和发送告警

## 2. 部署架构
– 集中式部署:所有监控组件部署在一个中心节点
– 分布式部署:监控组件分布在多个节点
– 混合部署:结合集中式和分布式部署

## 3. 高可用架构
– 监控系统高可用:部署多个监控节点
– 数据存储高可用:使用复制和分片
– 告警系统高可用:部署多个告警节点
– 网络高可用:使用多网络路径

## 4. 扩展性架构
– 水平扩展:增加监控节点
– 垂直扩展:增加单个节点资源
– 自动扩展:根据负载自动调整资源
– 模块化设计:支持功能模块的扩展

## 5. 安全架构
– 访问控制:认证和授权
– 数据加密:传输和存储加密
– 网络隔离:监控网络与生产网络隔离
– 审计日志:记录监控系统操作

## 6. 集成架构
– 与CI/CD集成:监控部署和发布
– 与配置管理集成:自动配置监控
– 与容器平台集成:监控容器和服务
– 与云平台集成:使用云服务监控

生产环境建议:监控与可观测性策略需要根据实际业务场景和系统规模进行调整,不同类型的业务需要不同的监控策略和可观测性方案。学习交流加群风哥微信: itpux-com

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

3.1 监控实施方案

3.1.1 Prometheus和Grafana部署

# Prometheus和Grafana部署

## 1. 部署Prometheus
$ tiup cluster deploy fgedu-tidb-cluster 7.5.0 topology.yaml –user root -p

## 2. 配置Prometheus
$ tiup cluster edit-config fgedu-tidb-cluster
prometheus_servers:
– host: 192.168.1.100
config:
global:
scrape_interval: 15s
evaluation_interval: 15s
alerting:
alertmanagers:
– static_configs:
– targets: [‘192.168.1.100:9093’]
rule_files:
– “rules/*.yml”
scrape_configs:
– job_name: ‘tidb’
static_configs:
– targets: [‘192.168.1.100:10080’]
– job_name: ‘tikv’
static_configs:
– targets: [‘192.168.1.101:20180’, ‘192.168.1.102:20180’, ‘192.168.1.103:20180’]
– job_name: ‘pd’
static_configs:
– targets: [‘192.168.1.100:2379’]

## 3. 部署Grafana
$ tiup cluster deploy fgedu-tidb-cluster 7.5.0 topology.yaml –user root -p

## 4. 配置Grafana
$ tiup cluster edit-config fgedu-tidb-cluster
grafana_servers:
– host: 192.168.1.100
config:
server:
http_port: 3000
security:
admin_user: admin
admin_password: admin
datasources:
datasources.yaml:
apiVersion: 1
datasources:
– name: Prometheus
type: prometheus
url: http://192.168.1.100:9090
access: proxy
isDefault: true

## 5. 重启集群使配置生效
$ tiup cluster reload fgedu-tidb-cluster

## 6. 访问Grafana
# 访问 http://192.168.1.100:3000
# 用户名:admin,密码:admin

3.1.2 监控指标配置

# 监控指标配置

## 1. 查看默认监控指标
$ curl http://192.168.1.100:9090/metrics

## 2. 配置自定义监控指标
$ cat > /tidb/app/prometheus/rules/custom.rules.yml << EOF groups: - name: custom_rules rules: - alert: TiDBQueryLatencyHigh expr: sum(rate(tidb_server_handle_query_duration_seconds_sum[5m])) by (instance) / sum(rate(tidb_server_handle_query_duration_seconds_count[5m])) by (instance) > 0.1
for: 5m
labels:
severity: warning
annotations:
summary: “TiDB query latency high”
description: “TiDB instance {{ $labels.instance }} query latency is {{ $value }} seconds”
– alert: TiKVStorageFull
expr: tikv_store_size_bytes / tikv_store_capacity_bytes > 0.8
for: 5m
labels:
severity: warning
annotations:
summary: “TiKV storage full”
description: “TiKV instance {{ $labels.instance }} storage usage is {{ $value | humanizePercentage }}”
EOF

## 3. 重启Prometheus使配置生效
$ tiup cluster reload fgedu-tidb-cluster -R prometheus

## 4. 查看监控指标
$ curl http://192.168.1.100:9090/api/v1/query?query=tidb_server_handle_query_duration_seconds_sum

## 5. 创建Grafana仪表盘
# 访问 http://192.168.1.100:3000
# 创建新的仪表盘,添加面板,选择Prometheus数据源,输入查询语句

3.2 可观测性实施方案

3.2.1 日志收集与分析

# 日志收集与分析

## 1. 部署ELK Stack
$ yum install -y docker docker-compose
$ cat > docker-compose.yml << EOF version: '3' services: elasticsearch: image: elasticsearch:7.17.0 ports: - "9200:9200" environment: - discovery.type=single-node - ES_JAVA_OPTS=-Xms1g -Xmx1g volumes: - es_data:/usr/share/elasticsearch/data logstash: image: logstash:7.17.0 ports: - "5044:5044" volumes: - ./logstash/pipeline:/usr/share/logstash/pipeline kibana: image: kibana:7.17.0 ports: - "5601:5601" environment: - ELASTICSEARCH_HOSTS=http://elasticsearch:9200 volumes: es_data: EOF ## 2. 配置Logstash $ mkdir -p logstash/pipeline $ cat > logstash/pipeline/logstash.conf << EOF input { file { path => “/tidb/app/tidb-deploy/tidb-4000/log/tidb.log”
start_position => “beginning”
sincedb_path => “/dev/null”
}
file {
path => “/tidb/app/tidb-deploy/tikv-20160/log/tikv.log”
start_position => “beginning”
sincedb_path => “/dev/null”
}
file {
path => “/tidb/app/tidb-deploy/pd-2379/log/pd.log”
start_position => “beginning”
sincedb_path => “/dev/null”
}
}

filter {
grok {
match => { “message” => “%{TIMESTAMP_ISO8601:timestamp} \[%{DATA:level}\] \[%{DATA:component}\] \[%{DATA:file}\:%{NUMBER:line}\] %{GREEDYDATA:message}” }
}
date {
match => [ “timestamp”, “yyyy-MM-dd HH:mm:ss.SSS” ]
target => “@timestamp”
}
}

output {
elasticsearch {
hosts => [“elasticsearch:9200”]
index => “tidb-logs-%{+YYYY.MM.dd}”
}
}
EOF

## 3. 启动ELK Stack
$ docker-compose up -d

## 4. 访问Kibana
# 访问 http://192.168.1.100:5601
# 创建索引模式 tidb-logs-*,查看日志

## 5. 配置日志告警
# 在Kibana中创建告警,基于日志内容触发告警

3.2.2 分布式追踪

# 分布式追踪

## 1. 部署Jaeger
$ docker run -d –name jaeger \
-e COLLECTOR_ZIPKIN_HOST_PORT=:9411 \
-p 5775:5775/udp \
-p 6831:6831/udp \
-p 6832:6832/udp \
-p 5778:5778 \
-p 16686:16686 \
-p 14268:14268 \
-p 14250:14250 \
-p 9411:9411 \
jaegertracing/all-in-one:1.35

## 2. 配置TiDB启用追踪
$ tiup cluster edit-config fgedu-tidb-cluster
tidb_servers:
– host: 192.168.1.100
config:
tracing:
enable: true
jaeger:
agent-endpoint: “192.168.1.100:6831”
sampling-rate: 0.1

## 3. 重启TiDB使配置生效
$ tiup cluster reload fgedu-tidb-cluster -R tidb

## 4. 访问Jaeger UI
# 访问 http://192.168.1.100:16686
# 查看分布式追踪数据

## 5. 分析追踪数据
# 在Jaeger UI中查看请求的完整执行路径,分析性能瓶颈

3.3 告警实施方案

3.3.1 告警配置

# 告警配置

## 1. 配置Alertmanager
$ tiup cluster edit-config fgedu-tidb-cluster
alertmanager_servers:
– host: 192.168.1.100
config:
global:
resolve_timeout: 5m
smtp_smarthost: ‘smtp.fgedu.net.cn:587’
smtp_from: ‘alertmanager@fgedu.net.cn’
smtp_auth_username: ‘alertmanager@fgedu.net.cn’
smtp_auth_password: ‘password’
route:
group_by: [‘alertname’]
group_wait: 30s
group_interval: 5m
repeat_interval: 1h
receiver: ’email’
routes:
– match:
severity: critical
receiver: ’email’
receivers:
– name: ’email’
email_configs:
– to: ‘admin@fgedu.net.cn’
send_resolved: true

## 2. 配置告警规则
$ cat > /tidb/app/prometheus/rules/alert.rules.yml << EOF groups: - name: tidb_alerts rules: - alert: TiDBDown expr: up{job="tidb"} == 0 for: 5m labels: severity: critical annotations: summary: "TiDB instance down" description: "TiDB instance {{ $labels.instance }} has been down for more than 5 minutes" - alert: TiKVDown expr: up{job="tikv"} == 0 for: 5m labels: severity: critical annotations: summary: "TiKV instance down" description: "TiKV instance {{ $labels.instance }} has been down for more than 5 minutes" - alert: PDDown expr: up{job="pd"} == 0 for: 5m labels: severity: critical annotations: summary: "PD instance down" description: "PD instance {{ $labels.instance }} has been down for more than 5 minutes" - alert: TiDBQueryLatencyHigh expr: sum(rate(tidb_server_handle_query_duration_seconds_sum[5m])) by (instance) / sum(rate(tidb_server_handle_query_duration_seconds_count[5m])) by (instance) > 0.1
for: 5m
labels:
severity: warning
annotations:
summary: “TiDB query latency high”
description: “TiDB instance {{ $labels.instance }} query latency is {{ $value }} seconds”
– alert: TiKVStorageFull
expr: tikv_store_size_bytes / tikv_store_capacity_bytes > 0.8
for: 5m
labels:
severity: warning
annotations:
summary: “TiKV storage full”
description: “TiKV instance {{ $labels.instance }} storage usage is {{ $value | humanizePercentage }}”
EOF

## 3. 重启Alertmanager使配置生效
$ tiup cluster reload fgedu-tidb-cluster -R alertmanager

## 4. 查看告警状态
$ curl http://192.168.1.100:9093/api/v2/alerts

## 5. 测试告警
$ curl -X POST -H “Content-Type: application/json” -d ‘{“alerts”:[{“status”:”firing”,”labels”:{“alertname”:”TestAlert”,”severity”:”warning”},”annotations”:{“summary”:”Test alert”,”description”:”This is a test alert”},”generatorURL”:”http://localhost:9090/graph?g0.expr=up\u0026g0.tab=1″}]}’ http://192.168.1.100:9093/api/v2/alerts

风哥提示:监控与可观测性是一个系统性的工作,需要结合监控策略和可观测性方案,才能确保系统的稳定性和可靠性。学习交流加群风哥QQ113257174

Part04-生产案例与实战讲解

4.1 电商行业监控案例

某电商平台监控案例:

# 案例背景
– 业务场景:电商平台订单处理和支付
– 数据量:用户表数据量达到500万,订单表数据量达到1000万,支付表数据量达到500万
– 监控需求:实时监控系统状态,及时发现和处理问题
– 可观测性需求:快速定位故障,优化系统性能

# 问题分析
1. 系统复杂度高,组件多,需要全面监控
2. 高峰期流量大,需要实时监控系统性能
3. 业务连续性要求高,需要及时发现和处理问题
4. 故障定位困难,需要快速定位问题根源

# 优化措施
1. 监控方案:
– 部署Prometheus和Grafana,监控系统和数据库指标
– 部署ELK Stack,收集和分析日志
– 部署Jaeger,实现分布式追踪
– 配置告警规则,及时发现问题

2. 可观测性方案:
– 集成指标、日志和追踪数据
– 创建统一的监控仪表盘
– 配置智能告警,减少误报
– 建立故障排查流程

3. 技术实现:
– 部署完整的监控和可观测性栈
– 配置关键指标的监控和告警
– 实现日志的集中收集和分析
– 实现分布式追踪,跟踪请求路径

# 优化效果
– 系统可用性:从99.9%提升到99.99%
– 故障响应时间:从30分钟缩短到5分钟
– 问题定位时间:从1小时缩短到15分钟
– 系统性能:显著提升,高峰期响应时间稳定

4.2 金融行业监控案例

某银行监控案例:

# 案例背景
– 业务场景:银行交易处理和账户管理
– 数据量:账户表数据量达到1000万,交易表数据量达到5000万
– 监控需求:高可靠性,实时监控系统状态
– 可观测性需求:快速定位故障,确保业务连续性

# 问题分析
1. 系统安全性要求高,需要监控安全事件
2. 交易数据量大,需要监控系统性能
3. 业务连续性要求极高,需要及时发现和处理问题
4. 合规要求,需要记录和分析所有操作

# 优化措施
1. 监控方案:
– 部署Prometheus和Grafana,监控系统和数据库指标
– 部署ELK Stack,收集和分析日志
– 部署Jaeger,实现分布式追踪
– 配置安全监控,监控安全事件

2. 可观测性方案:
– 集成指标、日志和追踪数据
– 创建统一的监控仪表盘
– 配置智能告警,减少误报
– 建立故障排查流程
– 实现合规审计,满足监管要求

3. 技术实现:
– 部署完整的监控和可观测性栈
– 配置关键指标的监控和告警
– 实现日志的集中收集和分析
– 实现分布式追踪,跟踪请求路径
– 配置安全监控,监控安全事件

# 优化效果
– 系统可用性:从99.95%提升到99.999%
– 故障响应时间:从20分钟缩短到3分钟
– 问题定位时间:从45分钟缩短到10分钟
– 安全事件:减少90%以上
– 合规要求:满足监管要求

4.3 制造业监控案例

某制造企业监控案例:

# 案例背景
– 业务场景:生产数据管理和设备监控
– 数据量:生产数据表数据量达到2000万,设备表数据量达到100万
– 监控需求:实时监控生产数据和设备状态
– 可观测性需求:快速定位设备故障,优化生产流程

# 问题分析
1. 生产设备数量多,需要集中监控
2. 生产数据实时性要求高,需要实时监控
3. 设备故障会影响生产,需要及时发现和处理
4. 生产流程复杂,需要优化生产效率

# 优化措施
1. 监控方案:
– 部署Prometheus和Grafana,监控系统和数据库指标
– 部署ELK Stack,收集和分析日志
– 部署IoT监控系统,监控设备状态
– 配置告警规则,及时发现问题

2. 可观测性方案:
– 集成指标、日志和设备数据
– 创建统一的监控仪表盘
– 配置智能告警,减少误报
– 建立故障排查流程
– 实现生产数据分析,优化生产流程

3. 技术实现:
– 部署完整的监控和可观测性栈
– 配置关键指标的监控和告警
– 实现日志的集中收集和分析
– 实现设备数据的实时采集和监控
– 配置生产数据分析,优化生产流程

# 优化效果
– 设备可用性:从95%提升到99%
– 故障响应时间:从1小时缩短到15分钟
– 问题定位时间:从2小时缩短到30分钟
– 生产效率:提升15%以上
– 生产成本:降低10%以上

生产环境建议:监控与可观测性策略需要根据实际业务场景和系统规模进行调整,不同行业的监控与可观测性策略可能有所不同。更多学习教程公众号风哥教程itpux_com

Part05-风哥经验总结与分享

5.1 监控与可观测性最佳实践

监控与可观测性的最佳实践:

  • 制定完善的监控策略:根据业务需求和系统规模制定合适的监控策略。
  • 部署完整的监控栈:包括指标、日志和追踪的完整监控体系。
  • 监控关键指标:识别和监控对业务最重要的指标。
  • 配置合理的告警规则:避免过多的误报,确保重要问题及时告警。
  • 建立统一的监控仪表盘:集中展示关键指标,便于快速了解系统状态。
  • 实现日志的集中收集和分析:便于故障排查和审计。
  • 实现分布式追踪:跟踪请求路径,快速定位性能瓶颈。
  • 定期审查监控配置:根据业务变化和系统演进,定期调整监控配置。
  • 建立故障排查流程:明确故障排查的步骤和责任,提高故障处理效率。
  • 培训团队成员:提高团队成员的监控和可观测性意识,确保监控系统的有效使用。

5.2 常见问题与解决方法

# 常见问题与解决方法

## 1. 监控数据过多
– 问题:监控数据量过大,存储和处理成本高
– 解决方法:设置合理的数据保留期,使用数据降采样,只监控关键指标

## 2. 告警风暴
– 问题:系统故障时产生大量告警,导致告警疲劳
– 解决方法:配置告警抑制和聚合,设置合理的告警阈值,使用告警升级策略

## 3. 监控盲区
– 问题:某些系统组件或业务流程没有被监控
– 解决方法:全面梳理系统组件和业务流程,确保所有关键部分都被监控

## 4. 故障定位困难
– 问题:故障发生后,难以快速定位问题根源
– 解决方法:实现分布式追踪,集成指标、日志和追踪数据,建立故障排查流程

## 5. 监控系统自身故障
– 问题:监控系统自身出现故障,无法监控其他系统
– 解决方法:部署高可用的监控系统,监控监控系统自身的状态

## 6. 监控配置管理混乱
– 问题:监控配置分散,难以管理和维护
– 解决方法:使用版本控制管理监控配置,建立监控配置的变更流程

## 7. 性能影响
– 问题:监控数据采集对被监控系统造成性能影响
– 解决方法:调整数据采集频率,使用轻量级采集器,合理设置监控范围

## 8. 缺乏统一视图
– 问题:不同监控工具的数据分散,缺乏统一视图
– 解决方法:集成不同监控工具的数据,创建统一的监控仪表盘

5.3 持续改进建议

持续改进建议:

  • 定期评估监控策略:根据业务变化和系统演进,定期评估和调整监控策略。
  • 优化监控配置:根据实际运行情况,不断优化监控配置,提高监控的有效性。
  • 增强可观测性:不断完善可观测性体系,提高系统的可观测性水平。
  • 自动化监控:使用自动化工具管理监控配置和告警,减少人工干预。
  • 智能化监控:使用机器学习和人工智能技术,实现智能告警和异常检测。
  • 持续学习:关注监控和可观测性领域的新技术和最佳实践,不断提升监控能力。
  • 知识共享:建立监控和可观测性的知识库,分享经验和最佳实践。
  • 与业务结合:将监控与业务指标结合,更好地支持业务决策。
  • 定期演练:定期进行故障演练,测试监控系统的有效性。
  • 反馈改进:根据故障处理经验,持续改进监控系统和流程。
风哥提示:监控与可观测性是一个持续的过程,需要根据业务变化和系统演进不断调整和完善。from tidb视频:www.itpux.com

持续改进:监控与可观测性是TiDB运维的重要组成部分,需要建立完善的监控和可观测性体系,确保系统的稳定性和可靠性。建议定期进行监控评估,不断优化监控策略和可观测性方案。

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

联系我们

在线咨询:点击这里给我发消息

微信号:itpux-com

工作日:9:30-18:30,节假日休息