碼上快樂

相關內容    簡體    繁體

轉 zabbix 優化方法 以及 后台數據庫查詢方法 兩則

本文轉載自   查看原文   2019-08-14 17:37   498    運維幫

############sample 1

https://blog.51cto.com/sfzhang88/1558254

如何從Zabbix數據庫中獲取監控數據

sfzhang 關注 6人評論 40627人閱讀2014-09-25 21:08:57
 

    做過Zabbix的同學都知道，Zabbix通過專用的Agent或者SNMP收集相關的監控數據，然后存儲到數據庫里面實時在前台展示。Zabbix監控數據主要分為以下兩類：

    歷史數據：history相關表,從history_uint表里面可以查詢到設備監控項目的最大，最小和平均值,即存儲監控數據的原始數據。

    趨勢數據：trends相關表,趨勢數據是經過Zabbix計算的數據，數據是從history_uint里面匯總的，從trends_uint可以查看到監控數據每小時最大，最小和平均值，即存儲監控數據的匯總數據。

    Zabbix可以通過兩種方式獲取歷史數據：

1.通過Zabbix前台獲取歷史數據

    通過Zabbix前台查看歷史數據非常簡單，可以通過Monitoring->Lastest data的方式查看。也可以點擊右上角的As plain test按鈕保存成文本文件。

wKioL1QkDOCjpLoTAAOm77_P1z4367.jpg

2.通過前台獲取的數據進行處理和二次查詢有很多限制，因此可以通過SQL語句直接從后台DB查詢數據。    

    首先大家應該熟悉SQL語句Select 常用用法：

 

SELECT [ALL | DISTINCT] Select_List [INTO [New_Table_name] FROM { Table_name | View_name} [ [,{table2_name | view2_name} [,...] ] [ WHERE Serch_conditions ] [ GROUP BY Group_by_list ] [ HAVING Serch_conditions ] [ ORDER BY Order_list [ASC| DEsC] ]
 

    說明：

1)SELECT子句指定要查詢的特定表中的列，它可以是*，表達式，列表等。

2)INTO子句指定要生成新的表。

3)FROM子句指定要查詢的表或者視圖。

4)WHERE子句用來限定查詢的范圍和條件。

5)GROUP BY子句指定分組查詢子句。

6)HAVING子句用於指定分組子句的條件。

7)ORDER BY可以根據一個或者多個列來排序查詢結果，在該子句中，既可以使用列名，也可以使用相對列號，ASC表示升序，DESC表示降序。

8）mysql聚合函數：sum()，count()，avg()，max()，avg()等都是聚合函數，當我們在用聚合函數的時候，一般都要用到GROUP BY 先進行分組，然后再進行聚合函數的運算。運算完后就要用到Having子句進行判斷了,例如聚合函數的值是否大於某一個值等等。

從Zabbix數據庫中查詢監控項目方法,這里已查詢主機的網卡流量為例子：

1）通過hosts表查找host的ID。

mysql> select host,hostid from hosts where host="WWW05"; +-------+--------+ | host | hostid | +-------+--------+ | WWW05 | 10534 | +-------+--------+ 1 row in set (0.00 sec)
 

2）通過items表查找主的監控項和key以及itemid。

mysql> select itemid,name,key_ from items where hostid=10534 and key_="net.if.out[eth0]"; +--------+-----------------+------------------+ | itemid | name | key_ | +--------+-----------------+------------------+ | 58860 | 發送流量： | net.if.out[eth0] | +--------+-----------------+------------------+ 1 row in set (0.00 sec)
 

3）通過itemid查詢主機的監控項目（history_uint或者trends_uint)，單位為M。

   主機流入流量：

mysql> select from_unixtime(clock) as DateTime,round(value/1024/1024,2) as Traffic_in from history_uint where itemid="58855" and from_unixtime(clock)>='2014-09-20' and from_unixtime(clock)<'2014-09-21' limit 20; +---------------------+------------+ | DateTime | Traffic_in | +---------------------+------------+ | 2014-09-20 00:00:55 | 0.10 | | 2014-09-20 00:01:55 | 0.09 | | 2014-09-20 00:02:55 | 0.07 | | 2014-09-20 00:03:55 | 0.05 | | 2014-09-20 00:04:55 | 0.03 | | 2014-09-20 00:05:55 | 0.06 | | 2014-09-20 00:06:55 | 0.12 | | 2014-09-20 00:07:55 | 0.05 | | 2014-09-20 00:08:55 | 0.10 | | 2014-09-20 00:09:55 | 0.10 | | 2014-09-20 00:10:55 | 0.12 | | 2014-09-20 00:11:55 | 0.12 | | 2014-09-20 00:12:55 | 0.13 | | 2014-09-20 00:13:55 | 3.16 | | 2014-09-20 00:14:55 | 0.23 | | 2014-09-20 00:15:55 | 0.24 | | 2014-09-20 00:16:55 | 0.26 | | 2014-09-20 00:17:55 | 0.23 | | 2014-09-20 00:18:55 | 0.14 | | 2014-09-20 00:19:55 | 0.16 | +---------------------+------------+ 20 rows in set (0.82 sec)
 

 

    主機流出流量：

mysql> select from_unixtime(clock) as DateTime,round(value/1024/1024,2) as Traffic_out from history_uint where itemid="58860" and from_unixtime(clock)>='2014-09-20' and from_unixtime(clock)<'2014-09-21' limit 20; +---------------------+-------------+ | DateTime | Traffic_out | +---------------------+-------------+ | 2014-09-20 00:00:00 | 4.13 | | 2014-09-20 00:01:00 | 3.21 | | 2014-09-20 00:02:00 | 2.18 | | 2014-09-20 00:03:01 | 1.61 | | 2014-09-20 00:04:00 | 1.07 | | 2014-09-20 00:05:00 | 0.92 | | 2014-09-20 00:06:00 | 1.23 | | 2014-09-20 00:07:00 | 2.76 | | 2014-09-20 00:08:00 | 1.35 | | 2014-09-20 00:09:00 | 3.11 | | 2014-09-20 00:10:00 | 2.99 | | 2014-09-20 00:11:00 | 2.68 | | 2014-09-20 00:12:00 | 2.55 | | 2014-09-20 00:13:00 | 2.89 | | 2014-09-20 00:14:00 | 4.98 | | 2014-09-20 00:15:00 | 6.56 | | 2014-09-20 00:16:00 | 7.34 | | 2014-09-20 00:17:00 | 6.81 | | 2014-09-20 00:18:00 | 7.67 | | 2014-09-20 00:19:00 | 4.11 | +---------------------+-------------+ 20 rows in set (0.74 sec)
 

4）如果是兩台設備，匯總流量，假如公司出口有兩台設備，可以用下面的SQL語句匯總每天的流量。下面SQL語句是匯總上面主機網卡的進出流量的。

mysql> select from_unixtime(clock,"%Y-%m-%d %H:%i") as DateTime,sum(round(value/1024/1024,2)) as Traffic_total from history_uint where itemid in (58855,58860) and from_unixtime(clock)>='2014-09-20'and from_unixtime(clock)<'2014-09-21' group by from_unixtime(clock,"%Y-%m-%d %H:%i") limit 20; +------------------+---------------+ | DateTime | Traffic_total | +------------------+---------------+ | 2014-09-20 00:00 | 4.23 | | 2014-09-20 00:01 | 3.30 | | 2014-09-20 00:02 | 2.25 | | 2014-09-20 00:03 | 1.66 | | 2014-09-20 00:04 | 1.10 | | 2014-09-20 00:05 | 0.98 | | 2014-09-20 00:06 | 1.35 | | 2014-09-20 00:07 | 2.81 | | 2014-09-20 00:08 | 1.45 | | 2014-09-20 00:09 | 3.21 | | 2014-09-20 00:10 | 3.11 | | 2014-09-20 00:11 | 2.80 | | 2014-09-20 00:12 | 2.68 | | 2014-09-20 00:13 | 6.05 | | 2014-09-20 00:14 | 5.21 | | 2014-09-20 00:15 | 6.80 | | 2014-09-20 00:16 | 7.60 | | 2014-09-20 00:17 | 7.04 | | 2014-09-20 00:18 | 7.81 | | 2014-09-20 00:19 | 4.27 | +------------------+---------------+ 20 rows in set (1.52 sec)
 

5)查詢一天中主機流量的最大值，最小值和平均值。

mysql> select date as DateTime,round(min(traffic)/2014/1024,2) as TotalMinIN,round(avg(traffic)/1024/1024,2) as TotalAvgIN,round(max(traffic)/1024/1024,2) as TotalMaxIN from (select from_unixtime(clock,"%Y-%m-%d") as date,sum(value) as traffic from history_uint where itemid in (58855,58860) and from_unixtime(clock)>='2014-09-20' and from_unixtime(clock)<'2014-09-21' group by from_unixtime(clock,"%Y-%m-%d %H:%i") ) tmp; +------------+------------+------------+------------+ | DateTime | TotalMinIN | TotalAvgIN | TotalMaxIN | +------------+------------+------------+------------+ | 2014-09-20 | 0.01 | 4.63 | 191.30 | +------------+------------+------------+------------+ 1 row in set (1.74 sec)
 

6）查詢主機組里面所有主機CPU Idle平均值（原始值）。

mysql> select from_unixtime(hi.clock,"%Y-%m-%d %H:%i") as DateTime,g.name as Group_Name,h.host as Host, hi.value as Cpu_Avg_Idle from hosts_groups as hg join groups g on g.groupid = hg.groupid join items i on hg.hostid = i.hostid join hosts h on h.hostid=i.hostid join history hi on i.itemid = hi.itemid where g.name='上海機房--項目測試' and i.key_='system.cpu.util[,idle]' and from_unixtime(clock)>='2014-09-24' and from_unixtime(clock)<'2014-09-25' group by h.host,from_unixtime(hi.clock,"%Y-%m-%d %H:%i") limit 10; +------------------+----------------------------+----------+--------------+ | DateTime | Group_Name | Host | Cpu_Avg_Idle | +------------------+----------------------------+----------+--------------+ | 2014-09-24 00:02 | 上海機房--項目測試 | testwb01 | 94.3960 | | 2014-09-24 00:07 | 上海機房--項目測試 | testwb01 | 95.2086 | | 2014-09-24 00:12 | 上海機房--項目測試 | testwb01 | 95.4308 | | 2014-09-24 00:17 | 上海機房--項目測試 | testwe01 | 95.4580 | | 2014-09-24 00:22 | 上海機房--項目測試 | testwb01 | 95.4611 | | 2014-09-24 00:27 | 上海機房--項目測試 | testwb01 | 95.2939 | | 2014-09-24 00:32 | 上海機房--項目測試 | testwb01 | 96.0896 | | 2014-09-24 00:37 | 上海機房--項目測試 | testwb01 | 96.5286 | | 2014-09-24 00:42 | 上海機房--項目測試 | testwb01 | 96.8086 | | 2014-09-24 00:47 | 上海機房--項目測試 | testwb01 | 96.6854 | +------------------+----------------------------+----------+--------------+ 10 rows in set (0.75 sec)
 

