本文作者：昆仑银行许中华、陈峰

背景

目前很多大中型企业如国内大银行（中、农、工、建等）、某些股份（招行、光大、中信银行等）、城商行银行用了传统的监控软件如Tivoli等，但是随着IBM等公司在中国业务的萎缩，支持力度越来越差，同时为了满足国家层面的国产化要求，大家纷纷考虑采用开源Zabbix或Prometheus替代Tivoli产品，现就从数据采集、数据存储、HA、监控对象、流程、事件管理、管理部署复杂度、架构等几个个方面进行比较分析。

Tivoli和Prometheus产品比较

IBM Tivoli Monitoring 软件的基本体系结构由 Tivoli Enterprise Portal Client 和三个服务器组件（(Tivoli Data Warehouse、Tivoli Enterprise Portal Server 和 Tivoli Enterprise Monitoring Server）组成。

可以扩展基本体系结构以与诸如 IBM Tivoli Netcool/OMNIbus 或 Tivoli Enterprise Console 之类的事件服务器和 Jazz for Service Management 组件及其 IBM Tivoli Monitoring 扩展进行集成。Jazz for Service Management 将开放服务生命周期协作 (OSLC) 社区的用于链接数据和其他共享集成服务（包括仪表板、报告和安全服务）的开放规范组合到一起。以下 IBM Tivoli Monitoring 组件与 Jazz for Service Management 组件配合使用：

Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库，属于轻量级监控产品。从字面上理解，Prometheus由两个部分组成，一个是监控报警系统(Alert Manager)，另一个是自带的时序数据库（TSDB）。

2016年，由Google发起的Linux基金会旗下的原生云基金会（Cloud Native Computing Foundation）将Prometheus纳入其第二大开源项目。Prometheus在开源社区也十分活跃，在GitHub上拥有两万多Star，并且系统每隔一两周就会有一个小版本的更新。

架构比较

Prometheus架构

通过pull方式采集数据不同Exporter和putgateway数据，同时提供Push方式将采集数据push给gateway；Prometheus server通过Push方式将告警推送给AlertManager。

Tivoli 架构

开发语言比较：

Tivoli：

采用JAVA平台，遵循J2EE标准，在系统监测技术中主要采用WMI，对各操作系统、数据库、中间件支持比较全面。

Prometheus:

为了应对高并发和快速迭代的需求，采用Go语言进行开发。Go凭借简洁的语法和优雅的并发，在Java占据业务开发，C占领底层开发的情况下，准确定位中间件开发需求，在当前开源中间件产品中被广泛应用。Golang效率比 Java 高同时也支持跨平台运行。

产品成熟度比较：

Tivoli：

应用于高端客户和运营商级别客户。具备非常成熟的稳定性，具备大规模网络运行案例。

Prometheus:

Prometheus是最近几年才诞生的，虽然功能还在不断迭代更新，但站在巨人的肩膀之上，在架构设计上借鉴了很多老牌监控系统的经验。

系统可扩展性比较

Tivoli：

通过Agent Builder方式定制客户化监控需求，扩展监控功能。支持Shell、Python等。

Prometheus：

Prometheus则定义了一套监控数据规范，并通过各种exporter扩展系统采集能力。灵活简单实现各种数据类型监控需求。支持Python、Golang。

数据存储比较

Tivoli：

Tivoli主要采用关系型数据库保存采集的实时性能数据和历史性能数据，相对而言限制了Tivoli采集的性能。

Prometheus：

而Prometheus自研一套高性能的时序数据库，在V3版本可以达到每秒千万级别的数据存储，通过对接第三方时序数据库扩展历史数据的存储；

容器支持度支持

Tivoli：

由于Tivoli产品出现较早，当时容器还未诞生，因此对容器的支持力度有限。

Prometheus：

Prometheus的动态发现机制，不仅可以支持swarm原生集群，还支持Kubernetes容器集群的监控，是目前容器监控最好解决方案。伴随着容器的发展，Prometheus开始成为主导及容器监控方面的标配，并且在未来可见的时间内被广泛应用。

想要监控 docker 需要用到名为cadvisor 的工具，是谷歌开源的，它用于收集正在运行的容器资源使用和性能信息，需要在要监控的服务器上部署 cadvisor，直接用 docker 去启动就完了 。 容器启动后也是会暴露一个指标接口 （ 默认是8080/metrics ） 下一步就是加入到 Pemetheus 中进行监控 即可。

管理/部署复杂度比较

Tivoli：

ITM监控组件主要包括TEPS，TEMS，TEMA，ISM等组件；Netcool/OMNIbus事件处理平台主要包括OMNIbus Server，Probe，Gateway等组件；JaZZ包括WebSpere Server，TCR, DB2等组件，部署配置相对复杂。Tivoli需要安装基于java的客户端管理组件，管理相对复杂。

Prometheus：

Prometheus只有一个核心server组件，一条命令便可以启动，采集端接收满足数据格式的监控数据，部署相对简单。Prometheus通过脚本/配置文件方式完成配置。

高可用性比较

Tivoli：

通过“架构 - Tivoli”可知作为非常成熟的监控产品，Tivoli可以根据不同监控场景，不同的监控规模，设计适合监控需求的高可用部署架构。

Prometheus：

由Improbable发布了开源的项目 Thanos项目 ，它可以将现有的Prometheus部署无缝转换成一个统一的监控系统，配套一个不受限制的历史数据存储，架构如下：

监控方式对比– 主机

Tivoli：

Tivoli产品族提供代理程序和远程监控两种监控方式。根据主机类型、中间件类型、数据库类型选择相应的监控代理程序部署在监控对象所在的服务器上，Tivoli监控代理提供丰富的监控指标，精细的监控颗粒度，满足95%以上监控需求。

Prometheus：

Prometheus主要通过不同类型的exporter满足各种监控需求，exporter具有轻量级，按需定制，高灵活性，部署简单等特性。成熟产品有 N ode_exporter。

监控方式对比-定制开发

Tivoli

T ivoli通过 UA实现接口扩展及无代理方式

• UA 支持 (http, file, ODBC, post, script, SNMP, socket, API 等 ), 可为机房环境、安保等特定系统提供扩展。

Prometheus提供了 script_exporter 执行脚本实现定制化开发 ,它会收集所要监控脚本的执行结果和执行花费的时间。

监控方式对比- 网络可达性

Tivoli

Tivoli提供了专用产品ISM（全称Internetservice management），可以提供界面进行ICMPpin监控。**

Prometheus

提供blackbox_exporter 可以实时监控Web服务的状态，支持http和https，它还可以采集TCP、DNS、ICMP、SMTP相关的数据。

举例说一下利用prometheus的blackbox_exporter进行ICMP测试

· 相关代码块添加到Prometheus 配置文件内

· 对应blackbox.yml文件的 icmp 模块如下

• job_name: 'blackbox00_ping_idc_ip'

scrape_interval: 10s

metrics_path: /probe

params:

module: [ icmp ] #ping

static_configs:

• targets: [ '1x.xx.xx.xx' ]

labels:

group: 'xxnginx 虚拟 IP'

relabel_configs:

• source_labels: [ address ]

regex: ( .* )( :80 ) ?

target_label: __param_target

replacement: ${1}

• source_labels: [ __param_target ]

regex: ( .* )

target_label: ping

replacement: ${1}

• source_labels: []

regex: .*

target_label: address

replacement: 1x.xxx.xx.xx:9115

运行后的icmp截图如下：

监控方式对比- 日志

Tivoli ：

有现成的日志监控agent，只要简单配置即可实现日志文件（包括Linux、Unix、Windows平台）监控。

Prometheus

没有现成的日志监控组件，建议单独搭建大数据平台进行日志分析。

监控方式对比-数据库、中间件

Tivoli

有成熟的Agent for DB2 ，Agent for Oracle, Agent For Sybase, Agent for MQ 。

Prometheus

有监控Mysql、Oracle、Mysql、PostgresSQL、Redis、MQ的现成expo rter ，但是没有现成的DB2和Sybase的恶性porter，

需要定制开发。

监控方式对比- 网络设备

Tivoli：

Tivoli产品可以实时监控网络状况，网络拓扑自动发现（3层基于IP的拓扑、2层物理连接拓扑、MPLS 拓扑、以设备型号为粒度的发现技术代理），关联和管理事件及简单网络管理协议(SNMP)的中断，监视网络的健康状态及采集网络性能数据，提供完善的网络监控方案，实现集中化、远程的网络设备、线路的管理和维护,产品包括ITNM。 Tivoli Network Manger 通过基于拓扑的根源故障分析 RCA 引擎，自动定位根源故障事件，消除事件风暴危害。

Prometheus：

Snmp_exporter可以用于监控网络设备，没有网络发现能力，管理界面主要依赖命令行，效率较低。不提供Syslog、Snamp Trap日志处理模块，可以搭建大数据分析平台进行syslog、Snamp trap日志分析。

prometheus 监控交换机流量

1. 手动验证能否获取交换机数据

用prometheus 监控交换机流量首先需要确定安装prometheus 的机器已经被交换机允许获取他的数据。命令如下： 以交换机版本为v2c为例：

snmpwalk -v 2c 10.0.1.52 -c public ifDescr 获取网卡信息

其中-v是指版本（SNMP主要有SNMPv1、SNMPV2c、SNMPv3几种最常用的版本。）,-c 是指密钥（Community：团体名，用于Agent与NMS之间的认证，由交换机提供）。 如果返回数据，则说明可以进行下一步通过prometheus获取数据了，数据如下：

2. 安装 snmp 插件

wget https://github.com/prometheus/snmp_exporter/releases/download/v0.13.0/snmp_exporter-0.13.0.linux-amd64.tar.gz

解压并打开snmp.yml 根据需要进行修改

tar -xzvf snmp_exporter-0.13.0.linux-amd64.tar.gz

cd snmp_exporter-0.13.0.linux-amd64/

vim snmp.yml

由于生产上的交换机，一般都有认证才能对交换机进行访问，所以需要交换机提供Community以及版本号，这两个需要在snmp.yml进行配置。 修改如下：

找到if_mib模块，如下图：

找到if_mib模块最下面，加入 version（以版本为v2c为例子），以及认证community，如下图：

根据我的经验，可能会遇到这样一个问题，你要监控的所有交换机的认证community可能不一样，而我们不能在配置文件里在community后面加好几个认证码，那么解决办法是：

1、将 if_mib 模块的所有配置再复制一遍，改一下模块的名字，如改成 if_mib2, 相应的改一下 version 和 community 即可。
2、启动snmp_exporter。
3、./snmp_exporter --config.file=snmp.yml。
4、验证snmp监控数据。
5、 curl 'http:// 安装 snmp_exporter 的机器的 IP:9116/snmp?target= 安装 snmp_exporter 的机器的 IP'。

3. 配置prometheus的配置文件

添加关于snmp的配置，如下：

其中红线化掉的是安装snmp_exporter的机器的ip，而9116，是snmp_exporter的端口。如果出现多个community的情况（如上面所说），只需要再加一个job即可，如下：

到目前为止，prometheus通过 snmp_exporter 抓取交换机流量数据已完成。

监控方式对比– 应用程序

Tivoli：

IBM APM通过非侵入式的用户性能监控，提供预测性分析、专家级事务追踪，帮助减少宕机、提供性能并优化利用率。业务指标监控通过定制实现。

Prometheus：

通过JMX_exporter监控基于JVM 的应用程序。业务指标也只能靠定制。

监控方式对比– 硬件监控

Tivoli

Tivoli没有现成的硬件监控产品。

Prometheus

Prometheus提供 ipmi_exporter 、 zhmc-prometheus-exporter 、Dell Hardware 、 IoT Edison exporter 。

事件管理比较

Tivoli

自动化压缩、信息丰富、管理处理、复合过滤、分角色呈现、自动化通知， Omnibus 采用内存数据库技术，处理效率很高，从容应对海量告警，提供界面进行配置。

跨功能域的部署对于 Omnibus 是常用方式，而且根据事件量大小可以分层扩展配置。

Prometheus

有专门的告警组件Alertmanager,可以实现告警抑制、分组、收敛、静默（维护期）、告警转发（邮件、短信、微信、SNMPTrap等），只能通过编辑脚本yml方式进行配置。

举例说明：

Tivoli配置告警策略：

1、Prometheus告警策略配置

指定服务监听alertmanager端口及报警规则目录

vim /usr/ local /prometheus/prometheus.yml

#__配置__alertmanager__信息

alerting:

alertmanagers:

• static_configs:
• targets: [ 'localhost:9093' ]

#__配置告警规则目录

rule_files:

• /usr/ local /prometheus/rules/*.rules

2、Rules策略配置

创建一个服务down的报警规则

vim /usr/ local /prometheus/rules/service_down.rules

groups:

• name: ServiceStatus #__规则组名称__

rules:

• alert: ServiceStatusAlert #__单个规则的名称

expr: up == 0 #__匹配规则__, up==0

for : 10 s #__持续时间

labels: #__标签

project: zhidaoAPP #__自定义__lables

annotations: #__告警正文

summary: "Instance {{ $labels.instance }} down"

description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minutes."

3、Alertmanager配置

vim /usr/local/alertmanager/alertmanager.yml

#__全局配置__,__比如配置发件人

global :

resolve_timeout: 5 m #__处理超时时间，默认为__5min

smtp_smarthost: 'smtp.163.com:25' #__邮箱__smtp__服务器代理

smtp_from: 'z zz @ qq .com' #__发送邮箱名称

smtp_auth_username: 'z zz @ qq .com' #__邮箱名称

smtp_auth_password: '12345678xxOO' #__邮箱密码或授权码

#__定义模板信息__,__可以自定义__html__模板__,__发邮件的时候用自己定义的模板内容发

templates:

• 'template/*.tmpl'

#__定义路由树信息__,__这个路由可以接收到所有的告警__,__还可以继续配置路由__,__比如__project: zhidaoAPP(prometheus__告警规则中自定义的__lable)__发给谁__,project: baoxian__的发给谁

route:

group_by: [ 'alertname' ] #__报警分组依据

group_wait: 10 s #__最初即第一次等待多久时间发送一组警报的通知

group_interval: 60 s #__在发送新警报前的等待时间

repeat_interval: 1 h #__发送重复警报的周期____对于__email__配置中，此项不可以设置过低，否则将会由于邮件发送太多频繁，被__smtp__服务器拒绝

receiver: 'email' #__发送警报的接收者的名称，以下__receivers name__的名称

#__定义警报接收者信息

receivers:

• name: 'email' #__路由中对应的__receiver__名称

email_configs: #__邮箱配置

• to: 'admin@minminmsn.com' #__接收警报的__email__配置

  #html: '{{ template "test.html" . }}' #__设定邮箱的内容模板

运维流程比较

Tivoli

事件平台内部故障处理流程贴近操作环境，简洁有效，按需应变，是 ITIL 标准流程的重要辅助性“微流程” 。故障操作流程的实例如下：事件的再分配 ( 给直接责任操作员 ) 、事件的确认、事件转发、事件自动触发升级、事件关闭、处理跟踪日志 , 等等、 Omnibus Object Server 提供主流 ITIL 帮助台接口，以及标准技术接口、工单自动 / 手动派发、工单状态双向同步。

举例说明：

Prometheus目前无此功能，需要单独定制开发。

综合比较结果

结论

从产品成熟度稳定性、企业使用情况及使用惯性方面分析，作为商业软件的Tivoli产品更有优势，受欢迎度更高，运维服务更有保障；从可扩展性、性能、新技术支持程度及管理部署方面分析，Prometheus更具有竞争力，更适合当前监控需求，满足监控产品的要求；二者都具有灵活的高可用部署方案和监控方式。目前Prometheus支持力度比较差，需要有自己的研发团队进行研究。实时路径建议可以先搭建平台实现对Redis、mysql、kafka等开源软件的监控，后续可以扩展对现有监控对象的监控，两套系统并行运行一段时间后再考虑是否下线Tivoli监控系统。