分布式監控系統之Zabbix宏、模板和自定義item

2020-12-08 紙鶴視界

前文我們聊了下zabbix的基礎使用,包括主機的添加、監控項、觸發器、action以及告警通知的配置,回顧請參考https://www.cnblogs.com/qiuhom-1874/p/14007342.html;今天我們來了解下zabbix的宏、模板和自定義監控項的相關話題;

1、什麼是宏?

簡單講宏就是一個字符串變量,作用和變量作用很類似;不同的是宏它是一個常量,通常是一個固定值的替代形式;宏主要作用是方便我們配置一些經常需要修改的值,用宏替換比較方便;比如我們要監控700臺nginx,其中nginx的埠有時候監聽在80,有時候監聽在8080,如果不使用宏,那麼對應埠信息就是一個數字,如果埠發生變化我們要修改700次;有了宏我們只需要修改對應宏的值即可;

宏的分類

在zabbix中宏分內建宏和自定義宏,所謂內建宏就是zabbix中原生就有的宏,我們可以直接調用;自定義宏就是我們自己按照需求定義的一個宏;除了按照這種方式劃分宏,我們也可以按照宏的作用範圍來劃分;比如定義在某一個主機之上,其作用域僅對該主機生效的宏我們叫主機宏,這種宏作用範圍小,但優先級很高;除了主機宏還有模板宏,全局宏;所謂模板宏就是定義在某個模板上的宏,其作用域是針對連結了該模板的所有主機,其優先級要略小主機宏;全局宏是指作用整個zabbix的宏,其優先級最小,生效範圍是zabbix上的所有調用了該宏主機;在zabbix中內建宏的格式是{全大寫字母},我們在引用時,直接使用大括號+宏名就好;在上一篇博客中,我們定義腳本媒介時,就用到了三個內建的宏,{ALERT.SENDTO},這個就是一個內建宏,它代表接收郵件的地址;內建宏在官方文檔中有很詳細的說明,如果用到可以去官方文檔查看https://www.zabbix.com/documentation/4.0/manual/appendix/macros/supported_by_location;自定義宏在定義和引用和內建宏稍有不同,自定義宏在定義和引用都需要用在大括號裡用$符號+宏名;比如定義一個nginx埠的宏,我們可以寫成{$NGINX_PORT};

zabbix自定義全局宏

提示:在Administration--->General 然後選擇下拉菜單找到Macros,點擊進去進入全局宏的定義頁面;

提示:這樣就定義了兩個全局宏,我們在添加主機監控項就可以直接調用對應的宏就可以了;

自定義主機宏

提示:在主機列表中找到對應主機,然後點擊進入編輯主機信息的頁面,找到Macros;

自定義模板宏

提示:在configuration--->Templates中,找對應要定義模板宏的模板,點擊進入編輯模板的界面,找到Macros,添加對應的宏即可;最後點擊update即可;

2、自定義監控項

在上一篇博客我們就了解了什麼是監控項,監控項就是定義怎麼去採集數據的一個key;但是我們前邊用到都是內建的監控項,在zabbix上內建的監控項都是針對很通用的指標數據;在一定程度上不是很滿足自己業務的監控需求,此時我們就需要自定義監控項來採集我們需要的指標數據;我們在使用監控項時,其實就是在使用一種方法或程序通過zabbix server和agent通信,在被監控主機上執行我們選定的程序或方法,程序和方法執行後得到的數據,就是監控項採集的數據,然後通過zabbix agent將採集的數據發送或響應給zabbixserver;不難理解就是在被監控端執行一段代碼,然後將代碼返回的結果通過agent發送或響應給zabbix server完成一次數據採集;那麼我們自定義監控項就是來自定義怎麼獲取對應指標數據的方法;然後給這個獲取對應指標數據的方法或程序用一個key表示,在zabbix上直接調用key,zabbix就會發指令給agent執行對應key說對應的程序或方法來採集數據;在zabbix中,自定義監控項我們需要自己手動寫腳本或命令去獲取指定的數據;然後通過配置文件的方式告訴agent;

自定義監控項的格式

在zabbix agent配置文件中以UserParameter=<key>,<shell command>格式來自定義監控項;通常我們都是將自定義監控項手動的寫一個以.conf結尾的文件中,然後通過zabbix agent配置文件中的Include指定將其導入agent配置生效;默認/etc/zabbix/zabbix_agentd.d/目錄下的所有以.conf結尾的文件都是被導入的;

示例:自定義監控項採集node04上的內存空閒空間

[root@node04 ~]# cat /etc/zabbix/zabbix_agentd.d/mem.confUserParameter=node04.os.Mem.free,free |awk '/^Mem/{print $4}' [root@node04 ~]#

