装在笔记本里的私有云环境：监控篇( 二 )

至于日志落地存储，一般的选择有直接使用类似 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