开发者学堂课程【HBase 入门与实战：如何快速构建高效的监控系统】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/808/detail/13901
如何快速构建高效的监控系统
内容介绍
一、APM的概念
二、Lindorm 时序引擎简介
一、APM 的概念
1.APM 的概念与价值
全称 Application Performance Management，对企业的应用系统进行实时监控、诊断分析、故障告警。它是用于实现对应用程序性能管理和故障管理的系统化的解决方案
在整个 APM 的概念框架中实际上是关注五个维度。
关注五个维度
·终端用户体验，衡量从用户请求到数据再返回的流量传输，用于终端用户体验的部分，测量结果被称为实时的应用程序监控。具有被动和主动二个部分，被动监控通常指使用网络端口镜像实践不带领的监控，主动监控是事先预定好的探针或怪物机器人组成，用于报告整个系统业务事故的监控方式 .应用架构映射,实际上是应用程序发现和依赖关心映射解决方案，用于自动执行将事务和应用程序定制到底层的基础架构组件的过程。
·应用事务分析，主要关注用户定义的事务以及对整个业务具有一定意义的页面定义相关维度的分析。
·深度应用诊断，通常此层面需要安装代理，通过针对中间件进行监控。
·性能数据分析，主要是获得通用的度量标准从而收集和报告每一个应用程序非常重要的指标，将相关的数据标准化，并且进行整体的成键。
2.APM 的功能与类型
核心功能
.应用系统存活检测 .应用程序性能指标检测
.应用程序关键事件检测 .服务调用跟踪
.检测数据持久化存储及多维查询
.监控告警
整个 APM 的框架中监控侧重类型侧重三种
·日志型(Log) .调用链型(Tracing) .度量型(Metrics)
技能监控应用主要是度量型，怎样构建度量型监控系统
3.APM典型的技术架构
·采集 ·收集存储 .分析&展示 ·报警
通常所说的 ATM 监控系统投射出以下架构图
系统中包括测试指标、监控指标的采集端包括整个监控进行上传统一收集的收集端，指标持久化存储端，APM 包括监控报警相关的报警管理，以及分析篇，整个 APM 的组成部分。同时市场流行的 Prometheus 监控报警系统中每一个端都能通知到 Prometheus 系统监控中的每个组件。
4.度量型 APM 的常用概念
常用度量类型
·Gauge(瞬时状态)
·Counter(计数器)
·Historgram(直方图)
·Meter(时间段内均值)
·Timer(计时器) 监控对象分层
基础监控
·系统层
业务监控
·应用层
·用户层
度量性 APM 有若干个概念，度量性 APM 通常将它的监控指标分为几种类型。第一种瞬时状态，类似于汽车转速盘仪表盘，表示某一时刻的瞬时状态，类似于系统中缓存的大小。
Counter 比如要度量整个页面访问的次数，通常采用指标Counter 形式。
直方图用于表示数据分布，比如访问延时按 Historgram 进行记录，比单纯的记录延迟更有意义。Meter 时间段内均值，比如一分钟、五分钟、十五分钟中 JPS 的变化速率，这样的指标用 Meter 进行记录。Timer 是 Historgram 与 Meter 的结合。
监控类型可分为三种，第一个系统层主要指的是 CPU 或内存、服务器方面的监控，这些方面的指标通常是基础架构预留的同学关注的对象。应用层指服务应用角度的监控，比如接口、框架以及某个服务具体的监控状态、吞吐量、访问延时等等，是一般服务开发框架开发人员关注的。用户层主要是用户体验和业务正常的功能指标属于上层的功能层面，大多数产品经理、项目经理关注此指标。
日常的分类来说通常把系统层认为基础监控，应用层、用户层为业务监控。
5.度量型 APM 对数据库的要求
度量型 APM 的采集特点
.采集到的度量数据都必然带一个时间戳
.数据写入频率相对稳定，且伴随监控规模采集到的数据向存储端的写入量通常较大 .查询采集到的度量数据时通常高频访问最新的一段时间数据 由数据存储采集查询的特点，度量型的 APM 对于数据库通常由几个要求。
需求的数据库能力
.支持大吞吐量的极致写入性能
.能够随着监控对象的量级提升动态扩容
.能够支持时间维度以及监控维度的多维检索
.能够支持数据的冷热温分层，最大化提升使用性价比
二.Lindorm 时序引擎简介
1.Lindorm 云原生多模型数据库
此图为 Lindorm 云原生多模型数据库整体的产品架构，是自研的云原生的多模数据库，是面向海量多模型数据的低成本组合分析。Lindorm 支持宽表模型、数据模型，同时支持搜索引擎，包括文件系统兼容的 HBase 一系列开源结构，同时提供了搜索查询、时序梳理、解锁分析等等多元化能力。
Lindorm 提供毫秒级别的响应性能，支持 PD级的存储以及千万级的 JPS,在阿里内部发挥关键价值。
让海量数据存得起，看得见
物联网 AlsT
大数据存储
数据湖存储
交互实时存储
2.Lindorm 时序引擎内部结构
在 Lindorm 多模数据库中 Lindorm 时序引擎，是基于 Lindorm Store 实现的 Shared-Storage架构时序组成部分。
在存储引擎自研了一套贴合时序数据模型的文件格式以及存储式，使得可以面对海量持续数据写入性能时达到极致的写入性能同时使成本在相对便宜的层面，而且能够相对平滑的实现存储层面的水平扩展。更上层的查询引擎层面，兼容的 Open TSDB 的读写接口基础上实现了一套面向时序数据查询接口，同时兼容 InfluxDB MemChunk 用于支撑更多融化时序植入。
目标兼容开源生态的同时还能启用更加便利的访问接口。
Shared-Storage架构
.核心特性
-开放融合
-高性价比
- 弹性伸缩
-时序计算
3.Lindorm 时序引擎的数据模型
在 Lindorm 时序引擎所处理的数据模型与刚才提到的 APM 数据采集到的性能模型相当强的映射关系。Lindorm 时序引擎中通常将数据模型描绘成此架构，整体会随着 Metric 作为数据集合归类的标准，各种类型采集的监控指标会以 Metric 换成不同的数据集合，同时会有一个类似 Tags 的标签来描述采集到的数据源的特征，这样的标签不随着直接的变化变化。
对于具体的监控值通常描绘在 Field 类型字段中，用于表述整个数据值的测指标，通常会随着时间不断变化。在时序模型中非常重要的 Timestamp,Timestamp 每个监控指标都会带有一个时间戳。整个监控时序数据模型中一个非常隐含的概念是时间线的概念，通常时序数据所组织的单元由时间线组成，数据源的某一个指标随时间变化，形成时间线。比如整个时序数据模型中实际上分成了两个时间线，分别代表了代表两个数据源的持续的时序数据。
.Metric/Table
Metric 类似关系型数据库里的表(Table)，代表一系列同类时序数据的集合
.Tags
Tag 描述数据源的特征，通常不随时间变化
..Field 描述数据源的量测指标，通常随着时间不断变化
.时间线
数据组织的单元。数据源的某一个指标随时间变化，形成时间线，Metric+Tags+Field 组合确定一条时间线
4.数据点格式
Lindorm 支持的数据点格式通常有两种模式
.单值模型（兼容Open TSDB）
与开源的 Open TSDB 持续模型完全相同，在一个数据点中首先通过 metric 标识是怎样的指标，通过 tags 标识数据源是怎样的属性，timestamp、value。这样的数据模型可以标识每一个数据点对应的具体指标是什么。在实际业务中更推荐多值模型
.多值模型(推荐)
多值模型中 metric 可以标识一个数据源所代表的含义，通过 tags 描述整个数据源具体的特性，最后可将数据源采集到的指标分为若干个 field,每个 field 都有对应采集的指标。在多值模型中可将一类设备描述为共通的 metric,根据每一个设备采集的数据产生相应的不同的 field。
时序模型中支持精确到毫秒
.支持丰富的数据类型
-整型
-浮点型
-布尔型
-字符串
-字节数组
.支持精确到毫秒的时间戳
5.时间序列的基础概念
在时序数据库中，一个数据源会就一个或多个指标持续写入一系列数据，这便构成了一个时间序列。通常一个时间序列也被称为一条时间线。以下为时间线在5个时间点产生的各自指标。
怎样衡量A组数据来自一个时间序列还是多个时间序列？
在 Lindorm 时序模型中 Metric 名相同，Tags 数量完全相同，每一个 Tag 的 value 都相同那么这样一个时间序列为一组。
时间序列的决定因素
.Metric名相同 .Tags数量完全相同 .每一个Tag的value都相同
6.时序查询的基础概念
.降采样(Downsample)
查询数据时，在指定的查询时间段内，相较原始的数据写入精度，以较低的精度进行查询，投射到真实的业务场景中，通常监控数据以高频度的采集方式持续的行动。比如采集频率每秒钟一次或十秒钟一次采集一组数据，但真正做查询时并不想按照原始的力度采集展示数据，因为展示的数据非常多，对观测没有太大价值。展示数据时以低密度的方式展示，比方数据展示时五分钟一次这样相对低密度的方式展示。这样的查询本质上是一个数据源在一条时间线上的数据在时间维度进行聚合。
降采样的本质实际上也是对一条时间线上的数据在时间维度进行聚合。
按照图中给的例子，实际上通过降采样变为上图。
聚合(Aggregate)
查询数据时，在指定的查询时间段内，对于查询出的多条时间线的数据按时间戳对齐后并按对齐后的时间间隔将不同时间线的值进而聚合成一条时间线的值。
这样的查询在监控中非常常用的，采集上若干条数据、若干条时间线数据可能在同一层楼中有若干个传感器采集各个角度的温度，但最终想了解整栋楼的温度，这时可能有四个传感器，将四个传感器采集的数据某个时间对齐后进行 Aggregate 操作。
聚合的本质实际上也是对一条时间线上的数据在数据源维度进行聚合计算。
7.主流时序数据库产品对比
Lindorm 时序本身适合 APM 工业互联网集群，提供的查询接口 Open TSDB 自研的SQL，比较高的性价比，支持多维检索包括高可用水平扩展，预降精度、聚合实时计算提供支持。
目前其它产品在这些功能层面或多或少有一些劣势，并不是所有产品都支持投入 APM。