提示:以上配置表示自定義監控項的key為node04.os.Mem.free;對應採集數據的方法是執行後面對命令;

重啟zabbix agent 

[root@node04 ~]# systemctl restart zabbix-agent.service [root@node04 ~]# ss -tnlState Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:80 *:* LISTEN 0 128 *:22 *:* LISTEN 0 100 127.0.0.1:25 *:* LISTEN 0 128 *:10050 *:* LISTEN 0 128 :::80 :::* LISTEN 0 128 :::22 :::* LISTEN 0 100 ::1:25 :::* [root@node04 ~]#

提示:重啟如果對應agent監聽埠正常處於監聽,說明我們的配置文件沒有問題;

在zabbix server上安裝zabbix-get工具

[root@node03 ~]# yum install -y zabbix-get

驗證:在zabbix server上使用zabbix_get命令看看是否能夠使用對應的key獲取到數據呢?

[root@node03 ~]# zabbix_get -s 192.168.0.44 -p 10050 -k 'node04.os.Mem.free'1594992[root@node03 ~]# zabbix_get -s 192.168.0.44 -p 10050 -k 'node04.os.Mem.free'1595248[root@node03 ~]# zabbix_get -s 192.168.0.44 -p 10050 -k 'node04.os.Mem.free'1595132[root@node03 ~]# zabbix_get -s 192.168.0.44 -p 10050 -k 'node04.os.Mem.free'1595008[root@node03 ~]#

提示:可以看到在zabbix sever上能夠使用zabbix_get工具獲取到node04上我們自定義監控項的值;

配置zabbix 使用自定義監控項,周期性的檢測

提示:調用自定義監控項,直接寫對應的key即可;

提示:可以看到對應的監控項已經採集到數據了;

自定義帶參監控項

所謂帶參監控項指使用一個key,傳遞不同的參數,採集不同的指標;

示例:根據傳遞不同參數,來採集內存總量、空閒量、buffers等值

[root@node04 ~]# cat /etc/zabbix/zabbix_agentd.d/mem.confUserParameter=node04.os.Mem.free,free |awk '/^Mem/{print $4}' UserParameter=os.mem[*], awk '/^$1/ {print $$2}' /proc/meminfo [root@node04 ~]#

提示:這裡需要說明一點,在配置文件中使用$1表示引用傳遞給key的第一個參數,那麼對應awk中的$1就需要寫成$$1來表示awk自身的參數;以上配置表示使用os.mem這個key在中括號裡支持參數,傳遞的參數將會被後面定義的命令中的$1引用;

重啟zabbix-agent,讓其配置生效

[root@node04 ~]# systemctl restart zabbix-agent.service [root@node04 ~]# ss -tnlState Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:80 *:* LISTEN 0 128 *:22 *:* LISTEN 0 100 127.0.0.1:25 *:* LISTEN 0 128 *:10050 *:* LISTEN 0 128 :::80 :::* LISTEN 0 128 :::22 :::* LISTEN 0 100 ::1:25 :::* [root@node04 ~]#

驗證:在zabbix server 上使用zabbix_get來獲取指定key是否能夠獲取到數據?

[root@node03 ~]# zabbix_get -s node04 -p 10050 -k 'os.mem[MemTotal]'1867048[root@node03 ~]# zabbix_get -s node04 -p 10050 -k 'os.mem[MemFree]' 1595552[root@node03 ~]# zabbix_get -s node04 -p 10050 -k 'os.mem[Buffers]'2108[root@node03 ~]#

提示:可以看到在zabbix server上使用zabbix_get工具,給key傳遞不同的參數,獲取到的數據也不盡相同;我們就可以基於這個key傳遞不同的參數來採集對應的指標數據;

驗證:在zabbix上使用我們自定義帶參監控項周期性採集數據,看看是否能夠採集到數據?

提示:添加item對應key和參數即可;

提示:可以看到在zabbix上使用指定帶參監控項也能正常的採集到數據;

3、模板

模板是zabbix中快速添加配置監控的一種機制;它省去了我們大量重複的配置item,觸發器,graph等等操作;它是一個邏輯的概念,只有當模板連結到某個主機才會生效;在zabbix也內建了很多模板,我們添加主機時,直接連接某個模板,對應主機就會繼承連接的模板上定義的所有監控配置;模板可以導出和導入,也可以模板中嵌套模板;

模板的使用

連結某個模板到node04

提示:在主機列表中找到對應主機,點擊對應主機名稱進入編輯主機配置界面,找到Templates子菜單,選擇要連結的模板,點擊add後再點擊updete即可;

