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