7)查詢主機組里面所有主機CPU Idle平均值（匯總值）。

mysql> select from_unixtime(hi.clock,"%Y-%m-%d %H:%i") as Date,g.name as Group_Name,h.host as Host, hi.value_avg as Cpu_Avg_Idle from hosts_groups as hg join groups g on g.groupid = hg.groupid join items i on hg.hostid = i.hostid join hosts h on h.hostid=i.hostid join trends hi on i.itemid = hi.itemid where g.name='上海機房--項目測試' and i.key_='system.cpu.util[,idle]' and from_unixtime(clock)>='2014-09-10' and from_unixtime(clock)<'2014-09-11' group by h.host,from_unixtime(hi.clock,"%Y-%m-%d %H:%i") limit 10; +------------------+----------------------------+----------+--------------+ | Date | Group_Name | Host | Cpu_Avg_Idle | +------------------+----------------------------+----------+--------------+ | 2014-09-10 00:00 | 上海機房--項目測試 | testwb01 | 99.9826 | | 2014-09-10 01:00 | 上海機房--項目測試 | testwb01 | 99.9826 | | 2014-09-10 02:00 | 上海機房--項目測試 | testwb01 | 99.9825 | | 2014-09-10 03:00 | 上海機房--項目測試 | testwb01 | 99.9751 | | 2014-09-10 04:00 | 上海機房--項目測試 | testwb01 | 99.9843 | | 2014-09-10 05:00 | 上海機房--項目測試 | testwb01 | 99.9831 | | 2014-09-10 06:00 | 上海機房--項目測試 | testwb01 | 99.9829 | | 2014-09-10 07:00 | 上海機房--項目測試 | testwb01 | 99.9843 | | 2014-09-10 08:00 | 上海機房--項目測試 | testwb01 | 99.9849 | | 2014-09-10 09:00 | 上海機房--項目測試 | testwb01 | 99.9849 | +------------------+----------------------------+----------+--------------+ 10 rows in set (0.01 sec)
 

8）其它與Zabbix相關的SQL語句。

    查詢主機已經添加但沒有開啟監控主機：

select host from hosts where status=1;
 

    查詢NVPS的值：

mysql> SELECT round(SUM(1.0/i.delay),2) AS qps FROM items i,hosts h WHERE i.status='0' AND i.hostid=h.hostid AND h.status='0' AND i.delay<>0; +--------+ | qps | +--------+ | 503.40 | +--------+ 1 row in set (0.11 sec)
 

    查詢IDC機房的資產信息：

mysql> select name,os,tag,hardware from host_inventory where hostid in (select hostid from hosts_groups where groupid=69) limit 2; +-------+----------------------------+------+-------------------+ | name | os | tag | hardware | +-------+----------------------------+------+-------------------+ | SHDBM | CentOS release 5.2 (Final) | i686 | ProLiant DL360 G5 | | SHDBS | CentOS release 5.2 (Final) | i686 | ProLiant DL360 G5 | +-------+----------------------------+------+-------------------+ 2 rows in set (0.00 sec)
 

    查詢Zabbix interval分布情況：

mysql> select delay,count(*),concat(round(count(*) / (select count(*) from items where status=0)*100,2),"%") as percent from items where status=0 group by delay order by 2 desc; +-------+----------+---------+ | delay | count(*) | percent | +-------+----------+---------+ | 3600 | 41168 | 38.92% | | 300 | 35443 | 33.51% | | 600 | 16035 | 15.16% | | 60 | 12178 | 11.51% | | 0 | 902 | 0.85% | | 36000 | 46 | 0.04% | | 30 | 1 | 0.00% | +-------+----------+---------+ 7 rows in set (0.68 sec)
 

    總結：通過SQL語句可以查詢出任何監控項目的數據，並且在SQL語句的末尾通過into outfile '/tmp/zabbix_result.txt'直接把查詢的結果保存到系統上面，在通過腳本發送查詢結果到指定的用戶，實現自動化查詢的過程，網上很少有介紹Zabbix數據庫查詢的文章，希望對大家有所幫助。

   

 ##################sample 2 (重要)

https://www.cnblogs.com/wumingxiaoyao/p/7412312.html

ZABBIX數據庫表結構解析

 

 

 下面開始介紹：

1.添加監控表結構詳解

（1）hosts，存儲被監控的機器的信息，表結構如下：

 

（2）items

（3）hosts_templates，存儲機器和模版或者模版和模版之間的關系

由於模版和機器都存儲在hosts表中，所以hosts_templates和hosts 之間可以hostid關聯也可以通過templateid關聯。

 （4）interface，存儲了所有設備的ip和端口的數據。（由於hosts表中不僅保存了設備信息還保存了模版信息，所以統計實際監控的設備，此表更加准確）

 

 2.數據存儲表結構詳解

 

將clock 轉化為人性化時間：

3.報警相關表結構詳解

 

（1）triggers

 

 

 

附 functions 表結構：

 （2）events

 

 

例子：

1. 找出某台主機的所有items ,含有某個key_的item , 統計items 總個數
SELECT * FROM HOSTS WHERE hostid=10157;
SELECT * FROM items WHERE hostid=10157 AND key_ LIKE '%agent%';
SELECT COUNT(*) FROM items;

2. 找出觸發trigger次數最多的事件，並按trigger 降序排列。
SELECT a.description, COUNT(*) cnt FROM TRIGGERS a , EVENTS b 
WHERE a.triggerid=b.objectid ORDER BY cnt DESC ;
3. 從item記錄各找出一個value類型為整形，浮點型的key_。
統計這兩個key_ 存儲在history或者history_uint 某一個時間段（比如2017/06/12）
的最大值，最小值，平均值，然后與 trends 或者 trends_unint 中相應時間段做對比

整型
SELECT * FROM items WHERE value_type=3 AND hostid=10157 LIMIT 1;
SELECT * FROM history_uint a,trends_uint b WHERE a.clock=b.clock AND a.itemid=b.itemid LIMIT 1;

浮點型
SELECT * FROM items WHERE value_type=0 AND hostid=10157 LIMIT 1;
SELECT * FROM history a,trends b WHERE a.clock=b.clock AND a.itemid=b.itemid LIMIT 1;

 

4.統計Zabbix Dashboard中triggers總數的來源。

SELECT  count(*)
  FROM TRIGGERS
WHERE triggerid IN
       (SELECT triggerid
          FROM functions
         WHERE itemid IN (SELECT itemid
                            FROM items
                           WHERE hostid IN (SELECT hostid FROM interface)
                             AND key_ NOT LIKE '%#%'
                             AND key_ NOT LIKE '%discovery%'
                             AND STATUS != 1));
 
說明：
通過之前對zabbix表結構的學習，我們知道，表triggers和functions相關聯，而functions和items相關聯，那么，要對triggers做統計，就需要從這三張表下手。
關鍵就是對items表中的數據做出篩選，key_中帶“#”和“discovery”的和status=1（不可用狀態）都要排除，這樣就統計出來了。
 
 
####sample 3
https://www.cnblogs.com/shhnwangjian/p/5484352.html

想理解zabbix的前端代碼、做深入的二次開發，甚至的調優，那就不能不了解數據庫的表結構了。

我們這里采用的zabbix1.8、mysql，所以簡單的說下我們mysql這邊的表結構，其他環境不保證正確。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
mysql> show tables;
+-----------------------+
| Tables_in_zabbix      |
+-----------------------+
| acknowledges          |
| actions               |
| alerts                |
| application_template  |
| applications          |
| auditlog              |
| auditlog_details      |
| autoreg_host          |
| conditions            |
| config                |
| dbversion             |
| dchecks               |
| dhosts                |
| drules                |
| dservices             |
| escalations           |
| events                |
| expressions           |
| functions             |
| globalmacro           |
| globalvars            |
| graph_discovery       |
| graph_theme           |
| graphs                |
| graphs_items          |
| group_discovery       |
| group_prototype       |
|  groups                 |
|  history                |
| history_log           |
| history_str           |
| history_text          |
| history_uint          |
| host_discovery        |
| host_inventory        |
| hostmacro             |
| hosts                 |
| hosts_groups          |
| hosts_templates       |
| housekeeper           |
| httpstep              |
| httpstepitem          |
| httptest              |
| httptestitem          |
| icon_map              |
| icon_mapping          |
| ids                   |
| images                |
| interface             |
| interface_discovery   |
| item_condition        |
| item_discovery        |
| items                 |
| items_applications    |
| maintenances          |
| maintenances_groups   |
| maintenances_hosts    |
| maintenances_windows  |
| mappings              |
| media                 |
| media_type            |
| opcommand             |
| opcommand_grp         |
| opcommand_hst         |
| opconditions          |
| operations            |
| opgroup               |
| opmessage             |
| opmessage_grp         |
| opmessage_usr         |
| optemplate            |
| profiles              |
| proxy_autoreg_host    |
| proxy_dhistory        |
| proxy_history         |
| regexps               |
| rights                |
| screens               |
| screens_items         |
| scripts               |
| service_alarms        |
| services              |
| services_links        |
| services_times        |
| sessions              |
| slides                |
| slideshows            |
| sysmap_element_url    |
| sysmap_url            |
| sysmaps               |
| sysmaps_elements      |
| sysmaps_link_triggers |
| sysmaps_links         |
| timeperiods           |
| trends                |
| trends_uint           |
| trigger_depends       |
| trigger_discovery     |
| triggers              |
| user_history          |
|  users                  |
| users_groups          |
| usrgrp                |
| valuemaps             |
+-----------------------+

actions

actions表記錄了當觸發器觸發時，需要采用的動作。

mysql> desc actions;
+---------------+---------------------+------+-----+---------+-------+
| Field         | Type                | Null | Key | Default | Extra |
+---------------+---------------------+------+-----+---------+-------+
| actionid      | bigint(20) unsigned | NO | PRI | 0 | | | name | varchar(255) | NO | | | | | eventsource | int(11) | NO | MUL | 0 | | | evaltype | int(11) | NO | | 0 | | | status | int(11) | NO | | 0 | | | esc_period | int(11) | NO | | 0 | | | def_shortdata | varchar(255) | NO | | | | | def_longdata | blob | NO | | NULL | | | recovery_msg | int(11) | NO | | 0 | | | r_shortdata | varchar(255) | NO | | | | | r_longdata | blob | NO | | NULL | | +---------------+---------------------+------+-----+---------+-------+

alerts

alerts 表保存了歷史的告警事件，可以從這個表里面去做一些統計分析，例如某個部門、 
某人、某類時間的告警統計，以及更深入的故障發生、恢復時間，看你想怎么用了。

