TIGK监控平台介绍
1 概述
??眾所周知監控平臺對大數據平臺是非常重要的，監控是故障診斷和分析的重要輔助利器，在發生事故之前就能預警，最大限度降低系統故障率。
??監控系統我們可以分為業務層面，應用層面，系統層面
1.1 業務層面
??業務系統是為了達成某種業務目標，因此監控業務系統最有效的方式是從數據上監控業務目標是否達成，因為業務系統的是多樣的所以應由各個業務系統實現監控指標開發。
1.2 應用層面
??需要對應用的整體運行狀況進行了解、把控。一般通過抽象出的統一指標收集組件，收集應用級指標，如JVM堆內存、GC、CPU使用率等。
1.3 系統層面
??實時監控服務器工作狀態，監控性能、內存消耗、容量和整體系統健康狀態等來保證服務器穩定運行。
2 TIGK架構
??大部分的監控系統一般為4個模塊：數據采集、數據存儲、數據展示、告警 。TIGK平臺也是按照此規則，TIGK其實本身技術棧為TICK，即Telegraf，InfluxDB，Chronograf，Kapacitor，但是由于Chronograf沒有Grafana擴展性和易用性強，所以使用了Grafana作為替代方案形成TIGK。下圖為TIGK的整體架構。
??監控系統從收集到分析的流程如下
3 TIGK各組件
3.1 Telegraf
??Telegraf是一個插件驅動的服務器代理，用于收集和報告度量指標。通過plugin來實現數據的input和output，內置了很多常用服務的插件。
??Telegraf通過插件可以直接從它正在運行的系統中獲取各種指標，從第三方API獲取指標，甚至通過Statsd和Kafka的消費者服務來接收度量指標。它提供的輸出插件，將指標發送到各種各樣的數據存儲、服務和消息隊列，包括InfluxDB，Graphite，Kafka，等他組件。
??上圖為官網所示的支持的插件統計，種類非常多，具體可到官網查看https://docs.influxdata.com/telegraf/v1.14/plugins/plugin-list/
Telegraf有四種類型的插件：
??①輸入插件（Inputs）：收集各種時間序列性指標，包含各種系統信息和應用信息的插件。
??②處理插件（Process）：對收集到的指標數據流進行簡單的處理，如給所有指標添加、刪除、修改一個Tag。只是針對當前的指標數據進行。
??③聚合插件（Aggregate）：聚合插件有別于處理插件，就在于它要處理的對象是某段時間流經該插件的所有數據（所以，每個聚合插件都有一個period設置，只會處理now()-period時間段內的數據），比如取最大值、最小值、平均值等操作。
??④輸出插件（Outputs）：收集到的數據，經過處理和聚合后，輸出到數據存儲系統，可以是各種地方，如：文件、InfluxDB、各種消息隊列服務等等。
3.1.1 Telegraf特性
??（1）Go語言編寫，編譯為一個二進制文件，沒有外部依賴。
??（2）占用內存小，通過插件開發人員可輕松添加input和output來支持其他服務的擴展
??（3）支持眾多流行服務大量插件，滿足主流監控需求。
3.1.2 Telegraf相關概念
??Telegraf工作原理：定時去執行輸入插件收集數據，數據經過處理插件和聚合插件，批量輸出到數據存儲。
數據指標（Metrics）：
??①指標名（Measurement name）：指標描述和命名。
??②標簽集合（Tags）：Key/Value鍵值對，常用于快速索引和唯一標識。標簽在設計的時候，盡量避免各種數值型，盡量使用有限集合。
??③字段集合（Fields）：Key/Value鍵值對，包含指標描述的數據類型和值。
??④時間戳（Timestamp）：此條指標數據的時間戳。
3.2 Influxdb
??Influxdb是一個開源的分布式時序、時間和指標數據庫，使用go語言編寫，無需外部依賴。從創建之初就考慮到處理高的寫和查詢負載。InfluxDB是一個定制的高性能數據庫特別用來存儲時間戳數據，包括DevOps監控、應用指標、物聯網傳感器數據，實時分析。為了節省機器上的存儲空間，可以配置InfluxDB保持數據的時間長度，自動到期和從系統中刪除任何不需要的數據。InfluxDB還提供與數據交互的SQL的查詢語言。
3.2.1 Influxdb特性
??（1）時序性（Time Series）：與時間相關的函數的靈活使用（諸如最大、最小、求和等）；
??（2）度量（Metrics）：對實時大量數據進行計算；
??（3）事件（Event）：支持任意的事件數據，換句話說，任意事件的數據我們都可以做操作。
同時，它有以下幾大特點：
??schemaless(無結構)，可以是任意數量的列；
??min, max, sum, count, mean, median 一系列函數，方便統計；
??Native HTTP API, 內置http支持，使用http讀寫；
??Powerful Query Language 類似sql；
??Built-in Explorer 自帶管理工具。
3.2.2 數據格式
??（1）數據格式
??在 InfluxDB 中可以粗略的將要存入的一條數據看作一個虛擬的 key （包括 database, retention policy, measurement, tag sets, field name, timestamp）和其對應的 value(field value)。
??行協議指定了寫入數據的格式：
??①database: 數據庫名，在 InfluxDB 中可以創建多個數據庫，不同數據庫中的數據文件是隔離存放的，存放在磁盤上的不同目錄。
??②retention policy: 存儲策略，用于設置數據保留的時間，每個數據庫剛開始會自動創建一個默認的存儲策略 autogen，數據保留時間為永久。用戶可以自己設置，例如保留最近2小時的數據。插入和查詢數據時如果不指定存儲策略，則使用默認存儲策略，且默認存儲策略可以修改。InfluxDB 會定期清除過期的數據。
??③measurement: 測量指標名，也就是表名。
??④tag sets: tags 在 InfluxDB 中會按照字典序排序，不管是 tagk 還是 tagv，只要不一致就分別屬于兩個 key。
??⑤tag，標簽，在InfluxDB中，tag是一個非常重要的部分，表名+tag一起作為數據庫的索引，是“key-value”的形式。
??⑥field name: InfluxDB 中支持一條數據中插入多個 fieldName，這其實是一個語法上的優化，在實際的底層存儲中，是當作多條數據來存儲。
??⑦timestamp: 每一條數據都需要指定一個時間戳，在 TSM 存儲引擎中會特殊對待，以為了優化后續的查詢操作。
??（3）與關系型數據庫（MySQL）的基礎概念對比
| 數據庫 | database | database |
| 表 | table | measurement |
| 列 | column | t ag(帶索引的，非必須)、field(不帶索引)、timestemp(唯一主鍵) |
??（3）points
??points表示表里面的一行數據，由時間戳time（每個數據記錄時間，是數據庫中的主索引(會自動生成)）、數據field（各種記錄值（沒有索引的屬性））、標簽tags（各種有索引的屬性）。
??（4）Series
??Series 相當于是數據的集合，在同一個 database 中，retention policy、measurement、tag sets 完全相同的數據同屬于一個 series，同一個 series 的數據在物理上會按照時間順序排列存儲在一起。
??（5）Shard
?? Shard 它和 retention policy 相關聯。每一個存儲策略下會存在許多 shard，每一個 shard 存儲一個指定時間段內的數據，并且不重復，如 7點-8點 的數據落入 shard0 中，8點-9點的數據則落入 shard1 中。每一個 shard 都對應一個底層的 tsm 存儲引擎，有獨立的 cache、wal、tsm file。
??（6） 理解series 和 point
??假設對不同學校的歷年排名情況。首先整個數據是一個 measurement ，它包含了許多數據；然后我們根據學校 名稱構建 tag ，把 排名得分作為 field ，那么所有數據行就類似于：
??tag set 就是 tag key = tag value 的不同組合，這里的 tag set 有2種school=Peking和school=Tsinghua。
??2個 tag set 構成了2個 series ，而每個 point 點就是 series 上具體某個 timestamp 對應的點。
3.2.3 TSM 存儲引擎
??TSM 存儲引擎主要由幾個部分組成： cache、wal、tsm file、compactor。
??①Cache：cache 相當于是 LSM Tree 中的 memtabl。插入數據時，實際上是同時往 cache 與 wal 中寫入數據，可以認為 cache 是 wal 文件中的數據在內存中的緩存。當 InfluxDB 啟動時，會遍歷所有的 wal 文件，重新構造 cache，這樣即使系統出現故障，也不會導致數據的丟失。cache 中的數據并不是無限增長的，有一個 maxSize 參數用于控制當 cache 中的數據占用多少內存后就會將數據寫入 tsm 文件。如果不配置的話，默認上限為 25MB，每當 cache 中的數據達到閥值后，會將當前的 cache 進行一次快照，之后清空當前 cache 中的內容，再創建一個新的 wal 文件用于寫入，剩下的 wal 文件最后會被刪除，快照中的數據會經過排序寫入一個新的 tsm 文件中。
??②WAL：wal 文件的內容與內存中的 cache 相同，其作用就是為了持久化數據，當系統崩潰后可以通過 wal 文件恢復還沒有寫入到 tsm 文件中的數據。
??③TSM File：單個 tsm file 大小最大為 2GB，用于存放數據。
??④Compactor：compactor 組件在后臺持續運行，每隔 1 秒會檢查一次是否有需要壓縮合并的數據。主要進行兩種操作，一種是 cache 中的數據大小達到閥值后，進行快照，之后轉存到一個新的 tsm 文件中。另外一種就是合并當前的 tsm 文件，將多個小的 tsm 文件合并成一個，使每一個文件盡量達到單個文件的最大大小，減少文件的數量，并且一些數據的刪除操作也是在這個時候完成。
3.2.4 目錄與文件結構
??InfluxDB 的數據存儲主要有三個目錄。默認情況下是 meta, wal 以及 data 三個目錄。
??（1）meta 用于存儲數據庫的一些元數據，meta 目錄下有一個 meta.db 文件。
??（2）wal 目錄存放預寫日志文件，以 .wal 結尾
??（3）data 目錄存放實際存儲的數據文件，以 .tsm 結尾。
上面幾張圖中，_internal為數據庫名，monitor為存儲策略名稱，再下一層目錄中的以數字命名的目錄是 shard 的 ID 值。
存儲策略下有兩個 shard，ID 分別為 1 和 2，shard 存儲了某一個時間段范圍內的數據。再下一級的目錄則為具體的文件，分別是 .wal 和 .tsm 結尾的文件。
3.2.5 InfluxDB操作方式：
??客戶端命令行方式
??HTTP API接口
??各語言API庫
??基于WEB管理頁面操作
3.3 Grafana
??Grafana是一個功能齊全的度量儀表盤軟件，支持從多種數據源讀取數據用圖表顯示，界面美觀，有沖擊力，功能設計方便實用。多用于可視化基礎實施和應用分析的時間序列數據，也可應用在其它領域，包括工業傳感器、家庭自動化、天氣和過程控制。
3.3.1 Grafana特點
??（1）展示方式：快速靈活的客戶端圖表，面板插件有許多不同方式的可視化指標和日志，官方庫中具有豐富的儀表盤插件，比如熱圖、折線圖、圖表等多種展示方式。監控dashboard 導入、導出，這個功能比較實用，做好一個比較滿意的展示面板，導出后主要修改一下里面的IP等信息，通過導入，其它主機的展示全部搞定。
??（2）豐富的數據源接口：Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch和KairosDB等都能接入；
??（3）通知提醒：以可視方式定義最重要指標的警報規則，Grafana將不斷計算并發送通知，在數據達到閾值時通過Slack、PagerDuty等獲得通知；
??（4）混合展示：在同一圖表中混合使用不同的數據源，可以基于每個查詢指定數據源，甚至自定義數據源；
??（5）注釋：使用來自不同數據源的豐富事件注釋圖表，將鼠標懸停在事件上會顯示完整的事件元數據和標記；
??（6）過濾器：Ad-hoc過濾器允許動態創建新的鍵/值過濾器，這些過濾器會自動應用于使用該數據源的所有查詢；
??（7）豐富的API接口，方便自動化程序調用。
3.4 Kapacitor
??Kapacitor是時序數據分析、處理引擎。它可以處理來自InfluxDB的流數據和批量數據。Kapacitor允許插入用戶自定義的邏輯或用戶自定義的函數來處理基于動態門限的告警，匹配模式指標，計算統計異常，并根據這些告警執行特定動作，比如動態負載均衡。Kapacitor支持Email，HTTP，TCP，HipChat，OpsGenie，Alerta，Sensu，PagerDuty，Slack等多種方式告警。
3.4.1 特點
??（1）可以處理基于InfluxQL的批處理與將數據存儲在內存中的流處理，并使用tick腳本來進行處理規則的定義；
??（2）按計劃從InfluxDB查詢數據，或通過line協議從InfluxDB接收數據；
??（3）使用InfluxQL對數據做各種轉換；將轉換后的數據存回InfluxDB，事件輸出源還可以是email,http post,tcp, log, telegram,kafka,alerta,MQTT等；
??（4）添加用戶自定義函數檢測異常；
與HipChat, OpsGenie, Alerta, Sensu, PagerDuty, Slack等集成。
3.4.2 相關名詞解釋
| task | 數據計算規則，由一系列節點node形成的數據處理的有向無環圖DAG |
| task template | 通過模版變量來定制task |
| topic | 預警檢測程序-如果沒有顯示在alert中用topic指定，會用程序的alert node來代替 |
| event | 觸發的報警事件 |
| handler | 報警事件輸出程序 |
| topic handler | 報警事件的輸出有兩種方式，一種是alert node的屬性方法直接調用，一種是通過alert指定topic與yaml描述文件來定義 |
| record | 數據錄制 |
| replay | 數據回放 |
| name | 度量名（相當于influxdb的measurement） |
| tags | 標簽（相當于influxdb的tag key tag field） |
| columns | 字段（相當于influxdb的 field key） |
| values | 字段值（相當于influxdb的field value） |
| string template | 字符串模版 |
| lambda | 函數表達式 |
3.4.3 數據處理模型
?? 它遵循基于工作流的編程模型。數據流從一個node到另一個node，每個node是一個黑盒的過程，它能以任意方式處理數據。nodes是以有向無環圖的方式分布的
?? Tasks是通過TICK腳本來定義的，有三種狀態disabled，enabled not executing，enabled executing
??傳輸數據的數據模型有兩種Stream和Batch。①Stream：數據點（由時間戳timestamp，一系列的屬性fileds和tags組成）作為單個實體傳遞。數據立即被transfer，并且每次只transfer一個數據點②Batch：數據點以數據組的形式傳遞，將多個數據點看作一個整體輸入
總結
以上是生活随笔為你收集整理的TIGK监控平台介绍的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： k近邻算法(KNN)-分类算法
- 下一篇： java封装省市区三级json格式,微信