案例分享 | 美國新能源科技公司Netco從零開始Zabbix的自動化之路
文章簡介
本文分享的是美國新能源科技公司(英文名:Netco Technology)的Zabbix自動化部署和管理方案,用于監(jiān)控大量各種類型的網(wǎng)絡(luò)設(shè)備。在此也特別感謝伍昕先生對演講原文的翻譯和整理!
01 - 介紹
這篇文章中我們將介紹,我們在實際工作中關(guān)于Zabbix自動化安裝與維護方案。我們現(xiàn)在使用Zabbix監(jiān)控了大量各種類型的網(wǎng)絡(luò)設(shè)備,因此我們需要通過自動化來完成這些設(shè)備監(jiān)控的初始化。我很樂意分享我們是怎么做到這些的,以及這樣做的原因,希望大家可以從我們的分享中有所收獲。
Netco 是一家網(wǎng)絡(luò)基礎(chǔ)設(shè)施供應(yīng)商,這意味著我們?yōu)楦鞣N類型的客戶建立和維護網(wǎng)絡(luò)。幾年前,我們開始為一些大型的零售商建立網(wǎng)絡(luò),這些客戶需要將分散在各地的數(shù)百臺設(shè)備通過廣域網(wǎng)連接起來。他們同時希望接入第三方的網(wǎng)絡(luò),比如其他合作公司或者總部。所以他們需要一個集中的廣域網(wǎng)來管理網(wǎng)絡(luò)流量和提供網(wǎng)絡(luò)服務(wù)。
我們公司的網(wǎng)絡(luò)服務(wù)非常受歡迎,所以我們將這部分業(yè)務(wù)作為Retailstekker(在荷蘭語中是“零售插頭”的意思)進行獨立銷售。取Retailstekker這個名字背后的想法是,我們將客戶的辦公地點以提供插件的方式將各類設(shè)備接入我們的網(wǎng)絡(luò),然后進行維護和管理。收付款設(shè)備、打印設(shè)備、銷售終端設(shè)備等都可以接入。
02 - 技術(shù)概述
我們的Retailstekker網(wǎng)絡(luò),通過python和上圖中的各項技術(shù)組件實現(xiàn)。我們使用SaltStack作為我們的自動化工作的內(nèi)核和管理工具,但是我們將會給出一些更通用的建議以便你們能通過Ansible,Puppet或者其他推送工具來實現(xiàn)。
Retail 網(wǎng)絡(luò)架構(gòu)
一個Retailstekker網(wǎng)絡(luò)可以包含數(shù)百個客戶網(wǎng)絡(luò)節(jié)點,所有的客戶網(wǎng)絡(luò)節(jié)點都有一個路由器設(shè)備,通常是Cisco路由器。這些路由器通過連接到我們的數(shù)據(jù)中心來組成一個廣域網(wǎng)絡(luò)并且有一個核心防火墻來防護和管理所有網(wǎng)絡(luò)的進出訪問。通過這個,我們可以建立到總部或者第三方合作商的通信鏈接,同時也能向客戶提供VPN訪問以便他們可以訪問所有自己的本地設(shè)備。
以上這些可以實現(xiàn),得益于不同技術(shù)的組合:FreeRADIUS用于客戶網(wǎng)絡(luò)節(jié)點的接入驗證,DHCP和BIND用于提供網(wǎng)絡(luò)服務(wù)。Zabbix用于對整個網(wǎng)絡(luò)的監(jiān)控。我們使用Django開發(fā)了一個儀表版用于讓客戶了解他們當(dāng)前的網(wǎng)絡(luò)狀態(tài)。
03 - 平臺儀表板
NETCO平臺面板
儀表板上顯示了當(dāng)前正常的DSL和光纖上行鏈路節(jié)點數(shù)量。同時還顯示了使用4G網(wǎng)絡(luò)和LTE接入的客戶網(wǎng)絡(luò)節(jié)點數(shù)量,以防這些客戶網(wǎng)絡(luò)節(jié)點無法建立DSL或者光纖鏈接。為了將這些信息可視化,我們將地圖上的每一個客戶網(wǎng)絡(luò)節(jié)點的狀態(tài)都做了顏色編碼。
網(wǎng)絡(luò)區(qū)域告警面板
如果客戶想了解某個客戶網(wǎng)絡(luò)節(jié)點的更多信息,可以點擊它查看現(xiàn)場設(shè)備的延遲狀態(tài)、已使用的4G流量,還可以運行各種診斷測試。此圖顯示所選客戶網(wǎng)絡(luò)節(jié)點使用蜂窩連接的時間,允許客戶監(jiān)視其付費數(shù)據(jù)的使用情況。
NETCO告警頁面
不久前,我們還將部分監(jiān)控集成到儀表板中。現(xiàn)在,當(dāng)客戶有供應(yīng)商需要使用VPN來進行鏈接時,我們可以提供Zabbix監(jiān)控,以便他們快速檢查這些特殊供應(yīng)商的狀態(tài)。這樣,我們就可以對連接是否正常有更高級別的展示。
04 - NOC面板
所有的客戶在廣域網(wǎng)中都是互通的,該網(wǎng)絡(luò)由Zabbix監(jiān)控。但是實際上每一個客戶都有自己獨立的網(wǎng)絡(luò)和獨立的ZabbixServer,這意味著會有多個相關(guān)配置。為了關(guān)注我們的NOC上的所有的ZabbixServer,我們使用Grafana創(chuàng)建單個儀表板用來展示這些ZabbixServer的性能數(shù)據(jù),告警,并實現(xiàn)對ZabbixServers本身的監(jiān)控。
VPN 節(jié)點面板
這個VPN儀表板,我們用它來監(jiān)控所有正常,關(guān)閉,正在維護的VPN節(jié)點狀態(tài)。如您所見,所有Zabbix服務(wù)器的所有告警也都顯示在這一個屏幕上。
Zabbix servers 統(tǒng)計面板
當(dāng)然我們依然在使用Zabbix本身來監(jiān)控這些Zabbix Servers。在這一頁,每一列都代表一臺Zabbix Server服務(wù)器,展示了它們的負(fù)載,監(jiān)控項數(shù)量,緩存情況等Zabbix Server的性能狀況。這樣可以讓我們關(guān)注我們?yōu)榭蛻舸罱ǖ母鱾€Zabbix 實例的運行情況。
05 - 安裝
上一小節(jié)解釋了我們?yōu)楹我褂眠@么多Zabbix Server的原因和背景。方便大家更好的了解我們?yōu)槭裁葱枰鲎詣踊?/p>
如果你擁有數(shù)十臺Zabbix Server,手動維護它們將會是一些麻煩。這也是我們?yōu)槭裁赐ㄟ^自動化來完成Zabbix Server 的安裝配置以及優(yōu)化。
安裝頁面
在設(shè)置中我們寫了一個python腳本來請求以下數(shù)據(jù):
1.客戶名稱
2.環(huán)境參數(shù)(用于區(qū)分不同的客戶)
3.IP地址等等。
然后將會自動生成后續(xù)在環(huán)境中需要使用的密碼。
一旦數(shù)據(jù)被輸入到腳本并確認(rèn)已經(jīng)部署,SaltStack服務(wù)將通知一臺KVM設(shè)備,然后啟動對應(yīng)的Zabbix實例,并完成其他操作。
在Zabbix Server啟動后,將會連接SaltStack的Server并建立agent-server關(guān)聯(lián)。SaltStack將會在Zabbix Server上做以下操作:
1.注冊Katello(代碼管理系統(tǒng))
2.注冊FreeIPA(認(rèn)證管理系統(tǒng))
3.開始安裝Zabbix組件
當(dāng)這一切完成后,我們將我們的代碼從GitLab上推送到本地磁盤中。
06 - 配置
通過前面的步驟我們有了一個已經(jīng)安裝好了的Zabbix Server,現(xiàn)在我們需要通過自動化的對這些Zabbix 組件進行深入的配置和定制。
我們要做的第一件事是配置FreeIPA作為服務(wù)器的身份驗證機制。另外將會使用LDAP作為我們的用戶管理后端,一遍我們的客戶使用常規(guī)的賬號密碼驗證。這些操作通過SQL來完成,我們通過SaltStack發(fā)起這些操作讓客戶通過LDAP來訪問Zabbix頁面。
啟用LDAP認(rèn)證:
mysql_query.run: - database: zabbix - query: "UPDATE config SET authentication_type=1, ldap_host='ldap://{{ ldap.host }}', ldap_port={{ ldap.port }}, ldap_base_dn='{{ ldap.basedn }}', ldap_bind_dn='{{ ldap.binddn }}', ldap_bind_password='{{ ldap.password }}', ldap_search_attribute='{{ ldap.search }}'"
完成登陸驗證配置侯,將會開始配置Zabbix的默認(rèn)郵箱告警配置,仍然是通過SaltStack的方式往各個Server上推送郵箱的配置文件。
配置Zabbix的默認(rèn)郵箱告警配置。
$ cat /srv/salt/zabbix-server/mediatypes.sls zabbix_mediatype.present: - name: 'Email' - mediatype: 0 - smtp_server: localhost - smtp_helo: {{ salt['grains.get']('id','localhost') }} - smtp_email: 'zabbix@example.com'
我們繼續(xù)配置不同的用戶組——管理員和普通用戶,管理員用戶組有我們的API和技術(shù)支持人員使用。普通用戶組則提供給我們的客戶使用。當(dāng)然,客戶實際上訪問的是我們自己的儀表版而不是Zabbix的的儀表板。但是我們?nèi)匀恍枰@個組,用來配置告警媒介的配置。
大家會發(fā)現(xiàn)使用LDAP的Zabbix仍然需要在Zabbix頁面來創(chuàng)建新的用戶,這樣會帶來一些麻煩。我們通過SaltStack解決了這個問題,通過getent的方式循環(huán)讀取Zabbix用戶和LDAP中的用戶進行對比,找出在LDAP新創(chuàng)建的用戶,然后在Zabbix自動創(chuàng)建。
$ cat /srv/salt/zabbix-server/users.sls {%- for username in salt['cmd.run']("getent group \ 'grp-zabbix-users'").split(':')[3].split(',') %} Zabbix user {{ username }}: zabbix_user.present: - alias: '{{ username }}' - passwd: '' - password_reset: False - usrgrps: - Support - medias: - mediatypeid: {{ salt['zabbix.mediatype_get'](name='Email') }} sendto: '{{ username }}@example.com' active: 0 severity: 63 period: '1-7,00:00-24:00' {%- endfor %}
完成以上工作后,SaltStack 將會安裝Gitlab相關(guān)的交互及通知腳本。這意味著后續(xù)新的代碼都將會自動部署到所有的服務(wù)器上去。
$ cat /srv/salt/zabbix-server/scripts.sls external-scripts: git.latest: - name: https://gitlab.local/zabbix/external-scripts.git - target: /opt/zabbix/scripts/external - force_reset: True - require: - pkg: git
這種方式也可以用于同步Zabbix的模板,每一個模板都放到Gitlab的存儲庫中,當(dāng)SaltStack在服務(wù)器上運行時,Git將會將服務(wù)器上的文件拉到本地進行對比,如果發(fā)生了變化,一個python腳本將會導(dǎo)入該模板及對應(yīng)的關(guān)聯(lián)模板(遞歸關(guān)聯(lián),確保所有直接間接相關(guān)模板都會導(dǎo)入)。
$ cat /srv/salt/zabbix-server/templates.sls templates: file.directory: - name: /opt/zabbix/templates/ git.latest: - name: https://gitlab.local/zabbix/templates.git - target: /opt/zabbix/templates/ - require: - pkg: git cmd.run: - name: /opt/zabbix/scripts/template-import.py -v -T /opt/zabbix/templates/ - runas: zabbix - onchanges: - git: templates
特定的目錄結(jié)構(gòu)向我們顯示了首先加載哪些模板,從而可以遞歸地導(dǎo)入不同級別的模板。如果有一個模板使用另一個相互鏈接的模板,我們將逐個遍歷目錄,以確保所有模板都按順序正確導(dǎo)入。
07 - Host 管理
這樣我們就有了一個”Zabbix server”(Server非彼Server),里面有我們所有的Zabbix組件并且擁有所有的腳本和模板。下一步就是如何配置這些需要監(jiān)控的Hosts。
主機群組
首先,在添加主機前必須定義主機群組。我們有兩種類型的主機群組將會通過Salt 推送到各個Zabbix組件中。上面截圖中的白色主機群組是標(biāo)準(zhǔn)主機群組,在各個地方都會用到,比如 用于同一分公司辦公室里面的所有Host,或者Zabbix server所在服務(wù)器的自監(jiān)控模板等。藍色的群組(預(yù)發(fā)布,維護,離線)用于我們的維護工作。還有一些物理設(shè)備群組,包含了客戶所在客戶網(wǎng)絡(luò)節(jié)點的所有設(shè)備。
Zabbix將會通過SaltStack添加Hosts。在SaltStack中定義好Host后,Zabbix將會自動創(chuàng)建。我們也能通過SaltStack來批量推送宏和模板,并且在SaltStack運行時,被遺漏的host也會自動添加到Zabbix中
zabbix.hosts: - name: google-public-dns-a.google.com label: Google DNS1 ip: 8.8.8.8 groups: - 3rd Parties macros: - '{$TIMEOUT}': 180 template: "t_availability_ping"
低級別host的管理
先前的方式一般用于分支機構(gòu)或者第三方服務(wù)商。對于數(shù)量上百的獨立商店,我們有更快速的解決方案,通過一個名為“infrabuilder”的Python腳本解決。這個Python腳本通過調(diào)用HTTP API的方式訪問我們的CMDB。CMDB中包含了我們Retailstekker網(wǎng)絡(luò)中所有產(chǎn)品的客戶網(wǎng)絡(luò)節(jié)點和配置信息。
這個腳本從CMDB獲取客戶的客戶網(wǎng)絡(luò)節(jié)點信息,并且用這些信息來解決以下問題:
1.常見一個DNS記錄
2.創(chuàng)建FreeRADIUS記錄
3.創(chuàng)建DHCP
4.獲取交換機的配置文件并將其放到TFTP服務(wù)器上
5.與Zabbix進行通信
CMDB中的每一個host都會被推送到Zabbix中。如果CMDB中的host被刪掉了,比如說因為合同不再續(xù)約,這個腳本也會自動將Zabbix中對應(yīng)的host刪除。
Host聚合
最后,還有聚合host類型。SaltStack會為每個設(shè)備群組創(chuàng)建一個聚合;所以當(dāng)給路由器創(chuàng)建一個群組時,將會通過跟蹤群組中的路由器來自動創(chuàng)建一個Host的聚合。Zabbix將會開始監(jiān)控這些Host有多少是連通的,又有多少正在維護。這可以讓我們對每一個獨立商店的狀態(tài)有一個更全局的了解。
08 - 維護
當(dāng)我們擁有了一個各個功能非常完善的Zabbix系統(tǒng)后,進一步降低這個系統(tǒng)的人力投入及故障率將會變得非常重要。這也是通過自動化系統(tǒng)的維護來實現(xiàn)的。
三種類型的維護周期
如圖所示,Zabbix中有3個維護周期,每個周期內(nèi)都繼續(xù)保持?jǐn)?shù)據(jù)收集。將被維護的主機放入到這些維護周期類可以防止因為維護產(chǎn)生的告警。
我們?yōu)楹我O(shè)置3個不同的維護周期呢?當(dāng)一個host被infrabuilder導(dǎo)入后,腳本將會將其放入到Predeployment維護周期中。這意味著即使對應(yīng)的交換機未交付,這個新的host也可以立刻被納入到Zabbix監(jiān)控。因為這些host在維護周期里面,我們的工程師并不會收到對應(yīng)的告警。
我們一般會在一般在8小時內(nèi)將路由器送到各個客戶網(wǎng)絡(luò)節(jié)點并進行配置,這個維護周期給了我們這些時間。在路由器啟動超過8小時后,對應(yīng)的host將會自動從Predeployment維護周期中刪除。這樣我們就可以將新的硬件放到Zabbix中,一旦設(shè)備被發(fā)現(xiàn),將會自動納入Zabbix的監(jiān)控。
然后是Offline維護。有一個腳本在后臺運行,用于檢查這些設(shè)備能否ping通。在實際工作過程中,我們經(jīng)常發(fā)現(xiàn)很多客戶會在不通知我們的情況下因為一些原因重啟或者關(guān)閉我們的設(shè)備,在我們的儀表盤中我們會看到對應(yīng)的host已經(jīng)down了一個月,并給我們的工程師造成了數(shù)據(jù)干擾,因為實際上并沒有故障發(fā)生。我們會將這些受影響的Host放到Offline維護中去,7天后面板上這些設(shè)備的狀態(tài)將會被設(shè)置為unknown。當(dāng)這個商店沖洗你上線后,對應(yīng)的host將會從Offline維護中移除。
第三種維護周期是給我們的工程師使用的。當(dāng)一個工程師在維護一臺路由器時,我們將會將這個路由器對應(yīng)的Host放入到這個周期中。所以在維護完成前,客戶將不會收到對應(yīng)的告警。工程師在維護完成后會將該Host從維護周期中移除。
監(jiān)控項清理
清理監(jiān)控項腳本
當(dāng)一各Host通過SNMP無法訪問時,Zabbix任然會嘗試獲取相關(guān)的系統(tǒng)信息。如果有大量這樣SNMP無法訪問的設(shè)備,Zabbix將會花費大量時間用于檢查這些監(jiān)控項是否正常。
這種情況促使我們編寫了一個Python腳本用于檢查設(shè)備是否能ping通。如果設(shè)備在特定時間內(nèi)無法ping通,腳本將會將對應(yīng)Host上的SNMP,HTTP,AGENT等相關(guān)監(jiān)控項全部金庸。這樣將會釋放那些嘗試連接這些無法ping通的設(shè)備的ZabbixPoller進程。當(dāng)這些設(shè)備重新被連接后,這些監(jiān)控項將會通過同一個腳本重新啟用。
依賴關(guān)系
想象一個場景:一家商店客戶有一個路由器,配置了對應(yīng)的交換機,以及一些用于在商店中連入WIFI的網(wǎng)絡(luò)接入點。當(dāng)路由器掛掉之后,我們希望只收到路由器的告警,而不是因為路由器掛掉引發(fā)的關(guān)聯(lián)交換機和訪問點的告警。這需要通過定義觸發(fā)器依賴來解決,一般情況下這些依賴是手動創(chuàng)建的。
在這種情況下我們通過一個腳本完成了這個配置依賴的過程。首先在我們的CMDB中,我們會同步每個客戶網(wǎng)絡(luò)節(jié)點的合同編號,因此一個客戶網(wǎng)絡(luò)節(jié)點中的所有設(shè)備在Zabbix中的資產(chǎn)管理中有一個inventory字段的值都是一樣的。通過這個inventory字段來標(biāo)識所有位于同一個客戶網(wǎng)絡(luò)節(jié)點的設(shè)備,而無需通過網(wǎng)絡(luò)自動發(fā)現(xiàn)來實現(xiàn)。
告警依賴
基于這個資產(chǎn)編號,我們就知道了這些接入點接入的是哪個交換機,對應(yīng)的交換機接入的是哪一個路由器。這個腳本將會根據(jù)這些設(shè)備的關(guān)系自動創(chuàng)建對應(yīng)的觸發(fā)器依賴。
告警
告警配置面板
當(dāng)一個區(qū)域的大量網(wǎng)絡(luò)節(jié)點有異常時,客戶希望能收到告警。并且希望時效性很高的告警,比如通過短信。
上圖的儀表板中有一個下拉菜單,可以讓客戶為告警選擇對應(yīng)的告警閾值。客戶選擇好后,后臺會給客戶在對應(yīng)的Host聚合中創(chuàng)建一個用戶宏。客戶可以在里面填寫他們的郵箱地址和電話號碼。在后端,這是通過一個Zabbix的“customer”級別的用戶實現(xiàn)的,僅有只讀權(quán)限。
報表
報表配置頁面
關(guān)于報表,我們通過一個腳本來抓取監(jiān)控項,監(jiān)控項采集值和資產(chǎn)信息來自動生成報表。比如,有一個SNMP監(jiān)控項,用于拉取設(shè)備的序列號作為一個資產(chǎn)信息字段的值。
正在執(zhí)行的報表腳本
這個腳本同時也會將主機名,序列號清單以及任何可以獲取到的監(jiān)控項信息輸出到報表中。這個報表每個月都會發(fā)送給我們的財務(wù)部門,財務(wù)部門可以用這個報表來檢查我們的收費情況與實際的服務(wù)情況是否一致或者用于其他地方。
文章簡介
本文分享的是美國新能源科技公司(英文名:Netco Technology)的Zabbix自動化部署和管理方案,用于監(jiān)控大量各種類型的網(wǎng)絡(luò)設(shè)備。在此也特別感謝伍昕先生對演講原文的翻譯和整理!
01 - 介紹
這篇文章中我們將介紹,我們在實際工作中關(guān)于Zabbix自動化安裝與維護方案。我們現(xiàn)在使用Zabbix監(jiān)控了大量各種類型的網(wǎng)絡(luò)設(shè)備,因此我們需要通過自動化來完成這些設(shè)備監(jiān)控的初始化。我很樂意分享我們是怎么做到這些的,以及這樣做的原因,希望大家可以從我們的分享中有所收獲。
Netco 是一家網(wǎng)絡(luò)基礎(chǔ)設(shè)施供應(yīng)商,這意味著我們?yōu)楦鞣N類型的客戶建立和維護網(wǎng)絡(luò)。幾年前,我們開始為一些大型的零售商建立網(wǎng)絡(luò),這些客戶需要將分散在各地的數(shù)百臺設(shè)備通過廣域網(wǎng)連接起來。他們同時希望接入第三方的網(wǎng)絡(luò),比如其他合作公司或者總部。所以他們需要一個集中的廣域網(wǎng)來管理網(wǎng)絡(luò)流量和提供網(wǎng)絡(luò)服務(wù)。
我們公司的網(wǎng)絡(luò)服務(wù)非常受歡迎,所以我們將這部分業(yè)務(wù)作為Retailstekker(在荷蘭語中是“零售插頭”的意思)進行獨立銷售。取Retailstekker這個名字背后的想法是,我們將客戶的辦公地點以提供插件的方式將各類設(shè)備接入我們的網(wǎng)絡(luò),然后進行維護和管理。收付款設(shè)備、打印設(shè)備、銷售終端設(shè)備等都可以接入。
02 - 技術(shù)概述
我們的Retailstekker網(wǎng)絡(luò),通過python和上圖中的各項技術(shù)組件實現(xiàn)。我們使用SaltStack作為我們的自動化工作的內(nèi)核和管理工具,但是我們將會給出一些更通用的建議以便你們能通過Ansible,Puppet或者其他推送工具來實現(xiàn)。
Retail 網(wǎng)絡(luò)架構(gòu)
一個Retailstekker網(wǎng)絡(luò)可以包含數(shù)百個客戶網(wǎng)絡(luò)節(jié)點,所有的客戶網(wǎng)絡(luò)節(jié)點都有一個路由器設(shè)備,通常是Cisco路由器。這些路由器通過連接到我們的數(shù)據(jù)中心來組成一個廣域網(wǎng)絡(luò)并且有一個核心防火墻來防護和管理所有網(wǎng)絡(luò)的進出訪問。通過這個,我們可以建立到總部或者第三方合作商的通信鏈接,同時也能向客戶提供VPN訪問以便他們可以訪問所有自己的本地設(shè)備。
以上這些可以實現(xiàn),得益于不同技術(shù)的組合:FreeRADIUS用于客戶網(wǎng)絡(luò)節(jié)點的接入驗證,DHCP和BIND用于提供網(wǎng)絡(luò)服務(wù)。Zabbix用于對整個網(wǎng)絡(luò)的監(jiān)控。我們使用Django開發(fā)了一個儀表版用于讓客戶了解他們當(dāng)前的網(wǎng)絡(luò)狀態(tài)。
03 - 平臺儀表板
NETCO平臺面板
儀表板上顯示了當(dāng)前正常的DSL和光纖上行鏈路節(jié)點數(shù)量。同時還顯示了使用4G網(wǎng)絡(luò)和LTE接入的客戶網(wǎng)絡(luò)節(jié)點數(shù)量,以防這些客戶網(wǎng)絡(luò)節(jié)點無法建立DSL或者光纖鏈接。為了將這些信息可視化,我們將地圖上的每一個客戶網(wǎng)絡(luò)節(jié)點的狀態(tài)都做了顏色編碼。
網(wǎng)絡(luò)區(qū)域告警面板
如果客戶想了解某個客戶網(wǎng)絡(luò)節(jié)點的更多信息,可以點擊它查看現(xiàn)場設(shè)備的延遲狀態(tài)、已使用的4G流量,還可以運行各種診斷測試。此圖顯示所選客戶網(wǎng)絡(luò)節(jié)點使用蜂窩連接的時間,允許客戶監(jiān)視其付費數(shù)據(jù)的使用情況。
NETCO告警頁面
不久前,我們還將部分監(jiān)控集成到儀表板中。現(xiàn)在,當(dāng)客戶有供應(yīng)商需要使用VPN來進行鏈接時,我們可以提供Zabbix監(jiān)控,以便他們快速檢查這些特殊供應(yīng)商的狀態(tài)。這樣,我們就可以對連接是否正常有更高級別的展示。
04 - NOC面板
所有的客戶在廣域網(wǎng)中都是互通的,該網(wǎng)絡(luò)由Zabbix監(jiān)控。但是實際上每一個客戶都有自己獨立的網(wǎng)絡(luò)和獨立的ZabbixServer,這意味著會有多個相關(guān)配置。為了關(guān)注我們的NOC上的所有的ZabbixServer,我們使用Grafana創(chuàng)建單個儀表板用來展示這些ZabbixServer的性能數(shù)據(jù),告警,并實現(xiàn)對ZabbixServers本身的監(jiān)控。
VPN 節(jié)點面板
這個VPN儀表板,我們用它來監(jiān)控所有正常,關(guān)閉,正在維護的VPN節(jié)點狀態(tài)。如您所見,所有Zabbix服務(wù)器的所有告警也都顯示在這一個屏幕上。
Zabbix servers 統(tǒng)計面板
當(dāng)然我們依然在使用Zabbix本身來監(jiān)控這些Zabbix Servers。在這一頁,每一列都代表一臺Zabbix Server服務(wù)器,展示了它們的負(fù)載,監(jiān)控項數(shù)量,緩存情況等Zabbix Server的性能狀況。這樣可以讓我們關(guān)注我們?yōu)榭蛻舸罱ǖ母鱾€Zabbix 實例的運行情況。
05 - 安裝
上一小節(jié)解釋了我們?yōu)楹我褂眠@么多Zabbix Server的原因和背景。方便大家更好的了解我們?yōu)槭裁葱枰鲎詣踊?/p>
如果你擁有數(shù)十臺Zabbix Server,手動維護它們將會是一些麻煩。這也是我們?yōu)槭裁赐ㄟ^自動化來完成Zabbix Server 的安裝配置以及優(yōu)化。
安裝頁面
在設(shè)置中我們寫了一個python腳本來請求以下數(shù)據(jù):
1.客戶名稱
2.環(huán)境參數(shù)(用于區(qū)分不同的客戶)
3.IP地址等等。
然后將會自動生成后續(xù)在環(huán)境中需要使用的密碼。
一旦數(shù)據(jù)被輸入到腳本并確認(rèn)已經(jīng)部署,SaltStack服務(wù)將通知一臺KVM設(shè)備,然后啟動對應(yīng)的Zabbix實例,并完成其他操作。
在Zabbix Server啟動后,將會連接SaltStack的Server并建立agent-server關(guān)聯(lián)。SaltStack將會在Zabbix Server上做以下操作:
1.注冊Katello(代碼管理系統(tǒng))
2.注冊FreeIPA(認(rèn)證管理系統(tǒng))
3.開始安裝Zabbix組件
當(dāng)這一切完成后,我們將我們的代碼從GitLab上推送到本地磁盤中。
06 - 配置
通過前面的步驟我們有了一個已經(jīng)安裝好了的Zabbix Server,現(xiàn)在我們需要通過自動化的對這些Zabbix 組件進行深入的配置和定制。
我們要做的第一件事是配置FreeIPA作為服務(wù)器的身份驗證機制。另外將會使用LDAP作為我們的用戶管理后端,一遍我們的客戶使用常規(guī)的賬號密碼驗證。這些操作通過SQL來完成,我們通過SaltStack發(fā)起這些操作讓客戶通過LDAP來訪問Zabbix頁面。
啟用LDAP認(rèn)證:
mysql_query.run: - database: zabbix - query: "UPDATE config SET authentication_type=1, ldap_host='ldap://{{ ldap.host }}', ldap_port={{ ldap.port }}, ldap_base_dn='{{ ldap.basedn }}', ldap_bind_dn='{{ ldap.binddn }}', ldap_bind_password='{{ ldap.password }}', ldap_search_attribute='{{ ldap.search }}'"
完成登陸驗證配置侯,將會開始配置Zabbix的默認(rèn)郵箱告警配置,仍然是通過SaltStack的方式往各個Server上推送郵箱的配置文件。
配置Zabbix的默認(rèn)郵箱告警配置。
$ cat /srv/salt/zabbix-server/mediatypes.sls zabbix_mediatype.present: - name: 'Email' - mediatype: 0 - smtp_server: localhost - smtp_helo: {{ salt['grains.get']('id','localhost') }} - smtp_email: 'zabbix@example.com'
我們繼續(xù)配置不同的用戶組——管理員和普通用戶,管理員用戶組有我們的API和技術(shù)支持人員使用。普通用戶組則提供給我們的客戶使用。當(dāng)然,客戶實際上訪問的是我們自己的儀表版而不是Zabbix的的儀表板。但是我們?nèi)匀恍枰@個組,用來配置告警媒介的配置。
大家會發(fā)現(xiàn)使用LDAP的Zabbix仍然需要在Zabbix頁面來創(chuàng)建新的用戶,這樣會帶來一些麻煩。我們通過SaltStack解決了這個問題,通過getent的方式循環(huán)讀取Zabbix用戶和LDAP中的用戶進行對比,找出在LDAP新創(chuàng)建的用戶,然后在Zabbix自動創(chuàng)建。
$ cat /srv/salt/zabbix-server/users.sls {%- for username in salt['cmd.run']("getent group \ 'grp-zabbix-users'").split(':')[3].split(',') %} Zabbix user {{ username }}: zabbix_user.present: - alias: '{{ username }}' - passwd: '' - password_reset: False - usrgrps: - Support - medias: - mediatypeid: {{ salt['zabbix.mediatype_get'](name='Email') }} sendto: '{{ username }}@example.com' active: 0 severity: 63 period: '1-7,00:00-24:00' {%- endfor %}
完成以上工作后,SaltStack 將會安裝Gitlab相關(guān)的交互及通知腳本。這意味著后續(xù)新的代碼都將會自動部署到所有的服務(wù)器上去。
$ cat /srv/salt/zabbix-server/scripts.sls external-scripts: git.latest: - name: https://gitlab.local/zabbix/external-scripts.git - target: /opt/zabbix/scripts/external - force_reset: True - require: - pkg: git
這種方式也可以用于同步Zabbix的模板,每一個模板都放到Gitlab的存儲庫中,當(dāng)SaltStack在服務(wù)器上運行時,Git將會將服務(wù)器上的文件拉到本地進行對比,如果發(fā)生了變化,一個python腳本將會導(dǎo)入該模板及對應(yīng)的關(guān)聯(lián)模板(遞歸關(guān)聯(lián),確保所有直接間接相關(guān)模板都會導(dǎo)入)。
$ cat /srv/salt/zabbix-server/templates.sls templates: file.directory: - name: /opt/zabbix/templates/ git.latest: - name: https://gitlab.local/zabbix/templates.git - target: /opt/zabbix/templates/ - require: - pkg: git cmd.run: - name: /opt/zabbix/scripts/template-import.py -v -T /opt/zabbix/templates/ - runas: zabbix - onchanges: - git: templates
特定的目錄結(jié)構(gòu)向我們顯示了首先加載哪些模板,從而可以遞歸地導(dǎo)入不同級別的模板。如果有一個模板使用另一個相互鏈接的模板,我們將逐個遍歷目錄,以確保所有模板都按順序正確導(dǎo)入。
07 - Host 管理
這樣我們就有了一個”Zabbix server”(Server非彼Server),里面有我們所有的Zabbix組件并且擁有所有的腳本和模板。下一步就是如何配置這些需要監(jiān)控的Hosts。
主機群組
首先,在添加主機前必須定義主機群組。我們有兩種類型的主機群組將會通過Salt 推送到各個Zabbix組件中。上面截圖中的白色主機群組是標(biāo)準(zhǔn)主機群組,在各個地方都會用到,比如 用于同一分公司辦公室里面的所有Host,或者Zabbix server所在服務(wù)器的自監(jiān)控模板等。藍色的群組(預(yù)發(fā)布,維護,離線)用于我們的維護工作。還有一些物理設(shè)備群組,包含了客戶所在客戶網(wǎng)絡(luò)節(jié)點的所有設(shè)備。
Zabbix將會通過SaltStack添加Hosts。在SaltStack中定義好Host后,Zabbix將會自動創(chuàng)建。我們也能通過SaltStack來批量推送宏和模板,并且在SaltStack運行時,被遺漏的host也會自動添加到Zabbix中
zabbix.hosts: - name: google-public-dns-a.google.com label: Google DNS1 ip: 8.8.8.8 groups: - 3rd Parties macros: - '{$TIMEOUT}': 180 template: "t_availability_ping"
低級別host的管理
先前的方式一般用于分支機構(gòu)或者第三方服務(wù)商。對于數(shù)量上百的獨立商店,我們有更快速的解決方案,通過一個名為“infrabuilder”的Python腳本解決。這個Python腳本通過調(diào)用HTTP API的方式訪問我們的CMDB。CMDB中包含了我們Retailstekker網(wǎng)絡(luò)中所有產(chǎn)品的客戶網(wǎng)絡(luò)節(jié)點和配置信息。
這個腳本從CMDB獲取客戶的客戶網(wǎng)絡(luò)節(jié)點信息,并且用這些信息來解決以下問題:
1.常見一個DNS記錄
2.創(chuàng)建FreeRADIUS記錄
3.創(chuàng)建DHCP
4.獲取交換機的配置文件并將其放到TFTP服務(wù)器上
5.與Zabbix進行通信
CMDB中的每一個host都會被推送到Zabbix中。如果CMDB中的host被刪掉了,比如說因為合同不再續(xù)約,這個腳本也會自動將Zabbix中對應(yīng)的host刪除。
Host聚合
最后,還有聚合host類型。SaltStack會為每個設(shè)備群組創(chuàng)建一個聚合;所以當(dāng)給路由器創(chuàng)建一個群組時,將會通過跟蹤群組中的路由器來自動創(chuàng)建一個Host的聚合。Zabbix將會開始監(jiān)控這些Host有多少是連通的,又有多少正在維護。這可以讓我們對每一個獨立商店的狀態(tài)有一個更全局的了解。
08 - 維護
當(dāng)我們擁有了一個各個功能非常完善的Zabbix系統(tǒng)后,進一步降低這個系統(tǒng)的人力投入及故障率將會變得非常重要。這也是通過自動化系統(tǒng)的維護來實現(xiàn)的。
三種類型的維護周期
如圖所示,Zabbix中有3個維護周期,每個周期內(nèi)都繼續(xù)保持?jǐn)?shù)據(jù)收集。將被維護的主機放入到這些維護周期類可以防止因為維護產(chǎn)生的告警。
我們?yōu)楹我O(shè)置3個不同的維護周期呢?當(dāng)一個host被infrabuilder導(dǎo)入后,腳本將會將其放入到Predeployment維護周期中。這意味著即使對應(yīng)的交換機未交付,這個新的host也可以立刻被納入到Zabbix監(jiān)控。因為這些host在維護周期里面,我們的工程師并不會收到對應(yīng)的告警。
我們一般會在一般在8小時內(nèi)將路由器送到各個客戶網(wǎng)絡(luò)節(jié)點并進行配置,這個維護周期給了我們這些時間。在路由器啟動超過8小時后,對應(yīng)的host將會自動從Predeployment維護周期中刪除。這樣我們就可以將新的硬件放到Zabbix中,一旦設(shè)備被發(fā)現(xiàn),將會自動納入Zabbix的監(jiān)控。
然后是Offline維護。有一個腳本在后臺運行,用于檢查這些設(shè)備能否ping通。在實際工作過程中,我們經(jīng)常發(fā)現(xiàn)很多客戶會在不通知我們的情況下因為一些原因重啟或者關(guān)閉我們的設(shè)備,在我們的儀表盤中我們會看到對應(yīng)的host已經(jīng)down了一個月,并給我們的工程師造成了數(shù)據(jù)干擾,因為實際上并沒有故障發(fā)生。我們會將這些受影響的Host放到Offline維護中去,7天后面板上這些設(shè)備的狀態(tài)將會被設(shè)置為unknown。當(dāng)這個商店沖洗你上線后,對應(yīng)的host將會從Offline維護中移除。
第三種維護周期是給我們的工程師使用的。當(dāng)一個工程師在維護一臺路由器時,我們將會將這個路由器對應(yīng)的Host放入到這個周期中。所以在維護完成前,客戶將不會收到對應(yīng)的告警。工程師在維護完成后會將該Host從維護周期中移除。
監(jiān)控項清理
清理監(jiān)控項腳本
當(dāng)一各Host通過SNMP無法訪問時,Zabbix任然會嘗試獲取相關(guān)的系統(tǒng)信息。如果有大量這樣SNMP無法訪問的設(shè)備,Zabbix將會花費大量時間用于檢查這些監(jiān)控項是否正常。
這種情況促使我們編寫了一個Python腳本用于檢查設(shè)備是否能ping通。如果設(shè)備在特定時間內(nèi)無法ping通,腳本將會將對應(yīng)Host上的SNMP,HTTP,AGENT等相關(guān)監(jiān)控項全部金庸。這樣將會釋放那些嘗試連接這些無法ping通的設(shè)備的ZabbixPoller進程。當(dāng)這些設(shè)備重新被連接后,這些監(jiān)控項將會通過同一個腳本重新啟用。
依賴關(guān)系
想象一個場景:一家商店客戶有一個路由器,配置了對應(yīng)的交換機,以及一些用于在商店中連入WIFI的網(wǎng)絡(luò)接入點。當(dāng)路由器掛掉之后,我們希望只收到路由器的告警,而不是因為路由器掛掉引發(fā)的關(guān)聯(lián)交換機和訪問點的告警。這需要通過定義觸發(fā)器依賴來解決,一般情況下這些依賴是手動創(chuàng)建的。
在這種情況下我們通過一個腳本完成了這個配置依賴的過程。首先在我們的CMDB中,我們會同步每個客戶網(wǎng)絡(luò)節(jié)點的合同編號,因此一個客戶網(wǎng)絡(luò)節(jié)點中的所有設(shè)備在Zabbix中的資產(chǎn)管理中有一個inventory字段的值都是一樣的。通過這個inventory字段來標(biāo)識所有位于同一個客戶網(wǎng)絡(luò)節(jié)點的設(shè)備,而無需通過網(wǎng)絡(luò)自動發(fā)現(xiàn)來實現(xiàn)。
告警依賴
基于這個資產(chǎn)編號,我們就知道了這些接入點接入的是哪個交換機,對應(yīng)的交換機接入的是哪一個路由器。這個腳本將會根據(jù)這些設(shè)備的關(guān)系自動創(chuàng)建對應(yīng)的觸發(fā)器依賴。
告警
告警配置面板
當(dāng)一個區(qū)域的大量網(wǎng)絡(luò)節(jié)點有異常時,客戶希望能收到告警。并且希望時效性很高的告警,比如通過短信。
上圖的儀表板中有一個下拉菜單,可以讓客戶為告警選擇對應(yīng)的告警閾值。客戶選擇好后,后臺會給客戶在對應(yīng)的Host聚合中創(chuàng)建一個用戶宏。客戶可以在里面填寫他們的郵箱地址和電話號碼。在后端,這是通過一個Zabbix的“customer”級別的用戶實現(xiàn)的,僅有只讀權(quán)限。
報表
報表配置頁面
關(guān)于報表,我們通過一個腳本來抓取監(jiān)控項,監(jiān)控項采集值和資產(chǎn)信息來自動生成報表。比如,有一個SNMP監(jiān)控項,用于拉取設(shè)備的序列號作為一個資產(chǎn)信息字段的值。
正在執(zhí)行的報表腳本
這個腳本同時也會將主機名,序列號清單以及任何可以獲取到的監(jiān)控項信息輸出到報表中。這個報表每個月都會發(fā)送給我們的財務(wù)部門,財務(wù)部門可以用這個報表來檢查我們的收費情況與實際的服務(wù)情況是否一致或者用于其他地方。
Zabbix 綜合能源服務(wù)
版權(quán)聲明:本文內(nèi)容由網(wǎng)絡(luò)用戶投稿,版權(quán)歸原作者所有,本站不擁有其著作權(quán),亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容,請聯(lián)系我們jiasou666@gmail.com 處理,核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。