kubernetes使得複雜環境的管理變得容易，但是為了確保可用性，對kubernetes元件以及群集上執行的所有應用程式進行操作深入分析至關重要。在coreos，我們相信監控是良好生產環境的基石，這也是我們投入開發prometheus監控系統（的原因。作為乙個由cloud native computing foundation（cncf）支援的專案，prometheus迅速獲得了基礎設施及應用監控方面的熱度，今天是它更進一步的時候。
coreos將prometheus作為我們企業級kubernetes平台tectonic的整合元件，並且我們也一直在努力提公升其對kubernetes使用者的價值。今年早些時候，我們分享了關於下一代prometheus（version 2.0）的新儲存層方面的工作。為了穩固這項工作，我們和prometheus團隊以及我們的使用者進行了更加密切的合作。在3個alpha版本，6個beta版本以及3個rc版本之後，今天prometheus 2.0正式宣布穩定版本。感謝brian brazil和goutham veeramachaneni，他們在這項工作中付出巨大。在我們探索該發行版的優點之前，讓我們回過頭來，先**一下我們為何需要乙個新的儲存層。
時間序列和動態環境
prometheus關於監控的理念鼓勵在堆疊的每一層都採用高度詳細的度量工具。容器的狀態，通過的請求流，甚至是執行於其中的應用的深層資訊都通過度量工具對外可見。prometheus帶來了一款強力的查詢語言幫助將度量資料彙總轉換成行動方案。
prometheus通過時間序列的方式收集和儲存資料，它是通過固定間隔收集到的帶有時間戳資料的序列。這種設計可以使執行中的容器輕鬆產生成千的時間序列。隨著容器的規模從成百擴充套件到成千，在集群中很可能產生數百萬被跟蹤的時間序列。
為上百萬的時間序列持續寫入資料顯然是一項技術難題。更糟糕的是，kubernetes使得持續銷毀和建立容器變得十分容易。該項模型對於持續部署，自動擴容以及批處理作業排程而言是極為強大的，因此只會隨著時間的推移而變得越來越普遍。
每個容器都有乙個獨一無二的識別符號，所有其時間序列均包含該識別符號，以達到最佳的視角。因此當被跟蹤的活躍時間序列總數大致固定時，prometheus中可以對外訪問的所有歷史時間序列資料是持續增長的。允許查詢十億級的時間序列是一項全新的挑戰，但我們決定讓prometheus很好地支援該特性。
新的儲存引擎就是用來解決這項挑戰的。受到全文搜尋的啟發，它使用倒排索引以提供對於prometheus時間序列可能擁有的任意緯度進行快速檢索。新的磁碟格式確保相關的時間序列資料良好分布，另外write-ahead日誌也使得prometheus 2.0n能夠從崩潰中恢復。
prometheus同樣變得更易操作了。prometheus 1.x的使用者應該對調整期望負載的儲存配置十分熟悉。然而，有了新的儲存層之後，這些控制就不再需要了。
基準測
這項工作的真實結果是令人印象深刻的。prometheus 2.0的資源消耗得到了顯著降低，使用率更加穩定，並且新的索引方式帶來了更低且一致的查詢延遲。
下方的圖是乙個基準測試集的結果，它來自乙個執行著成百個應用pod並被監控的kubernetes集群。pod按照高頻率替換以產生時間序列的擾動。各有2個prometheus 1.5和prometheus 2.0例項執行採集新資料。不同版本中，各有1個例項對外服務，以產生適中性的高查詢負載。
從前2個圖中，我們可以看到prometheus 2.0的記憶體和cpu消耗均明顯更低，並且自啟動後，它們很快到達穩定狀態。prometheus 1.5則需要更多的資源，並且其資源使用率難以**。
prometheus 2.0中最大的改進是其每秒寫入磁碟的資料量，可以檢視下圖。新版本的寫入量較之前低了近2個數量級。很明顯，這能增加ssd的壽命（譯者：ssd壽命由pe次數決定，與寫入資料量密切相關），進而降低成本。在高序列擾動的情況下，即使使用相同的序列壓縮演算法，依舊可以觀察到顯著的磁碟空間節省。
在prometheus 1.5中，隨著更多的時間序列被建立，查詢的延遲是線性增長的。prometheus 2.0則從一開始就維持了穩定的效能，它使得查詢的反饋更加敏捷，正如下圖所示。
其餘新特性
prometheus 2.0的大多數工作都聚焦於提公升效能並使其更加易於操作。但是新的儲存層同樣被設計以更好地和prometheus的外部互動，這使得圍繞收集到的時間序列資料進行廣泛的定製處理成為可能。
快照備份是一項被頻繁要求的特性。當使用flag --web.enable-admin-api時，只需要通過簡單的api呼叫，prometheus 2.0便可原生支援它們。
bash$ curl -xpost http:///api/v2/admin/tsdb/snapshot快照存放於名為返回值的目錄中，且可以被上傳到歸檔儲存中，它們幾乎不會占用額外的磁碟空間。最棒的是，新的prometheus伺服器可以從備份的資料啟動，你只需將資料移動到新的伺服器資料目錄中即可。
關於完整的變更列表以及如何從prometheus 1.x遷移，請檢視官方宣告（以及遷移指南（
敬請嘗試
有關prometheus 2.0增強的最佳部分是，prometheus當前不但可以比以往更好地支援kubernetes的工作負載，更在於當kubernetes在基礎設施中活力倍增時，它預留了足夠的空間來支撐屆時的工作負載。
如果你想要親自了解整合prometheus支援是如何使得coreos tectonic成為真正的企業級kubernetes平台的，你可以免費部署乙個不多於10個節點的tectonic集群。你將能夠使用最新的prometheus操作器不費吹灰之力地在集群中部署prometheus 2.0，而無需額外的配置。
宣告：本文中的基準測試通過prombench（生成。為了復現它們，你需要乙個配置好的aws賬戶，並且你必須指定想要執行的基準測試spec。spec.example.yaml正是生成本文所用圖的spec。
grafana安裝及監控Prometheus
grafana是乙個跨平台的開源的度量分析和視覺化工具，可以通過將採集的資料查詢然後視覺化的展示，並及時通知。它主要有以下六大特點 1 展示方式 快速靈活的客戶端圖表，面板外掛程式有許多不同方式的視覺化指標和日誌，官方庫中具有豐富的儀錶盤外掛程式，比如熱圖 折線圖 圖表等多種展示方式 2 資料來源 ...
docker容器監控
容器具有以下特性 容器是短期存活的，並且可以動態排程 容器的本質是程序，而不是乙個完整作業系統 由於容器非常輕量，容器的建立和銷毀也會比傳統虛擬機器更加頻繁。docker 容器的監控方案有很多，除了 docker 自帶的docker stats命令，還有很多開源的解決方案，例如 sysdig cad...
TIG監控平台監控docker容器
influxdb是乙個時序資料庫，用來記錄監控資訊。開放8083和8086兩個埠 8083是influxdb的web管理端，8086是資料傳輸埠 初始建立資料庫telegraf供telegraf儲存資料 telegraf是負責收集docker資訊並 到influxdb的工具，通過簡單的配置即可監控d...