1 网络指标监控
网络设备(交换机、路由器、防火墙)本身并没有太多的监控方式，常规的是使用snmp，通过oid去采集网络设备的指标，例如，流量或者错包，不过近年来也出现了新的采集方式，例如，telemetry或者gnmi，不过这种方式通常都需要对接接口，并且较新的设备才支持。
prometheus本身提供snmp的exporter，在项目初期人力不足的情况下，可以直接部署prometheus，只要将要采集的设备列表放到配置文件，然后配置好告警规则就可以完成初步的网络指标监控。
2 prometheus
基于prometheus和snmp_exporter的原生架构如下图：
其中，以prometheus为中心，调用snmp_exporter采集数据并存储，然后判断告警规则，如果满足告警规则则调用alertmanager推送告警，alertmanager可以对接邮件、钉钉等功能，并且可以自行开发alerthook对接自有的告警通道。
3 配置文件
3.1 prometheus.yml
prometheus.yml(https://github.com/prometheus/prometheus/blob/df80dc4d3970121f2f76cba79050983ffb3cdbb0/docs/configuration/configuration.md)是prometheus自身启动使用的配置文件，其中主要包含5个部分：
(1)global
全局配置，一般会配置三个值：scrape_interval，抓取间隔，也就是prometheus定时抓取目标的scrape_configs的间隔默认是1分钟；scrape_timeout，抓取超时，当prometheus调用exporter抓取数据超过该值，就认为超时了，也就是抓取数据失败，默认是10s；evaluation_interval，告警规则判断的间隔，当prometheus抓取到数据后，会每隔一段时间查询出满足告警规则的数据，然后推送告警，可以说着是prometheus判断告警的粒度。
(2)alerting
告警推送配置，其中会配置alertmanger的地址，如下配置，当prometheus判断告警后会将满足条件的告警数据推送给1.1.1.1:9999：
alerting:
alertmanagers:
- static_configs:
- targets:
- 1.1.1.1:9999
(3)rule_files
告警规则配置文件，这里可以配置多个，这里使用一个规则文件alert_rules.yml：
rule_files:
- "alert_rules.yml"
(4)scrape_configs
抓取配置，这里就是各种exporter的配置，例如，snmp_exporter：
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'snmp'
file_sd_configs:
- refresh_interval: 1m
files:
- "targets_*.yml"
metrics_path: /snmp
params:
module: [if_mib]
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: localhost:snmp_port # The SNMP exporter's real hostname:port.
这里有两个job，第一个是prometheus本身，也就是采集自身的指标数据，第二个就是snmp_exporter的地址，其中主要关注几个配置：
files：要监控的设备
refresh_interval：多长时间读取设备列表
merics_path：指标路径，调用snmp_exporter会将改配置放到url路由里面
replacement：snmp_exporter的IP和端口
(5)remote_write 远端写的url
3.2 alert_rules.yml 告警规则配置文件
groups:
- name:默认指标告警规则
rules:
- alert:入流量告警
expr: ceil(irate(ifHCInOctets[2m])*8 / ifHighSpeed / 100) /
100 > 90 and ceil(irate(ifHCInOctets[2m])*8 / ifHighSpeed
/ 100) / 100 < 100
for: 30s
labels:
source: snmp
severity: WARNING
annotations:
summary: ""
current: '{{ $value }}'
告警规则文件中最重要的配置是expr，也就是一条promsql语句，prometheus定时执行该语句，如果条件满足并持续for时间，则推送告警，告警中包含annotations字段。
3.3 snmp.yml
snmp.yml中配置的是需要采集哪些指标
3.4 alertmanager.yml(https://github.com/prometheus/alertmanager/blob/b54f77998d4a5c42881d136408e6711de3b602f1/docs/configuration.md)
global:
resolve_timeout: 5m # 如果5分钟之内没有产生同类型的告警，则认为告警已经解决
route:
group_by: [instance, ifDescr, alertname]#按照这三个维度进行分组
group_wait: 30s#当收到告警后，等待多久推送，默认30s，建议5m以内
group_interval: 30s#默认5m，建议大于等于5m
repeat_interval: 60s#如果告警已经推送，则间隔多久再次推送告警，默认4h，建议大于等于3h
receiver: 'web.hook'
receivers:
- name: 'web.hook'
webhook_configs:
- url: 'http://ip:port/prometheus/alerting/webhook'
这里配置了webhook，webhook可以对接自有的告警通道，例如，可以将告警发送给用户自己的IM软件。
4 系统部署
前面所有的程序(snmp_exporter、prometheus、alertmanager)全部可以用github(https://github.com/prometheus/prometheus/releases)上面的二进制进行部署，因此，完成网络指标监控部署只需要干两件事：
(1)下载所有二进制，并编写好对应的配置文件
(2)webhook对接自己的告警推送通道
5 存在的问题
前面原生的snmp_exporter+prometheus+alertmanager+alerthook已经能够满足基本的需求，只需要开发alerthook对接自己的告警推送通道即可，基本没有开发工作量。
但是，这种方式在实际使用过程中存在以下问题：
(1) 需要监控的设备配置在prometheus.yml中，如果需要调整，需要手工修改prometheus.yml，比较麻烦
(2) 告警规则也配置在prometheus中，手工调整容易出错
(3) prometheus是个时序数据库，但是不提供集群解决方案，会出现单点问题
6 配置自动变更
为了能够自动调整要监控的设备以及告警规则，引入了一个配置自动生成的组件：configd。
基本实现逻辑是：
(1) 将一组告警规则构成一个告警规则组，然后将设备与告警规则组关联
(2) configd获取到设备与告警和告警组的关联关系，就可以生成：要监控的设备列表、告警规则列表
(3) 将要监控的设备列表和告警规则列表注入到上面对应的配置文件中即可实现告警配置自动变更
(4) 当变更设备、变更告警规则时，都会根据配置重新生成配置并写入配置文件，然后调用prometheus的热加载功能使配置文件生效
7 高可用
当前prometheus最大的问题就是存储的单点问题：未提供集群解决方案。如果prometheus所在的设备宕机，监控数据就没有了。另外，为了数据采集的容灾，可能会用多个prometheus同时去采集某个交换机，由于交换机的CPU处理能力较弱，而且交换机自身还需要完成路由计算等功能，因此，交换机留给snmp采集的资源很少，如果用多个prometheus同时去采集，可能会造成采集超时，prometheus就会采集不到数据。
因此，我们的目标是：
(1) 指标数据可以容灾，当服务器宕机时还有备份数据可用
(2) 采集端容灾时，一个交换机只能被一个prometheus采集
7.1 远端存储
为了解决第一个问题，需要引入远端存储：prometheus将数据写入一个远端存储的URL，当prometheus所在的服务器宕机时，数据还是可用的。
远端存储的主要目的是可以将数据持久化到后端的高可用存储中，通过在prometheus.yml中配置remote_write的url，当prometheus采集到数据后，可以将数据发送给该URL。对应的进程收到数据后可以将数据存储到后端的高可用存储。现在常用的存储方案有：Clickhouse、InfluxDB、TimescaleDB。
核心代码如下：
7.2 采集容灾
数据实现了高可用，剩下的就是数据采集的高可用。基于上面的两个原因，这里实现了类似负载均衡的数据采集容灾：
(1) 每个交换机只会被一个prometheus采集
(2) 每个机房至少有两个prometheus执行采集操作，多个prometheus拿到要采集的设备列表后，会进行平分。
(3) 当某个prometheus挂掉(自身的进程或者进程所在的服务器)后，采集设备的列表会进行重新分配。
例如，有3个prometheus执行采集操作，那么每个prometheus会采集1/3的设备，当某个prometheus挂掉后，剩下的2个prometheus会平分所有的设备，每个prometheus会采集1/2的设备。
实现方式：
在configd生成prometheus.yml配置文件过程中，会获得所有的设备列表，然后根据可用的prometheus实例数量以及当前prometheus的索引计算出当前prometheus要采集的设备列表。
最终，完整的部署架构如下图所示：
