Puppet監(jiān)控速查問(wèn)題的原因及解決方案是什么

Puppet監(jiān)控速查問(wèn)題的原因及解決方案是什么,相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策,為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法,通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

在上饒等地區(qū),都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局,加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力,以專注、極致的服務(wù)理念,為客戶提供做網(wǎng)站、成都網(wǎng)站制作 網(wǎng)站設(shè)計(jì)制作按需定制,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),網(wǎng)絡(luò)營(yíng)銷推廣,成都外貿(mào)網(wǎng)站建設(shè),上饒網(wǎng)站建設(shè)費(fèi)用合理。

Puppet是基于C/S架構(gòu)的集中配置管理系統(tǒng),基于自有描述性語(yǔ)言,可以實(shí)現(xiàn)對(duì)配置文件、用戶、定時(shí)任務(wù)、軟件包、系統(tǒng)服務(wù)等管理,保證大規(guī)模集群基礎(chǔ)配置一致性。

我們用Puppet管理了上千臺(tái)服務(wù)器,經(jīng)過(guò)多次優(yōu)化監(jiān)控,自動(dòng)化灰度發(fā)布保證了所有集群基礎(chǔ)配置一致性。本文探討了如何對(duì)Puppet系統(tǒng)進(jìn)行監(jiān)控,也將典型問(wèn)題和解決方案一并分享給大家。

監(jiān)控選型

Foreman提供了較全面的交互設(shè)施,包括Web前端、CLI和RESTful API。在此基礎(chǔ)之上,可以構(gòu)建監(jiān)控管理系統(tǒng),以及實(shí)現(xiàn)報(bào)警等功能。

核心業(yè)務(wù)流程

可以簡(jiǎn)單將Puppet的工作流程抽象為四部分:

  • 請(qǐng)求階段:Agent基于SSL將自身信息發(fā)送給Server;

  • 響應(yīng)階段:Server基于客戶端信息解析相應(yīng)的配置,并最終將偽代碼(catalog)發(fā)送回Agent;

  • 執(zhí)行階段:Agent接收catalog并執(zhí)行命令或者更新文件;

  • 匯報(bào)階段:Agent把結(jié)果匯報(bào)給Server。

Puppet監(jiān)控速查問(wèn)題的原因及解決方案是什么

圖1 Puppet工作流程

監(jiān)控概覽

對(duì)Puppet的核心監(jiān)控主要覆蓋如下環(huán)節(jié):

  • Agent與Master通信是否正常;

  • Agent策略執(zhí)行是否生效;

  • Puppet發(fā)布的策略生效時(shí)間及范圍;

  • Master及其所管理集群的運(yùn)行狀態(tài)。

黑盒監(jiān)控

Puppet黑盒監(jiān)控指標(biāo)不符合預(yù)期,說(shuō)明集群不能正常工作或出現(xiàn)異常,黑盒監(jiān)控指標(biāo)有:所有策略是否都生效,策略生效范圍是否符合預(yù)期,策略生效結(jié)果是否符合預(yù)期。

所有策略是否都生效

說(shuō)明:將一批測(cè)試節(jié)點(diǎn),加入到線上Puppet集群,通過(guò)定期運(yùn)行檢查腳本驗(yàn)證所有策略是否都生效。

策略生效范圍

說(shuō)明:策略上線后,需要確認(rèn)其生效范圍是否符合預(yù)期,即策略是否僅在指定的節(jié)點(diǎn)生效。

實(shí)現(xiàn):通過(guò)Puppet模塊MCollective定時(shí)執(zhí)行檢查任務(wù)(檢查實(shí)際生效的機(jī)器列表和服務(wù)樹(shù)機(jī)器列表是否一致),如下圖,集群hn-xdata 有98%的機(jī)器符合預(yù)期,2%不符合。

Puppet監(jiān)控速查問(wèn)題的原因及解決方案是什么

圖2 Puppet策略生效范圍監(jiān)控

策略生效結(jié)果是否符合預(yù)期

說(shuō)明:策略上線后,需要確保所有策略在所有機(jī)器都生效。

實(shí)現(xiàn):通過(guò)Puppet模塊MCollective定時(shí)執(zhí)行檢查任務(wù),(檢查實(shí)際生效的機(jī)器列表和服務(wù)樹(shù)機(jī)器列表是否一致),如下圖,每一個(gè)策略有一張餅圖。

Puppet監(jiān)控速查問(wèn)題的原因及解決方案是什么

圖3 Puppet策略結(jié)果監(jiān)控

白盒監(jiān)控

白盒監(jiān)控是黑盒監(jiān)控的補(bǔ)充,服務(wù)于故障定位,從集群容量、流量、延遲、錯(cuò)誤四個(gè)方面梳理。

數(shù)據(jù)采集方式:

  • 通過(guò)Foreman API

  • Master日志分析

表1 通過(guò)Foreman API獲取采集的白盒指標(biāo)概覽

指標(biāo)

說(shuō)明

No reports

沒(méi)有匯報(bào)的主機(jī)

Error

連上了但是執(zhí)行策略出錯(cuò)

Out of sync

執(zhí)行策略超時(shí);主機(jī)名重復(fù);主機(jī)連不上

Active

Agent拉取策略正常

Pending

容量指標(biāo),Master處理不過(guò)來(lái)

No changes

Agent正常拉取策略但是沒(méi)有變更

puppet_report_time_total

Agent執(zhí)行策略總時(shí)間

Pv

每分鐘訪問(wèn)量

容量

Master所在實(shí)例的CPU,網(wǎng)絡(luò)連接數(shù)指標(biāo),網(wǎng)卡

流量

Agent PV,基于Puppet Master的訪問(wèn)日志puppetserver-access.log來(lái)計(jì)算流量

