本文转载自微信公众号「虞大胆的叽叽喳喳」，作者虞大胆。转载本文请联系虞大胆的叽叽喳喳公众号。
我们有zabbix和promethous两种监控系统，其实理解监控本质很重要，正好看到《promethous监控实战》这本书，第一章对于监控的定义描述的非常好，分上下篇说明下。
监控是衡量和管理技术系统的工具和流程，但更重要的是监控能将系统和应用程序生成的指标转换为对应的业务价值。监控不仅能检测和解决故障，还能帮助洞察关键的产品和技术决策，并衡量项目是否成功。
监控的一些反模式
1：事后监控，将监控和运维工作是为应用程序的增值组件而非核心功能。
2：机械式监控
比如就监控主机的CPU，内存，而不监控应用程序是否正常运行的关键服务。
应该根据价值体系设计自上而下的监控系统，比如业务逻辑》应用程序》操作系统。
3：不够准确的监控
4：不频繁的监控
频繁的监控能够：
- 识别故障和异常
- 提供更细颗粒度的数据
- 满足响应时间预期，你总不希望用户提出故障吧
尽量保存长时间的监控数据，做出长期的趋势图。
5：缺少自动化和自服务
监控系统没做好的原因可能是很难实现，比如开发人员去做监控就很难，另外不成熟的监控系统可能需要手动维护，导致监控系统本身出现问题。
所以好的监控系统：
- 全局视角，从业务层依次展开监控
- 协助故障诊断
- 基础设施，是开发人员的信息源头
- 内置于应用程序设计、开发和部署的生命周期中。
监控机制
1：探针和内省
内省将事件、日志和指标发送到监控工具。而探针是查询应用程序的外部特征，比如端口是否开启。
2：拉取和推送
是将数据发完监控系统，还是监控系统主动拉取数据
3：监控数据的类型
数据主要有两种形式：
(1)指标，比如promethous就是典型的事件序列数据存储，用于应用程序度量的状态。
(2)日志，日志数据量大，一般是文本的事件，它们对于故障诊断最有用，比如ELK比较擅长日志收集和管理。
监控服务层级
来自于Google的经验，自上而下：
- 产品设计
- 软件开发
- 容量规划
- 测试和发布
- 事后总结/问题根源分析
- 应急事件处理
- 监控
