微服务监控与问题定位

将系拆成更小的、细粒度的服务会带来很多好处，然而,它也增加了生产系统的监控和定位问题的复杂性。当系统出问题时，你要了解的第一件事是问题到底出在哪里，在单体系统的世界中，我们至少非常清楚该从哪里开始调查。在基于微服务的系统中，有多个服务需要监控，有多个日志需要筛选，多个地方有可能因为两络延迟而出现问题。

答案很简单: 监控小的服务，然后聚合起来看整体。

对于单一服务单一服务器的情况，首先我们希望监控主机本身，包括CPU、内存等数据。我们想知道，当系统健康的时候他们是什么样子，当超出边界时，就会发出告警。接下来，我们要查看服务器本身的日志。如果用户报告了一个错误，这些日志应当告诉我们，在何时何地发生了这些错误。最后，我们可能还想要监控应用程序本身。最低限度是要监控服务的响应时间。如果我们想要更进一步，可能还需要追踪报告中错误出现的次数等。

对于单一服务多个服务器的情况，我们仍然需要监控与之前一样的内容。但为了定位问题，我们的做法会有所不同。当CPU占用过高，如果发生在所有的服务器上，那么可能是服务的问题，如果发生在一台主机上，那么可能是主机的问题。我们想要把数据聚合起来，又想深入分析每台主机。对应用程序的监控也采用类似的方式。接下来是日志。在多个主机上运行相同的命令，用一个大显示屏，就可以定位错误了。对于像响应时间这样的监控，我们可以在负载均衡器中进行追踪。

对于多个服务多个服务器的情况，答案是，从日志到应用程序指标，集中收集和聚合尽可能多的数据到我们手上。

在监控这个领域的标准化是至关重要的，服务之间使用多个接口，以很多不同的方式合作为用户提供功能，你需要以整体的视角查看系统。你应该尝试以标准格式的方式记录日志。你需要把所有的指标放在一个地方，需要为度量提供一个标准名称的列表。工具在标准化方面可以提供帮助。

对于每个服务而言:

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

最低限度要跟踪所有下游服务的健康状态，包括下游调用的响应时间，最好能够追踪错误率。

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

如果可能的话，以标准的格式将日志记录到标准的位置。如果每个服务各自使用不同的方式，聚合会非常痛苦。

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

对整个系统而言:

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

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

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

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

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

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

调查对各种指标聚合方式做统一化的可能性。

系统监控的发展方向，是从专门只做一件事的系统转向通用事件处理系统，从而可以全面地审视你的系统。

​