微服务的监控的原则:监控小的服务,然后聚合起来看整体
1. 单一服务,单一服务器
1) 监控主机的CPU、内存等信息。可以使用Nagios或者New Relic
2) 查看服务器本身的日志,何时何地发生了什么事情
3) 监控应用程序本身,最低限度是监控服务的响应时间
2. 单一服务,多个服务器
1) 既要查看所有主机的数据,还要查看单个主机的数据。换句话说,即要数据聚合起来,又想深入分析每台主机。可以使用Nagios
2) 查看服务器的日志,需要用到分布式日志收集和分析工具,比如ELK。
3) 在负载均衡器里监控响应时间,另外,对负载均衡器本身也要监控,比如它的行为是否正常等。
4) 在负载均衡器里监控服务的健康状况
3. 多个服务,多个服务器
从日志到应用程序指标,集中收集和聚合尽可能多的数据
4. 多个服务的指标跟踪
秘诀:收集系统指标足够长的时间,直到清晰的模式浮现
1) 能够方便从新的主机收集指标
2) 能够看到整个系统聚合后的指标(例如,平均CPU负载)
3) 给定的一些服务实例聚合后的指标
4) 单个服务实例的指标
Graphite可以很容易实现上述要求:
1) 提供一个非常简单的API,允许实时发送指标数据给它
2) 通过查看这些指标生成的图标和其他展示方式来了解当前的情况
3) 通过有效的配置,可以减少旧指标的精度,以确保容量不会太大。例如:最近十分钟,每隔10秒记录一次主机CPU的指标;过去的一天,以分钟为单位对数据进行聚合;过去的几年,以30分钟为单位进行聚合
4) 可以跨样本做聚合,或者深入到某个部分,这样就可以查看整个系统、一组服务或者单独实例的响应时间。
了解趋势也可以帮组我们做容量规划,确保恰好有足够的基础设施来满足需求。
5. 服务指标
1) 公开服务的基本指标(系统指标),如响应时间和错误率等
2) 公开服务的应用相关的指标(应用程序级指标),如过往订单的次数,过去一天赚的钱数
很多平台都存在一些库来帮助服务发送指标到一个标准系统。Codahale的Metrics库,运作在JVM上,可以计数、计时或计量,支持带时间限制的指标,还可以把数据发送到Graphite 和其它汇总报告系统中。
6. 语义监控
使用合成事务来确保系统行为在语义上的正确性。
语义监控比使用低层次指标的告警更能表明系统的问题,然而语义监控也并不能取代低层次的监控,那些细节有助于我们了解什么语义监控会报告问题。
实现语义监控:服务/系统的端到端测试都是实现语义监控所需的。另外,我们的系统也已经开放了测试和查看结果所需要的钩子(hook)
7. 关联标识
一个服务调用最终会触发多个下游的服务调用,更为复杂的初始请求有可能生成一个下游的调用链,并且以异步的方式处理触发的事件。如何跟踪?
一个非常有用的方法是使用关联标识(ID):在触发第一个调用时,生成一个GUID,然后把它传递给所有的后续调用。类似日志级别和日期,我们也可以把关联标识以结构化的方式写入日志。使用合适的日志聚合工具,就能够对事件在系统中触发的所用调用进行跟踪。
建议:创建一个内部客户端库来标准化这样的工作,并确保这个库是轻量的并且不依赖提供的任何特定服务。
8. 级联
监控系统之间的集成点非常关键
1) 每个服务的实例都应该追踪和显示其下游服务的健康状态,从数据库到其它合作服务。
2) 了解下游服务调用的响应时间,并检测是否有错误
3) 汇总这些信息,得到一个整合的画面
建议:使用库实现一个断路器网络调用,以更加优雅地处理级联故障和功能降级
9. 标准化
监控这个领域的标准化至关重要:服务之间的多个接口,可以用很多不同的方式合作来提供功能,需要以全局的视角来规划。
1) 标准格式来记录日志
2) 把所有的指标放到一个地方
3) 为度量提供一个标准名称的列表
4) 使用工具在标准化方面提供帮助
10. 考虑受众
监控收集的数据会触发一些事件,有些数据会触发支持团队立即采取行动。
需要考虑一下因素:
1) 现在需要知道什么
2) 之后想要什么
3) 如何消费数据
11. 未来:指标聚合
同一化各种指标聚合方式,例如,以同样的方式处理运营指标和业务指标。从专门只做一件事的系统转向通用事件处理系统。不再为不同类型的指标提供专门的工具链,而是提供伸缩性很好的更为通用的事件路由系统。
Riemann:事件服务器,允许高级的聚合和事件路由,该工具可以作为上述解决方案的一部分
Suro:Netflix的数据流水线,明确可以处理两种数据:用户行为的相关指标和更多的运营数据。然后这些数据可以被分发到不同的系统中,像Storm的实时分析、离线批处理的Hadoop或日志分析的Kibana