最近在review一些基礎監控項，發現有部分基礎的監控缺失，好比disk usage,network card相關的監控。
由於機器的配置不一樣，不太好配置一個統一的模板，不過在新版本的zabbix中有個功能Low-level discovery，能夠根據主機的配置自動生成須要的監控，只須要傳入宏變量便可。
好比監控每一個網卡的出流量net.if.out[{#IFNAME}]，監控網卡的speed os.get[NetworkCardSpeed,{#IFNAME}]
有些狀況下網卡會從1000M變成100M，所以添加了相關的trigger:
{os.get[NetworkCardSpeed,{#IFNAME}].last(0)}<1000
這裏有兩個細節的問題：
1）新版本的network card speed的item是os.get[NetworkCardSpeed,xxxx],在網卡的speed爲unknown時，其結果是0。
zabbix_get -s 127.0.0.1 -k 'os.get[NetworkCardSpeed,eth2]'
0
爲了排除這種狀況，更改trigger爲以下規則：
{os.get[NetworkCardSpeed,{#IFNAME}].last(0)}<1000 &
{os.get[NetworkCardSpeed,{#IFNAME}].last(0)}#0
能夠經過以下sql查看speed 爲100M的機器：
select
distinct(a.host),c.ip,b.name,b.lastvalue from hosts a,items b,
interface c where a.hostid=c.hostid and a.hostid=b.hostid and
b.key_ like 'os.get[NetworkCardSpeed%' and b.lastvalue='1000';
2）關於bonding
因爲datanode的shuffle階段須要大量的網絡操做，很容易出現網卡瓶頸，所以datanode通常會作網卡的bonding，經常使用的模式是6,根據原理來看outgoing和incoming的流量大體應該是相同的，但實際狀況下看到，outgoing的流量通常是比較平均，而incoming的流量相差很大,下面是一個sar的結果：
14時24分28秒 IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/s rxmcst/s
14時24分29秒 eth0 6.93 28139.60 473.27 41837599.01 0.00 0.00 6.93
14時24分29秒 eth1 29448.51 31732.67 1929669.31 47286517.82 0.00 0.00 6.93
14時24分29秒 bond0 29455.45 59872.28 1930142.57 89124116.83 0.00 0.00 13.86
另外，若是一個網卡由1000M變爲100M也不會出現短板效應(以前一直覺得會出現短板效應)，而是根據speed的狀況來作流量分發，speed大的流量大，speed小的流量小。
另外注意bonding配置中miimon參數的含義，它是檢測的server到switch的直連鏈路問題，若是switch的上層鏈路出問題是不會work的。交換機鏈路的ha就須要考慮以太通道等技術了。。