// ARCHIVE Words and Reflections · LONELY HORSE ## 一、为什么要修改我的博客 # FastAPI + Docker + Prometheus + Grafana：我的第一次完整可观测性实战 ## 一、为什么要修改我的博客 1. 我最开始的博客后端使用的是 Flask，它已经能够实现文章、笔记和项目文件的展示功能。但随着自己逐步学习 FastAPI，我开始尝试对博客后端进行重构。一方面，FastAPI 在接口组织、异步支持和工程化结构上更适合我后续继续扩展；另一方面，它在当下的 Python Web 开发与运维开发场景中也更加主流。 2. 除了框架重构之外，我还希望这个博客不只是“能跑起来”，而是能够被观察、被分析。我想知道博客有没有人在访问、哪些页面更受欢迎、文章阅读量和下载量如何、是否存在大量 404 请求。因此，我决定在 FastAPI 的基础上，为博客接入 Prometheus 与 Grafana，完成一次真正意义上的可观测性实践。 ## 二、使用的技术栈 这次实践中，我主要使用了 `FastAPI`、`Docker Compose`、`Prometheus`、`Grafana`，以及 `GitHub Actions` 等工具。 * **FastAPI**: 负责后端服务； * **Docker Compose**: 负责容器化部署； * **Prometheus**: 负责抓取监控指标； * **Grafana**: 用于可视化展示； * **GitHub Actions**: 则用于后续的自动化构建与发布。 ## 三、具体监测的数据 * 博客服务的存活状态； * HTTP 的请求量； * 各个网页的访问量； * 项目下载量； * 文章阅读量。 ## 四、如何实现监测 根据官方文档，再自己自定义一下格式，以 `blog_index_views_total` 为例，实现数据的第一步：**采集**。 1. 在同一容器网络下，使用 Prometheus 抓取到采集的数据； 2. 将项目的容器名字写入配置 Target 中； 3. 最后通过 Grafana 的仪表盘呈现出具体的图形观测。 ## 五、关于我的“踩坑”记录 1. 因为我的 CI/CD 流程原因，需要我推送到我的私人仓库，但是我的代码是存在于我的本地的。在 VS Code 中修改后，忘记了保存，导致我推送的项目不完整，版本依旧停留在上一个版本中，最终导致我的服务运作出现问题。我为此消耗了不少的时间。这个问题让我意识到：在排障时，最基础的“代码是否真的更新”必须优先确认。 2. 在我将我的数据注入 Grafana 时，发现不管无论如何大屏都显示 `No Data`。最后在我几次检查下，发现是我在写 Prometheus 时的 URL，没有写 `http://`。Grafana 并不会自己解析 URL，这就导致它查询不到我的 URL 的存在，也就是为什么没有数据流入的原因。 3. **Docker 内部网络问题**：由于我的服务容器化，包括 Nginx 在内的服务几乎都在我的 Docker 容器内，然后我使用 Nginx 创建了一个容器网络环境，我的项目全在这里面实现网络。所以可谓是牵一发而动全身，它的地位十分重要，不得有失。 4. 在使用 Tailscale 搭建私人内网集群时，需要重点注意 **DNS 被污染**的问题。因为对于个人而言，集群内不存在一个单独的网络设备来提供网络服务。这也就导致如果 DNS 被污染，只能在内网中获取网络，进而无法连接网络。这个问题，导致了我的镜像源更新问题、更新项目问题等等一系列连锁问题。 ## 六、总结和收获 这次实践最终让我完成了一个从后端重构、监控埋点、容器部署到可视化展示的完整闭环。相比最开始只会使用 Flask 搭建一个“能运行的博客”，现在我已经能够使用 FastAPI 重构后端、通过 Prometheus 采集通用指标与业务指标，并在 Grafana 中完成可视化展示。 更重要的是，这次实践让我真正理解了“可观测性”不是简单的出图，而是一条包含代码埋点、网络配置、容器部署、数据抓取和查询表达式的完整链路。中间的许多问题并不是出在单个工具上，而是出在多个环节的联动上。对我来说，这比单纯学会某个框架更有价值。 ← RETURN HOME