8.微服务设计 --- 监控

1.单一服务，单一服务器
	监控主机本身。cpu,内存，服务器日志，应用程序本身。

2.单一服务，多个服务器
	当cpu占用高的时候，如果发生在所有机器上，那么可能是服务的问题。如果发生在一台主机上，那可能是主机的问题。

3.多个服务，多个服务器
4.日志，日志，更多的日志
5.多个服务的指标跟踪
	Graphite 
6.服务指标
7.综合监控
8.关联标识
	最终用户看到的任何功能都由大量的服务配合提供，一个初始化调用最终会触发多个下游的服务调用。更为复杂的初始请求有可能生成一个下游的调用链，并
  以异步的方式处理触发的事件。
    追踪：一个非常有用的方式是使用关联标识(ID)。在触发第一个调用的时候，生成一个GUID，然后把它传递给所有的后续调用。像Zipkin这样的软件，也可以
  跨多个系统边界追踪调用。基于Google自己的追踪系统Dapper的创意，Zipkin 可以提供非常详细的服务间调用的追踪信息，还有一个界面帮助显示数据。
    如果用的是 HTTP 作为通信协议，可以在 HTTP 头里面传递关联标识。
9.级联
	级联故障特别危险。比如2个服务之间的网络连接瘫痪了，服务本身是健康的，但它们之间无法交互。如果只看某个服务的监控状态，我们不会知道已经出问题了。
  使用合成监控(如模拟客户搜索一首歌)会将问题暴露出来。
    因此，监控系统之间的集成点非常关键。每个服务的实例都应该追踪和显示其下游服务的健康状态。
    你可以使用库实现一个断路器网络调用，以帮助你更加优雅的处理级联故障和功能降级。比如，JVM的 Hystrix
10.标准化
11.考虑受众

总结:
	对于每个服务而言：
		1.最低限度要追踪请求响应时间。做好之后，可以开始追踪错误率以及应用程序级的指标
		2.最低限度要追踪所有下游服务的健康状态，包括下游调用的响应时间，最好能够跟踪错误率。像Hystrix
		3.标准化如何收集指标以及存储指标
		4.如果可能的话，以标准的格式将日志记录到一个标准的位置
		5.监控底层操作系统，这样你就可以追踪流氓进程和进行容量规划了

	对于系统而言：
		1.聚合cpu之类的主机层级的指标以及应用程序级指标
		2.确保你选用的指标存储工具可以在系统和服务级别做聚合，同时也允许你查看单台主机的情况
		3.确保指标存储工具允许你维护数据足够长的时间，以了解你的系统趋势
		4.使用单个可查询工作来对系统进行聚合和存储
		5.强烈考虑标准化关联标识的使用
		6.了解什么样的情况需要行动，并根据这些信息构造相应的警报和仪表盘
		7.调查对各种指标聚合方式做统一的可能性，像Suro或 Riemann 这样的工具。