|
作者 | 京东云应用研发部门运维负责人 编辑 | 张婵 微服务架构在带来灵活性、扩展性、伸缩性以及高可用性等优点的同时，其复杂性也给运维工作中最重要的监控环节带来了很大的挑战，从用户的角度看，微服务架构下的监控应该注意哪些方面？ 微服务架构虽然诞生的时间并不长，却因为适应现今互联网的高速发展和敏捷、DevOps 等文化而受到很多企业的推崇。微服务架构在带来灵活性、扩展性、伸缩性以及高可用性等优点的同时，其复杂性也给运维工作中最重要的监控环节带来了很大的挑战：海量日志数据如何处理，服务如何追踪，如何高效定位故障缩短故障时常…… InfoQ 记者采访了京东云应用研发部门运维负责人，来谈一谈微服务架构下的监控应该注意哪些方面。 微服务架构带来的变化 在京东云运维专家看来，微服务架构给 IT 系统和团队带来了以下显著的变化：
微服务架构下用户面临的监控问题 在转型到微服务架构以后，用户在监控方面主要会面临以下问题。 首先，监控配置的维护成本增加。某个在线系统大概有 106 个模块，每个模块都需要添加端口监控，进程监控，日志监控和自定义监控；不同服务的监控指标，聚合指标，报警阈值，报警依赖，报警接收人，策略级别，处理预案和备注说明也不完全相同；如此多的内容，如何确保是否有效，是否生效，是否完整无遗漏。当前针对维护成本，业界常用的几种方法有：
其次，第三方依赖越来越多。例如 Docker 的可靠性很大程度上取决于宿主机，如果所在的宿主机发生资源争用，网络异常，硬件故障，修改内核参数，操作系统补丁升级等，都可能会让 Docker 莫名其妙地中招。 第三，服务故障的定位成本增加。假设故障是因为特定服务处理耗时增大导致的，那么如何快速从 106 个服务以及众多的第三方依赖中把它找出来，进一步，又如何确认是这个服务的单个实例还是部分实例的异常，这些都让故障定位变得更复杂。 在微服务架构下，提高故障定位效率的常用方法有：基于各类日志分析，通过仪表盘展示核心指标：数据流，异常的监控策略，变更内容，线上登录和操作记录，文件修改等内容。 微服务监控的难点及解决思路 在微服务架构下，监控系统在报警时效性不可改变的前提下，采集的指标数量是传统监控的三倍以上，如果是万台以上的规模，监控系统整体都面临非常大的压力，在监控方面的挑战主要来源于： 首先，存储功能的写入压力和可用性都面临巨大挑战。每秒写入几十万采集项并且需要保证 99.99% 的可用性，对于任何存储软件来讲，都不是一件轻松的事情。对于写入和可用性的压力，业界常见的解决思路主要是基于如下方式的组合：
其次，监控的生效速度也面临巨大挑战。微服务架构下，基于弹性伸缩的加持，从服务扩容或者迁移完毕到接入流量的耗时降低到 1Min 左右，且每时每刻都在不断发生着。对于复杂监控系统来讲，支持这样的变更频率绝非易事，而且实例变更如此频繁，对监控系统自身来讲，也会面临可用性的风险。 常见的提高监控生效速度的思路主要有如下的几种方式：
第三，基础设施的故障可能导致报警风暴的发生。基础设施如 IDC 故障，可能会在瞬时产生海量报警，进而导致短信网关拥塞较长时间。 解决这类问题的思路主要是如下方式：
微服务监控原则 对于采用微服务的团队，京东云运维专家建议在做监控时可以参考 Google SRE 的理论，结合自己长期的运维实践经验，他总结了几点可以参考的原则：
另外，京东云运维专家也给大家提供了一些黑盒监控的实施经验： 首先，应该监控哪些功能？建议将系统接入层的访问日志，TOP-10 的 URL 添加黑盒监控。那 TOP-9 的 URL 是否一定需要监控？TOP-11 的 URL 是否一定不需要监控？这取决于其访问量是否和前面的 URL 在一个数量级以及人工评估其接口的重要性程度，这里提供的更多是一个思路，而非可量化的方法。 第二，应该使用多少个样本 / 节点对一个功能进行黑盒监控？建议样本应该覆盖到对应模块的所有实例，这样也能发现由少数实例导致的小规模故障。
免责声明：本网站内容由网友自行在页面发布，上传者应自行负责所上传内容涉及的法律责任，本网站对内容真实性、版权等概不负责，亦不承担任何法律责任。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，并请自行核实相关内容。本站不承担此类作品侵权行为的直接责任及连带责任。如若本网有任何内容侵犯您的权益，请及时联系我们，本站将会在24小时内处理完毕。
发布者:科技君
|
京公网安备11010802031211号