本期我们重点介绍微服务架构下的监控。微服务架构虽然诞生时间不长，但因为适应了互联网的飞速发展和敏捷、DevOps的文化，受到了很多公司的推崇。微服务架构在带来灵活性、可扩展性、扩展性、高可用等优势的同时，其复杂性也给运维工作中最重要的监控环节带来了巨大挑战：海量日志数据如何处理、服务如何跟踪、服务如何跟踪高效定位故障，缩短故障持续时间……今天，我们就来说说微服务架构下的监控需要注意哪些方面。微服务架构带来的变化微服务架构给IT系统和团队带来了以下显着变化：基础设施的升级需要引入虚拟化（如Docker），现有的基础设施需要与之适配；系统架构升级需要引入服务注册（比如Consul），服务之间的交互也需要适配；对于运维平台的升级，建议引入日志采集（如Fluentd）、分布式追踪（如Zipkin）和仪表盘（如Vizceral/Grafana）等；运维效率和自动化水平的提升也迫在眉睫，否则无法应对快速增长的实例数量、变更频率和系统复杂度；理念、基础设施、系统架构、运维平台等方面的变化。要有实质性的升级，相应的战略战术也需要与之相适应。微服务架构下用户面临的监控问题过渡到微服务架构后，用户在监控方面主要会面临以下问题。首先，监控配置的维护成本增加。一个线上系统大概有106个模块，每个模块需要添加端口监控、进程监控、日志监控和自定义监控；不同服务的监控指标、聚合指标、告警阈值、告警依赖、告警接收者、策略级别，处理方案和注意事项不完全相同；这么多内容，如何保证是否有效，是否有效，是否完整。目前业界常用的维护成本有以下几种方法：通过变量尽量减少人工输入。解析监控配置文件，做一些标准化的校验。通过故障演练验证告警是否符合预期。第二，第三方依赖越来越多。.例如，Docker的可靠性在很大程度上取决于宿主机。如果宿主机出现资源争用、网络异常、硬件故障、内核参数被修改、操作系统补丁升级等情况，Docker都可能被莫名其妙地中招。第三，定位服务故障的成本增加。假设故障是由于某个服务的处理时间增加导致的，如何从106个服务和众多第三方依赖中快速找出，并进一步确认是这个服务的单个实例还是某些实例的异常，这些都让故障定位变得更加复杂。微服务架构下，常见的提高故障定位效率的方法有：基于各种日志分析，通过仪表盘展示核心指标：数据流向、异常监控策略、变更内容、在线登录和操作记录、文件修改，ETC。。微服务监控难点及解决方案微服务架构下，监控系统在不改变告警时效性的前提下，采集的指标是传统监控的3倍以上。面临巨大压力，监控方面的挑战主要来自：一是存储功能的写入压力和可用性面临巨大挑战。每秒写入数十万条采集项，并保证99.99%的可用性，对于任何存储软件来说都不是一件容易的事。针对编写和可用性的压力，业界常见的解决方案主要基于以下几种方式的组合：基于各个维度（如地域维度、功能维度、产品维度等）对集群进行拆分；增加缓存服务，降低Hbase读写压力；调整使用频率低的指标采集周期；通过批量写入降低Hbase的写入压力；通过写两套Hbase，避免数据丢失，实现故障后快速切换。其次，监控的有效速度也面临着很大的挑战。在微服务架构下，基于弹性伸缩的支持，从服务扩展或迁移到访问流量的耗时减少到1Min左右，并且一直在持续发生。对于一个复杂的监控系统来说，支持这样的变更频率并不容易，而且如此频繁的实例变更也会让监控系统本身面临可用性风险。提高监控有效性速度的常用方法有：实时热加载服务注册信息；监控配置合规性的强大验证；增加实例数量的阈值保护；支持快速回滚配置。第三，基础设施故障可能引发警报风暴。IDC等基础设施故障可能会在瞬间产生大量告警，导致短信网关长时间拥塞。解决此类问题的主要思路如下：通过延迟发送，基于告警接收者进行合并；为告警策略添加依赖；严重故障优先报警；增加电话、IM等多种告警通知方式。微服务监控原理对于使用微服务的团队，建议在做监控时参考GoogleSRE的理论。结合长期的运维实践经验，我们总结出几个可以参考的原则：第一，所有系统和第三方依赖必须在核心功能中加入黑盒监控；第二，所有模块必须添加白盒监控的四大黄金指标（饱和度、错误率、流量和延迟）；第三，需要收集所有变更，包括但不限于程序、配置、数据、网络、硬件、操作系统和各种基础设施。另外，我们也给大家提供一些黑盒监控的实现经验：首先，应该监控哪些功能？建议对系统访问层的访问日志和URL添加黑盒监控。TOP-9URL是否一定需要监控？URL是否一定需要监控？这取决于它的流量是否和之前的URL在同一个数量级，以及人工评估它的接口的重要性。这里更多的是一种想法，而不是一种量化的方法。第二，应该使用多少个样本/节点来对一个函数进行黑盒监控？建议样本覆盖对应模块的所有实例，这样也能发现少数实例引起的小规模故障。微服务架构下的理想监控系统从用户的角度来看，Prometheus的整体架构设计参考了GoogleBorgMon。该系统具有高度的灵活性，围绕其开放性逐渐形成了一个生态系统。具体来说，Prometheus采用Pull模型，PrometheusServer通过HTTPPull的方式从各个target中拉取监控数据。HTTP协议的支持可以让定制化开发更加方便，服务注册、信息采集、数据展示都支持各种形式/开源软件。结合国内正在兴起的智能化运维，或许在不久的将来，上面提到的各种监控问题都会迎刃而解。监控策略不再需要手动定义，而是转为机器学习。系统负责添加策略、设置阈值、异常检测、故障定位、自动止损。京东云监控与响应实践京东云运维平台提供数万台机器的监控、部署、机器管理、权限管理、安全管理、审计、运行分析等功能，为京东云所有业务提供服务各种异构网络环境。提供标准统一的运维支撑能力。根据产品的发展阶段和用户规模，报警频率也不同。理想情况下，报警频率应该等于故障频率，它反映了报警的准确率和召回率。如果每条告警对应一次业务故障，则准确率为100%。同理，如果每次服务失败都会产生Alarm，召回率为100%。根据以上两个指标，你可以衡量你的团队的现状，并制定有针对性的改进计划。关于响应流程，京东云有几个好的点供大家参考：第一，所有核心告警都有可靠的响应预案和处理机制，并通过定期的损毁演练不断完善。其次，公司监控中心7x24小时值班。像业务线运维同学一样，会收到所有影响核心系统稳定性的告警。时间内处理。若未在规定时间内处理完毕，监控中心将升级告警并通知系统管理人员，确保告警得到更高的关注和支持。总结监控系统未来的发展，从长远来看，依托Kubernetes的发展，在基础设施的各个领域，都会被少数主导公司所取代，从而在基础设施的各个领域实现标准化，进而推动整个生态的发展。繁荣。在监控方向，Prometheus未来可能是一个不错的选择。Prometheus等工具解决了通用的监控场景并标准化之后，就会出现在其上的各种应用场景，比如容量规划、流量监控、故障定位，以及基于大数据和人工智能的各种场景的实现。趋势。【本文为专栏作者“京东云”原创稿件，转载请通过作者微信公众号JD-jcloud获得授权】点此查看作者更多好文