mysql> desc alerts;
+-------------+---------------------+------+-----+---------+-------+
| Field       | Type                | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+-------+ | alertid | bigint(20) unsigned | NO | PRI | 0 | | | actionid | bigint(20) unsigned | NO | MUL | 0 | | | eventid | bigint(20) unsigned | NO | MUL | 0 | | | userid | bigint(20) unsigned | NO | MUL | 0 | | | clock | int(11) | NO | PRI | 0 | | | mediatypeid | bigint(20) unsigned | NO | MUL | 0 | | | sendto | varchar(100) | NO | | | | | subject | varchar(255) | NO | | | | | message | blob | NO | | NULL | | | status | int(11) | NO | MUL | 0 | | | retries | int(11) | NO | | 0 | | | error | varchar(128) | NO | | | | | nextcheck | int(11) | NO | | 0 | | | esc_step | int(11) | NO | | 0 | | | alerttype | int(11) | NO | | 0 | | +-------------+---------------------+------+-----+---------+-------+

config

config表保存了全局的參數，前端包括后端也是，很多情況下會查詢改表的參數的，例如用戶的自定義主題、 
登陸認證類型等，非常重要，

不過對我們做數據分析意義不大。

mysql> desc config;
+-------------------------+---------------------+------+-----+-----------------+-------+
| Field                   | Type                | Null | Key | Default         | Extra |
+-------------------------+---------------------+------+-----+-----------------+-------+
| configid                | bigint(20) unsigned | NO | PRI | 0 | | | alert_history | int(11) | NO | | 0 | | | event_history | int(11) | NO | | 0 | | | refresh_unsupported | int(11) | NO | | 0 | | | work_period | varchar(100) | NO | | 1-5,00:00-24:00 | | | alert_usrgrpid | bigint(20) unsigned | NO | | 0 | | | event_ack_enable | int(11) | NO | | 1 | | | event_expire | int(11) | NO | | 7 | | | event_show_max | int(11) | NO | | 100 | | | default_theme | varchar(128) | NO | | default.css | | | authentication_type | int(11) | NO | | 0 | | | ldap_host | varchar(255) | NO | | | | | ldap_port | int(11) | NO | | 389 | | | ldap_base_dn | varchar(255) | NO | | | | | ldap_bind_dn | varchar(255) | NO | | | | | ldap_bind_password | varchar(128) | NO | | | | | ldap_search_attribute | varchar(128) | NO | | | | | dropdown_first_entry | int(11) | NO | | 1 | | | dropdown_first_remember | int(11) | NO | | 1 | | | discovery_groupid | bigint(20) unsigned | NO | | 0 | | | max_in_table | int(11) | NO | | 50 | | | search_limit | int(11) | NO | | 1000 | | +-------------------------+---------------------+------+-----+-----------------+-------+

functions

function 表時非常重要的一個表了，記錄了trigger中使用的表達式，例如max、last、nodata等函數。

但其實這個表說他重要時因為同時記錄了trigger、itemid，那就可以做一些API的開發了，例如根據 
IP 茶香改IP的所有trigger，我記得1.8的版本的API是無法實現我說的這個功能的，那只能利用 
function表去自己查詢了。

mysql> desc functions ;
+------------+---------------------+------+-----+---------+-------+
| Field      | Type                | Null | Key | Default | Extra | +------------+---------------------+------+-----+---------+-------+ | functionid | bigint(20) unsigned | NO | PRI | 0 | | | itemid | bigint(20) unsigned | NO | MUL | 0 | | | triggerid | bigint(20) unsigned | NO | MUL | 0 | | | lastvalue | varchar(255) | YES | | NULL | | | function | varchar(12) | NO | | | | | parameter | varchar(255) | NO | | 0 | | +------------+---------------------+------+-----+---------+-------+

graphs

graphs 表包含了用戶定義的圖表信息，同樣的玩法可以是根據IP去查詢改IP下的所有圖表， 
不過似乎是有API的，我只是舉例而已。

mysql> desc graphs;
+------------------+---------------------+------+-----+---------+-------+
| Field            | Type                | Null | Key | Default | Extra |
+------------------+---------------------+------+-----+---------+-------+
| graphid          | bigint(20) unsigned | NO | PRI | 0 | | | name | varchar(128) | NO | MUL | | | | width | int(11) | NO | | 0 | | | height | int(11) | NO | | 0 | | | yaxismin | double(16,4) | NO | | 0.0000 | | | yaxismax | double(16,4) | NO | | 0.0000 | | | templateid | bigint(20) unsigned | NO | | 0 | | | show_work_period | int(11) | NO | | 1 | | | show_triggers | int(11) | NO | | 1 | | | graphtype | int(11) | NO | | 0 | | | show_legend | int(11) | NO | | 0 | | | show_3d | int(11) | NO | | 0 | | | percent_left | double(16,4) | NO | | 0.0000 | | | percent_right | double(16,4) | NO | | 0.0000 | | | ymin_type | int(11) | NO | | 0 | | | ymax_type | int(11) | NO | | 0 | | | ymin_itemid | bigint(20) unsigned | NO | | 0 | | | ymax_itemid | bigint(20) unsigned | NO | | 0 | | +------------------+---------------------+------+-----+---------+-------+

graphs_items

graphs_items 保存了屬於某個圖表的所有的監控項信息。

mysql> desc graphs_items;
+-------------+---------------------+------+-----+---------+-------+
| Field       | Type                | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+-------+
| gitemid     | bigint(20) unsigned | NO | PRI | 0 | | | graphid | bigint(20) unsigned | NO | MUL | 0 | | | itemid | bigint(20) unsigned | NO | MUL | 0 | | | drawtype | int(11) | NO | | 0 | | | sortorder | int(11) | NO | | 0 | | | color | varchar(6) | NO | | 009600 | | | yaxisside | int(11) | NO | | 1 | | | calc_fnc | int(11) | NO | | 2 | | | type | int(11) | NO | | 0 | | | periods_cnt | int(11) | NO | | 5 | | +-------------+---------------------+------+-----+---------+-------+

groups

groups 沒啥說的，都懂，就是保存了組名和組的ID 。

mysql> desc groups ;
+----------+---------------------+------+-----+---------+-------+
| Field    | Type                | Null | Key | Default | Extra |
+----------+---------------------+------+-----+---------+-------+ | groupid | bigint(20) unsigned | NO | PRI | 0 | | | name | varchar(64) | NO | MUL | | | | internal | int(11) | NO | | 0 | | +----------+---------------------+------+-----+---------+-------+

history 、history_str、history_log 、history_uint_sync等

這部分表都差不多，唯一不同的是保存的數據類型，history_str保存的數據 
類型就算str即字符類型的。這個是和采集時設置的數據類型一致的。

需要注意的時，因為history表有這么多的類型，那自己寫報表系統等去查詢 
數據時，就需要判斷下數據的采集類型，如果查錯了表，那肯定時沒有數據的。

mysql> desc history;
+--------+---------------------+------+-----+---------+-------+
| Field  | Type                | Null | Key | Default | Extra |
+--------+---------------------+------+-----+---------+-------+ | itemid | bigint(20) unsigned | NO | PRI | 0 | | | clock | int(11) | NO | PRI | 0 | | | value | double(16,4) | NO | | 0.0000 | | +--------+---------------------+------+-----+---------+-------+ mysql> desc history_str; +--------+---------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+---------------------+------+-----+---------+-------+ | itemid | bigint(20) unsigned | NO | MUL | 0 | | | clock | int(11) | NO | | 0 | | | value | varchar(255) | NO | | | | +--------+---------------------+------+-----+---------+-------+

接收item值時的時間值存放在兩個字段內，大於1秒的部分存放找clock字段單位是秒(s)，小於一秒的部分存放在ns字段單位是納秒(ns)。

兩個字段相加的值才是接收item值時的時間值，一般不用關心小於1秒的部分。

trends、trends_uint

trends 也是保存了歷史數據用的，和history不同的時，trends表僅僅保存了 
小時平均的值，即你可以理解為是history表的數據壓縮。所以trends表也有 
很多的類型，對應history。

值的注意的trends和history表這兩類表數據量都非常大，我們一天大概就要有 
40G 的數據。

所以注意定是去做壓縮、刪除。

mysql> desc trends;
+-----------+---------------------+------+-----+---------+-------+
| Field     | Type                | Null | Key | Default | Extra |
+-----------+---------------------+------+-----+---------+-------+ | itemid | bigint(20) unsigned | NO | PRI | 0 | | | clock | int(11) | NO | PRI | 0 | | | num | int(11) | NO | | 0 | | | value_min | double(16,4) | NO | | 0.0000 | | | value_avg | double(16,4) | NO | | 0.0000 | | | value_max | double(16,4) | NO | | 0.0000 | | +-----------+---------------------+------+-----+---------+-------+ mysql> desc trends_uint; +-----------+---------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------+---------------------+------+-----+---------+-------+ | itemid | bigint(20) unsigned | NO | PRI | 0 | | | clock | int(11) | NO | PRI | 0 | | | num | int(11) | NO | | 0 | | | value_min | bigint(20) unsigned | NO | | 0 | | | value_avg | bigint(20) unsigned | NO | | 0 | | | value_max | bigint(20) unsigned | NO | | 0 | | +-----------+---------------------+------+-----+---------+-------+

hosts

hosts 非常重要，保存了每個agent、proxy等的IP 、hostid、狀態、IPMI等信息， 
幾乎是記錄了一台設備的所有的信息。

當然hostid是當中非常非常重要的信息，其他的表一般都時關聯hostid的。

mysql> desc hosts;
+--------------------+---------------------+------+-----+-----------+-------+
| Field              | Type                | Null | Key | Default   | Extra |
+--------------------+---------------------+------+-----+-----------+-------+
| hostid             | bigint(20) unsigned | NO | PRI | 0 | | | proxy_hostid | bigint(20) unsigned | NO | MUL | 0 | | | host | varchar(64) | NO | MUL | | | | dns | varchar(64) | NO | | | | | useip | int(11) | NO | | 1 | | | ip | varchar(39) | NO | | 127.0.0.1 | | | port | int(11) | NO | | 10050 | | | status | int(11) | NO | MUL | 0 | | | disable_until | int(11) | NO | | 0 | | | error | varchar(128) | NO | | | | | available | int(11) | NO | | 0 | | | errors_from | int(11) | NO | | 0 | | | lastaccess | int(11) | NO | | 0 | | | inbytes | bigint(20) unsigned | NO | | 0 | | | outbytes | bigint(20) unsigned | NO | | 0 | | | useipmi | int(11) | NO | | 0 | | | ipmi_port | int(11) | NO | | 623 | | | ipmi_authtype | int(11) | NO | | 0 | | | ipmi_privilege | int(11) | NO | | 2 | | | ipmi_username | varchar(16) | NO | | | | | ipmi_password | varchar(20) | NO | | | | | ipmi_disable_until | int(11) | NO | | 0 | | | ipmi_available | int(11) | NO | | 0 | | | snmp_disable_until | int(11) | NO | | 0 | | | snmp_available | int(11) | NO | | 0 | | | maintenanceid | bigint(20) unsigned | NO | | 0 | | | maintenance_status | int(11) | NO | | 0 | | | maintenance_type | int(11) | NO | | 0 | | | maintenance_from | int(11) | NO | | 0 | | | ipmi_ip | varchar(64) | NO | | 127.0.0.1 | | | ipmi_errors_from | int(11) | NO | | 0 | | | snmp_errors_from | int(11) | NO | | 0 | | | ipmi_error | varchar(128) | NO | | | | | snmp_error | varchar(128) | NO | | | | +--------------------+---------------------+------+-----+-----------+-------+