提示:可以看到連結了某個模板以後,對應主機上就多了很多item,觸發器和graphs等等,同時在templates下也顯示了連結的某班名稱;

創建模板

提示:在configuration--->Templates菜單下找到create template按鈕,點擊進入創建模板的界面;

提示:填寫好對應的名稱和組點擊add,一個模板就創建好了;

提示:創建好一個空模板就有點類似我們添加了一個主機,上面沒有任何監控配置,我們可以像在某個主機上定義監控項,觸發,graph一樣的操作在模板上定義監控項,觸發器等等;

取消模板連結

提示:找到對應主機,進入編輯主機配置界面,進入templates子菜單,選擇對應模板的操作;這裡有unlink和unlink and clear兩個操作,unlink表示取消連結模板,但之前收集的數據並不會刪除,第二個unlink add clear表示取消連結的同時刪除之前收集的數據;

導入模板

在zabbix share這個網站上有很多模板,我們可以選擇一款模板下載下來導入到本地使用

示例:找模板監控redis的模板

提示:找到對應的代碼託管地址,然後點擊進入對應地址下載模板和agent配置文件;

提示:下載上面兩個文件,.conf文件是agent配置文件,在對應主機上下載放在agentd.d目錄下;模板文件是.xml格式的文件,下載到本地上傳至zabbix上;

在node04上安裝redis,telnet

[root@node04 ~]# yum install redis telnet -y

修改redis配置文件,讓其監聽在node04的所有可用地址上

[root@node04 ~]# grep "^bind" /etc/redis.confbind 0.0.0.0[root@node04 ~]#

啟動redis

[root@node04 ~]# systemctl start redis[root@node04 ~]# ss -tnlState Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:6379 *:* LISTEN 0 128 *:80 *:* LISTEN 0 128 *:22 *:* LISTEN 0 100 127.0.0.1:25 *:* LISTEN 0 128 *:10050 *:* LISTEN 0 128 :::80 :::* LISTEN 0 128 :::22 :::* LISTEN 0 100 ::1:25 :::* [root@node04 ~]#

將配置文件導入到zabbix agent配置目錄下

[root@node04 ~]# wget https://raw.githubusercontent.com/cuimingkun/zbx_tem_redis/master/userparameter_redis_lld_plus.conf -O /etc/zabbix/zabbix_agentd.d/userparameter_redis_lld_plus.conf--2020-11-20 23:16:36-- https://raw.githubusercontent.com/cuimingkun/zbx_tem_redis/master/userparameter_redis_lld_plus.confResolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.76.133Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.76.133|:443... connected.HTTP request sent, awaiting response... 200 OKLength: 1717 (1.7K) [text/plain]Saving to: 『/etc/zabbix/zabbix_agentd.d/userparameter_redis_lld_plus.conf』100%[======================================================================>] 1,717 --.-K/s in 0.08s 2020-11-20 23:17:06 (20.8 KB/s) - 『/etc/zabbix/zabbix_agentd.d/userparameter_redis_lld_plus.conf』 saved [1717/1717][root@node04 ~]# ll /etc/zabbix/zabbix_agentd.d/userparameter_redis_lld_plus.conf-rw-r--r-- 1 root root 1717 Nov 20 23:17 /etc/zabbix/zabbix_agentd.d/userparameter_redis_lld_plus.conf[root@node04 ~]#

修改zabbix agent配置文件和unit file,允許zabbix agent 以root身份運行

[root@node04 ~]# grep "^AllowRoot" /etc/zabbix/zabbix_agentd.conf AllowRoot=1[root@node04 ~]# grep "^[User|Group]" /etc/systemd/system/multi-user.target.wants/zabbix-agent.service User=rootGroup=root[root@node04 ~]#

重啟zabbix_agent

[root@node04 ~]# systemctl daemon-reload [root@node04 ~]# systemctl restart zabbix-agent.service [root@node04 ~]# ss -tnlState Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:6379 *:* LISTEN 0 128 *:80 *:* LISTEN 0 128 *:22 *:* LISTEN 0 100 127.0.0.1:25 *:* LISTEN 0 128 *:10050 *:* LISTEN 0 128 :::80 :::* LISTEN 0 128 :::22 :::* LISTEN 0 100 ::1:25 :::* [root@node04 ~]#

在zabbix web gui導入模板

提示:在configuration--->Templates菜單下找到Import,點擊進入導入模板的界面;

提示:選擇下載的模板,然後點擊Import即可;

查看導入的模板

提示:可以看到我們的模板已經導入成功;

連結導入的模板到node04,看看是否能夠採集到對應的數據呢?

