一、APM的概念
（一）APM的概念与价值
APM全称Application Performance Management，对企业的应用系统进行实时监控、诊断分析、故障告警。它是用于实现对应用程序性能管理和故障管理的系统化的解决方案。
APM的概念框架
对于APM的概念框架，我们主要关注以下五个维度：
1. 终端用户体验
衡量从用户请求到数据再返回的流量传输是捕获最终用户体验（EUE）的一部分。此测量的结果称为实时应用程序监视（又称自顶向下监视），它具有被动和主动两个组件。被动监控通常是使用网络端口镜像实现的无代理设备。主动监控由预定义的合成探针和Web机器人组成，用于报告系统可用性和业务事务。
2. 应用架构映射
应用程序发现和依赖关系映射（ADDM）解决方案用于自动执行将事务和应用程序映射到底层基础架构组件的过程。
3. 应用事务分析
关注用户定义的事务或对业务社区有一定意义的URL页面定义。
4. 深度应用诊断
深度应用诊断（DDCM）需要安装代理，通常针对中间件，侧重于Web，应用程序和消息服务器。
5. 性能数据分析
获得一组通用的度量标准以收集和报告每个应用程序非常重要，然后标准化有关数据并呈现应用程序性能数据的常见视图。
（二）APM的功能与类型
- 核心功能
1）应用系统存活检测
2）应用程序性能指标检测
3）应用程序关键事件检测
4）服务调用跟踪
5）检测数据持久化存储及多维查询
6）监控告警
- 在APM框架中，监控分为三个侧重类型：
1）日志型（Log）
2）调用链型（Tracing）
3）度量型（Metrics）
本文重点阐述如何构建度量型监控系统。
（三）APM典型的技术架构
上图为APM监控系统技术架构图。
从图中我们可以看到，系统包含监控指标的采集端，指标统一上传与收集的收集端，指标持久化存储的存储端，还有监控报警的报警管理模块，以及分析与展示端。
架构图映射到当下流行的监控系统Prometheus中，每个模块也得到一一对应。
（四）度量型APM的常用概念
在度量型APM中有五种常用度量类型：
- Gauge （瞬时状态）
- Counter （计数器）
- Historgram （直方图）
- Meter （时间段内均值）
- Timer（计时器）
瞬时状态（Gauge）类似于汽车转速盘，表示某一个时刻的瞬时状态，比如系统中一个缓存的大小。
计数器（Counter）主要度量场景如整个页面访问的总字数。
直方图（Historgram）用于表示数据分布的度量，比方访问延时，我们会按Historgram类型进行记录。
时间段内均值（Meter）通常是度量一个事件的发生频率，比方1分钟或者5分钟内GPS的变化数据，这样的指标会用Meter类型进行记录。
计时器（Timer）本质上是直方图和时间段内均值这两个类型的结合。
除此之外，监控对象也可以分成三个类型。
系统层主要指的是CPU/磁盘/内存等服务器层面的监控，这类监控指标通常是技术架构运营人员会比较关注的对象。
应用层指的是服务应用，主要监控的是接口、框架以及某一个服务具体的健康状态，如它的吞吐量、访问延时等，这类监控指标通常是服务开发或者框架开发人员会比较关注的对象。
用户层主要是与用户体验以及业务正常功能所相关的指标，它属于上层的一个功能层面。大多数情况下，项目经理或者产品经理会关注这类监控指标。
在日常运维中，我们通常把系统层认为是技术监控，而应用层和用户层是业务监控。
（五）度量型APM对数据库的要求
那么度量型的APM系统对数据库有哪些要求呢？我们可以通过分析度量型APM的采集特点进而得出它所需求的数据库能力。
Ø 度量型APM的采集特点
1）采集到的度量数据都必然带一个时间戳；
2）数据写入频率相对稳定，且伴随监控规模采集到的数据向存储端的写入量通常较大；
3）查询采集到的度量数据时通常高频访问最新的一段时间数据。
Ø 需求的数据库能力
1）支持大吞吐量的极致写入性能；
2）能够随着监控对象的量级提升动态扩容；
3）能够支持时间维度以及监控维度的多维检索；
4）能够支持数据的冷热温分层，最大化提升使用性价比。
上文介绍了APM的基础概念，接下来将介绍在APM系统中，云原生多模数据库Lindorm能够发挥怎样的价值。
二、Lindorm时序引擎简介
（一）Lindorm云原生多模数据库
云原生多模数据库 Lindorm 提供各规模、多模型的云原生数据库服务。可兼容HBase/Cassandra、OpenTSDB、Solr、SQL、HDFS等多种开源标准接口。支持海量数据的低成本存储处理和弹性按需付费，是互联网、IoT、车联网、广告、社交等场景首选数据库，也是为阿里核心业务提供支撑的数据库之一。
（二）Lindorm时序引擎内部架构
上图为Lindorm时序引擎内部架构图。
Lindorm时序引擎是基于Lindorm Store实现Shared-Storage架构的时序数据库产品，核心特性是开放融合、高性价比、弹性伸缩和时序计算。
在存储引擎中，我们自研了一套贴合时序数据模型的文件格式及存储系统，使得面对海量时序数据写入时，写入性能能够达到极致，同时维持较低成本，并且能够非常平滑地实现存储层面的水平扩展。
在更上层的查询引擎层面，在兼容了Open TSDB读写接口的基础之上，实现了一套面向时序数据查询的SQL Line的查询语言作为访问接口，同时兼容InfluxDB，用于支撑更多元化的时序数据写入。
我们的目标是兼容开源生态的同时，还能够提供更加便利易用的访问接口供广大开发者使用。
（三）Lindorm 时序引擎的数据模型
上图为Lindorm时序引擎的数据模型，它与上文提到的APM技术架构模型有很强的映射关系，其中的包含了许多监控指标：
Ø Metric/Table
Metric 类似关系型数据库里的表 （Table），代表一系列同类时序数据 的集合。
Ø Tags
Tag描述数据源的特征，通常不随时间变化。
Ø Field
描述数据源的量测指标，通常随着时间不断变化。
Ø Timestamp
每个监控指标都会带时间戳。
Ø 时间线
数据组织的单元。数据源的某一个指标随时间变化形成时间线，“Metric + Tags + Field”组合确定一条时间线。
Lindorm时序引擎整体会将Metric作为数据集合归类的标准，采集到的各种类型监控指标会根据Metric划分成不同的数据集合。
上方图中的2条时间线分别代表了来自于两个数据源写入的时序数据。
（四）数据点格式
接下来看在时序模型中每一个数据点代表的含义。
在Lindorm支持两种数据点格式，一种是单值模型，另一种是多值模型。
如上图所示，单值模型实际上和开源的Open TSDB时序模型完全相的。
在一个数据点中，首先会通过Metric标识它是怎样的指标，然后通过Tags标识数据属性，接着是Timestamp和Value，这样的数据模型可以标识每一个数据点所对应的具体指标。
但是在实际业务中，我们更推荐多值模型。
如上图所示，在多值模型中，可以通过Metric标识一个数据源所代表的含义，然后可以通过Tags描述数据源的具体特性，最后可以将这个数据源所采集到的指标分成若干个Field，每一个Field都有对应采集的主要值。
这样的话，在整个多值模型中可以将一类设备描述为共通的一个Metric，然后根据每一个设备所采集到的数据产生相应的Field。
同时，时序模型支持丰富的数据类型，如整型、浮点型、布尔型、字符串、字节数组等，并且支持精确到毫秒级的时间戳。
（五）时间序列的基础概念
在时序数据库中，一个数据源会就一个或多个指标持续写入一系列数据，这便构成了一个时间序列，通常一个时间序列也被称为一条时间线。
上图描述的就是一个时间线，它在5个时间点所产生了不同的指标，我们如何判断它的一组数据到底是来自于一个时间序列还是多个时间序列？
在Lindorm时序模型中，时间序列的决定因素主要有三个，如果Metric名相同，Tags数量完全相同，每一个Tag的Value都相同，这样的一组数据那就可以理解成是同一个时时序序列。
（六）时序查询的基础概念
接下来介绍一下在时序数据库中时序查询的基础概念。
1. 降采样（Downsample）
查询数据时，在指定的查询时间段内，相较原始的数据写入精度，以较低的精度进行查询。降采样的本质实际上也是对一条时间线上的数据在时间维度进行聚合。
辐射到真实的业务监控场景中，通常情况下，监控数据会以一个非常高频率的采集方式去持续写入，比如10秒/次，甚至1秒/次采用一组数据，然后写到数据库中。
但是真正在做查询的时候，按照这种原始的粒度展示数据的话，往往会展示数据太多，也不具备观测价值。因此，这种情况我们希望能够以低粒度的方式，比如采集频率为1分钟/次，甚至5分钟/次，以相对较低粒度的方式展示数据，两种采集方式呈现的效果如下。
2. 聚合（Aggregate）
查询数据时，在指定的查询时间段内，对于查询出的多条时间线的数据按时间戳对齐后并按对齐后的时间间隔将不同时间线的值进而聚合成一条时间线的值。
聚合的本质实际上也是对一条时间线上的数据在数据源维度进行聚合计算。
以上图为例，采集到若干条时间线的数据，可能在同一层楼中有若干个传感器去采集各个角度的温度，而我们的目的是了解整层楼的平均温度。
此时可能有4个传感器采集数据，我们需要在将这4个传感器采集到的数据以时间对齐后，然后进行一个求平均操作。
（七）主流时序数据库产品对比
三、最佳实践
（一）适应不同APM场景的Lindorm时序技术栈
Lindorm时序引擎已兼容大多主流的APM开源组件，因此可适用于多种APM场景。
对于常见的监控需求，推荐采用的“Lindorm 时序引擎 + 开源组件”的架构。
如上图所示，Prometheus虽然本身有一个本地存储，但是能保存的数据有限，因此可以通过Prometheus Server接入Lindorm TSDB。
同时还有一些主流的架构，比如通过Telearaf采集数据后写入Kafka，然后通过Flink进行汇总，之后写到Lindorm时序引擎。
目前市面上几乎所有的开源的APM架构中，都是会将Grafana作为APM架构的展示端。
（二）案例:某互联网餐饮系统的业务APM
Ø 采集端
自制采集脚本
Ø 收集端
自制Collector +Kafka+Flink
Ø 存储端
Lindorm时序引擎
Ø 分析&展示
自制可视化工具
使用Lindorm方案带来的提升：
1）稳定性提升到99.9%；
2）系统不可用时长每年可以降低约8.76小时；
3）MTBR缩短约30%。
（三）案例:某直播平台运维监控APM
Ø 采集端
自制采集工具
Ø 收集端
自制Collector +Kafka+定 制Consumer
Ø 存储端
Lindorm 时序引擎
Ø 分析&展示
Grafana
Ø 告警
Bosun
使用Lindorm方案带来的提升：
1） 相较原先的OpenTSDB集群，写入性能提升，集群稳定性提升；
2） 借助Lindorm TSDB的时间线索引，复杂聚合查询成为可能。
（四）案例: Lindorm 时序公有云实例自监控
Ø 采集端
Telegraf
Ø 收集端
SLS + 实时计算Flink版
Ø 存储端
Lindorm 时序引擎
Ø 分析&展示
Grafana
Ø 告警
阿里云监控
使用Lindorm方案带来的提升：
1）写入速率达到50万点/秒+
2）时间序列规模 1000万+ (持续增长中)
3）数据保留 60天
（五）最佳实践 - 监控数据建模
- 数据建模的核心是时间线的设计，最关键的便是标签的设计。
- 尽量减少时间线的数量。
时间线示例
- TSDB会为标签建立倒排索引，因此要避免设计类似所有时间线都具备的同一个标签键值对的情况。因为当一个标签可以命中全部时间线时，这样的倒排索引本身已不再有意义。
倒排索引的示意图
- 对于使用开源组件作为监控数据链路的上下游时，当前建议通过Open TSDB协议接入，因此该类场景下的的数据模型只能是单值数据模型。
（六）最佳实践 - Lindorm时序引擎规格选择
- 两种实例形态
1. Serverless共享型实例
适用于: 开发/测试环境、业务流量峰谷分明、免运维
实例计算资源共享、数据隔离。并发查询限制严格。
2. 资源独享型实例
适用于: 生产环境、大规模写入型业务、时序查询密集型业务、存在自主运维需求
独享型实例申购时的引擎节点规格能力。
（七）最佳实践 - Grafana对接Lindorm时序引擎
Lindorm TSDB可通过Open TSDB协议与Grafana实现对接。
Ø 配置要点
1）OpenTSDB协议版本
2）Lindorm TSDB实例URL
3）时间戳的精度
4）(根据实例配置)用户认证信息
