Puppet監控速查手冊：問題/原因→解決方案

導語

基於京東雲豐富的實戰經驗，我們將陸續分享運維方面的乾貨，幫助小夥伴們進階為運維達人，歡迎持續關注。首先帶來的是“監控”專題系列。

本期作者：木槿

京東雲

應用研發部

Puppet是基於C/S架構的集中配置管理系統，基於自有描述性語言，可以實現對配置檔案、使用者、定時任務、軟體包、系統服務等管理，保證大規模叢集基礎配置一致性。

我們用Puppet管理了上千臺伺服器，經過多次最佳化監控，自動化灰度釋出保證了所有叢集基礎配置一致性。本文探討了如何對Puppet系統進行監控，也將典型問題和解決方案一併分享給大家。

監控選型

Foreman提供了較全面的互動設施，包括Web前端、CLI和RESTful API。在此基礎之上，可以構建監控管理系統，以及實現報警等功能。

核心業務流程

可以簡單將Puppet的工作流程抽象為四部分：

請求階段：Agent基於SSL將自身資訊傳送給Server；
響應階段：Server基於客戶端資訊解析相應的配置，並最終將虛擬碼（catalog）傳送回Agent；
執行階段：Agent接收catalog並執行命令或者更新檔案；
彙報階段：Agent把結果彙報給Server。

圖1 Puppet工作流程

監控概覽

對Puppet的核心監控主要覆蓋如下環節：

Agent與Master通訊是否正常；
Agent策略執行是否生效；
Puppet釋出的策略生效時間及範圍；
Master及其所管理叢集的執行狀態。

黑盒監控

Puppet黑盒監控指標不符合預期，說明叢集不能正常工作或出現異常，黑盒監控指標有：所有策略是否都生效，策略生效範圍是否符合預期，策略生效結果是否符合預期。

所有策略是否都生效

說明：將一批測試節點，加入到線上Puppet叢集，透過定期執行檢查指令碼驗證所有策略是否都生效。

策略生效範圍

說明：策略上線後，需要確認其生效範圍是否符合預期，即策略是否僅在指定的節點生效。

實現：透過Puppet模組MCollective定時執行檢查任務（檢查實際生效的機器列表和服務樹機器列表是否一致），如下圖，叢集hn-xdata 有98%的機器符合預期，2%不符合。

圖2 Puppet策略生效範圍監控

策略生效結果是否符合預期

說明：策略上線後，需要確保所有策略在所有機器都生效。

實現：透過Puppet模組MCollective定時執行檢查任務，（檢查實際生效的機器列表和服務樹機器列表是否一致），如下圖，每一個策略有一張餅圖。

圖3 Puppet策略結果監控

白盒監控

白盒監控是黑盒監控的補充，服務於故障定位，從叢集容量、流量、延遲、錯誤四個方面梳理。

資料採集方式：

透過Foreman API
Master日誌分析

表1 透過Foreman API獲取採集的白盒指標概覽

指標	說明
No reports	沒有彙報的主機
Error	連上了但是執行策略出錯
Out of sync	執行策略超時；主機名重複；主機連不上
Active	Agent拉取策略正常
Pending	容量指標，Master處理不過來
No changes	Agent正常拉取策略但是沒有變更
puppet_report_time_total	Agent執行策略總時間
Pv	每分鐘訪問量

容量

Master所在例項的CPU，網路連線數指標，網路卡

流量

Agent PV，基於Puppet Master的訪問日誌puppetserver-access.log來計算流量

圖4 Agent PV流量圖

延遲

單個Agent更新策略需要的時間：puppet_report_time_total

說明：puppet_report_time_total 是Agent從連線Master到傳送報告給Master總時間，0-3s的佔50%，0-11s的佔90%，0-15s佔99%。

圖5 Agent 延遲

錯誤

No reports：沒有報告的例項數量；
Error agent：執行策略出錯的例項數量；
Out of sync：執行策略超時、主機名重複、主機連不上Master的例項數量。

圖6 Foreman錯誤監控指標

Puppet監控發現的問題

Agent覆蓋所有機器

問題：不能保證所有機器Agent都正常執行。

解決方案：基於服務樹或者CMDB相關係統將所有機器填加Agent程式監控。

Agent執行策略超時

問題：大檔案併發下載時，出現超時告警。

排查方法：在Agent上執行命令“puppet agent -t --debug”, 發現在拉取檔案時超時，由於檔案較大，在Master上同時很多Agent拉取，導致超時。

解決方案：將大檔案存放在雲端儲存上，提高下載速度。

分組不止僅限於現有Facter屬性

問題：策略分組和灰度釋出分組現有Facter屬性不滿足。

原因：隨著接入業務越來越多，業務分組也越多。

解決方案：自定義Facter。

Agent不同步（Out of Sync）

問題：Agent報不同步。

原因及解決方案：

表二

原因	解決方案
主機名重複	修改Agent Hostname後重新認證
主機認證後重新命名	直接在Foreman控制檯中刪除原名稱認證的機器
Agent服務異常	在Agent上重啟Puppet服務
Agent磁碟打滿	清理磁碟後，Agent會自行啟動並恢復
Agent端證書error	在Agent上刪除/etc/puppetlabs/puppet/ssl資料夾後，執行puppet agent –t重新認證
Agent端puppet.conf檔案為空	將相應的[Agent]配置寫入puppet.conf檔案中即可恢復
Master端puppe.conf檔案為空	將相應[Master]配置寫入puppet.conf檔案中即可恢復
Foreman服務down掉	在Foreman機器上執行service httpd restart、service foreman restart
Could not request certificate	1)Agent與Master時間不同步，ntpdate master –IP同步時間；2)Agent與Master端網路不通；3)Master端8140埠不通

策略釋出到非預期叢集

問題：策略生效範圍出錯。

原因：Puppet Master入口檔案統一為site.pp，由於策略分組多，在灰度釋出階段，相應分支也會很多，運維工程師很容易操作出錯。

解決方案：將site.pp作為一個策略模組進行管理，策略模組中包含預設default分組，以及需要灰度釋出的分組。manifest資料夾下的site.pp只需include該模組即可。

圖7 site.pp最佳化後default分組策略

圖8 策略釋出灰度階段分組

功能監控發現所同步的檔案非預期

問題：Master採用叢集方式部署，在策略變更期間多臺Master上資料可能不同步，此時，同一Agent拉取到的檔案可能不一致。

原因：由於有多臺Master，其中一臺Master沒有更新檔案，LB透過輪詢策略進行轉發，當Agent請求Master時是Master A，再拉取檔案時請求的可能是Master B，兩臺Master資料不一致。

解決方案：LB策略更新為源IP雜湊。

Puppet監控速查手冊：問題/原因→解決方案

相關文章