熱門搜索 Zabbix技術資料 Zabbix常見問、答討論 成功案例 Zabbix交流區 Prometheus交流區
這一期尊龍時凱君主要跟大家來探討新一代的開源監控prometheus，我們知道 zabbix 在監控界占有不可撼動的地位，功能強大。但是對容器監控顯得力不從心。為解決監控容器的問題，引入了 Prometheus 技術。接下來的文章打算圍繞 Prometheus 做一個系列的介紹，順便也幫自己理清一下知識點。
Prometheus官網上的自述是：“From metrics to insight.Power your metrics and alerting with a leading open-source monitoring solution.”翻譯過來就是：從指標到洞察力，Prometheus通過領先的開源監控解決方案為用戶的指標和告警提供強大的支持。通過PromQL實現多維度數據模型的靈活查詢。 定義了開放指標數據的標準，自定義探針（如Exporter等），編寫簡單方便。 PushGateway組件讓這款監控系統可以接收監控數據。 提供了VM和容器化的版本。 尤其是第一點，這是很多監控系統望塵莫及的。多維度的數據模型和靈活的查詢方式，使監控指標可以關聯到多個標簽，并對時間序列進行切片和切塊，以支持各種圖形、表格和告警場景。
Prometheus主要由Prometheus Server、Pushgateway、Job/Exporter、Service Discovery、Alertmanager、Dashboard這6個核心模塊構成。Prometheus通過服務發現機制發現target，這些目標可以是長時間執行的Job，也可以是短時間執行的Job，還可以是通過Exporter監控的第三方應用程序。被抓取的數據會存儲起來，通過PromQL語句在儀表盤等可視化系統中供查詢，或者向Alertmanager發送告警信息，告警會通過頁面、電子郵件、釘釘信息或者其他形式呈現。
從上述架構圖中可以看到，Prometheus不僅是一款時間序列數據庫，在整個生態上還是一套完整的監控系統。對于時間序列數據庫，在進行技術選型的時候，往往需要從寬列模型存儲、類SQL查詢支持、水平擴容、讀寫分離、高性能等角度進行分析。而監控系統的架構，往往還需要考慮通過減少組件、服務來降低成本和復雜性以及水平擴容等因素。
很多企業自己研發的監控系統中往往會使用消息隊列Kafka和Metrics parser、Metrics process server等Metrics解析處理模塊，再輔以Spark等流式處理方式。應用程序將Metric推到消息隊列（如Kafaka），然后經過Exposer中轉，再被Prometheus拉取。之所以會產生這種方案，是因為考慮到有歷史包袱、復用現有組件、通過MQ（消息隊列）來提高擴展性等因素。這個方案會有如下幾個問題。
增加了查詢組件，比如基礎的sum、count、average函數都需要額外進行計算。這一方面多了一層依賴，在查詢模塊連接失敗的情況下會多提供一層故障風險；另一方面，很多基本的查詢功能的實現都需要消耗資源。而在Prometheus的架構里，上述這些功能都是得到支持的。 抓取時間可能會不同步，延遲的數據將會被標記為陳舊數據。如果通過添加時間戳來標識數據，就會失去對陳舊數據的處理邏輯。
Prometheus適用于監控大量小目標的場景，而不是監控一個大目標，如果將所有數據都放在Exposer中，那么Prometheus的單個Job拉取就會成為CPU的瓶頸。這個架構設計和Pushgateway類似，因此如果不是特別必要的場景，官方都不建議使用。 缺少服務發現和拉取控制機制，Prometheus只能識別Exposer模塊，不知道具體是哪些target，也不知道每個target的UP時間，所以無法使用Scrape_*等指標做查詢，也無法用scrape_limit做限制。
對于上述這些重度依賴，可以考慮將其優化掉，而Prometheus這種采用以拉模式為主的架構，在這方面的實現是一個很好的參考方向。同理，很多企業的監控系統對于cmdb具有強依賴，通過Prometheus這種架構也可以消除標簽對cmdb的依賴。
Job/Exporter屬于Prometheus target，是Prometheus監控的對象。
Job分為長時間執行和短時間執行兩種。對于長時間執行的Job，可以使用Prometheus Client集成進行監控；對于短時間執行的Job，可以將監控數據推送到Pushgateway中緩存。
Prometheus收錄的Exporter有上千種，它可以用于第三方系統的監控。Exporter的機制是將第三方系統的監控數據按照Prometheus的格式暴露出來，沒有Exporter的第三方系統可以自己定制Exporter。
Exporter種類繁多，每個Exporter又都是獨立的，每個組件各司其職。但是Exporter越多，維護壓力越大，尤其是內部自行開發的Agent等工具需要大量的人力來完成資源控制、特性添加、版本升級等工作。
針對以上問題，可以考慮用Influx Data公司開源的Telegra統一進行管理。Telegraf是一個用Golang編寫的用于數據收集的開源Agent，其基于插件驅動。Telegraf提供的輸入和輸出插件非常豐富，當用戶有特殊需求時，也可以自行編寫插件（需要重新編譯）。
Telegraf就是Influx Data公司的時間序列平臺TICK（一種高性能時序中臺）技術棧中的“T”，主要用于收集時間序列型數據，比如服務器CPU指標、內存指標、各種IoT設備產生的數據等。Telegraf支持各種類型Exporter的集成，可以實現Exporter的多合一。還有一種思路就是通過主進程拉起多個Exporter進程，仍然可以跟著社區版本進行更新。
Telegraf的CPU和內存使用率極低，支持幾乎所有的集成監控和豐富的社區集成可視化，如Linux、Redis、Apache、StatsD、Java/Jolokia、Cassandra、MySQL等。由于Prometheus和InfluxDB都是時間序列存儲監控系統，可以變通地將Telegraf對接到Prometheus中。在實際POC環境驗證中，使用Telegraf集成Prometheus比單獨使用Prometheus會擁有更低的內存使用率和CPU使用率。
Prometheus是拉模式為主的監控系統，它的推模式就是通過Pushgateway組件實現的。Pushgateway是支持臨時性Job主動推送指標的中間網關，它本質上是一種用于監控Prometheus服務器無法抓取的資源的解決方案。它也是用Go語言編寫的，在Apache 2.0許可證下開源。
Pushgateway作為一個獨立的服務，位于被采集監控指標的應用程序和Prometheus服務器之間。應用程序主動推送指標到Pushgateway，Pushgateway接收指標，然后Pushgateway也作為target被Prometheus服務器抓取。它的使用場景主要有如下幾種: 臨時/短作業。 批處理作業。 應用程序與Prometheus服務器之間有網絡隔離，如安全性（防火墻）、連接性（不在一個網段，服務器或應用程序僅允許特定端口或路徑訪問）。 Pushgateway與網關類似，在Prometheus中被建議作為臨時性解決方案，主要用于監控不太方便訪問到的資源。它會丟失很多Prometheus服務器提供的功能，比如UP指標和指標過期時進行實例狀態監控。
Prometheus通過服務發現機制對云以及容器環境下的監控場景提供了完善的支持。
Prometheus會周期性地從文件中讀取最新的target信息。
對于支持文件的服務發現，實踐場景下可以衍生為與自動化配置管理工具（Ansible、Cron Job、Puppet、SaltStack等）結合使用。
Prometheus還支持多種常見的服務發現組件，如Kubernetes、DNS、Zookeeper、Azure、EC2和GCE等。例如，Prometheus可以使用Kubernetes的API獲取容器信息的變化（如容器的創建和刪除）來動態更新監控對象。
通過服務發現的方式，管理員可以在不重啟Prometheus服務的情況下動態發現需要監控的target實例信息。
服務發現中有一個高級操作，就是Relabeling機制。Relabeling機制會從Prometheus包含的target實例中獲取默認的元標簽信息，從而對不同開發環境（測試、預發布、線上）、不同業務團隊、不同組織等按照某些規則（比如標簽）從服務發現注冊中心返回的target實例中有選擇性地采集某些Exporter實例的監控數據。
這句話的意思就是Relabeling機制可以讓prometheus按照動態的按照某些規則采集指定監控數據。
Prometheus服務器是Prometheus最核心的模塊。它主要包含抓取、存儲和查詢這3個功能
Prometheus Server通過服務發現組件，周期性地從上面介紹的Job、Exporter、Pushgateway這3個組件中通過HTTP輪詢的形式拉取監控指標數據。
抓取到的監控數據通過一定的規則清理和數據整理（抓取前使用服務發現提供的relabel_configs方法，抓取后使用作業內的metrics_relabel_configs方法），會把得到的結果存儲到新的時間序列中進行持久化。多年來，存儲模塊經歷了多次重新設計，Prometheus 2.0版的存儲系統是第三次迭代。該存儲系統每秒可以處理數百萬個樣品的攝入，使得使用一臺Prometheus服務器監控數千臺機器成為可能。使用的壓縮算法可以在真實數據上實現每個樣本1.3B。建議使用SSD，但不是嚴格要求。
本地存儲：會直接保留到本地磁盤，性能上建議使用SSD且不要保存超過一個月的數據。記住，任何版本的Prometheus都不支持NFS。一些實際生產案例告訴我們，Prometheus存儲文件如果使用NFS，則有損壞或丟失歷史數據的可能。 遠程存儲：適用于存儲大量的監控數據。Prometheus支持的遠程存儲包括OpenTSDB、InfluxDB、Elasticsearch、Graphite、CrateDB、Kakfa、PostgreSQL、TimescaleDB、TiKV等。遠程存儲需要配合中間層的適配器進行轉換，主要涉及Prometheus中的remote_write和remote_read接口。在實際生產中，遠程存儲會出現各種各樣的問題，需要不斷地進行優化、壓測、架構改造甚至重寫上傳數據邏輯的模塊等工作。
Prometheus持久化數據以后，客戶端就可以通過PromQL語句對數據進行查詢了。
在Prometheus架構圖中提到，Web UI、Grafana、API client可以統一理解為Prometheus的Dashboard。Prometheus服務器除了內置查詢語言PromQL以外，還支持表達式瀏覽器及表達式瀏覽器上的數據圖形界面。實際工作中使用Grafana等作為前端展示界面，用戶也可以直接使用Client向Prometheus Server發送請求以獲取數據。
Alertmanager是獨立于Prometheus的一個告警組件，需要單獨安裝部署。Prometheus可以將多個Alertmanager配置為一個集群，通過服務發現動態發現告警集群中節點的上下線從而避免單點問題，Alertmanager也支持集群內多個實例之間的通信。
Alertmanager接收Prometheus推送過來的告警，用于管理、整合和分發告警到不同的目的地。Alertmanager提供了多種內置的第三方告警通知方式，同時還提供了對Webhook通知的支持，通過Webhook用戶可以完成對告警的更多個性化的擴展。Alertmanager除了提供基本的告警通知能力以外，還提供了如分組、抑制以及靜默等告警特性。
Prometheus固然強大，但它還是具有一定局限性的。
Prometheus作為一個基于度量的系統，不適合存儲事件或者日志等，它更多地展示的是趨勢性的監控。如果用戶需要數據的精準性，可以考慮ELK或其他日志架構。另外，APM更適用于鏈路追蹤的場景。
Prometheus認為只有最近的監控數據才有查詢的需要，所有Prometheus本地存儲的設計初衷只是保存短期（如一個月）的數據，不會針對大量的歷史數據進行存儲。如果需要歷史數據，則建議使用Prometheus的遠端存儲，如OpenTSDB、M3DB等。
Prometheus在集群上不論是采用聯邦集群還是采用Improbable開源的Thanos等方案，都沒有InfluxDB成熟度高，需要解決很多細節上的技術問題（如耗盡CPU、消耗機器資源等問題），這也是本章開頭提到的InfluxDB在時序數據庫中排名第一的原因之一。部分互聯網公司擁有海量業務，出于集群的原因會考慮對單機免費但是集群收費的InfluxDB進行自主研發。
總之，使用Prometheus一定要了解它的設計理念：它并不是為了解決大容量存儲問題，TB級以上數據建議保存到遠端TSDB中；它是為運行時正確的監控數據準備的，無法做到100%精準，存在由內核故障、刮擦故障等因素造成的微小誤差
這一期的Prometheus技術分享到這就結束了，更多開源監控技術分享請持續關注尊龍時凱官網或尊龍時凱社區（http://forum.ydcanyin.com/）
通過Nginx反向代理是一個不錯的選擇。 本文尊龍時凱君將介紹通過Nginx反向代理增加401認證方式來實現加密登錄。
View details
prometheus監控宿主機，使用node_exporter工具來暴露主機和因公程序上的指標； prometheus監控docker容器，通過Cadviso
View details
對于運維監控而言，除了監控展示以外，另一個重要的需求無疑就是告警了。良好的告警可以幫助運維人員及時的發現問題，處理問題并防范于未然，是運維工作中不...
View details
prometheus監控宿主機，使用node_exporter工具來暴露主機和因公程序上的指標； prometheus監控docker容器，通過Cadviso
View details
尊龍時凱監控實現對城建學院復雜網絡環境的直觀、透明式展示和管理，實時、準確了解整個網絡的動態運行情況，給信息部門的決策提供依據。
View details
尊龍時凱官網
