读书笔记《微服务设计》---监控

书籍《微服务设计》，地址：微服务设计 (豆瓣)

微服务会带来很多好处，但是也增加了生产系统的监控复杂性。有个方法就是监控小的服务，然后聚合起来看整体。

1、单一服务，单一服务器：一台主机运行一个服务。需要监控主机（CPU，内存等）、服务器日志（日志可以显示何时何地发生了这个错误）、应用程序（最低限度是要监控服务的响应时间）。

2、单一服务，多个服务器：一个服务的多个副本实例运行在多个独立的主机上，通过负载均衡分发不同的请求到不同的服务实例。这种情况，需要监控所有主机的数据，以及单个主机自己的数据。Nagios可以了解一下。日志方面，ssh-multiplexers在多个主机上运行相同的命令，在一个屏幕上定位错误。响应时间的监控可以在负载均衡器中进行追踪，负载均衡器本身也需要监控。

3、多个服务，多个服务器：多服务合作为用户提供功能，这些服务运行在多个物理或虚拟主机上。需要从日志到应用程序指标，集中收集和聚合尽可能多的数据。

4、日志：多服务，多服务器情况，日志从终端机看就不方便了，logstash可以解析多种日志文件格式，并将它们发送给下游系统进行进一步调查。Kibana是一个基于ElasticSearch查看日志的系统，可以很直观的查看日志和生成图表，可以了解一下。

5、多个服务的指标跟踪：多个服务，我们需要寻找更好的方式来收集和查看指标（例如平均的CPU负载）。Graphite提供API，允许实时发送指标数据给它，然后可以直观的了解到当前情况。监控指标，可以帮助我们做扩容规划。

6、服务指标：Web服务，应该又响应时间和错误率这样的指标。Codahale的Metrics库是一个运行在JVM上的库，它允许存储一些指标，例如计数器、计时器、计量表；支持带时间限制的指标；还为将数据发送到Graphite和其他汇总报告系统提供支持。

7、综合监控：Nagios可以做到综合监控的，但是语义监控能更好的表明系统的问题，两者可配合使用。端到端测试，可以用来实现语义监控。但是大量跑测试数据的时候，要避免和用户的直接交互。

8、关联标识：关联标识（ID），在第一次调用时，生成一个GUID，然后把他传递给所有的后续调用。这种方式方便再多个服务中进行追踪。传递关联标识一定要保持一致性。

9、级联：级联故障特别危险，服务本身没有问题，集成点就很重要了，所以监控系统之间的集成点非常关键。每个服务的实例都应该追踪和显示其下游服务的健康状态，从数据库到其他合作服务。

10、标准化：监控的标准化很重要，并尝试以标准格式的方式记录日志。

11、考虑受众：监控要考虑受众，例如他们现在需要知道什么，他们之后想要什么，他们如何消费数据。

12、未来：运营指标和业务指标都保持实时。Riemann是一个事件服务器，允许高级的聚合和事件路由。Suro明确可以处理两种数据，用户行为的相关指标和更多的运营数据。

13、小结：

       对每个服务而言：

       （1）最低限度要跟踪请求响应时间。做好之后，可以开始跟踪错误率及应用程序集的指标。

       （2）最低限度要跟踪所有下游服务的健康状态，包括下游调用的响应时间，最好能够跟踪错误率。一些像Hystrix这样的库，可以在这方面提供帮助。

       （3）标准化如何收集指标以及存储指标。

       （4）如果可能的话，以标准的格式将日志记录到一个标准的位置。

       （5）监控底层操作系统，这样你就可以跟踪流氓进程和进行容量规划。

      对系统而言：

       （1）聚合CPU之类的主机层级的指标及应用程序级指标。

       （2）确保你选用的指标存储工具可以在系统和服务级别做聚合，同时也允许你查看单台主机的情况。

       （3）确保指标存储工具允许你维护数据足够长的时间，以了解你的系统的趋势。

       （4）使用单个可查询工具来对日志进行聚合和存储。

       （5）强烈考虑标准化关联标识的使用。

       （6）了解什么样的情况需要行动，并根据这些信息构造响应的警报和仪表盘。

       （7）调查对各种指标聚合方式做统一化的可能性，像Suro和Riemann这样的工具会有用。