一、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
1） 相較原先的OpenTSDB叢集，寫入性能提升，叢集穩定性提升；
2） 借助Lindorm TSDB的時間線索引，複雜聚合查詢成為可能。
（四）案例: Lindorm 時序公有雲執行個體自監控
Telegraf
SLS + 實時計算Flink版
阿裡雲監控
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）(根據執行個體配置)使用者認證資訊