Puppet監(jiān)控速查問(wèn)題的原因及解決方案是什么

圖4 Agent PV流量圖

延遲

單個(gè)Agent更新策略需要的時(shí)間:puppet_report_time_total

說(shuō)明:puppet_report_time_total 是Agent從連接Master到發(fā)送報(bào)告給Master總時(shí)間,0-3s的占50%,0-11s的占90%,0-15s占99%。

Puppet監(jiān)控速查問(wèn)題的原因及解決方案是什么

圖5 Agent 延遲

錯(cuò)誤

  • No reports:沒(méi)有報(bào)告的實(shí)例數(shù)量;

  • Error agent:執(zhí)行策略出錯(cuò)的實(shí)例數(shù)量;

  • Out of sync:執(zhí)行策略超時(shí)、主機(jī)名重復(fù)、主機(jī)連不上Master的實(shí)例數(shù)量。

Puppet監(jiān)控速查問(wèn)題的原因及解決方案是什么

圖6 Foreman錯(cuò)誤監(jiān)控指標(biāo)

Puppet監(jiān)控發(fā)現(xiàn)的問(wèn)題

Agent覆蓋所有機(jī)器

問(wèn)題:不能保證所有機(jī)器Agent都正常運(yùn)行。

解決方案:基于服務(wù)樹(shù)或者CMDB相關(guān)系統(tǒng)將所有機(jī)器填加Agent進(jìn)程監(jiān)控。

Agent執(zhí)行策略超時(shí)

問(wèn)題:大文件并發(fā)下載時(shí),出現(xiàn)超時(shí)告警。

排查方法:在Agent上執(zhí)行命令“puppet agent -t --debug”, 發(fā)現(xiàn)在拉取文件時(shí)超時(shí),由于文件較大,在Master上同時(shí)很多Agent拉取,導(dǎo)致超時(shí)。

解決方案:將大文件存放在云存儲(chǔ)上,提高下載速度。

分組不止僅限于現(xiàn)有Facter屬性

問(wèn)題:策略分組和灰度發(fā)布分組現(xiàn)有Facter屬性不滿足。

原因:隨著接入業(yè)務(wù)越來(lái)越多,業(yè)務(wù)分組也越多。

解決方案:自定義Facter。

Agent不同步(Out of Sync)

問(wèn)題:Agent報(bào)不同步。

原因及解決方案:

表二

原因

解決方案

主機(jī)名重復(fù)

修改Agent Hostname后重新認(rèn)證

主機(jī)認(rèn)證后重命名

直接在Foreman控制臺(tái)中刪除原名稱認(rèn)證的機(jī)器

Agent服務(wù)異常

在Agent上重啟Puppet服務(wù)

Agent磁盤打滿

清理磁盤后,Agent會(huì)自行啟動(dòng)并恢復(fù)

Agent端證書(shū)error

在Agent上刪除/etc/puppetlabs/puppet/ssl文件夾后,執(zhí)行puppet agent –t重新認(rèn)證

Agent端puppet.conf文件為空

將相應(yīng)的[Agent]配置寫入puppet.conf文件中即可恢復(fù)

Master端puppe.conf文件為空

將相應(yīng)[Master]配置寫入puppet.conf文件中即可恢復(fù)

Foreman服務(wù)down掉

在Foreman機(jī)器上執(zhí)行service httpd restart、service foreman restart

Could not request certificate

1)Agent與Master時(shí)間不同步,ntpdate master –IP同步時(shí)間;2)Agent與Master端網(wǎng)絡(luò)不通;3)Master端8140端口不通

策略發(fā)布到非預(yù)期集群

問(wèn)題:策略生效范圍出錯(cuò)。

原因:Puppet Master入口文件統(tǒng)一為site.pp,由于策略分組多,在灰度發(fā)布階段,相應(yīng)分支也會(huì)很多,運(yùn)維工程師很容易操作出錯(cuò)。

解決方案:將site.pp作為一個(gè)策略模塊進(jìn)行管理,策略模塊中包含默認(rèn)default分組,以及需要灰度發(fā)布的分組。manifest文件夾下的site.pp只需include該模塊即可。

Puppet監(jiān)控速查問(wèn)題的原因及解決方案是什么

圖7 site.pp優(yōu)化后default分組策略

Puppet監(jiān)控速查問(wèn)題的原因及解決方案是什么

圖8 策略發(fā)布灰度階段分組

功能監(jiān)控發(fā)現(xiàn)所同步的文件非預(yù)期

問(wèn)題:Master采用集群方式部署,在策略變更期間多臺(tái)Master上數(shù)據(jù)可能不同步,此時(shí),同一Agent拉取到的文件可能不一致 。

原因:由于有多臺(tái)Master,其中一臺(tái)Master沒(méi)有更新文件,LB通過(guò)輪詢策略進(jìn)行轉(zhuǎn)發(fā),當(dāng)Agent請(qǐng)求Master時(shí)是Master A,再拉取文件時(shí)請(qǐng)求的可能是Master B,兩臺(tái)Master數(shù)據(jù)不一致。

解決方案:LB策略更新為源IP哈希。

看完上述內(nèi)容,你們掌握Puppet監(jiān)控速查問(wèn)題的原因及解決方案是什么的方法了嗎?如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容,歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道,感謝各位的閱讀!

本文標(biāo)題:Puppet監(jiān)控速查問(wèn)題的原因及解決方案是什么
文章地址:http://bm7419.com/article22/gipdjc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供動(dòng)態(tài)網(wǎng)站軟件開(kāi)發(fā)、定制網(wǎng)站、網(wǎng)站策劃、靜態(tài)網(wǎng)站、Google

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)

h5響應(yīng)式網(wǎng)站建設(shè)