F5 可用性研究以及使用 Zabbix 监控 F5
目前部门的各类系统大部分都使用 F5 发布 VIP 提供给用户使用,而之前对 F5 的监控基本没有,本文诣在研究如何通过 SNMP 的方式读取 F5 的各类状态、性能指标,以及什么样的状况需要去告警。
将 F5 的 OID 模版导入到 Zabbix Server 的 /usr/share/snmp/mibs
目录中之后,即可使用 snmpwalk
命令请求 F5 的各项状态。在请求时,大部分值均需要增加 OID 前缀,本文基本只涉及 F5-BIGIP-LOCAL-MIB.txt
这个模版中的内容,所以请求命令的样子如下:
F5 Status
F5 自身状态中需要关注的一个是 CPU、内存使用率,另外就是主备同步状态及故障转移状态。
Failover Status
待补充
ConfigSync Status
待补充
Virtual Server
Virtual Server(VS)是 F5 对外提供访问的入口,是 Local Traffic Manager(LTM)中最外层的对象,一旦 Down 掉了整体服务将不可用。这也是除 F5 本身挂掉以外最严重的问题。
VS Status
VS 状态对应的一个 OID 值是 ltmVsStatusAvailState
,这代表了 VS 可用状态。除此之外,还需要关注 VS 的运营状态,其 OID 值是 ltmVsStatusEnabledState
。
RED(3)
状态应该是我们最需要关注的状况。如果运营状态为 Enabled
且可用状态是 Offline
,即代表此 VS 出现了不可用的状况。
VS Statistics
VS Statistics 中比较需要关注的包括流量、连接数、请求次数。分别对应下面几个 OID 值:
- ltmVirtualServStatClientCurConns
- ltmVirtualServStatTotRequests
- ltmVirtualServStatClientBytesOut
- ltmVirtualServStatClientBytesIn
Pool
Pool 是 VS 的资源池,通过某种负载均衡方式将请求转发至池中的 Member。
Pool Status
资源池也是有状态的,但只有可用状态,无运营状态。相应的,其 OID 值是 ltmPoolStatusAvailState
,池的状态同样列举如下:
ICON | 可用状态 | 可用状态代码 | 描述 |
---|---|---|---|
Avaliable | GREEN(0) | 池成员健康检查正常 | |
Unknown | BLUE(4) | 池成员健康检查状态未知 | |
Offline | RED(3) | 池成员健康检查异常 |
关注资源池的状态意义不太明显,因为就目前的服务发布架构(一个 VS 对应一个 Pool),池状态变为 Offline 时,VS 一定也会变成 Offline。所以基本上只需要关注 Pool 的统计数字即可。
Pool Statistics
Pool Statistics 中的统计数字可以为整体运营数据提供另一个纬度的指标,意义不如 VS Statistics 那样明显,对应的 OID 值如下:
- ltmPoolLbMode
- ltmPoolStatusAvailState
- ltmPoolActiveMemberCnt
- ltmPoolStatServerCurConns
- ltmPoolStatTotRequests
- ltmPoolStatServerBytesOut
- ltmPoolStatServerBytesIn
Node
Node 是 LTM 中最小的粒度,对应的是实际的服务器(Real Server or RS),Node 是 Pool 中的成员,
Node Status
这里讨论的 Node 的状态只包括运营状态 ltmNodeAddrStatusEnabledState
,因为在现存架构中,Node 的可用状态必须结合 Pool 的健康检查方式来看。Node 可用状态也可以单独设定,但不在本文的讨论范围内。
ICON | 运营状态 | 运营状态代码 | 描述 |
---|---|---|---|
黑色 | Disabled | disabled(1) | 已禁用 |
其他 | Enabled | enabled(0) | 已启用 |
Node Statistics
Node 的统计数字仅仅作为单机流量的参考,主要包括下面几个 OID 值:
- ltmNodeAddrStatServerBytesIn
- ltmNodeAddrStatServerBytesOut
- ltmNodeAddrStatServerCurConns
Pool Member Monitor Status
其实相比 Pool Status,更有用的应该是 Pool Member Monitor Status,由于所有的业务均由 F5 统一发布,所以 F5 有着最为敏锐、实时的健康检查机制:一旦发布的服务端口不可用,或延迟较高,则马上将其在 Pool 中排除,以免将用户请求分发到问题节点,从而引起访问超时甚至不可用。
于是,监控 F5 的健康检查状态,比直接使用 Zabbix 的端口检测更加直接。但是,由于 F5 自己会排除问题节点,所以单纯的节点故障不会引起整个服务的异常。此监控产生的告警仅仅需要知会管理员,按照我的监控定义,生成二级告警即可。
ICON | 可用状态 | 可用状态代码 | 描述 |
---|---|---|---|
Availabe | up(4) | 可用 | |
Offline | down (19) | 不可用 | |
Forced Down | forcedDown (20) | 已禁用且不可用 |
Pool Active Member Percentage
目前的服务发布机制,每个 Pool 中的服务器数量均基本大于 3 个,相比单纯的 Member Status,关注 Pool 中活动节点的比例显得更为重要。
服务架构设计之初,即考虑到了其冗余性,极端状况下,允许一半的节点停止服务,于是
Active Member Percentage 可以通过活动节点数量 ltmPoolActiveMemberCnt
除以全部节点数量 ltmPoolMemberCnt
来计算出来。
Alarm Policy
根据上述内容,我制定出 F5 监控的告警策略,分为一、二、三级告警,分别对应 High、Average、Warning 三个内置告警级别:
High
- VS Offline
- Pool Active Member Percentage < 50%
- CPU Usage > 80%
Average
- Pool Member Monitor Status Offline
- Failover Status Failed
- Pool Offline
Warning
- Pool Member Monitor Status Disabled
- ConfigSync Status NotSync
- Node Disabled
- VS Disabled
F5 可用性研究以及使用 Zabbix 监控 F5