将系统拆分成更小的，细粒度的微服务会带来很多好处，然而，它也增加了生产系统的监控复杂性。
在单块应用的世界里，我们至少非常清除从哪里开始调查。网站慢？是单块应用的问题。网站异常？是单块应用的问题。CPU占用率100%？还是单块应用额问题。单一故障点会极大简化对问题的调查。
监控小的服务，然后聚合起来看整体。
8.1 单一服务，单一服务器
image.png
单一服务，单一服务器的监控比较简单。
首先，我们希望监控主机本身。CPU，内存等所有这些主机的数据都有用。
再者，我们要查看服务器本身的日志。如果用户报告了一个错误，这些日志应该可以告诉我们，在何时何地发生了何种错误。
最后，我们还想监控应用程序本身，比如监控服务的相应时间等。
8.2 单一服务，多个服务器
image.png
通过负载均衡分发不同的请求到不同的服务实例。
我们的服务运行在多个服务器上，登录到每台服务器查看日志，可能会让我们感到厌倦。类似于n多次的grep "Error" app.log（多块屏幕只能缓解，而无法解决这个问题）
对于响应时间，可以在负载均衡器中进行追踪，很容易拿到聚合后的数据。但同时，负载均衡器也需要监控，
8.3 多个服务，多个服务器
image.png
当多个服务，多个服务器的情况下。你如何在多个主机上的，成千上万行的日志中定位错误的原因？如何确定是一个服务的异常，还是系统性的问题？如何在多个主机间跟踪一个错误的调用连，找出引起这个错误的原因？
收集更多的日志，收集和聚合尽可能多的数据到我们手上。
8.4 日志，日志，更多的日志
image.png
收集日志：logstash(http:?/logstash.net),它可以解析多种日志文件格式，并将它们发送给下游系统进行进一步调查。
查看日志：Kibana(https://www.elastic.co/products/kibana)是一个基于ElasticSearch查看日志的系统，你可以使用查询预发来搜索日志，它允许在查询时指定时间和日期范围，或者使用正则表达式来查找匹配的字符串。
8.5 多个服务的指标跟踪
当我们观察一个复杂系统的指标时，很难知道什么样是好的。网站每秒约50条4XX的HTTP的错误状态码是问题吗?CPU负载突然增加了20%是有什么问题发生吗？要想知道什么时候该紧张，什么时候该放松，秘诀是收集系统指标足够长的时间，知道有清晰的模式浮现。
8.6 服务指标
作为web服务，最低限度应该暴露如响应时间和错误率这样的一些指标。
有句老话，80%的软件功能从未使用过。如果收集类似的指标，就可以知道用户真正使用频繁的20%的功能分布在什么地方，这样，对于我们就可以决策将宝贵的精力分布在哪些地方。
另外，通过了解用户如何使用我们的系统，可以反映出系统的行为，让我们明白如何改进系统。
最后，我们永远无法知道什么数据是有用的。很多次，知道机会已经错过很久后，我才发现如果当时记录了数据，事情就容易理解的多。所以作者倾向于暴露一切数据，然后依靠指标系统对它们进行处理。
8.7 综合监控
通过定义正常的CPU级别，或者可接受的响应时间，判断一个服务是否健康。如果我们的监控系统检测到实际值超出这些安全水平，就可以触发警告。
然而，这些测量结果离我们真正关心的内容仍有一些差距，即系统是否在正常工作。
语义监控：创建一个假的事件，即合成事件。使用此事件来确保系统行为在语义上的正确性。
8.8 关联标识
最终用户看到的任何功能都由大量的服务配合提供，一个初始调用最终会触发多个下游服务的调用。如何将服务之间的相互调用甚关联起来呢？一个非常有用的方法是使用关联标识（ID）。在触发第一个调用时，生成一个GUID。让皇后把它传递给所有的后续调用。
image.png
使用关联标识时，一个现实的问题是，你常常直至问题出现才知道需要它，而且只有在开始时就存在关联标识才能诊断出问题。团队达到一定的规模时，很难保证每个人都以正确的方式调用下游服务以收集正确的数据。如果你正在使用HTTP作为通信协议，只需要包装标准的HTTP客户端库，添加代码确保在HTTP头传递关联标识即可。
8.9 级联
级联故障特别危险。发生级联故障时，如果之查看某个服务的健康状态，我们不知道已经出现问题了。使用合成监控（例如，模拟客户搜索一首歌）会将问题暴露出来。
因此，每个服务的实例都应该追踪和现实其下游服务的健康状态，从数据库到其他合作服务。也应该将这些信息汇总，以得到一个整合的画面。你会想了解下游服务调用的响应事件，并检测是否由错误。
8.10 标准化
监控这个领域的标准化是至关重要的，应该尝试以标准格式的方式记录日志。
8.11 考虑受众
收集数据是为了不同的人而收集，帮助他们完成工作，这些数据会触发一些事件。对于查看这些数据的同步类型的人来说，需要考虑以下因素：
- 他们现在需要知道什么
- 他们之后想要什么
- 他们如何消费数据
8.12 未来
在很多组织中，很多指标被孤立到不同的系统中。存储业务指标的系统通常无法直接，实时地访问，但存储运营指标的系统却可以。如果我们可以统一收集，聚合以及存储这些事件，使他们可用于报告，最终会得到一个更简单的架构。
徐国组织正在朝一个完全不同的方向麦精：不再为不同类型的指标提供专门的工具链，而是提供伸缩性很好的更为通用的事件路由系统。
网友评论