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