prometheus 入门与思考

王强

作为一个engineer,监控报警提起这个估计没人不知道,朗朗上口的有zabbix,nagios等xxx,这些都是硬件中间件层面的,但就是这个层面的现在市面上开源的产品整个体系完美点的其实并不是很多的,国内用的多的是小米开发的open-falcon。随着容器的普及的,迫切的需要能监控容器内部的状况和容器内部服务的信息,prometheus因时而生。

前生今世

传统的ops到dev ops在到sre。服务模式onlyone到微服务化的,单纯的运维解决问题的速度和效率也大打折扣,所以要的从工具话变成产品化,能更快的衡量服务的各项性能指标、或者资源的可用度做出预测,及时通知运维人员也帮开发人员更快的解决问题,最终还是商业价值的体现,减少对公司对客户的损失。

普罗米修斯(prometheus)是google内部监控报警系统的开源版本,是google sre 思想在其内部不断完善的产物,它的存在是为了更快和高效的发现问题,快速的接入速度,简单灵活的配置都很好的解决了这一切。

顺便盗用一张官方大图对其内部有个更好的了解

重要组件有

  • prometheus server (任务抓取指标,进行存储)
  • exporter (暴露指标让任务来抓)
  • pushgateway (push的方式到pushgatway)
  • alertmanager (报警组件)
  • adhoc查询数据

应用实践

启动

下载完prometheus的包后使用一下命令启动的

-- storage.tsdb.path指定数据文件存储的位置

--web.enable-lifecycle支持热更新,就是你修改了这个Prometheus.yaml文件之后,直接执行localhost:9090/-/reload立即生效

prometheus --web.listen-address="0.0.0.0:9093" --storage.tsdb.path="data_global/" --config.file=prometheus.yaml --web.enable-admin-api --web.enable-lifecycle

监控

传统的监控方式分为push和pull方式,prometheus的默认是pull的方式,在监控点暴露号对应的指标url之后,promethus会根据这些url进行拉取

服务器中间件

