监控随想，业务和迭代
其实我不知道我在说啥*
These services are built around business capabilities and independently deployable by fully automated deployment machinery.
< Microservices > By Matin fowler
如 Matin 大爷所言，微服务的两个重要特征：面向业务和自动化。随着微服务架构的普及和深入，每一个线上业务都是由为数众多的独立运行的微服务协作完成的。加之容器、云计算等技术的引进使用，自动化工具链也加入战团，这一切情况的叠加，使得一个具体业务的整个生命周期所涉及的 IT 资产数量不断膨胀，并且微服务化带来的快速变更，原有的按照网域、按照应用类型等监控 Screen 的定义方式越来越难跟上业务需求，运维监控这一分支的技术工作成为背锅侠的风险越来越大。
目前见过的几个的监控方式，有几个共同点：
- 自发：有啥用啥，基于监控软件系统所提供的指标，结合个人经验，形成的主机和监控指标列表，以及建筑其上的 Graph、Screen 等。
- 独立：基础设施和构建其上的业务系统之间呈割裂状态，监控方面各行其是，甚至是业务和基础设施分别由不同的系统进行监控。忽略了底层到上层的实际联系。
- 断层：和开发团队不同，现有的很多监控技术的实现，并没有明确的知识管理、版本控制等技术传承手段，一定程度上影响了监控方面整体能力的成长。
对于一个长期存在并演进的项目来说，开发和监控都是这一产品生命周期的必要组成部分，换个角度来看监控，和很多业务系统一样，都是基于一个较大的基础系统之上进行配置和开发。如果从软件开发的方法来看待监控的话，这些问题似乎就不难解决了。
监控系统应该有明确的需求
监控事实上应该作为系统的功能性需求的常备部分，其中需要明确列出需要完成的业务指标和技术指标监控能力，对于不同类型的主机、集群和业务，应该有标准化的指标、图形和 Screen 组合（pattern/template）。
为增强易用性，还应该对监控图形展示、指标组合关系以及递进关系，做出适合展示和系统排错的设计。
例如一个短信系统，其短信队列的长度就是一个关键的业务指标，如果发送队列的长度持续增长，代表业务积压，对应的外部调用量、数据库压力、容器数量、南向接口响应时间等相关指标如果能够同屏呈现，无疑会同时给运营和运维极大助力。
监控系统也有架构
一般来说对于系统的监控是比较直接的，通常都有比较成熟的解决方法：
- 监控系统自带的指标和模板
- 软件厂商、开源社区等第三方指标和模板
- SNMP 等第三方通用协议的接入
而对于业务的监控就个性得多，也复杂得多了。对业务量的度量经常会使用到侵入式的检测方法，比如直接访问业务数据库，会遇到很多软件开发部署过程中的类似问题：
- 网络连通性：比如到数据库主机的连通性、到监控 Server、Proxy 的连通性等
- 系统负载：对监控服务器、数据库、日志等的使用所造成的系统压力
- 环境依赖：例如 Python 版本和模块、某些 Shell 命令
- 数据管理：数据的采集频率、转换、存储以及清理
如上所述，一个成熟的对系统的监控工作，其涉猎范围并不小于业务系统本身，不难理解，如此范围的功能叠加，没有适当的设计和实现过程，失控是可以预见的必然趋势，最终结果就是起不到应有的预警和复盘的能力，甚至对业务系统的运行造成干扰。
监控系统的代码管理
这里的代码二字，除了监控中使用的 SQL 和各种语言的脚本之外，还应该有针对监控平台的一些能够代码化的配置内容。
软件开发过程中常用到的分支、合并、Tag 等开发代码管理、甚至配置管理的技巧在这里同样适用。
监控系统的持续改进
上文提到种种，无非是为了说明，监控具有完整的生命周期，对业务系统的重要性自然也是不言而喻；运作健康良好的监控系统，需要有持续的智力投入，和其他业务功能一样，监控系统也是有具体的持续优化和演进的需要。
这里可以参考软件开发中的敏捷方法，来建立初步的监控开发内容。
主动的监控
总而言之，成熟的业务项目需要成熟的监控系统，作为项目中的重要技术组成部分，监控系统同样需要与时俱进、谋定后动。主动跟进架构演进，主动发现问题，业务视角会是监控工作的几个潜在的重要目标。
而随着监控系统的持续改进，数据关系的深入挖掘，监控系统将有助于系统故障的早期发现和预警，事后的复盘和故障的排除，业务的整体展现都会产生极大的帮助。