提示:可以看到對應主機連結模板以後,多了兩個自動發現的配置;其他的監控項,觸發器都沒有變,這是因為它這個模板是自動發現的配置,等它掃描完配置,對應的監控配置都會自動應用上去;

查看是否能夠採集到數據呢?

提示:這個掃描配置和採集數據的過程稍微有點長,要耐心多等一會;

現在查看主機列表,看看對應監控項和其他監控配置是否有變化呢?

提示:可以看到現在就多了很多監控配置;好了從網際網路下載的模板已經成功導入到zabbix並成功採集到數據;

相關焦點

  • Zabbix學習筆記之zabbix自定key
    客戶端開通10050埠firewall-cmd --add-port=10050/tcp伺服器端測試zabbix-get命令,被server和agent認可的key,以及自定義的key>zabbix_get -s 10.41.1.97 -p 10050 -k "system.uname"zabbix_get -s 10.41.1.97 -p 10050 -k "login_user"創建和編輯自定義key文件文件創建到
  • 系統學習 Zabbix 系統監控(三)VMware 虛擬平臺監控、郵件告警、企業微信告警配置 | 運維進階
    8 Vmware 虛擬平臺監控閱讀 zabbix 官方文檔,官方提供了 Vmware 虛擬機監控模板,並對模板進行了解釋說明
  • Zabbix5.2發布,由loT物聯網和綜合監控驅動!
    >物聯網和工業設備監控UI和API的負載平衡創建自定義視圖用YAML導入/導出可用性改進與告警系統的內嵌集成與ITSM系統的內嵌集成全新的和升級的模板和插件您可以選擇:在本地或雲端部署更多全新的和升級的功能01 - 綜合監控此功能使複雜數據收集和可靠的多步驟可用性監控的腳本化場景成為可能。
  • zabbix系統「Too many processes on AdGuard」告警解決方法
    Zabbix學習筆記(二十九)- zabbix系統「Too many processes on AdGuard」告警解決方法今天在查看zabbix監控系統,發現拓撲圖中一個新增加的CentOS Linux系統出現報警,報警信息為「Too many
  • 詳解十三款運維監控工具
    WEB界面的提供分布式系統監控以及網絡監控功能的企業級開源運維平臺,也是目前國內網際網路用戶中使用最廣的監控軟體,雲智慧遇到的85%以上用戶在使用Zabbix做監控解決方案。Zabbix易於管理和配置,能生成比較漂亮的數據圖,其自動發 現功能大大減輕日常管理的工作量,豐富的數據採集方式和API接口可以讓用戶靈活進行數據採集,而分布式系統架構可以支持監控更多的設備。理論上,通過 Zabbix提供的插件式架構,可以滿足企業的任何需求。
  • 解決zabbix系統歷史數據緩存過低告警
    Zabbix學習筆記(三十一)-解決zabbix系統Cache過低告警Zabbix伺服器本身告警提示:「Zabbix value cache working in low memory mode」,意思是zabbix值工作在低內存的工作模式下,出現此告警的原因是ValueCacheSize
  • 完美的分布式監控系統——普羅米修斯
    Prometheus於2012年由SoundCloud創建,目前已經已發展為最熱門的分布式監控系統。Prometheus完全開源的,被很多雲廠商(架構)內置,在這些廠商(架構)中,可以簡單部署Prometheus,用來監控整個雲基礎架構設施。比如DigitalOcean或Docker都是普羅米修斯作為基礎監控。
  • 技術|TopOn分布式服務設計與伺服器監控預警部署
    作為全球領先的聚合管理工具,TopOn已與千餘家國內外開發團隊合作,接入移動遊戲和應用超過3000款,每日廣告展示2億+、廣告請求10億+、服務請求20億+。巨額的服務壓力下,TopOn服務端是如何保障開發者在全球範圍穩定高效使用聚合管理功能的?今天小T就為開發者詳細闡述TopOn的聚合平臺分布式服務以及確保伺服器穩定的監控預警部署。
  • zabbix監控之交換機監控
    #snmp-agent sys-info location #交換機名稱#snmp-agent sys-info version all #顯示系統中運行的SNMP版本#snmp-agent community complexity-check disable #配置取消SNMP團體名密碼複雜度檢測
  • 監控系統選型,這篇不可不讀
    較強的擴展性:支持Proxy分布式監控,有agent自動發現功能,插件式架構支持用戶自定義數據採集腳本。配置管理方便:能通過Web界面進行監控和告警配置,操作方便,上手簡單。應用層監控支持有限:如果想對應用程式做侵入式的埋點和採集(比如監控線程池或者接口性能),zabbix沒有提供對應的sdk,通過插件式的腳本也能曲線實現此功能,個人感覺zabbix就不是做這個事的。數據模型不強大:不支持tag,因此沒法按多維度進行聚合統計和告警配置,使用起來不靈活。
  • 分布式發電機勵磁監控系統的設計
    摘要:介紹了用分布式技術設計的發電機勵磁監控系統。發電機勵磁系統對於維持電力系統的電壓水平、提高電力系統穩定運行的能力、改善電力系統及發電機的運行條件等起到重要的作用。微機勵磁調節器是勵磁系統的核心元件,除了完成控制功能外,還要實現人機互動、遠方通信等功能。單微機難以實現所有功能,故採用雙微機設計勵磁調節器,並通過通信網絡構建分布式發電機勵磁監控系統。
  • Zabbix 5.2由淺入深系列之郵箱告警
    在以往的zabbix版本,自帶的php mail會導致zabbix server服務異常重啟,在5.0之後就已經解決了,所以既可以傻瓜式,也可以腳本化實現,之前我翻閱過大部分的這方面的文章,sh腳本基本通過mailx這種方式,雖然這種方式也可以,但是還有多多少少有點缺陷,所以今天帶來兩種方式,分別是zabbix原生和基於Python。
  • UVM序列篇之三:sequence和item(下)
    這個例子中,我們暫時沒有使用sequence的宏或者其它用來發送item的宏來表示sequence/item與sequencer之間的傳送方法,而是用更直白的方式來描述這種層次關係和包含性。在上面例碼中沒有給出例如`uvm_do/`uvm_do_with/`uvm_create等宏是為了讓讀者首先認清sequence與item之間的關係。因此上面的例子也只給出了在flat_seq::body()任務中創建和隨機item,而省略了發送item。關於完整的過程,我們將在稍後的《sequencer與sequence》中具體闡述常見的方法和宏。
  • sar工具在監控性能方向的實踐
    以某系統正式環境為例,該系統壓測接口透傳,不涉及資料庫,機器分布:涉及一臺nginx和一臺jboss伺服器。針對該系統,可以通過linux系統自帶的工具包,進行監控,查看性能指標。5、與zabbix監控工具對比圖表結果5.1 zabbix工具介紹5.1.1 Zabbix的部署架構Zabbix分為三種部署架構,這三種架構為
  • 監控系統選型,這篇不可不讀!
    這篇文章,我將對監控體系的基礎知識、原理和架構做一次系統性整理,同時還會對幾款最常用的開源監控產品做下介紹,以便大家選型時參考。內容包括3部分:監控系統俗稱「第三隻眼」,幾乎是我們每天都會打交道的系統,下面 4 項基礎知識我認為是必須要了解的。正所謂「無監控,不運維」,監控系統的地位不言而喻。
  • word模板應用:定製一個日常專屬模板
    而今天的文章將在5分鐘教會你透徹理解Word模板,大大減少重複性的工作,將節省下來的時間專注在內容本身,提升工作效率。1、什麼是Word模板?相信許多朋友都用過PPT模板,而Word模板用的就相對少了許多。其實無論是Word還是Excel和PPT,系統都為我們內置了樣式豐富的模板,簡潔、專業又美觀。
  • [Stardust]星塵分布式全鏈路監控
    隨著業務的發展,微服務系統會變得越來越大,各個服務之間的調用關係也會日趨複雜。一個WebApi請求,後方可能經歷多個微服務以及資料庫和MQ操作,在這個調用過程中,可能因為某一個服務節點出現延遲或者失敗,而導致整個請求失敗,此時極為需要全鏈路的調用監控。星塵Stardust提供了分布式全鏈路監控的解決方案。
  • Dapper: 大規模分布式系統鏈路追蹤基礎設施
    這裡介紹由Google生產的分布式系統鏈路追蹤系統Dapper的設計,並描述其設計目標如何滿足大規模系統低開銷、對應用透明性和廣泛的覆蓋部署設計目標介紹分布式服務追蹤是整個分布式系統中跟蹤一個用戶請求的過程,包括數據採集、數據傳輸、數據存儲、數據分析和數據可視化,捕獲此類跟蹤讓我們構建用戶交互背後的整個調用鏈的視圖
  • 聊聊下一代監控:Prometheus
    那麼 Prometheus 和這些監控系統有啥異同呢?我們在這就介紹下 Zabbix 這個監控系統。Zabbix 是由 Alexei Vladishev 開源的分布式監控系統,支持多種採集方式和採集客戶端,同時支持 SNMP、IPMI、JMX、Telnet、SSH 等多種協議,它將採集到的數據存放到資料庫中,然後對其進行分析整理,如果符合告警規則