其實1.0的版本中，是沒有這么多的字段的，好像只有hostid、host、status、disable_until 
等幾個字段，但1.8已經如此豐富了。

hosts_groups

hosts_groups 保存了host（主機）與host groups（主機組）的關聯關系。

這部分信息可以在我們自己做一些批量查詢，例如查詢關聯到某個主機組的所有 
設備的IP 、存活狀態等，進一步去查詢該批量設備的load、IO、mem等統計信息。

我之前做的一個簡單的報表就是例如了這部分的信息去查詢某個業務線下所有設備 
的一周統計信息，當然了是在同一個主機組或者模版組才可以的。

mysql> desc hosts_groups ;
+-------------+---------------------+------+-----+---------+-------+
| Field       | Type                | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+-------+ | hostgroupid | bigint(20) unsigned | NO | PRI | 0 | | | hostid | bigint(20) unsigned | NO | MUL | 0 | | | groupid | bigint(20) unsigned | NO | MUL | 0 | | +-------------+---------------------+------+-----+---------+-------+

items

items 表保存了采集項的信息。

mysql> desc items ;
+-----------------------+---------------------+------+-----+---------+-------+
| Field                 | Type                | Null | Key | Default | Extra |
+-----------------------+---------------------+------+-----+---------+-------+ | itemid | bigint(20) unsigned | NO | PRI | 0 | | | type | int(11) | NO | | 0 | | | snmp_community | varchar(64) | NO | | | | | snmp_oid | varchar(255) | NO | | | | | snmp_port | int(11) | NO | | 161 | | | hostid | bigint(20) unsigned | NO | MUL | 0 | | | description | varchar(255) | NO | | | | | key_ | varchar(255) | NO | | | | | delay | int(11) | NO | | 0 | | | history | int(11) | NO | | 90 | | | trends | int(11) | NO | | 365 | | | lastvalue | varchar(255) | YES | | NULL | | | lastclock | int(11) | YES | | NULL | | | prevvalue | varchar(255) | YES | | NULL | | | status | int(11) | NO | MUL | 0 | | | value_type | int(11) | NO | | 0 | | | trapper_hosts | varchar(255) | NO | | | | | units | varchar(10) | NO | | | | | multiplier | int(11) | NO | | 0 | | | delta | int(11) | NO | | 0 | | | prevorgvalue | varchar(255) | YES | | NULL | | | snmpv3_securityname | varchar(64) | NO | | | | | snmpv3_securitylevel | int(11) | NO | | 0 | | | snmpv3_authpassphrase | varchar(64) | NO | | | | | snmpv3_privpassphrase | varchar(64) | NO | | | | | formula | varchar(255) | NO | | 1 | | | error | varchar(128) | NO | | | | | lastlogsize | int(11) | NO | | 0 | | | logtimefmt | varchar(64) | NO | | | | | templateid | bigint(20) unsigned | NO | MUL | 0 | | | valuemapid | bigint(20) unsigned | NO | | 0 | | | delay_flex | varchar(255) | NO | | | | | params | text | NO | | NULL | | | ipmi_sensor | varchar(128) | NO | | | | | data_type | int(11) | NO | | 0 | | | authtype | int(11) | NO | | 0 | | | username | varchar(64) | NO | | | | | password | varchar(64) | NO | | | | | publickey | varchar(64) | NO | | | | | privatekey | varchar(64) | NO | | | | | mtime | int(11) | NO | | 0 | | +-----------------------+---------------------+------+-----+---------+-------+

media

media 保存了某個用戶的media配置項，即對應的告警方式。

mysql> desc media;
+-------------+---------------------+------+-----+-----------------+-------+
| Field       | Type                | Null | Key | Default         | Extra |
+-------------+---------------------+------+-----+-----------------+-------+
| mediaid     | bigint(20) unsigned | NO | PRI | 0 | | | userid | bigint(20) unsigned | NO | MUL | 0 | | | mediatypeid | bigint(20) unsigned | NO | MUL | 0 | | | sendto | varchar(100) | NO | | | | | active | int(11) | NO | | 0 | | | severity | int(11) | NO | | 63 | | | period | varchar(100) | NO | | 1-7,00:00-23:59 | | +-------------+---------------------+------+-----+-----------------+-------+

media_type

media_type 表與media 表不同的是media_type 記錄了某個告警方式對應的腳步等的存放路徑。

mysql> desc media_type;
+-------------+---------------------+------+-----+---------+-------+
| Field       | Type                | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+-------+ | mediatypeid | bigint(20) unsigned | NO | PRI | 0 | | | type | int(11) | NO | | 0 | | | description | varchar(100) | NO | | | | | smtp_server | varchar(255) | NO | | | | | smtp_helo | varchar(255) | NO | | | | | smtp_email | varchar(255) | NO | | | | | exec_path | varchar(255) | NO | | | | | gsm_modem | varchar(255) | NO | | | | | username | varchar(255) | NO | | | | | passwd | varchar(255) | NO | | | | +-------------+---------------------+------+-----+---------+-------+

media 與media_type 通過mediatypeid 鍵關聯。

profiles

profiles 表保存了用戶的一些配置項。

mysql> desc profiles ;
+-----------+---------------------+------+-----+---------+-------+
| Field     | Type                | Null | Key | Default | Extra |
+-----------+---------------------+------+-----+---------+-------+
| profileid | bigint(20) unsigned | NO | PRI | 0 | | | userid | bigint(20) unsigned | NO | MUL | 0 | | | idx | varchar(96) | NO | | | | | idx2 | bigint(20) unsigned | NO | | 0 | | | value_id | bigint(20) unsigned | NO | | 0 | | | value_int | int(11) | NO | | 0 | | | value_str | varchar(255) | NO | | | | | source | varchar(96) | NO | | | | | type | int(11) | NO | | 0 | | +-----------+---------------------+------+-----+---------+-------+

rights

rights 表保存了用戶組的權限信息，zabbix的權限一直也是我理不太清的地方， 
其實這個表里面有詳細的記錄。

mysql> desc rights;
+------------+---------------------+------+-----+---------+-------+
| Field      | Type                | Null | Key | Default | Extra |
+------------+---------------------+------+-----+---------+-------+
| rightid    | bigint(20) unsigned | NO | PRI | 0 | | | groupid | bigint(20) unsigned | NO | MUL | 0 | | | permission | int(11) | NO | | 0 | | | id | bigint(20) unsigned | YES | MUL | NULL | | +------------+---------------------+------+-----+---------+-------+

screens

screens 表保存了用戶定義的圖片。

mysql> desc graphs;
+------------------+---------------------+------+-----+---------+-------+
| Field            | Type                | Null | Key | Default | Extra |
+------------------+---------------------+------+-----+---------+-------+
| graphid          | bigint(20) unsigned | NO | PRI | 0 | | | name | varchar(128) | NO | MUL | | | | width | int(11) | NO | | 0 | | | height | int(11) | NO | | 0 | | | yaxismin | double(16,4) | NO | | 0.0000 | | | yaxismax | double(16,4) | NO | | 0.0000 | | | templateid | bigint(20) unsigned | NO | | 0 | | | show_work_period | int(11) | NO | | 1 | | | show_triggers | int(11) | NO | | 1 | | | graphtype | int(11) | NO | | 0 | | | show_legend | int(11) | NO | | 0 | | | show_3d | int(11) | NO | | 0 | | | percent_left | double(16,4) | NO | | 0.0000 | | | percent_right | double(16,4) | NO | | 0.0000 | | | ymin_type | int(11) | NO | | 0 | | | ymax_type | int(11) | NO | | 0 | | | ymin_itemid | bigint(20) unsigned | NO | | 0 | | | ymax_itemid | bigint(20) unsigned | NO | | 0 | | +------------------+---------------------+------+-----+---------+-------+

screens_items

同graphs_items。

mysql> desc screens_items;
+--------------+---------------------+------+-----+---------+-------+
| Field        | Type                | Null | Key | Default | Extra |
+--------------+---------------------+------+-----+---------+-------+
| screenitemid | bigint(20) unsigned | NO | PRI | 0 | | | screenid | bigint(20) unsigned | NO | | 0 | | | resourcetype | int(11) | NO | | 0 | | | resourceid | bigint(20) unsigned | NO | | 0 | | | width | int(11) | NO | | 320 | | | height | int(11) | NO | | 200 | | | x | int(11) | NO | | 0 | | | y | int(11) | NO | | 0 | | | colspan | int(11) | NO | | 0 | | | rowspan | int(11) | NO | | 0 | | | elements | int(11) | NO | | 25 | | | valign | int(11) | NO | | 0 | | | halign | int(11) | NO | | 0 | | | style | int(11) | NO | | 0 | | | url | varchar(255) | NO | | | | | dynamic | int(11) | NO | | 0 | | +--------------+---------------------+------+-----+---------+-------+

sessions

sessions 表很重要，保存了每個用戶的sessions,在登陸、注銷的時候均會操作 
該張表的。

做cas等統一認證時，需要了解下該表和相關的登陸、驗證流程。有興趣的看我 
前面的文章吧。

mysql> desc sessions;
+------------+---------------------+------+-----+---------+-------+
| Field      | Type                | Null | Key | Default | Extra |
+------------+---------------------+------+-----+---------+-------+ | sessionid | varchar(32) | NO | PRI | | | | userid | bigint(20) unsigned | NO | MUL | 0 | | | lastaccess | int(11) | NO | | 0 | | | status | int(11) | NO | | 0 | | +------------+---------------------+------+-----+---------+-------+

triggers

triggers 顧名思義保存了trigger的所有信息。

mysql> desc triggers;
+-------------+---------------------+------+-----+---------+-------+
| Field       | Type                | Null | Key | Default | Extra |
+-------------+---------------------+------+-----+---------+-------+
| triggerid   | bigint(20) unsigned | NO | PRI | 0 | | | expression | varchar(255) | NO | | | | | description | varchar(255) | NO | | | | | url | varchar(255) | NO | | | | | status | int(11) | NO | MUL | 0 | | | value | int(11) | NO | MUL | 0 | | | priority | int(11) | NO | | 0 | | | lastchange | int(11) | NO | | 0 | | | dep_level | int(11) | NO | | 0 | | | comments | blob | NO | | NULL | | | error | varchar(128) | NO | | | | | templateid | bigint(20) unsigned | NO | | 0 | | | type | int(11) | NO | | 0 | | +-------------+---------------------+------+-----+---------+-------+

