最近在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就须要考虑以太通道等技术了。。