设为首页 - 加入收藏 汉中大乐透机选倍投一注 (http://www.0916zz.com)- 国内知名站长资讯网站,提供最新最全的站长资讯,创业经验,网站建设等!
热搜: 前瞻 1000 什么 beta
当前位置: 首页 > 运营中心 > 网站设计 > 教程 > 正文

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

发布时间:2019-05-18 05:45 所属栏目:[教程] 来源:京东云
导读:本期我们重点讲述微服务架构下的监控 微服务架构虽然诞生的时间并不长,却因为适应现今互联网的高速发展和敏捷、DevOps等文化而受到很多企业的推崇。微服务架构在带来灵活性、扩展性、伸缩性以及高可用性等优点的同时,其复杂性也给运维工作中最重要的监控

本期我们重点讲述微服务架构下的监控

微服务架构虽然诞生的时间并不长,却因为适应现今互联网的高速发展和敏捷、DevOps等文化而受到很多企业的推崇。微服务架构在带来灵活性、扩展性、伸缩性以及高可用性等优点的同时,其复杂性也给运维工作中最重要的监控环节带来了很大的挑战:海量日志数据如何处理,服务如何追踪,如何高效定位故障缩短故障时长……今天,我们就来谈一谈微服务架构下的监控应该注意哪些方面。

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

微服务架构带来的变化

微服务架构给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协议的支持能够更加方便的进行定制化开发,服务注册、信息采集和数据展示均支持多种形式/开源软件。

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

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章