trigger_depends

trigger_depends 保存了trigger的依賴關系。

mysql> desc trigger_depends;
+----------------+---------------------+------+-----+---------+-------+
| Field          | Type                | Null | Key | Default | Extra |
+----------------+---------------------+------+-----+---------+-------+ | triggerdepid | bigint(20) unsigned | NO | PRI | 0 | | | triggerid_down | bigint(20) unsigned | NO | MUL | 0 | | | triggerid_up | bigint(20) unsigned | NO | MUL | 0 | | +----------------+---------------------+------+-----+---------+-------+

users

不需要解釋了,值的一提的部分用戶配置會在該表中，例如auotlogin、autologout、 
url、theme等信息。

mysql> desc users;
+----------------+---------------------+------+-----+-------------+-------+
| Field          | Type                | Null | Key | Default     | Extra |
+----------------+---------------------+------+-----+-------------+-------+
| userid         | bigint(20) unsigned | NO | PRI | 0 | | | alias | varchar(100) | NO | MUL | | | | name | varchar(100) | NO | | | | | surname | varchar(100) | NO | | | | | passwd | char(32) | NO | | | | | url | varchar(255) | NO | | | | | autologin | int(11) | NO | | 0 | | | autologout | int(11) | NO | | 900 | | | lang | varchar(5) | NO | | en_gb | | | refresh | int(11) | NO | | 30 | | | type | int(11) | NO | | 0 | | | theme | varchar(128) | NO | | default.css | | | attempt_failed | int(11) | NO | | 0 | | | attempt_ip | varchar(39) | NO | | | | | attempt_clock | int(11) | NO | | 0 | | | rows_per_page | int(11) | NO | | 50 | | +----------------+---------------------+------+-----+-------------+-------+

轉載：http://www.furion.info/623.html

 

使用python獲取表中TCP連接數，生成Execl文件\

 

 

############sample 4

https://blog.csdn.net/IREwyz/article/details/50374500

版權聲明：本文為博主原創文章，遵循 CC 4.0 by-sa 版權協議，轉載請附上原文出處鏈接和本聲明。
本文鏈接：https://blog.csdn.net/IREwyz/article/details/50374500
zabbix是一個強大的網管工具，其功能和用途也隨之多變，但萬變不離其宗，對於龐大的監控系統性能優化、方案優化是不可缺少的。

以下是我閱讀zabbix官方文檔，結合兩個項目的心得。

一、拓撲優化

zabbix再帶proxy功能，因本公司自主研發私有雲平台，故可以在個別項目上用虛擬機來作proxy服務器，在確保vm正常運作的前提下，減少了server端的負荷。

二、方案優化

那么有的同學說了，如果硬件條件有限且同一批次中標業務么有私有雲，那么建議在agent端采取active checks模式，根據官網定義，雖然agent端有更復雜的流程，且有舉例

1. Agent opens a TCP connection
2. Agent asks for the list of checks
3. Server responds with a list of items (item key, delay)4. Agent parses the response
5. TCP connection is closed
6. Agent starts periodical collection of data 

但是相對於被動agent，對於server的壓力會大大減小，避免server端宕機，被動agent在此不做贅述，網上有很多部署方法。
若采用active checks模式，首先針對zabbix_agentd.conf文件修改

a）在ServerActive=xxx 填server端ip、

b）Hostname=xx 填agent的hostname 、

c）StartAgents=0 

（）

注：如果此處值為0，那么passive checks 將被disable，同學們可以根據實際業務大小來分配主動、被動agent個數）


d）針對模板變更，

1.以任何一個現有模板為例，clone並重命名，假如重命名模板為TEST

2.將模板TEST里所有items和discovery rules里的items都變更type為atvice agent

3.將創建的host關聯重命名的模板TEST，注意創建的時候，ip和port都填0，否則會因模式沖突看到一個紅色的Z，讓人覺得很不舒服，不是么


至此active-checks模式的agent部署完畢，可以在overview中查看模板中的監控項。


三 數據庫優化（此部分轉載，因時間關系，未能親自驗證，待有時間會把此部分自己試驗結果奉上）

分享一個zabbix數據庫的優化腳本，適合2.0版本。

對history，hostory_uint按日分區，trends,trends_uint按月分區；

關閉Houserkeeper:

vim zabbix_server.conf

DisableHousekeeper=1

對history,hostory_uint每日建立第二天的分區並刪除45天前的分區
對trends,trends_uint每月20號建立下一個月的分區，並刪除12個月前的分區

時間可以自己修改

由於events表的大小對儀表盤的展示速度影響很大，2.0以后的版本又對該表做過修改，具有主鍵約束，不能以clock做分區表優化，所以我每日都清理該表，只保留了3天的數據（根據自己的環境和需求而定，可以自己修改），很簡單的一個定期維護腳本，希望能幫到大家

 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59
#!/usr/bin/env python
# coding: utf-8
import MySQLdb
import datetime
now_time = datetime.datetime.now()
error_time = now_time.strftime('%Y-%m-%d %H:%M:%S')
theday = (now_time + datetime.timedelta(days=+1)).strftime('%Y%m%d')
next_day = (now_time + datetime.timedelta(days=+2)).strftime('%Y-%m-%d')
themonth = datetime.datetime(now_time.year,(now_time.month+1),now_time.day).strftime('%Y%m')
next_month = datetime.datetime(now_time.year,(now_time.month+2),1).strftime('%Y-%m-%d')
last_time = (now_time - datetime.timedelta(days=30)).strftime('%Y%m%d')
last_time_month = datetime.datetime((now_time.year-1),now_time.month,now_time.day).strftime('%Y%m')
events_time = (now_time - datetime.timedelta(days=1)).strftime('%Y-%m-%d')
history_time = (now_time - datetime.timedelta(days=45)).strftime('%Y%m%d')
trends_time = datetime.datetime((now_time.year-1),now_time.month,now_time.day).strftime('%Y%m')
table_day=['history', 'history_uint']
table_month=['trends', 'trends_uint']
conn=MySQLdb.connect(host='localhost',user='zabbix',passwd='zabbix',db='zabbix',port=3306)
cur=conn.cursor()
for name_d in table_day:
   try:
   ####新增分區#######
      cur.execute('ALTER TABLE `%s` ADD PARTITION (PARTITION p%s VALUES LESS THAN (UNIX_TIMESTAMP("%s 00:00:00")))' % (name_d, theday, next_day))
                                                                                                                                                 
   except MySQLdb.Error,e:
       print "[%s] Mysql Error %d: %s" % (error_time, e.args[0], e.args[1])
       pass
for name_m in table_month:
   try:
      ####新增分區#######
      if now_time.day == 20:
         cur.execute('ALTER TABLE `%s` ADD PARTITION (PARTITION p%s VALUES LESS THAN (UNIX_TIMESTAMP("%s 00:00:00")))' % (name_m, themonth, next_month))
   except MySQLdb.Error,e:
       print "[%s] Mysql Error %d: %s" % (error_time, e.args[0], e.args[1])
       pass
######清除events表1天前的數據######
try:
   cur.execute('DELETE FROM `events` where `clock` < UNIX_TIMESTAMP("%s 00:00:00")'% events_time)
   cur.execute('optimize table events;')
except MySQLdb.Error,e:
   print "[%s] Mysql Error %d: %s" % (error_time, e.args[0], e.args[1])
   pass
######清除history,histroy_uint表45天前的數據######
for name_d in table_day:
    try:
       cur.execute('ALTER TABLE `%s` DROP PARTITION p%s;' % (name_d, history_time))
    except MySQLdb.Error,e:
       print "[%s] Mysql Error %d: %s" % (error_time, e.args[0], e.args[1])
       pass
######清除trends,trends_uint表一年前的數據######
for name_m in table_month:
    try:
       cur.execute('ALTER TABLE `%s` DROP PARTITION p%s;' % (name_m, trends_time))
    except MySQLdb.Error,e:
       print "[%s] Mysql Error %d: %s" % (error_time, e.args[0], e.args[1])
       pass
conn.commit()
cur.close()
conn
---------------------
版權聲明：本文為CSDN博主「IRE王一喆」的原創文章，遵循CC 4.0 by-sa版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/IREwyz/article/details/50374500

 

####sample 5

 

http://blog.chinaunix.net/uid-26660567-id-4419434.html

https://www.cnblogs.com/gqdw/archive/2013/01/01/2841221.html

https://blog.csdn.net/ubggze6t/article/details/39119219

https://blog.csdn.net/shuxiang1990/article/details/53416090

Zabbix housekeeper processes more than 75% busy 報警排查
 

分類： 系統運維

2014-08-15 15:15:39

 
首先理解housekeeper 是什么，看zabbix_server.conf配置文件

點擊(此處)折疊或打開

  1. ### Option: HousekeepingFrequency
  2. # How often Zabbix will perform housekeeping procedure (in hours).
  3. # Housekeeping is removing unnecessary information from history, alert, and alarms tables.
  4. #
  5. # Mandatory: no
  6. # Range: 1-24
  7. # Default:
  8. # HousekeepingFrequency=1
  11. ### Option: MaxHousekeeperDelete
  12. # The table "housekeeper" contains "tasks" for housekeeping procedure in the format:
  13. # [housekeeperid], [tablename], [field], [value].
  14. # No more than 'MaxHousekeeperDelete' rows (corresponding to [tablename], [field], [value])
  15. # will be deleted per one task in one housekeeping cycle.
  16. # SQLite3 does not use this parameter, deletes all corresponding rows without a limit.
  17. # If set to 0 then no limit is used at all. In this case you must know what you are doing!
  18. #
  19. # Mandatory: no
  20. # Range: 0-1000000
  21. # Default:
  22. # MaxHousekeeperDelete=500
大意就是housekeeper就是清理數據庫里過期的歷史數據神馬的。然后MaxHousekeeperDelete就是一個閥值，每次輪詢housekeeper這個任務的時候，超過這個閥值的行都會被清理。

怎么查看housekeeper的執行情況？看日志：

點擊(此處)折疊或打開

  1. grep housekeeper /var/log/zabbix/zabbix_server.log 
  2.   4850:20140809:175626.071 executing housekeeper
  3.   4850:20140809:181408.036 housekeeper [deleted 279622 hist/trends, 0 items, 0 events, 0 sessions, 0 alarms, 0 audit items in 1061.962644 sec, idle 1 hour(s)]
  4.   4850:20140809:191408.037 executing housekeeper
  5.   4850:20140809:192611.432 housekeeper [deleted 287033 hist/trends, 0 items, 0 events, 0 sessions, 0 alarms, 0 audit items in 723.394480 sec, idle 1 hour(s)]
  6.   4850:20140809:202611.433 executing housekeeper
  7.   4850:20140809:203638.243 housekeeper [deleted 266125 hist/trends, 0 items, 0 events, 0 sessions, 0 alarms, 0 audit items in 626.808964 sec, idle 1 hour(s)]
  8.   4850:20140809:213638.244 executing housekeeper
  9.   4850:20140809:215445.003 housekeeper [deleted 258097 hist/trends, 0 items, 0 events, 0 sessions, 0 alarms, 0 audit items in 1086.756768 sec, idle 1 hour(s)]
  10.   4850:20140809:225445.004 executing housekeeper
  11.   4850:20140809:230601.581 housekeeper [deleted 286602 hist/trends, 0 items, 0 events, 0 sessions, 0 alarms, 0 audit items in 676.576122 sec, idle 1 hour(s)]
  12. ....
  13. ....