对于linux服务器或者中间件之类要获取相关的数据的话的就需要配置exporter,prometheus社区和官方开源了很多exporter的类(https://prometheus.io/docs/instrumenting/exporters/),基本涵盖常规使用,满足不了你的需求,如果你有兴趣自行也可以进行开发

  • Databases
  • Hardware related
  • Messaging systems
  • Storage
  • HTTP
  • APIs
  • Logging
  • Other monitoring systems
  • Miscellaneous

这里进行搜集系统硬件信息,使用Node/system metrics exporter (official),下载之后直接启动

prometheus.yml配置抓取设置,指定抓取源的地址

 - job_name: 'linux_poc'
   static_configs:
   - targets: ['192.168.11.75:9100']
     labels:
       node: 'poc'

http://localhost:9093/targets 在prometheus的对应地址可以看到相关target的状态,目标可达的话就是up,不可达的话就是down,之后报警的话就可以通过这个metric来进行,点击图中红圈内的url可以直接看到的对应的所有metrics信息

关于prometheus启动的配置,启动的命令行参数,配置报警规则都可以在url中看到对应的信息

数据搜集完毕,可以直接在graph中测试各种指标数据,这个时候PromQL就发挥作用了,PromQL其实就是prometheus便于数据聚合展示开发的一套ad hoc 查询语言的,你想要查什么找对应函数取你的数据好了

监控来说我们肯定要以更直观的方式去查看这些数据,各种柱状图,折线图,一般都是用grafana,减少了开发工作量,如果有耐心dashbaord你就一个一个的配置的,否则可以去grafana的市场找下有没有自己需要的 https://grafana.com/dashboards

如果机器少的话还好如果机器多的话这样一个一个的配置的着实有点类,可以修改exporter源码启动完成之后自动注册到consul,然后promethues去啦,这就是服务发现的范畴了,下面再讲

微服务

java的世界spring无处不在,尤其是微服务时代更少补了springboot,对于每个springboot的服务健康状况,比如内存cpu基本指标,怎么样监控,方案其实很多很多,不想侵入的话就通过agent的方式,能够容忍侵入就可以通过micrometer,参照官网接入方式,很简单,线上也不是要把所有信息都要暴露出来的,只暴露info,health,和prometheus metrics信息,其他向beans,threas这些敏感信息都可以用spring配置关闭掉、

关于micormeter可以自己写个starter包,便于集成,再启动的时候进行注册到consul或者添加kv值到consul然后通过consul-template生成json文件,prometheus通过服务发现方式就会抓取到这些url,healthcheck信息springboot不是prometheus的metric的格式,可以自己通过参考micrometer底层的实现,进行转换

prometheus收集到信息grafana那边就可以展示了,服务是否可用,healthcheck是通过,运行时间和内存,垃圾回收信息都可以很清晰展示。

扩展性

说到这个扩展性必须提到刚才说到的服务发现,默认服务肯定很多不可能去一个一个的去配置文件配置,这样配置的话肯定是一个不小的工作量,也low的不行,像硬件exporter这种,开源代码并没有扩展入口注册到第三方注册中心,想要的话肯定自己造轮子,但是自己有自己的资产系统,配置的时候进行注册同样可以达到目的,要不就在在consul建个配置项,输入ip和端口,但是应用服务肯定要完全自动化。

当任务多了的话,单点的prometheus肯定尴尬,单个机器再牛逼也会达到瓶颈,prometheus提供了fedefation机制,之前什么活都是老大干,现在找了几个小弟,现在小弟自己干自己的活,活干完了去老大那报道就是了,情况一五一十的反馈,具体小弟任务怎么个分法呢。 那就是hash,每个prometheus server在抓取任务的时候,拿到原始ip地址,进行hash,去取自己需要执行的任务,老大要获取情况就要去小弟那边啦数据了。不建议从每个prometheus server拉所有数据,只取重要的,或者每个prometheus server数据简单的合并,也可以减少主prometheues的压力。

prometheus所有的time series数据都存储在每个prometheus server上的磁盘上,2个小时一个block 压缩存储,为了保证可靠的存储还是写到数据库靠谱,默认提供了一些adapter,比如可以将数据远程存储到influxdb,opentsdb等等

报警

报警是个单独的项目,alertmanager(am),多个am支持gossip集群,这样不会有单点故障

启动

下载alertmanager的包后指定端口和数据存储位置还有alertmanager.yml可以直接启动,一下就是一个gossip集群,启动后可以看到后续有服务加入

./alertmanager --web.listen-address=":19093" --cluster.listen-address="127.0.0.1:12001" --config.file=alertmanager.yml --storage.path=/usr/local/Cellar/Prometheus/2.3.2/alertmanager-0.15.1.darwin-amd64/a1 --log.level=debug

./alertmanager --web.listen-address=":19094" --cluster.listen-address="127.0.0.1:12002" --cluster.peer=127.0.0.1:12001 --storage.path=/usr/local/Cellar/Prometheus/2.3.2/alertmanager-0.15.1.darwin-amd64/a2 --config.file=alertmanager.yml --log.level=debug
http://tech.dianwoda.com/

./alertmanager --web.listen-address=":19095" --cluster.listen-address="127.0.0.1:12003" --cluster.peer=127.0.0.1:12001 --storage.path=/usr/local/Cellar/Prometheus/2.3.2/alertmanager-0.15.1.darwin-amd64/a3 --config.file=alertmanager.yml --log.level=debug

alertmanager.yml

  • 全局的邮箱相关的配置文件
  • 报警模版配置,默认的模版可能不太人性化,可以自己进行定制
  • 报警路由规则,可根据自定义的labal配置路由到不同的人
  • 接受者可以邮箱,webhook,wechat等多种方式的组合。

prometheys.yaml
配置文件中指定报警规则文件的位置

alert.rules
具体规则的话主要是一个报警名称alert,报警触发的promQL表达式,表达式成立持续多长时间报警,annotations就是报警的内容了.

  • 抑制 报警不光是简单的阀值配置,当服务器down掉,上面的所有的应用,中间件肯定都会有影响的,那如何将最准确最有价值的这些信息报出来,通过抑制机制将重复的信息只报警一次,就避免了邮件或者短信轰炸。

  • 静默

想要暂时屏蔽掉特定的一些报警,根据标签就可以使用静默机制,包括屏蔽多长时间,屏蔽那些报警。

不足和未来

集群功还是有待加强的,远程可读可写只支持部分数据库,比如influxdb,但是inflxuxdb本身的集群方案又不开源了,opentasdb只支持写不支持度,存储集中化有thaos方案,虽然还未正式release,不过还是很值得期待,已经pre release了。

报警功能规则配置不支持界面上直接配置,源码只有部分rest api,如果这些都能做到配置化,prometheus就更为完美了,自己如果需要这些功能的话肯定要进行二次开发,希望以后会有支持吧,毕竟1.0到2.0毕竟是一个很大的飞跃。

reference