首先，我们希望监控主机本身。CPU、内存等所有这些主机的数据都有用。我们想知道，系统健康的时候它们应该是什么样子的，这样当它们超出边界值时，就可以发出警告。
接下来，我们要查看服务器本身的日志。如果用户报告了一个错误，这些日志应该可以告诉我们，在何时何地发生了这个错误。
最后，我们可能还想要监控应用程序本身。最低限度是要监控服务的响应时间。你可以通过查看运行服务的Web服务器，或者服务本身的日志做到这一点。如果我们想要更进一步，可能还需要追踪报告中错误出现的次数。
随着时间的推移，负载增加，我们发现系统需要扩容。
对于像响应时间这样的监控，我们可以在负载均衡器中进行追踪，很容易就能拿到聚合后的数据。不过负载均衡器本身也需要监控；如果它的行为异常，也会导致问题。
了解趋势另一个重要的好处是帮助我们做容量规划。我们的系统到达极限了吗？多久之后需要更多的主机？如果了解我们的使用模式，就可以确保恰好有足够的基础设施来满足我们的需求。
在触发第一个调用时，生成一个GUID，然后把它传递给所有的后续调用。类似日志级别和日期，你也可以把关联标识以结构化的方式写入日志。使用合适的日志聚合工具，你能够对事件在系统中触发的所有调用进行跟踪。
使用关联标识时，一个现实的问题是，你常常直至问题出现才知道需要它，而且只有在开始时就存在关联标识才可能诊断出问题！这个问题非常棘手，因为在后面很难加装关联标识；你需要以标准化的方式处理它们，这样才能够轻易重建调用链。
监控系统之间的集成点非常关键。每个服务的实例都应该追踪和显示其下游服务的健康状态，从数据库到其他合作服务。你会想了解下游服务调用的响应时间，并检测是否有错误。
你应该尝试以标准格式的方式记录日志。你一定想把所有的指标放在一个地方，你可能需要为度量提供一个标准名称的列表。
对每个服务而言：
- 最低限度要跟踪请求响应时间。做好之后，可以开始跟踪错误率及应用程序级的指标。
- 最低限度要跟踪所有下游服务的健康状态，包括下游调用的响应时间，最好能够跟踪错误率。
- 标准化如何收集指标以及存储指标。
- 如果可能的话，以标准的格式将日志记录到一个标准的位置。如果每个服务各自使用不同的方式，聚合会非常痛苦！
- 监控底层操作系统，这样你就可以跟踪流氓进程和进程容量规划。
标签：服务,调用,聚合,指标,监控,设计,日志 From： https://www.cnblogs.com/hellosnow/p/17533528.html对系统而言：
- 聚合CPU之类的主机层级的指标及应用程序级指标。
- 确保你选用的指标存储工具可以在系统和服务级别做聚合，同时也允许你查看单台主机的情况。
- 确保指标存储工具允许你维护数据足够长的时间，以了解你的系统的趋势。
- 使用单个可查询工具来对日志进行聚合和存储。
- 强烈考虑标准化关联标识的使用。
- 了解什么样的情况需要行动，并根据这些信息构造相应的警报和仪表盘。
- 调查对各种指标聚合方式做统一化的可能性。