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