8.携程架构实践 --- 监控

Posted 2021-10-27 enlyhua

第8 章 监控 
8．1 指标监控和告警系统Hickwall 
	Hickwall是xc在 Metrics 方面的主要监控系统，可以提供指标数据的采集，存储，展示和告警。

	8．1．1 指标监控的应用和挑战 
		指标监控系统是一个对时序指标进行采集，分析和处理的系统，和日志系统不同的是，它并不记录时间或请求的详细信息，而是以数值的形式记录某个指标
	随着时间的变化情况，这些数值被称为时间序列。

		指标监控系统一般有以下几个应用场景：
			1.容量规划
			2.性能分析
			3.紧急告警
			4.故障分析

		根据指标的来源和使用场景，一般把监控的指标分为 
			1.系统层指标
				包括IDC的温湿度，各种设备的固件运行情况，网络设备的接口状态流量丢包，物理机虚拟机容器的cpu内存等，也包括mysql,redis等基础服务的
			状态。

			2.应用层指标
				框架埋点，如3个黄金指标(请求量，响应时间和错误数)，也包括用户自定义埋点，如某个模块中的内存队列长度。

			3.业务层指标
				如 订单量等全局的，直接影响公司业绩的指标。

	8．1．2 指标模型的选择 
	8．1．3 Hickwall 架构 

8．2 开源分布式应用监控系统CAT 
	8．2．1 为什么需要应用监控系统 
		一次简单的API调用，其背后可能隐藏了数以百计的对下游服务和存储的访问。

	8．2．2 应用监控系统的特点 
		应用监控应该满足哪些基本条件：
			1.监控范围必须覆盖足够的应用
			2.监控行为必须是长期不间断的进行

		应用监控系统的链路追踪功能设计目标，主要包含以下几个方面：
			1.客户端负载低
			2.业务应用级别的透明性
			3.服务端可水平扩展
			4.服务端高可用

		应用监控的作用域：
			1.Trace
				一次完整的事务调用请求。Trace最大的特点是，它有上下文环境，通常来说，Trace会由一个唯一的ID进行标识，一次Trace可能由多个不同的事务和标志事件(Event)组成。
			2.Log
				日志，代表用户主动记录的离散数据。
			3.Metric
				用户定义的，关心的或者通用的一些运行时指标。
			4.Report
				报表。

	8．2．3 客户端实现解析 
		CAT 的 Trace 功能设计思路来源于 Google Dapper 系统的相关论文，具体操作步骤如下：
			1.每一个Trace在CAT内部都被称为 Message Tree，由树形结构组织的Transaction及Event组成，每一个Trasaction代表某次具有特定耗时的调用(同步或者
			异步，如一次RPC或者一次DB操作)，每一个Event则代表业务关心的事件，
			2.客户端的每一个相关线程都有一个Tread Local 域，用于存储Message Tree，一旦客户调用 newTransaction接口，就会给这个Message Tree增加一个
			Transaction节点。
				a) 如果当前栈顶Trasaction节点还未结束，则新的Transaction节点会当做当前栈顶的子节点。
				b) 否则新的Transaction节点会当做当前栈顶Transaction节点的兄弟节点加入已有的Message Tree
			3.用户调用complete接口会将当前栈顶Transaction节点标记为结束，如果当前Message Tree的根结点已被标记为结束，则整个Message Tree会被加入本地内存
			队列中，由后台线程异步发送给服务端。


	8．2．4 存储模型解析 

8．3 公共日志服务平台CLog 
	8．3．1 日志系统的演进与特点 
		一个通用的企业级日志系统特性：
			1.高并发，高吞吐
			2.海量数据存储
			3.横向扩展
			4.稳定性
			5.实时性
			6.分析与可视化

	8．3．2 CLog 的架构 
		1.Client
		2.Collector
		3.Log Indexer
		4.Offline

8．4 告警系统 
	8．4．1 告警系统的需求特点 
		告警系统是一个实时数据分析系统。

	8．4．2 流式告警的实现和处理 
		告警最简单的实现就是定时从数据库中拉取数据，并检查是否异常。但这种pull的方式会对存储造成压力。

		经过研究，告警数据在所有监控数据中占比不大，大约8%，并且绝大部分是最近几分钟的数据，如果能够从数据流中直接获取所需要的数据，就能过滤掉大部分不必要的
	数据，避免对后台存储的依赖。这种方式被称为流式告警。