微服务架构下的监控须要注意哪些方面？

微服务架构在带来灵活性、扩展性、伸缩性以及高可用性等优势的同时，其复杂性也给运维工做中最重要的监控环节带来了很大的挑战，从用户的角度看，微服务架构下的监控应该注意哪些方面？ 微服务架构虽然诞生的时间并不长，却由于适应现今互联网的高速发展和敏捷、DevOps 等文化而受到不少企业的推崇。微服务架构在带来灵活性、扩展性、伸缩性以及高可用性等优势的同时，其复杂性也给运维工做中最重要的监控环节带来了很大的挑战：海量日志数据如何处理，服务如何追踪，如何高效定位故障缩短故障时常……

InfoQ 记者采访了京东云应用研发部门运维负责人，来谈一谈微服务架构下的监控应该注意哪些方面。

微服务架构带来的变化 在京东云运维专家看来，微服务架构给 IT 系统和团队带来了如下显著的变化：

基础设施的升级，须要引入虚拟化（如 Docker），现存基础设施也须要与之进行适配；

系统架构的升级，须要引入服务注册（如 Consul），服务间的交互方式也须要与之进行适配；

运维平台的升级，建议引入日志收集（如 Fluentd），分布式跟踪（如 Zipkin）和仪表盘（如 Vizceral/Grafana）等；

运维效率和自动化水平的提高也迫在眉睫，不然没法应对实例数量，变动频率，系统复杂度的快速增加；

观念的转变，基础设施，系统架构和运维平台等的大幅升级，犹如小米加步枪换成飞机大炮，相应的战略战术也须要与之相适配才行。

微服务架构下用户面临的监控问题 在转型到微服务架构之后，用户在监控方面主要会面临如下问题。

首先，监控配置的维护成本增长。某个在线系统大概有 106 个模块，每一个模块都须要添加端口监控，进程监控，日志监控和自定义监控；不一样服务的监控指标，聚合指标，报警阈值，报警依赖，报警接收人，策略级别，处理预案和备注说明也不彻底相同；如此多的内容，如何确保是否有效，是否生效，是否完整无遗漏。当前针对维护成本，业界经常使用的几种方法有：

经过变量的方式尽可能减小人工输入；

经过监控配置文件解析作一些可标准化的校验；

经过故障演练验证报警是否符合预期；

其次，第三方依赖愈来愈多。例如 Docker 的可靠性很大程度上取决于宿主机，若是所在的宿主机发生资源争用，网络异常，硬件故障，修改内核参数，操做系统补丁升级等，均可能会让 Docker 莫名其妙地中招。

第三，服务故障的定位成本增长。假设故障是由于特定服务处理耗时增大致使的，那么如何快速从 106 个服务以及众多的第三方依赖中把它找出来，进一步，又如何确认是这个服务的单个实例仍是部分实例的异常，这些都让故障定位变得更复杂。

在微服务架构下，提升故障定位效率的经常使用方法有：基于各种日志分析，经过仪表盘展现核心指标：数据流，异常的监控策略，变动内容，线上登陆和操做记录，文件修改等内容。

微服务监控的难点及解决思路 在微服务架构下，监控系统在报警时效性不可改变的前提下，采集的指标数量是传统监控的三倍以上，若是是万台以上的规模，监控系统总体都面临很是大的压力，在监控方面的挑战主要来源于：

首先，存储功能的写入压力和可用性都面临巨大挑战。每秒写入几十万采集项而且须要保证 99.99% 的可用性，对于任何存储软件来说，都不是一件轻松的事情。对于写入和可用性的压力，业界常见的解决思路主要是基于以下方式的组合：

集群基于各类维度进行拆分（如地域维度、功能维度和产品维度等）；

增长缓存服务来下降 Hbase 的读写压力；

调整使用频率较低指标的采集周期；

经过批量写入下降 Hbase 的写入压力；

经过写入两套 Hbase 避免数据丢失并作到故障后快速切换。

其次，监控的生效速度也面临巨大挑战。微服务架构下，基于弹性伸缩的加持，从服务扩容或者迁移完毕到接入流量的耗时下降到 1Min 左右，且每时每刻都在不断发生着。对于复杂监控系统来说，支持这样的变动频率绝非易事，并且实例变动如此频繁，对监控系统自身来说，也会面临可用性的风险。

常见的提升监控生效速度的思路主要有以下的几种方式：

实时热加载服务注册信息；

对监控配置的合规性进行强校验；

增长实例数量的阈值保护；

支持配置的快速回滚。

