- 系统层（CPU、网络状态、IO、机器负载等）
- 应用层（进程状态、错误日志、吞吐量等）
- 业务层（服务/接口的错误码、响应时间）
- 用户层（用户行为、舆情监控、前端埋点）
2. 全链路监控
服务拨测：服务拨测是探测服务（应用）可用性的监控方式，通过拨测节点对目标服务进行周期性探测，主要通过可用性和响应时间来度量，拨测节点通常有异地多个。
节点探测：节点探测是用来发现和追踪不同的机房（数据中心）节点之间网络可用性和通畅性的监控方式，主要通过响应时间、丢包率、跳数来度量，探测方法一般是ping、mtr或其他私有协议。
告警过滤：对某些可预知的告警进行过滤，不进入告警统计的数据，如少量爬虫访问导致的http响应500错误，业务系统自定义异常信息等。
告警去重：当一个告警通知负责人后，在这个告警恢复之前，不会继续收到相同的告警。
告警抑制：为了减少由于系统抖动带来的干扰，还需要实现抑制，例如服务器瞬间高负载，可能是正常的，只有持续一段时间的高负载才需要得到重视。
告警恢复：开发/运维人员不仅需要收到告警通知，还需要收到故障消除告警恢复正常的通知。
告警合并：对同一时刻产生的多条相同告警进行合并，如某个微服务集群同一时刻出现多个子服务负载过高的告警，需要合并成为一条告警。
告警收敛：有时某个告警产生时，往往会伴随着其它告警。这时可以只对根本原因产生告警，其它告警收敛为子告警一并发送通知。如云服务器出现CPU负载告警时往往伴随其搭载的所有系统的可用性告警。
故障自愈：实时发现告警，预诊断分析，自动恢复故障，并打通周边系统实现整个流程的闭环。
服务治理
1. 微服务
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API).每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
2. 服务发现
服务发现是指使用一个注册中心来记录分布式系统中的全部服务的信息，以便其他服务能够快速的找到这些已注册的服务。服务发现是支撑大规模 SOA 和微服务架构的核心模块，它应该尽量做到高可用。
3. 流量削峰
如果观看抽奖或秒杀系统的请求监控曲线，你就会发现这类系统在活动开放的时间段内会出现一个波峰，而在活动未开放时，系统的请求量、机器负载一般都是比较平稳的。为了节省机器资源，我们不可能时时都提供最大化的资源能力来支持短时间的高峰请求。所以需要使用一些技术手段，来削弱瞬时的请求高峰，让系统吞吐量在高峰请求下保持可控。削峰也可用于消除毛刺，使服务器资源利用更加均衡和充分。常见的削峰策略有队列，限频，分层过滤，多级缓存等。
