yeedomliu
《微服务设计》第 8 章 监控
关注作者
前往小程序,Get
更优
阅读体验!
立即前往
腾讯云
开发者社区
文档
建议反馈
控制台
登录/注册
首页
学习
活动
专区
工具
TVP
最新优惠活动
文章/答案/技术大牛
搜索
搜索
关闭
发布
首页
学习
活动
专区
工具
TVP
最新优惠活动
返回腾讯云官网
yeedomliu
首页
学习
活动
专区
工具
TVP
最新优惠活动
返回腾讯云官网
社区首页
>
专栏
>
《微服务设计》第 8 章 监控
《微服务设计》第 8 章 监控
yeedomliu
关注
发布于 2019-09-28 12:58:13
819
0
发布于 2019-09-28 12:58:13
举报
文章被收录于专栏:
yeedomliu
第 8 章 监控
将系统拆分成更小的、细粒度的微服务会带来很多好处。然而,它也增加了生产系统的监控复杂性
ssh-multiplexers 这样的工具,在多个主机上运行相同的命令。用一个大的显示屏,和一个 grep "Error" app.log,我们就可以定位错误了
8.3 多个服务,多个服务器
你如何在多个主机上的、成千上万行的日志中定位错误的原因?如何确定是一个服务器异常,还是一个系统性的问题?如何在多个主机间跟踪一个错误的调用链,找出引起这个错误的原因?答案是,从日志到应用程序指标,集中收集和聚合尽可能多的数据到我们的手上
8.4 日志,日志,更多的日志
Kibana(https://www.elastic.co/products/kibana)是一个基于 ElasticSearch 查看日志的系统, 如图 8-4 所示。你可以使用查询语法来搜索日志,它允许在查询时指定时间和日期范围,或使用正则表达式来查找匹配的字符串。Kibana 甚至可以把你发给它的日志生成图表,只需看一眼就能知道已经发生了多少错误
Kibana 甚至可以把你发给它的日志生成图表,只需看一眼就能知道已经发生了多少错误
8.5 多个服务的指标跟踪
我们希望能够看到整个系统聚合后的指标(例如,平均的 CPU 负载),但也会想要给定的一些服务实例聚合后的指标,甚至某单个服务实例的指标。这意味着,我们需要将指标的元数据关联,用来帮助推导出这样的结构
Graphite 就是一个让上述要求变得很容易的系统。它提供一个非常简单的 API,允许你实时发送指标数据给它
8.6 服务指标
当你在 Linux 机器上安装 collectd 并让它指向 Graphite 时,会发现我们运行的操作系统会生成大量的指标。同样,像 Nginx 或 Varnish 这样的支撑子系统,也会暴露很多有用的信息,例如响应时间或缓存命中率
我强烈建议你公开自己服务的基本指标。作为 Web 服务,最低限度应该暴露如响应时间和错误率这样的一些指标
首先,有一句老话,80% 的软件功能从未使用过
其次,可以通过了解用户如何使用我们的系统得知如何改进,在这个方面,我们比以往任何时候做得都要好
最后,我们永远无法知道什么数据是有用的!
很多平台都存在一些库来帮助服务发送指标到一个标准系统中。Codahale 的 Metrics 库(http://metrics.codahale.com/)就是这样一个运行在 JVM 上的库。它允许你存储一些指标,例如计数器、计时器或计量表(gauge); 支持带时间限制的指标(这样你就可以指定如“过去五分钟的订单数量”这样的指标);
8.7 综合监控
我们可以通过定义正常的 CPU 级别,或者可接受的响应时间,判断一个服务是否健康。如果我们的监控系统监测到实际值超出这些安全水平,就可以触发警告。类似像 Nagios 这样的工具,完全有能力做这个
实现语义监控
8.8 关联标识
一个非常有用的方法是使用关联标识(ID)。在触发第一个调用时,生成一个 GUID。然后把它传递给所有的后续调用
使用关联标识时,一个现实的问题是,你常常直至问题出现才知道需要它,而且只有在开始时就存在关联标识才可能诊断出问题!
8.9 级联
监控系统之间的集成点非常关键。每个服务的实例都应该追踪和显示其下游服务的健康状态,从数据库到其他合作服务。你也应该将这些信息汇总,以得到一个整合的画面。你会想了解下游服务调用的响应时间,并检测是否有错误
一些库,例如 JVM 上的 Hystrix,便很好地提供了这些监控功能
8.10 标准化
你应该尝试以标准格式的方式记录日志。你一定想把所有的指标放在一个地方,你可能需要为度量提供一个标准名称的列表;如果一个服务指标叫作 ResponseTime,另一个叫作 RspTimeSecs,而它们的意思是一样的,这会非常令人讨厌
8.11 考虑受众
我们为不同的人收集这些数据,帮助他们完成工作;这些数据会触发一些事件。有些数据会触发支持团队立即采取行动,比如我们的一个综合监控测试失败了
8.12 未来
为什么不能以同样的方式处理运营指标和业务指标?最终,两种类型的指标分解成事件后,都说明在 X 时间点发生了一些事情。如果我们可以统一收集、聚合及存储这些事件的系统,使它们可用于报告,最终会得到一个更简单的架构
Riemann(http://riemann.io/)是一个事件服务器,允许高级的聚合和事件路由,所以该工具可以作为上述解决方案的一部分。Suro(https://github.com/Netflix/suro)是 Netflix 的数据流水线,其解决的问题与 Riemann 类似。Suro 明确可以处理两种数据,用户行为的相关指标和更多的运营数据(如应用程序日志)。然后这些数据可以被分发到不同的系统中,像 Storm 的实时分析、离线批处理的 Hadoop 或日志分析的 Kibana
8.13 小结
对每个服务
最低限度要跟踪请求响应时间。做好之后,可以开始跟踪错误率及应用程序级的指标
最低限度要跟踪所有下游服务的健康状态,包括下游调用的响应时间,最好能够跟踪错误率。一些像 Hystrix 这样的库,可以在这方面提供帮助
标准化如何收集指标以及存储指标
如果可能的话,以标准的格式将日志记录到一个标准的位置。如果每个服务各自使用不同的方式,聚合会非常痛苦!
监控底层操作系统,这样你就可以跟踪流氓进程和进行容量规划
对系统
聚合 CPU 之类的主机层级的指标及应用程序级指标
确保你选用的指标存储工具可以在系统和服务级别做聚合,同时也允许你查看单台主机的情况
确保指标存储工具允许你维护数据足够长的时间,以了解你的系统的趋势
使用单个可查询工具来对日志进行聚合和存储
强烈考虑标准化关联标识的使用
了解什么样的情况需要行动,并根据这些信息构造相应的警报和仪表盘
调查对各种指标聚合方式做统一化的可能性,像 Suro 或 Riemann 这样的工具可能会对你有用
书
Stephen Few 的优秀图书:《Information Dashboard Design: Displaying Data for Ata-Glance Monitoring》
《Lightweight Systems for Realtime Monitoring》
本文参与
腾讯云自媒体同步曝光计划
,分享自微信公众号。
原始发表:2019-09-27,如有侵权请联系
cloudcommunity@tencent.com
删除
apache
本文分享自
yeedomliu
微信公众号,
前往查看
如有侵权,请联系
cloudcommunity@tencent.com
删除。
本文参与
腾讯云自媒体同步曝光计划
,欢迎热爱写作的你一起参与!
apache
评论
登录
后参与评论
0 条评论
热度
最新
推荐阅读
LV.
文章
0
获赞
0
目录
第 8 章 监控
8.3 多个服务,多个服务器
8.4 日志,日志,更多的日志
8.5 多个服务的指标跟踪
8.6 服务指标
8.7 综合监控
8.8 关联标识
8.9 级联
8.10 标准化
8.11 考虑受众
8.12 未来
8.13 小结
书
相关产品与服务
Elasticsearch Service
腾讯云 Elasticsearch Service(ES)是云端全托管海量数据检索分析服务,拥有高性能自研内核,集成X-Pack。ES 支持通过自治索引、存算分离、集群巡检等特性轻松管理集群,也支持免运维、自动弹性、按需使用的 Serverless 模式。使用 ES 您可以高效构建信息检索、日志分析、运维监控等服务,它独特的向量检索还可助您构建基于语义、图像的AI深度应用。
免费体验
产品介绍
产品文档
ES特惠专场,首月1折秒杀,新客首购7折起!
领券
问题归档
专栏文章
快讯文章归档
关键词归档
开发者手册归档
开发者手册 Section 归档
0
0
0
推荐