第三，基础设施的故障可能致使报警风暴的发生。基础设施如 IDC 故障，可能会在瞬时产生海量报警，进而致使短信网关拥塞较长时间。

解决这类问题的思路主要是以下方式：

基于报警接收人经过延时发送进行合并；

报警策略添加依赖关系；

优先发送严重故障的报警短信；

增长多种报警通知方式如电话，IM 等。

微服务监控原则 对于采用微服务的团队，京东云运维专家建议在作监控时能够参考 Google SRE 的理论，结合本身长期的运维实践经验，他总结了几点能够参考的原则：

首先，全部系统和第三方依赖的核心功能必须添加黑盒监控；

第二，全部模块必须添加白盒监控的四个黄金指标（饱和度，错误，流量和延时）；

第三，全部的变动都须要进行采集，包括但不限于程序，配置，数据，网络，硬件，操做系统以及各种基础设施。

另外，京东云运维专家也给你们提供了一些黑盒监控的实施经验：

首先，应该监控哪些功能？建议将系统接入层的访问日志，TOP-10 的 URL 添加黑盒监控。那 TOP-9 的 URL 是否必定须要监控？TOP-11 的 URL 是否必定不须要监控？这取决于其访问量是否和前面的 URL 在一个数量级以及人工评估其接口的重要性程度，这里提供的更可能是一个思路，而非可量化的方法。

第二，应该使用多少个样本 / 节点对一个功能进行黑盒监控？建议样本应该覆盖到对应模块的全部实例，这样也能发现由少数实例致使的小规模故障。

微服务架构下的理想监控系统 从用户的角度看，Prometheus 的总体架构设计参考了 Google BorgMon，系统具备高度的灵活性，围绕其开放性如今也慢慢造成了一个生态系统。具体来讲，Prometheus 使用的是 Pull 模型，Prometheus Server 经过 HTTP 的 Pull 方式到各个目标拉取监控数据。HTTP 协议的支持可以更加方便的进行定制化开发，服务注册、信息采集和数据展现均支持多种形式 / 开源软件。

结合目前国内正在兴起的智能运维，也许不久的未来，上面提到的监控的各类问题也就迎刃而解了。监控策略不在须要人工定义，转由机器学习负责，诸如策略添加，阈值设定，异常检测，故障定位，自动止损等逐步由系统负责，运维人员再也不是“救火队长”。

京东云监控响应实践 京东云运维平台为数万台机器提供监控，部署，机器管理，权限管理，安全管理，审计和运营分析等功能，为京东云全部的业务在各种异构网络环境下提供标准和统一的运维支撑能力。

基于产品所处的发展阶段，用户规模的不一样，报警频率也不尽相同。理想状况下，报警频率应该等同于故障频率，这里面体现了报警的准确度和召回率两个指标，若是每一个报警都对应一个服务故障，则准确度为 100%，同理，若是每次服务故障均有报警产生，则召回率为 100%。你们能够基于上述两个指标，来衡量本身团队的现状，并针对性的制定提高计划便可。

对于响应流程，京东云有几个作的好的地方能够给你们参考。

首先，全部核心报警均有可靠的应对预案和处理机制，并经过按期的破坏演练持续进行完善。

其次，公司的监控中心会 7x24 值守，他们也会和业务线运维同窗同样，接收全部影响核心系统稳定性的报警，收到报警后会进行通报，确保核心报警在发生后第一时间内有人处理并在规定的时间内处理完毕。若是未在规定的时间内处理完毕，监控中心会进行报警升级，通报该系统的管理人员，从而确保该报警能够获得更高的重视度和支持力度。

结语 对于监控系统的将来发展，京东云的运维专家认为长期来看，依托于 Kubernetes 的发展，在基础设施的各个领域，都会从百花齐放到几家独大，从而将标准化落地到基础设施的各个领域，进而促进整个生态的繁荣。

在监控方向，Prometheus 在将来一段时间后，也许会是一个很好的选择。在 Prometheus 等工具解决了通用的监控场景并标准化以后，在其上的各种应用场景，如容量规划，流量监控，故障定位以及各类基于大数据和人工智能场景的落地等，就会出现百花齐放之势。

本文彩蛋 监控系统是整个 IT 架构中的重中之重，小到故障排查、问题定位，大到业务预测、运营管理，都离不开监控系统，能够说一个稳定、健康的 IT 架构中必然会有一个可信赖的监控系统。 欢迎工做一到五年的Java工程师朋友们加入Java程序员开发： 854393687 群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用本身每一分每一秒的时间来学习提高本身，不要再用"没有时间“来掩饰本身思想上的懒惰！趁年轻，使劲拼，给将来的本身一个交代！