核心要点摘要
- Categraf、Prometheus Exporter 以及各类采集器会采集大量英文指标，指标含义通常无法在一个地方查全。
- 排查指标含义时，建议先看仪表盘和告警规则，因为这些地方通常只保留运维场景中更常用的指标。
- 夜莺的指标视图会补充单位、中文名和注释，但这类整理工作量很大，目前仍在逐步完善。
- 如果仪表盘、告警规则和指标视图都查不到，就需要回到采集器源码、数据库官方文档或组件官方文档。
- 商业版客户遇到常用指标含义问题，可以联系快猫团队协助定位；非常冷门的指标也需要一起查源码或官方文档。
问题：在哪里看监控指标的含义说明
Categraf 或其他各类采集器会采集非常多的监控指标。对于新手而言，最常见的问题是：这些英文指标分别代表什么意思，应该去哪里看说明？
这个问题没有一个完美答案。通常可以从 4 个地方了解指标含义，但每个地方都不完整。
| 查找位置 | 适合查什么 | 局限 |
|---|---|---|
| 仪表盘 | 常用指标、图表标题、图表备注、面板单位 | 需要挨个面板查看，而且只覆盖常用指标 |
| 告警规则 | 告警相关指标、规则名称、规则描述、阈值语义 | 只能覆盖被写进规则的指标 |
| 夜莺指标视图 | 单位、中文名、注释、常见组件指标 | 仍在持续完善，无法覆盖所有组件和所有指标 |
| 源码和官方文档 | 原始采集逻辑、组件内部状态、数据库官方变量含义 | 阅读成本高，有些指标需要同时理解组件和采集器实现 |
先看仪表盘和告警规则
第一类信息来自仪表盘。通过梳理每个仪表盘的配置，可以获知一些指标含义。有些图表还有详细备注，更方便理解。但这个方法比较费劲，而且仪表盘里一般只会放较常用的指标，不会覆盖所有指标。
第二类信息来自告警规则。夜莺有一些内置告警规则，Prometheus 生态里也能搜到其他人整理的告警规则。告警规则通常包含名字、描述和表达式，可以从中理解某些指标的业务含义。
再看夜莺的指标视图
第三类信息来自夜莺的指标视图。夜莺的指标视图希望把常用指标整理出来，并补充单位、中文名字、注释等信息。不过这个工作量巨大，目前仍在逐步完善中。示例如下：
这些内容是从 integrations 目录下各个组件的 metrics 目录里的内容导入到 DB 中的，欢迎大家提 PR 来补充，就提到 integrations 下，仿照其他组件的 metrics 目录里的内容即可。
为什么不可能把所有指标说明一次性整理完整
有些组件会暴露非常多的指标。例如一个单节点的 ElasticSearch，如果把 ElasticSearch 暴露的所有指标都采集下来，即便索引比较少，指标数量也可能非常多。要把所有指标含义都整理出来，几乎不可能。
更麻烦的是，很多指标不是只看名字就能理解。它可能要求你既懂 ElasticSearch 的原理和源码，也懂采集器的实现逻辑。对于这类指标，通用说明只能解决一部分问题。
最后查源码和官方文档
第四个地方自然就是源码。其实有时即便看了采集器的源码，也搞不懂指标含义，比如 MySQL 采集插件，采集了很多 MySQL 的全局状态数据，是通过执行 SQL：SHOW GLOBAL STATUS 来获取的：
MariaDB [(none)]> show global status;
+------------------------------+------------+
| Variable_name | Value |
+------------------------------+------------+
| Aborted_clients | 3359 |
| Aborted_connects | 4923538 |
| Access_denied_errors | 11 |
| Acl_column_grants | 0 |
| Acl_database_grants | 1 |
| Acl_function_grants | 0 |
| Acl_procedure_grants | 0 |
| Acl_package_spec_grants | 0 |
| Acl_package_body_grants | 0 |
| Acl_proxy_users | 2 |
...
如上，左侧是指标名字，右侧是 value，作为采集器的研发人员，其实不需要知道各个指标是什么含义，直接采集了就可以了，所以你要问采集器的研发，他也未必能帮到你。MySQL 这些指标是什么含义可以从 MySQL 官方文档查询到。
建议的查找顺序
如果你遇到一个不认识的监控指标，可以按下面的顺序查：
- 先在对应组件的仪表盘里搜索指标名，看是否有图表标题、单位或备注。
- 再在告警规则里搜索指标名，看它是否已经用于告警判断。
- 如果使用夜莺，继续到指标视图里查中文名、单位和注释。
- 仍然查不到时，回到采集器源码，确认指标是从哪个接口、命令或状态变量采集出来的。
- 最后查组件官方文档，例如 MySQL 的全局状态变量、MongoDB 的 serverStatus、Redis 的 INFO 输出等。
总结
想要在一个地方看到所有指标的含义，很遗憾，目前没有。更现实的方式是先从仪表盘、告警规则和夜莺指标视图查常用指标；如果找不到，再回到源码和官方文档。
这个问题经常被问到，所以在这里统一答复一下。如果是商业版客户，遇到不懂的指标可以来问我们。常用指标含义我们通常了解；有些非常冷门的指标，我们也未必能凭经验直接回答，但可以一起去查源码和官方文档。
FAQ
Q1：为什么采集器没有直接提供所有指标的中文解释？
A：采集器的主要职责是采集和暴露数据，很多指标来自被监控组件自身。采集器研发人员可以知道指标从哪里来，但未必掌握每个组件内部变量的完整业务含义。
Q2：夜莺指标视图能覆盖全部指标吗？
A：不能。夜莺指标视图会持续整理常用指标的单位、中文名和注释，但组件数量和指标数量都很大，只能逐步完善。
Q3：最可靠的指标解释来源是什么？
A：通常是组件官方文档和采集器源码。仪表盘、告警规则和指标视图更适合快速理解常用指标，源码和官方文档更适合确认冷门指标的准确含义。
