容器|装在笔记本里的私有云环境:监控篇( 二 )


至于日志落地存储,一般的选择有直接使用类似 Prometheus 的 “TSDB”的方案、也有类似 Zabbix 使用的 MySQL / PostgreSQL,有一些希望精细化搜索日志的场景,我们甚至会选择使用 ES 来作为落地方案。当然,如果你的数据量小的话,使用按日期归档的纯文本也不是不可以。
考虑到易于集成的需求,本文选择比较有代表性的 “Prom” 全家桶来搭建基础的监控服务,还不熟悉 Prometheus 的同学可以先看看它的光辉履历。
容器|装在笔记本里的私有云环境:监控篇
文章插图

Prometheus 具备了许多用户喜欢的功能特点:
部署灵活,环境适应性强 。除了易于安装部署外,本身对于运行模式和存储模式也都比较宽容,可以多节点分布式运行,搭配分布式存储水平扩展,也可以多节点单一数据库,也可以单节点单一数据库模式运行。它既可以使用静态配置使用,也可以使用服务发现的方式来动态的汇聚需要监控的项目。
内置查询语言,数据查询灵活,还有大量现成模版,减少了定制软件本身的需要。如果使用 MySQL 或者其他数据库为后端的监控方案,还需要使用类似 ClickHouse 之类的方案进行查询加速,至于使用 ES 进行查询的方案嘛。众所周知,在资源性价比上,这个方案比较没有优势。
支持灵活的数据交互,数据监控依赖客户端和服务端的信息交换,而这个交换无非“推”、“拉”两个模式,多数监控采用拉模式定期收取数据。Prometheus 则支持使用网关插件集成的方式支持按需上报的“主动推送”模式。而且它的交互形式为容易调整的 HTTP 响应,如果需要调整和加工,直接在上报/拉取的过程中添加一个过程进行流程化修改也很方便。
语言支持、软件生态相对完善,Prom 覆盖了主流的开发语言,以及多数庞大用户量的软件的集成接入,能省不少功夫做集成。剩下的时间可以去做其他更有价值的事情。
报警定制灵活、简单,不论是报警规则策略管理,还是集成三方通知模块,在 Prom 里都只需要几行配置。只要你喜欢,也可以将它集成到各种 IM 里,比如 Slack、钉钉、企业微信、飞书、以及企业里自己定制开发的 IM里。或者通过云平台的短信和机器人电话进行告警通知。
可视化容易,这点应该是许多人选择的主要原因之一。不论是使用自带的 HTML 模版,还是搭配 Prom Stack 中的 Grafana 使用,都非常容易,甚至可以搭配公有云更酷炫的可视化产品一起使用。
聊了这么多,让我们使用容器来快速搭建一套适合本系列,或者说小团队使用的监控服务吧。
使用容器搭建一套最简单的监控为了方便读者的使用,我将下面的配置上传到了 GitHub 上,可以自取。和基础篇中一样,为了省事,我在 DHCP 中配置了一条规则,给这台专门用于监控服务的虚拟机起了一个名字“monitor.lab.com”,方便后续调试和访问:
address=/monitor.lab.com/10.11.12.186
主应用及数据库:PrometheusPrometheus 作为监控服务中数据落地存储的数据库,所以我们需要先配置它。
version: "3"
services:prometheus:image: prom/prometheus:v2.30.3container_name: prometheusrestart: alwaysuser: rootvolumes:- ./config:/etc/prometheus- ./data:/prometheus- /etc/localtime:/etc/localtime:ro- /etc/timezone:/etc/timezone:rocommand:- "--config.file=/etc/prometheus/prometheus.yml"- "--storage.tsdb.path=/prometheus"- "--web.console.libraries=/etc/prometheus/console_libraries"- "--web.console.templates=/etc/prometheus/consoles"- "--storage.tsdb.retention.time=1y"# 根据自己需求来考虑是否开启# https://prometheus.io/docs/prometheus/latest/migration/#prometheus-lifecycle- "--web.enable-lifecycle"expose:- 9090ports:- 9090:9090networks:- monitorlogging:driver: "json-file"options:max-size: "1m"networks:monitor:external: true