Prometheus 替代 IBM Tivoli Monitoring（ITM）可行性分析
【摘要】从数据采集、数据存储、HA、监控对象、流程、事件管理、管理部署复杂度、架构等多方面进行比较分析。
【作者】昆仑银行 许中华 陈峰
背景
目前很多大中型企业如国内大银行（中、农、工、建等）、某些股份（招行、光大、中信银行等）、城商行银行用了传统的监控软件如IBM Tivoli Monitoring（ITM）等，但是随着厂商支持力度减弱，同时为了满足国家层面的国产化要求，大家纷纷考虑采用开源Zabbix或Prometheus替代，现就从数据采集、数据存储、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
Tivoli通过 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 :
resolvetimeout: 5 m #处理超时时间，默认为5min_
smtpsmarthost: 'smtp.163.com:25' #邮箱smtp_服务器代理
smtpfrom: 'z zz @ qq .com' #_发送邮箱名称
smtp_authusername: 'z zz @ qq .com' #_邮箱名称
smtp_authpassword: '12345678xxOO' #_邮箱密码或授权码
_#定义模板信息,可以自定义html模板,_发邮件的时候用自己定义的模板内容发
templates:
'template/*.tmpl'
_#定义路由树信息,这个路由可以接收到所有的告警,还可以继续配置路由,比如project: zhidaoAPP(prometheus告警规则中自定义的lable)发给谁,project: baoxian_的发给谁
route:
groupby: [ 'alertname' ] #_报警分组依据
groupwait: 10 s #_最初即第一次等待多久时间发送一组警报的通知
groupinterval: 60 s #_在发送新警报前的等待时间
repeatinterval: 1 h #发送重复警报的周期__对于email配置中，此项不可以设置过低，否则将会由于邮件发送太多频繁，被smtp服务器拒绝_
receiver: 'email' _#发送警报的接收者的名称，以下receivers name_的名称
_#_定义警报接收者信息
receivers:
name: 'email' _#路由中对应的receiver_名称
emailconfigs: #_邮箱配置
to: 'admin@minminmsn.com' _#接收警报的email_配置
_#html: '{{ template "test.html" . }}' #_设定邮箱的内容模板
运维流程比较
Tivoli
事件平台内部故障处理流程贴近操作环境，简洁有效，按需应变，是 ITIL 标准流程的重要辅助性“微流程” 。故障操作流程的实例如下：事件的再分配 ( 给直接责任操作员 ) 、事件的确认、事件转发、事件自动触发升级、事件关闭、处理跟踪日志 , 等等、 Omnibus Object Server 提供主流 ITIL 帮助台接口，以及标准技术接口、工单自动 / 手动派发、工单状态双向同步。
举例说明：
Prometheus
目前无此功能，需要单独定制开发。
综合比较结果
序号 | 开发语言 | 成熟度 | 可扩展性 | 性能 | 容器支持度 | 企业使用情况 | 管理部署复杂度 | 高可用性 | 监控方式 |
Tivoli | Java | 高 | 中 | 中 | 低 | 高 | 高 | 高 | 高 |
Prometheus | Go | 中 | 高 | 高 | 高 | 高 | 低 | 高 | 高 |
结论
从产品成熟度稳定性、企业使用情况及使用惯性方面分析，作为商业软件的Tivoli产品更有优势，受欢迎度更高，运维服务更有保障；从可扩展性、性能、新技术支持程度及管理部署方面分析，Prometheus更具有竞争力，更适合当前监控需求，满足监控产品的要求；二者都具有灵活的高可用部署方案和监控方式。目前Prometheus支持力度比较差，需要有自己的研发团队进行研究。实时路径建议可以先搭建平台实现对Redis、MySQL、kafka等开源软件的监控，后续可以扩展对现有监控对象的监控，两套系统并行运行一段时间后再考虑是否下线Tivoli监控系统。
原标题：Prometheus替代IBM Tivoli Monitoring（ITM）可行性分析（部分代码来源网络）如有任何问题，可点击文末阅读原文，到社区原文下评论交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
相关推荐：
Tivoli集中监控解决方案
http://www.talkwithtrend.com/Document/detail/tid/150349
欢迎关注社区 "监控"技术主题 ，将会不断更新优质资料、文章。地址：
http://www.talkwithtrend.com/Topic/3937
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场