關於housekeeper的執行過程，摘抄了zabbix論壇上的：

 

點擊(此處)折疊或打開

  1. That is fine.
  2. Zabbix server housekeeper is doing all deletes in few stages:
  3. - in first is deleting from history* and trends* tables using clock key and it deletes ALL data from items older than specified in "Keep history" param,
  4. - in second stage is deleting rows of items of deleted items and deleted hosts (zabbix does not deletes all these data just when you click on delete but it adds all these items ids to 'housekeeper' table).
  5. - at the end it deletes items from events, acknowledgements, alarms tables
另外，在Monitor-Dashboard-Graphs里面也可以查看到Zabbix server的一些性能情況。
比如Zabbix internal process busy % 

到zabbix server上查看系統性能情況，發現io很高：

點擊(此處)折疊或打開

  1. [root@zabbix ~]# iostat -xm 1
  2. Linux 2.6.32-431.5.1.el6.x86_64 (zabbix)     08/14/2014     _x86_64_    (2 CPU)
  4. avg-cpu: %user %nice %system %iowait %steal %idle
  5.            8.57 0.00 4.23 11.05 0.13 76.02
  7. Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
  8. xvda 0.00 588.40 0.56 275.92 0.01 3.38 25.11 0.19 0.69 0.84 23.15
  9. xvdb 0.00 76.12 0.29 59.23 0.01 0.53 18.46 1.12 18.87 1.88 11.17
  10. dm-0 0.00 0.00 0.86 999.67 0.02 3.90 8.04 0.86 0.86 0.26 26.15
  11. dm-1 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 67.83 6.77 0.00
  13. avg-cpu: %user %nice %system %iowait %steal %idle
  14.           23.98 0.00 11.73 42.35 0.51 21.43
  16. Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
  17. xvda 0.00 2964.00 20.00 1292.00 0.31 16.39 26.07 13.19 9.43 0.60 78.90
  18. xvdb 0.00 37.00 0.00 36.00 0.00 0.14 8.00 4.02 59.64 6.64 23.90
  19. dm-0 0.00 0.00 22.00 4385.00 0.42 17.13 8.16 57.78 11.69 0.18 81.30
  20. dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
  22. avg-cpu: %user %nice %system %iowait %steal %idle
  23.           18.46 0.00 6.67 34.36 0.00 40.51
  25. Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
  26. xvda 0.00 1849.00 4.00 826.00 0.14 10.69 26.72 11.90 15.43 1.01 83.90
  27. xvdb 0.00 0.00 0.00 83.00 0.00 0.47 11.57 6.01 94.92 3.66 30.40
  28. dm-0 0.00 0.00 1.00 2700.00 0.02 10.55 8.01 57.89 23.79 0.32 87.10
  29. dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
感謝linux 群友 提供的實際經驗：

點擊(此處)折疊或打開

  1. “建議你照着群上的那個文檔去優化,基本10w的items不會有太大問題”
  2. 廣州-小王 15:44:26
  3. 做分區表,直接刪分區就好了
  4. 廣州-小王 15:44:43
  5. 文檔上有說,很簡單,用腳本定時去刪
  6. 廣州-小王 15:45:09
  7. history開頭的都能做分區,events表貌似2.0后就不能直接做了,有外鍵約束
  8. 廣州-小王 15:48:53
  9. housekeeper有點廢,當你量到達一定程度的時候刪的速度沒你增加的快..
  11. 廣州-Samma 15:38:33
  12. 看housekeeper具體做了什么事。如果寫對象是小一些的表，可以放到內存。
  13. 廣州-Samma 15:39:21
  14. 或者把housekeeper的頻度調大一些。 間隔N小時才執行一次
先寫到這里吧，搞優化去了
優化參考：
先配置獨立數據庫，使用獨立表空間
http://junqili.com/zabbix/zabbix-performance-tunning/
然后按照官網的這個文檔對mysql 做分區
https://www.zabbix.org/wiki/Docs/howto/mysql_partition

參考資料：https://www.zabbix.com/forum/showthread.php?t=43311
https://www.zabbix.com/forum/showthread.php?t=43311&page=2
 
 
 
####sample 3
 

zabbix配置詳解（三）

 監控報警  靠譜運維  2年前 (2017-11-30)  5684℃  0評論
一、zabbix-server對數據的存儲其他的監控系統是將數據存儲在rrd數據庫里面，不存在數據庫越來越大的情況，這跟數據庫的環形存儲特性有關系。zabbix不管是采用分布式架構還是傳統的服務端與客戶端直接相連的模式，最終都是將數據存儲在mysql里面。

 

1.1 zabbix對數據存儲

數據存儲的大小與每秒處理的數據量有關，所以數據存儲取決於兩個因素：更新的數據量和刪除的數據量（Housekeeper）。

zabbix-server將采集到的數據主要存儲在History和Trends表中，其表結構中的數據類型如下：

圖片.png

另外,acknowledges、alerts、auditlog、events和service_alarms表的數據也較大。

在History表中，主要存儲數據到的歷史數據，而Trends主要存儲經過計算的歷史數據（如每小時數據的最小值、最大值和平均值）。其實主要還是history表占的最大，trends表只是相對於其他表大而已。

在Trends表中，主要存儲的是趨勢數據，Trends 基本上是收集到的按小時合並的數據（僅僅是數值類型）。Zabbix 服務器按小時把所有的值從 history 表中提取出來，並按每小時計算最小值，平均值和最大值。

歷史圖：

圖片.png

#由上圖可以看出，一分鍾一個格（我們一般都是60秒采集一次），這種的話就是歷史數據，就是數據之間的時間相差不大，數據是以分鍾為單位存儲的，如果300台主機每個是10個監控項，一分鍾就是3000條數據。所以一般歷史數據的保存時間一般都不會設置太久，比如7天半個月之類的，雖然默認的是90天的歷史保留時間。

#當然有的除外，比如我這里有個zabbix是專門用來存儲各機房交換機出口的流量，因為cacti趨勢的比較狠，所以我這里的歷史保留時間和趨勢保留時間都比較久。但是一般的都不應該保留這么久。

趨勢圖：

圖片.png

#當前時間減7天，就是7月14日16點，然后看圖是3小時一個格，這明顯圖的顆粒變得很粗，這就是趨勢，1小時一條數據，24*7可比1*60*24*7，這個數據量級要少太多了。所以歷史數據保存時間短一點，數據庫空間增長會少很多。

圖片.png

#再拉大呢，我拉倒所有，這就跨年了，可以看到是7天一格，真的就是看一個大概趨勢了。這個日期是從上往下念，我圖中也有標准了。那么我這數據起始位置只有月日，沒有年啊，可以通過下面的圖來查看。

圖片.png

#看標紅的地方就能看出下面的趨勢圖從什么時間開始到什么時間結束，左邊那什么1h、2h、12h，7d等等，都是可以點的，就是你想看哪個時間跨度的圖。

圖片.png

Housekeeper

上面展示的history和Trends都存儲在mysql中，直到 Zabbix 服務器的 Housekeeper 基於 Keep history 和 Keep trends 配置刪除它們：

圖片.png

#看上圖，就是items里面的設置，首先采集時間是60秒，也就是一分鍾去采集一次，也就是說此條item一分鍾會往mysql的history表里面插入一條數據。歷史數據是保留7天的，然后這個item在history表里面保存的總條數為：1（分鍾）*60*24*7=10080行記錄，一般來說一條記錄需要占用50個字節，也就是說這一個監控項所占用的history表在實際物理空間上面的實際使用量為：504000字節=500KB左右。

#趨勢數據設置的是365天，趨勢數據是一小時計算一次，一般趨勢數據可以存放的時間長一點，比如5年10年的，也是看什么數據有沒有必要存那么長時間。它保存的是每小時收集到數據的最小值，最大值和平均值以及每小時收集到值的總數，也就是一小時一條數據。我們先按1年的時間來算，1*24（小時）*365=8760（條數據），如果換算成占用物理空間大小呢：趨勢數據一條記錄大概占用128字節，就是：8760*128=1095KB約等於1MB。

#而Housekeeper就是根據上圖定義的歷史數據在mysql表里面的保存時間和趨勢數據的保存時間，去通過查詢數據的時間戳去刪除超過時限的老數據。

#當然還有個事件（alerts）也會占用點磁盤空間：報警、警告、恢復等等事情，一個事件大概占用130個字節，這個就是按條算了，一般也占用不了太大的空間，一般也不會老報警啥的。

注：

如果是很大型的監控系統，一般都會禁止Housekeeper，因為數據庫里面數據太多了，每次去數據庫里面搜索並刪除消耗和耗時太大，一般都會采用優化數據庫表結構、分庫等其他的方法來搞。

默認歷史保存時間是90天，趨勢保存時間是365天，如果你想將歷史保存時間變短或者變長的話，不去改全局的話，那么創建的每個items都要去修改，這工作量就大了，如何全局修改呢？

圖片.png

圖片.png

再添加items會看到：

圖片.png

#這是一種方式，不用每次添加Items都手工修改一下，但是更好的方式還是盡量用模板的形式，這樣能大大的減少工作量，那么多主機和items肯定不能一個個來加，除非自定義的。

二、相關配置

2.1 配置流程

zabbix完整的監控配置流程可以簡單描述為：

Host groups（主機組）-》Hosts（主機）->Applications（監控項組）->Items（監控項）->Triggers(觸發器)->Event（事件）->Actions（處理動作）->User groups（用戶組）->Users(用戶)->Medias（告警方式）->Audit(日志審計)。

實際使用的時候Items、Trigger、Graph通常采用模板進行監控配置，模板的特點就是可以對相同需求的監控項重復使用，無須對每台主機進行逐個設置。

對於zabbix來說，配置Graph不是必須的，因為沒有配置圖形，數據獲取也不影響，數據獲取是Items的功能，我們只需要對比較關心的Items設置Graph進行數據可視化。

對於zabbix來說，配置Trigger不是必須的，但是對於特別關注的數據，需要對取到的值進行條件判斷，這時配置觸發器是必須的。

2.2 制作模板

圖片.png

圖片.png

2.3 給模板添加Applications：

圖片.png

#上圖是Template OS Linux的監控項組模板，這就是相當於我們的例子，我們就照着它來創建一些application，當然有些我們可能用不到的就去掉了。

圖片.png

#也可以通過去查看items去看看這個application下面都有哪些items供我們參考

#點擊右上角的Create application

圖片.png

