《微服务设计》读书笔记（八）

微服务的监控的原则：监控小的服务，然后聚合起来看整体

1. 单一服务，单一服务器

1) 监控主机的CPU、内存等信息。可以使用Nagios或者New Relic

2) 查看服务器本身的日志，何时何地发生了什么事情

3) 监控应用程序本身，最低限度是监控服务的响应时间

2. 单一服务，多个服务器

1) 既要查看所有主机的数据，还要查看单个主机的数据。换句话说，即要数据聚合起来，又想深入分析每台主机。可以使用Nagios

2) 查看服务器的日志，需要用到分布式日志收集和分析工具，比如ELK。

3) 在负载均衡器里监控响应时间，另外，对负载均衡器本身也要监控，比如它的行为是否正常等。

4) 在负载均衡器里监控服务的健康状况

3. 多个服务，多个服务器

从日志到应用程序指标，集中收集和聚合尽可能多的数据

4. 多个服务的指标跟踪

秘诀：收集系统指标足够长的时间，直到清晰的模式浮现

1) 能够方便从新的主机收集指标

2) 能够看到整个系统聚合后的指标（例如，平均CPU负载）

3) 给定的一些服务实例聚合后的指标

4) 单个服务实例的指标

Graphite可以很容易实现上述要求：

1) 提供一个非常简单的API，允许实时发送指标数据给它

2) 通过查看这些指标生成的图标和其他展示方式来了解当前的情况

3) 通过有效的配置，可以减少旧指标的精度，以确保容量不会太大。例如：最近十分钟，每隔10秒记录一次主机CPU的指标；过去的一天，以分钟为单位对数据进行聚合；过去的几年，以30分钟为单位进行聚合

4) 可以跨样本做聚合，或者深入到某个部分，这样就可以查看整个系统、一组服务或者单独实例的响应时间。

了解趋势也可以帮组我们做容量规划，确保恰好有足够的基础设施来满足需求。

5. 服务指标

1) 公开服务的基本指标（系统指标），如响应时间和错误率等

2) 公开服务的应用相关的指标（应用程序级指标），如过往订单的次数，过去一天赚的钱数

很多平台都存在一些库来帮助服务发送指标到一个标准系统。Codahale的Metrics库，运作在JVM上，可以计数、计时或计量，支持带时间限制的指标，还可以把数据发送到Graphite 和其它汇总报告系统中。

6. 语义监控

使用合成事务来确保系统行为在语义上的正确性。

语义监控比使用低层次指标的告警更能表明系统的问题，然而语义监控也并不能取代低层次的监控，那些细节有助于我们了解什么语义监控会报告问题。

实现语义监控：服务／系统的端到端测试都是实现语义监控所需的。另外，我们的系统也已经开放了测试和查看结果所需要的钩子（hook）

7. 关联标识

一个服务调用最终会触发多个下游的服务调用，更为复杂的初始请求有可能生成一个下游的调用链，并且以异步的方式处理触发的事件。如何跟踪？

一个非常有用的方法是使用关联标识（ID）：在触发第一个调用时，生成一个GUID，然后把它传递给所有的后续调用。类似日志级别和日期，我们也可以把关联标识以结构化的方式写入日志。使用合适的日志聚合工具，就能够对事件在系统中触发的所用调用进行跟踪。

建议：创建一个内部客户端库来标准化这样的工作，并确保这个库是轻量的并且不依赖提供的任何特定服务。

8. 级联

监控系统之间的集成点非常关键

1) 每个服务的实例都应该追踪和显示其下游服务的健康状态，从数据库到其它合作服务。

2) 了解下游服务调用的响应时间，并检测是否有错误

3) 汇总这些信息，得到一个整合的画面

建议：使用库实现一个断路器网络调用，以更加优雅地处理级联故障和功能降级

9. 标准化

监控这个领域的标准化至关重要：服务之间的多个接口，可以用很多不同的方式合作来提供功能，需要以全局的视角来规划。

1) 标准格式来记录日志

2) 把所有的指标放到一个地方

3) 为度量提供一个标准名称的列表

4) 使用工具在标准化方面提供帮助

10. 考虑受众

监控收集的数据会触发一些事件，有些数据会触发支持团队立即采取行动。

需要考虑一下因素：

1) 现在需要知道什么

2) 之后想要什么

3) 如何消费数据

11. 未来：指标聚合

同一化各种指标聚合方式，例如，以同样的方式处理运营指标和业务指标。从专门只做一件事的系统转向通用事件处理系统。不再为不同类型的指标提供专门的工具链，而是提供伸缩性很好的更为通用的事件路由系统。

Riemann：事件服务器，允许高级的聚合和事件路由，该工具可以作为上述解决方案的一部分

Suro：Netflix的数据流水线，明确可以处理两种数据：用户行为的相关指标和更多的运营数据。然后这些数据可以被分发到不同的系统中，像Storm的实时分析、离线批处理的Hadoop或日志分析的Kibana