将系统拆分成更小的、细粒度的微服务会带来很多好处。然而，它也增加了生产系统监控的复杂性。
1.单一服务，单一服务器
首先，我们希望监控主机本身。CPU、内存等所有这些主机的数据都有用。我们想知道，系统健康的时候它们应该是什么样子的，这样当它们超出边界值时，就可以发出警告。如果我们想运行自己的监控软件，可以使用Nagios，或者使用像New Relic这样的托管服务来帮助我们监控主机。
接下来，我们要查看服务器本身的日志。如果用户报告了一个错误，这些日志应该可以告诉我们，在何时何地发生了这个错误。这个时候，对于单台主机来说，只需要登录到主机上使用命令行工具扫描日志就可以了。我们甚至可以更进一步，使用logrotate帮助我们移除旧的日志，避免日志占满了磁盘空间。
2.单一服务，多个服务器
现在我们服务的多个副本实例，运行在多个独立的主机上。事情慢慢变得棘手。我们仍然需要监控与之前一样的内容，但为了定位问题，我们的做法会有所不同。
现在，除了要查看所有主机的数据，还要查看单个主机自己的数据。换句话说，我们既想把数据聚合起来，又想深入分析每台主机。Nagios允许以这样的方式组织我们的主机，到目前为止一切还好。类似的方式也可以满足我们对应用程序的监控。
接下来就是日志。我们的服务运行在多个服务器上，登录到每台服务器查看日志，可能会感到厌倦，如果只有几个主机，我们还可以使用像ssh-multiplexers这样的工具，在多个主机上运行相同的命令。
对于像响应时间这样的监控，我们可以在负载均衡器中进行追踪，很容易就能拿到聚合后的数据。
3.多个服务，多个服务器
3.1 日志，日志，更多的日志
现在，运行服务器的主机数量成为一个挑战。我们希望用专门获取日志的子系统来代替ssh-multiplexing，让日志能够集中在一起方便使用。
Kibana是一个基于ElasticSearch查看日志的系统。你可以使用查询语法来搜索日志，它允许在查询时指定时间和范围，或使用正则表达式来查找匹配的字符串。Kibana甚至可以把你发给它的日志生成图表，只需要看一眼就能知道发生了多少错误。
3.2 多个服务的指标跟踪
与查看不同主机上的日志遇到的挑战类似，我们也需要寻找更好的方式来收集和查看指标。
在更复杂的环境中，我们会频繁地重建服务的新实例，所以我们希望选择一个系统能够方便地从新的主机收集指标。我们希望能够看到整个系统聚合后的指标，但也会想要给定的一些服务实例聚合后的指标，甚至某单个服务实例的指标，这意味着，我们需要将指标的元数据关联，用来帮助推导出这样的结构。
Graphite就是让上述要求变得很容易的系统。它提供一个非常简单的api，允许你来实时发送指标数据给它。然后你可以通过查看这些指标生成的图表和其它展示方式来了解当前的情况。
3.3 关联标识
最终用户看到的任何功能都由大量的服务配合提供，一个初始调用最终会触发多个下游的服务调用。
这种情况下，一个非常有用的方法时使用关联标识。在触发第一个调用的时候，生成一个guid。然后把它传递给所有后续调用。
当然，你需要确保每个服务应该传递关联标识。此时你需要标准化，强制在系统中执行该标准。一旦这样做了，就可以创建各种工具来跟踪各种交互。这样的工具可以跟踪事件风暴、不常发生的特殊场景，甚至识别出时间过长的事务，因为你能勾勒出整个级联的调用。
像Zipkin这样的软件，也可以跨多个系统边界跟踪调用。基于Google自己的跟踪系统Dapper的创意，Zipkin可以提供非常详细的服务间调用的追踪信息，还有一个界面可以显示数据。
小结
对于服务
- 最低限度要跟踪请求响应时间。做好之后可以跟中错误率及应用程序级的指标。
- 最低限度要跟踪所有下游服务的健康状态，包括下游调用的响应时间，最好能跟踪错误率。
- 标准化如何收集指标以及存储指标
- 如果可能的话，以标准的格式将日志记录到一个标准的位置。
- 监控底层操作系统，这样你就可以跟踪流氓进程和进行容量规划
对于系统 - 聚合CPU之类的主机层级的指标及应用程序指标
- 确保你选用的指标存储工具可以在系统和服务级别做聚合，同时也允许你查看单台主机的情况
- 确保指标存储工具允许你维护数据足够长时间，以了解你系统的趋势
- 使用单个可查询工具对日志进行聚合和存储
- 强烈考虑标准化关联标识的使用
- 了解什么样的情况需要行动，并根据这些信息构造成相应的警告和仪表盘。
- 调查对各种指标聚合方式做统一化的可能性，像Suro或Riemann这样的工具可能会对你有用。