下面是搞完之后的applications截圖：

圖片.png

2.4 給模板添加items並關聯applications：

#這個就是照着Template OS Linux模板里面的items，想加哪個items就加哪個。如下面：

圖片.png

注（Name中的$1..$9）：

名稱：CPU $2 time  #這個$2代表下面鍵值中[]中第二個參數，[]里面就是傳進來的參數嘛，$1就是以第一個參數，以此類推，所以它的顯示因該是CPU system time。

鍵值：system.cpu.util[,system]

內置了哪些鍵呢：https://www.zabbix.com/documentation/3.2/manual/config/items/itemtypes/zabbix_agent

下面是主機items顯示的效果：

圖片.png

好了下圖我們定義了13個items：

圖片.png

#注意關於Units（單位的注意）：

Bash 
默認情況下，如果原始值超過1000，那么他會先除以1000並且顯示出來例如，設置了單位為bps並且收到的值為11102，將會顯示為11.1Kbps 如果單位被指定為 B (byte), Bps (bytes per second) ，那么它會除以1024然后再顯示數據。所以大家在監控流量和文件大小的時候不要用錯單位，否則會出現數據不一致的情況。 如下為時間單位: unixtime – 轉為 “yyyy.mm.dd hh:mm:ss”. 只能使用正數。 uptime – 轉為“hh:mm:ss” 或者“N days, hh:mm:ss” 例如，收到的值為881764秒，他將會顯示為“10 days, 04:56:04” s – 轉為“yyy mmm ddd hhh mmm sss ms”; 例如，收到的值為881764(單位秒)，他將會被顯示為10d 4h 56m”，只會顯示3個單元。有時候只會顯示2個單元，例如”1m 5h”（不包含分，秒，毫秒），如果返回的值小於0.001，他只會顯示”<1 ms”禁用單位：ms、rpm、RPM、%

 

2.5 給模板添加trigger(觸發器)：

還是觸發器的右上角點擊創建觸發器：

直接表達式添加觸發器：

圖片.png

#{HOST.NAME}是一個內置宏。這里是官網內置宏的列表：https://www.zabbix.com/documentation/3.2/manual/appendix/macros/supported_by_location

#主要是表達式，這里才是核心，如：{zabbix_linux_base:vm.memory.size[available].last(0)}<20M

表達式語法格式：

Bash 
{<server>:<key>.<function>(<parameter>)}<operator><constant>

用上面的例子拆分舉例就是：

Bash 
<server> ：模板名稱，即zabbix_linux_base，等誰引用這個模板，那這里就是引用模板對應的主機了 <key> ：即監控模板里的項目items，這里就是內存剩items的鍵：vm.memory.size[available] <function> ：就是我們觸發器里面的功能項也就是函數，這里last就是表示last函數，即last() <parameter> ：就是上面方法所使用的參數，這里即0，last(0)也就是表示倒數第0個值，也就是最新的值 <operator> ：可使用的操作符，這里<是小於的意思，操作符有：/ * - + < > #（不等於） = &（邏輯與） |（邏輯或） <constant> ： 常量，在這里即是20M

模板中trigger效果圖：

圖片.png

192.168.1.106主機添加完模板之后trigger效果圖：

圖片.png

function都有哪些啊，官網地址：https://www.zabbix.com/documentation/3.2/manual/appendix/triggers/functions

大概來說就是：

abschange   #作用：返回最近獲得值與之前獲得值的差值，對於字符串0表示相等，1表示不同

Bash 
舉例：
change(0)>n:忽略參數一般輸入0，表示最近得到的值與上一個值的差值大於n

avg                #返回一段時間的平均值

