《微服务设计》第 8 章 监控
- 2019 年 10 月 8 日
- 笔记
第 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》
