// ARCHIVE Words and Reflections · LONELY HORSE ## 一、项目背景 # 告别裸奔:基于 Prometheus + Alertmanager 的轻量级告警闭环实战 ## 一、项目背景 1. 由于本人在最初搭建博客时并没有加入很多的模块,所以最开始的博客项目处于半盲目的状态,也就是不清楚博客的具体数据,也不清楚大量报错的来源。 2. 对于简单的 `emailmessage` 以及 `smtplib` 的模块有所了解,我就想到如果有一个库可以做到监测我的博客网站,那就让我的博客更加完美。最后在查阅资料后,想要建立一套具备指标暴露,自动告警,邮件发信,自动化部署的监控设施。 ## 二、架构设计 1. 核心的组件为:`Prometheus`,`Grafana`,`Alertmanager`。 2. 以下是我的大致流程图: ```text [ 业务服务 (FastAPI) ] --暴露 /metrics--> [ Prometheus ] <--拉取基础指标-- [ Node Exporter ] | 触发规则评估 v [ Alertmanager ] --按路由规则处理--> [ QQ 邮箱通知 ] | [ Grafana 大盘 ] (数据可视化) ``` * **Prometheus**: 用于抓取到我的博客或者是 Linux 服务器的各项数据,并进行规则监测。 * **Alertmanager**: 作为告警的调度中心,负责收集 Prometheus 的各项报错,并进行分类和处理,合并等等操作,最后再拟发邮件到目的地。 * **Grafana**: 将 Prometheus 收集到的数据可视化。 ## 三、核心的告警规则 1. 最为重要的就是,能否抓取到暴露出来的数据,也就是 `up{job="My-blog"} == 0`。我们需要直接通过验证博客服务的 Prometheus 的状态的在线情况,这是监测博客的前提。 2. 作为一个博客网页,并且是暴露在公网中,所以我们需要监测网页的 404 数据,防止爬虫影响项目的运行和持续,最重要的就是防止遗弃网页占用资源,以及对用户造成困扰和麻烦,使用 `sum(increase(blog_not_found_total[5m])) > 20`,这样就可以观察 5 分钟内的 404 情况增长情况,来判断是否需要修改配置。 ## 四、关于我的踩坑和解决方法 1. 对于 YAML 类型的文档来说,不可以使用 Tab 来缩进,这样会极大影响 YAML 类型程序的运行,必须使用空格严格缩进。 2. 使用 Alertmanager,必须要有发件人的信息,以及 SMTP 密码,但是这些都是极度敏感的隐私信息,不能直接挂载或者写入,这样的安全性非常低,就算是 Git 到私人仓库,也存在暴露风险。所以必须使用 `.env` 和 `envsubst` 的渲染方法,来实现隐私信息的保护和隐藏,并且在 Git 中,使用 `.gitignore` 来取消对于 `.env` 等文件的推送。 3. 在使用 Git Actions 时,会用到 Workflows,但是在实际的部署中,有一个问题困扰了许久,也就是在 Workflows 中的服务器用户姓名指向和我在仓库中设置的用户名称不一样,导致了我的自动化 SSH 登陆连续报错。最终通过检查服务器上的 sshd 日志,排查出了实际的报错问题。 ## 五、CI/CD 的交付和配置 在本地机器修改完配置,只要推送到我的公开仓库中,它就会自动进入我的服务器内,拉取新版本的内容,通过发送 `docker kill -s SIGHUP` 信号,触发核心监控组件的无缝热重载,做到了配置即部署且监控零中断,实现了推送直接到服务更新的一键式操作。 ## 六、总结和下一步规划 1. 对于本次的项目建设和部署,我受益良多。首先就是告警问题,从 pending 到 firing 的过程,这就让我知道了告警不一定要绝对的迅速,因为可以由于一些客观的因素,不可避免的会出现一些情况,比如网络不稳定,导致的网页数据不稳定,有可能会影响 Prometheus 抓取数据,所以需要有告警空窗期,以及对于各种敏感信息的隔离和隐藏,不只有 `.gitignore` 来隐藏信息。 2. 对于我的下一步计划,有一个现实的需求就是,我的服务器性能很一般,所以对于挂载的几个服务,内存就不太够用了,所以我决定使用边缘计算等策略,来实现对于我的服务器的分压,将我的一些项目挂载到本地的 ARM 设备中,并且做好反代,使得本地设备也可以被公网访问。 ← RETURN HOME