Bash 
舉例：
avg(5):最后5秒的平均值 avg(#5）：表示最近5次得到值的平均值 avg(3600,86400）：表示一天前的一個小時的平均值 如果僅有一個參數，表示指定時間的平均值，從現在開始算起，如果有第二個參數，表示漂移，從第二個參數前開始算時間， #n表示最近n次的值

band             #

change          #最后的區別和之前的值

count             #返回時間間隔內數值的統計

Bash 
舉例：
count(600)最近10分鍾得到值的個數 count(600,12)最近10分鍾得到值的個數等於12 count(600,12,"gt")最近10分鍾得到值的個數大於12 count(#10,12,"gt")最近10個值中，值大於12的個數 count(600,12,"gt",86400)24小時之前的10分鍾內值大於12的個數 count(600,6/7,"band")-thenumberofvaluesforlast10minuteshaving'110'(inbinary)inthe3leastsignificantbits. count(600,,,86400)24小時之前的10分鍾數據值的個數 第一個參數：指定時間段 第二個參數：樣本數據 第三個參數：操作參數 第四個參數：漂移參數 #支持的操作類型 eq: 相等 ne: 不相等 gt: 大於 ge: 大於等於 lt: 小於 le: 小於等於 like: 內容匹配

date               #時間，返回當前的時間，格式YYYYMMDD

dayofmonth  #返回當前是本月的第幾天

dayofweek     #返回當前是本周的第幾天

delta               #返回時間間隔內的最大值與最小值的差值

diff                  #返回值為1表示最近的值與之前的值不同，0為其他情況

forecast           #預測未來的值

fuzzytime        #返回值為1表示監控項值的時間戳與ZabbixServer的時間多N秒,0為其他.常使用system.localtime來檢查本地時間是否與Zabbixserver時間相同.
iregexp            #不區分大小寫

last                   #最近的值，如果為秒，則忽略，#num表示最近第N個值，請注意當前的#num和其他一些函數的#num的意思是不同的

Bash 
last(0)等價於last(#1)last(#3)表示最近第3個值(並不是最近的三個值) 本函數也支持第二個參數time_shift，例如last(0,86400)返回一天前的最近的值 如果在history中同一秒中有多個值存在，Zabbix不保證值的精確順序 #num從Zabbix1.6.2起開始支持,timeshift從1.8.2其開始支持,可以查詢avg()函數獲取它的使用方法

logeventid      #

logseverity      #

logsource       #

max                #返回指定時間間隔的最大值.

min                 #返回指定時間間隔的最小值.

nodata            #檢查收到的任何數據。

now                 #返回距離Epoch(1970年1月1日00:00:00UTC)時間的秒數

percentile       #百分比

prev                 #返回之前的值，類似於last(#2)

regexp            #第一個參數為string,第二個參數為秒或#num。檢查最近的值是否匹配正則表達式，參數的正則表達式為POSIX擴展樣式,第二個參數為秒數或收集值的數目，將會處理多個值.本函數區分大小寫。當返回值為1時表示找到，0為其他.

str                    #第一個參數為string,第二個參數為秒或#num。查找最近值中的字符串。第一個參數指定查找的字符串，大小寫敏感。第二個可選的參數指定秒數或收集值的數目，將會處理多個值。當返回值為1時表示找到，0為其他.
strlen               #指定最近值的字符串長度(並非字節),參數值類似於last函數.例如strlen(0)等價於strlen(#1),strlen(#3)表示最近的第三個值,strlen(0,86400)表示一天前的最近的值.

sum                 #返回指定時間間隔中收集到的值的總和.時間間隔作為第一個參數支持秒或收集值的數目(以#開始).從Zabbix1.8.2開始，本函數支持time_shift作為第二個參數。可以查看avg函數獲取它的用法

Bash 
sum(600):表示在600秒之內接收到所有值的和 sum(#5):表示最后5個值的和

time                 #返回當前的時間，HHMMSS格式的當前時間。

timeleft            #一個項目達到所需的時間間隔,以秒為單位指定的閾值。

表達式語法舉例：

官網的一些舉例：https://www.zabbix.com/documentation/3.2/manual/config/triggers/expression

示例1：

Bash 
{www.zabbix.com:system.cpu.load[all,avg1].last()}>5 #www.zabbix.com這個主機的監控項，最新的CPU負載值如果大於5，那么表達式會返回true，這樣一來觸發器狀態就改變為“problem”了。

示例2：

Bash 
{www.zabbix.com:system.cpu.load[all,avg1].last()}>5 or {www.zabbix.com:system.cpu.load[all,avg1].min(10m)}>2 #當前cpu負載大於5或者最近10分內的cpu負載大於2，那么表達式將會返回true.

示例3：

Bash 
{www.zabbix.com:vfs.file.cksum[/etc/passwd].diff()}=1 #/etc/passwd最新的checksum與上一次獲取到的checksum不同，表達式將會返回true.

示例4：

Bash 
{www.zabbix.com:net.if.in[eth0,bytes].min(5m)}>100K #當前主機網卡eth0最后5分鍾內接收到的流量超過100KB那么觸發器表達式將會返回true

示例5：

Bash 
{smtp1.zabbix.com:net.tcp.service[smtp].last()}=0 and {smtp2.zabbix.com:net.tcp.service[smtp].last()}=0 #當smtp1.zabbix.com和smtp2.zabbix.com兩台主機上的SMTP服務器都離線，表達式將會返回true.

示例6：

Bash 
{zabbix.zabbix.com:agent.version.str("beta8")}=1 #如果當前zabbix agent版本包含beta8（假設當前版本為1.0beta8），這個表達式會返回true.

示例7：

Bash 
{zabbix.zabbix.com:icmpping.count(30m,0)}>5 #最近30分鍾zabbix.zabbix.com這個主機超過5次不可到達返回true

示例8：

Bash 
{zabbix.zabbix.com:tick.nodata(3m)}=1 #tick為Zabbix trapper類型，首先我們要定義一個類型為Zabbix trapper，key為tick的item。我們使用zabbix_sender定期發送數據給tick，如果在3分鍾內還未收到zabbix_sender發送來的數據，那么表達式返回一個true，與此同時觸發器的值變為“PROBLEM”。

示例9：

Bash 
{zabbix:system.cpu.load[all,avg1].min(5m)}>2 and {zabbix:system.cpu.load[all,avg1].time()}>000000 and {zabbix:system.cpu.load[all,avg1].time()}<060000 #只有在凌晨0點到6點整，最近5分鍾內cpu負載大於2，表達式返回true，觸發器的狀態變更為“problem”

示例10：

Bash 
{MySQL_DB:system.localtime.fuzzytime(10)}=0 #主機MySQL_DB當前服務器時間如果與zabbix server之間的時間相差10秒以上，表達式返回true，觸發器狀態改變為“problem”

示例11：

Bash 
{server:system.cpu.load.avg(1h)}/{server:system.cpu.load.avg(1h,1d)}>2 #最新一小時的平均負載峰值超過昨天同時段指標兩次進行報警

Hysteresis（滯后性）：

觸發器狀態轉變為problem需要一個條件，從problem轉變回來還需要一個條件才行。一般觸發器只需要不滿足觸發器為problem條件即可恢復。有時候我們需要一個時間間隔一個好的狀態和問題,而不是一個簡單的閾值。 例如,我們想定義一個觸發器,變成了問題當服務器機房溫度高於20 c和我們想要呆在這個狀態,直到溫度低於15度。為了做到這一點,我們首先定義觸發器事件的表達式問題。 然后選擇“恢復表達”好的事件代和輸入一個恢復好事件的表達式。
注意,復蘇將計算表達式的值只有當事件是先解決的問題。 復蘇是不可能解決問題,如果問題表達條件仍然存在。
示例1：

Bash 
問題表現：
{server:temp.last()}>20 恢復表達式： {server:temp.last()}<=15

圖片.png

示例2：

Bash 
問題表達式：
{server:vfs.fs.size[/,free].max(5m)}<10G #最近5分鍾內剩余磁盤空間小於10GB 恢復表達式： {server:vfs.fs.size[/,free].min(10m)}>40G #最近5分鍾內磁盤空間大於40GB

通過表達式構造器添加觸發器：

如果說表達式什么的那么多我記不住，我就知道個大概意思就可以了，那就可以通過表達式構造器來添加觸發器的表達式。

#通過點擊表達式那欄右邊的添加按鈕或者下方的表達式構造器，都可以進入到表達式添加欄。

圖片.png

Bash 
{zabbix_linux_base:vfs.fs.size[/,pfree].last()}<10 or {zabbix_linux_base:vfs.fs.size[/,free].last()}=10 #像這種多條表達式如果根分區磁盤空間百分比低於10%或者根分區磁盤空間小於10B（如果你不加單位就是以你Utils來換算，當然怎么也得寫個1G啥的啊），就報警

圖片.png

圖片.png

#然后上圖下面還有個圖片.png點擊這個就是保存設置了。

#說到這個Test，當你測試的時候，不能直接輸入單位啥的，需要輸入整數，比如你內存設置的是1M，那你就得把1M換算成字節的是多少數，然后輸入上去測試一下看返回的是True還是False。

改變嚴重性顯示的顏色：

圖片.png

觸發器支持的單位：

#觸發器支持的單位官網鏈接：https://www.zabbix.com/documentation/3.2/manual/config/triggers/suffixes

#觸發器如果不支持單位的話，那么比如你設置一個磁盤空間的觸發器設置，因為它的單位是B，所以你要設置小於1G報警的話，你就要1*1024*1024*1024=1073741824（字節），你的數字就要設置成1073741824

#從上面的例子可以看出，設置成支持的單位就是讓程序去算，我們就不用自己算了，因為zabbix采集的時候比如磁盤空間內存剩余空間都是字節的形式，你當然可以設置成字節跟采集上來的字節去比較，如果你設置了單位，它就會將采集上來的數換算成你設置的單位來比較，你再設置的觸發器的時候是方便的，不用你自己算了。

Bash 
時間可以使用：s（秒）、m（分鍾）、h（小時）、d（天）、w(周） 內存大小可以使用：K（千字節）、M（兆字節）、G（千兆字節）、T（太字節） 單位符號可以使用：K,M,G,T 當B，Bps中的項目值顯示在前端時，應用基准2（1K = 1024）。 否則使用10的基數（1K = 1000）。 另外還支持：P（peta）、E（exa）、Z（zetta）、Y（yotta）

 

2.6 給模板添加graphs（圖形）配置

大部分數據是不需要出圖了，一般CPU和網絡還有程序的進程,cache的占用等一些需要圖形來直觀的查看和分析。

官網鏈接：https://www.zabbix.com/documentation/3.2/manual/config/visualisation/graphs/custom

這里我們以cpu的負載來舉例：

圖片.png

#可以點擊圖形右邊的預覽，看看有沒有問題沒，沒問題就點擊圖中最下面的添加就可以了。

圖形的屬性：

Bash 
Name（名稱）：Graph唯一的名字
Width(寬度): 圖像在屏幕中的寬度（僅對餅行圖/分解圖有效） Height（高度）：圖像在屏幕中的高度 Graph type(圖形類別): Normal：常規圖標，值用線條表示。Stacked:疊圖就像cacti的流量圖。Pie：餅形圖。Exploded：分解餅形圖。 Show legend（查看圖例）：勾選會顯示圖標中的說明 Show working time（查看工作時間）：如果被選中，非工作時間用灰色背景顯示，不能用於餅形圖或分解圖中 Show triggers(查看觸發器):如果被選中，觸發達到閥值會用紅色的線條顯示，不能用餅形圖或是分解圖表示，注意，只有部分觸發器才支持在此處顯示，如min、max函數可支持在圖像中顯示觸發器的值。 Percentile line(left)(百分比線（左）)：左邊的Y軸用來顯示百分比，例如，給定95%，線條就會在95%的數值處，僅對常規圖表適用。 Percentile line(right)（百分比線（右））：右邊的Y軸用來顯示百分比，例如，給定95%，線條就會在95%的數值處，僅對常規圖表使用 Y axis MIN value（縱軸Y最小值MIN） ：Y軸表示的最小值，Calculated-Y（可計算的）軸表示自動計算值的最小值，Fixed-Y(固定的)軸表示修正最小值不能用於餅形圖或是分解餅形圖，Item（監控項）表示選擇的items最后一次獲取的數值將作為最小值 Y axis MAX value（縱軸最大值）：Y軸表示的最大值

監控項里面的的參數：

Bash 
Sort order(0->100)：畫圖時應該從0的順序開始，可以被用來畫線條或區域在另一個之后（或之前），可以在開始的線條箭頭處拖放項目，以設定分類順序或絕對將哪一個項目放在另一個項目的前面 Name(名稱)：Item的名稱顯示的數據 Type：類型（僅對餅形圖或是分解圖餅形圖使用），Simple:單一（簡單），Graph sum:圖表總數。這里上面的圖因為選的不是餅形圖，所以這里不顯示這兩個選項。 Function（功能）：當一個Item存在不止一個值時，決定顯示哪一個數據，all：全部（最小值、平均值和最大值），min：僅最小值，avg：僅平均值，max：僅最大值 Draw style（繪圖風格）：僅對常規圖表使用，對疊圖填充區域使用。Line線條：畫線條，Filled region（填滿的區域），Bold line(粗線)，Dot（圓點），Dashed Line（畫虛線），Gradient line（梯度線） Y axis side（縱軸Y軸）：Y軸的一側是從左邊開始還是右邊開始，視圖習慣一般從左邊開始 Colour（顏色）：在十六進制中引用RGB（紅、綠、藍）法。

2.7 添加主機關聯模板

主機的添加上面已經介紹過了，下面主機添加完后關聯下模板

圖片.png

模板也關聯了，zabbix_agentd也顯示啟動連接上了，我們看看是否能采集到新數據了吧：

圖片.png

#上面關於items添加的時候utils那里已經說過了，設置的單位很重要，我們磁盤大小那里單位設置的是B，所以zabbix會自動的將收到的值除以1024換算下去，從Byte換算成了GB.內存那里也是一樣的。

#去查看唯一的圖形，load圖形也出來了。就不截圖了。

#這個圖最后邊還有個圖形，這里沒有截圖，就算我們沒有事先定義圖形，在這里點擊圖形，也可以查看這個主機這個數據的繪圖,如查看一個內存選項的圖形：

圖片.png

圖片.png

2.8 模板關聯

你說我不想自創模板太麻煩了，圖省事那就關聯模板白。

圖片.png

#你關聯了模板，監控項 觸發器什么的不是可以啟用和禁用嗎，那你就把不想用的禁用掉吧，但是你禁用的是你所關聯模板里面的選項，所以如果不想監控那么多項還是自創模板吧靈活一點。

#注意：上圖中有個取消鏈接和取消鏈接並清理，這個要注意一下，取消鏈接的話模板會去掉但是應用級什么都會留下，而要什么都不留下的話就要選擇取消鏈接並清理。

2.9 宏（Macros）定義

宏介紹：

宏是一種抽象（Abstraction），它根據一系列預定義的規則替換一定的文本模式，而解釋器或編譯器在遇到宏時會自動進行這一模式替換。（其實就是變量）類似地，zabbix基於宏保存預設文本模式，並且在調用時將其替換為其中的文本宏的命名規范：大寫字母、0-9、下划線，只能大寫字母開頭。zabbix有很多內置宏前面已經提到了，宏可以應用在item keys和descriptions、trigger名稱和表達 式、主機接口IP/DNS及端口、discovery機制的SNMP協議 的相關信息中等。

宏的優先級：

zabbix有全局宏，模板宏，主機宏。
優先級別：
主機宏(checked first)
主機模板定義的宏,如果有多個模板，那么按照模板（ID）越靠前那么宏的優先級越高
全局宏(checked last)

定義全局宏：

管理（Administration）=》一般(General)=》宏（Macrps）（右上角下拉框）

圖片.png

定義模板宏：

圖片.png

圖片.png

#上面兩個全局宏並非單純的引用，我箭頭標注了可以更改，你點擊更改，然后這個宏就非全局宏了，就變成模板自己的宏了，你把這個宏刪除了，就又變回全局宏了，這就是優先級的問題了。

# 不管是全局宏還是模板宏，最后還是要被其他的地方引用才有它的價值，我來舉例，比如我大部分的虛擬機都是2核CPU4G內存，那么他們的cpu負載值一般設置成2啊，然后內存一般剩余多少MB就該觸發器了，觸發器一般定義在模板里面，那么這時候有個4核8G的虛擬機，那么他們的cpu負載就非2就應該是4了，那么你主機如果是自定義的觸發器當然你可以改這個值了，但是一般觸發器都是從模板繼承的，你不能改，只能在模板的觸發器里面改，但是模板里面的觸發器把觸發值改成了4，哪些2核CPU的就又不適用了。宏的價值就體現出來了。觸發器來引用這個宏，如果個別主機有特殊情況，自己設置個宏就OK了。下面讓我們來看例子：

圖片.png

圖片.png

圖片.png

#從上面兩張數據庫中可以看到觸發器引用的宏已經生效了。

主機宏：

比如現在我有一台新機器了是4C8G的，我也繼承了我現在定義的linux客戶端基本監控模板，那么一開始我的觸發器里面的CPU負載肯定是2內存負載肯定是100M，這個可以自行查看一下。那么我要更改了。

圖片.png

#直接在繼承宏那里將這兩個值改變一下。

圖片.png

#然后就變成我們自己主機的宏了，當然主機宏的添加就照着上圖這個來就行了。

圖片.png

 

轉載請注明：靠譜運維 » zabbix配置詳解（三）

喜歡 (3) or分享 (0)
 zabbix環境搭建部署(一)zabbix之Web檢測（四） 

 

https://www.ixdba.net/archives/2017/11/905.htm


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 數據庫查詢方法 MongoDB 數據庫 — 查詢方法 LINQ 數據庫各種查詢方法 數據庫常用查詢方法 Django 數據庫基本查詢方法 數據庫基本查詢方法等 MSSQL數據庫跨表和跨數據庫查詢方法簡(轉) 億級數據量場景下，如何優化數據庫分頁查詢方法？ python django 數據庫查詢方法總結 DjanGo數據庫查詢方法進階
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM