← PROJECT INDEX
在建2026CASE 04

OpsFusion Lab

为个人实验室和云主机建立可观测性与故障演练闭环:采集指标、展示状态、定位根因、恢复服务、记录复盘。

ROLE / 职责
方案、环境搭建、故障演练与 Runbook
FOCUS / 重点
已完成基础采集与 Nginx / Prometheus 验证;看板、告警和完整演练仍在建设。
  • Prometheus
  • node_exporter
  • Nginx
  • Docker
  • Runbook
01

已验证

Nginx 停止与恢复,使用 systemd 状态、端口监听和 HTTP 响应三项交叉确认。

02

已接入

node_exporter 与 Prometheus,观察 target 状态和 15 秒采集。

03

正在建设

Grafana、Alertmanager、容器停止、Nginx 502、DNS、端口和磁盘阈值演练。

  1. 01主机与 Nginx
  2. 02node_exporter
  3. 03Prometheus 15 秒采集
  4. 04看板 / 告警(在建)
  5. 05故障演练与 Runbook(在建)
目标结构示意:它不是已完成 Grafana 或告警平台的截图。
01

背景与约束

这是个人实验室与云主机上的可观测性、故障演练和 Runbook 项目,不宣称企业级高可用或完整告警平台。

02

我的职责

负责方案、环境搭建、最小验证、故障演练设计与后续 Runbook。

每一步先留下可观察结果,再推进下一步,而不是先画完整平台蓝图。

03

当前实现

已验证 Nginx 停止与恢复,并交叉检查 systemd 状态、端口监听和 HTTP 响应。

已接入 node_exporter 与 Prometheus,观察 target 状态和 15 秒采集周期。

04

下一步与验证

继续完成 Grafana、Alertmanager 和容器停止、Nginx 502、DNS、端口与磁盘阈值演练。

每类故障都会保留定位过程、恢复步骤和可复现 Runbook,而不只展示一张看板。

05

限制与反思

当前只完成基础采集与服务验证,Grafana、Alertmanager、完整告警链路仍在建设。

单个状态指标不能证明业务整体可用,因此需要多层证据与恢复演练。

故障记录 / O-04

一次 Nginx 停止与恢复的三项交叉验证

  1. 01

    观察

    主动停止后,不能仅看服务状态或单个页面结果就判断故障范围。

  2. 02

    检查对象

    同时检查 systemd 状态、80 端口监听和 HTTP 响应。

  3. 03

    决定性证据

    三处状态在停止与恢复前后保持一致,说明检查链路不是单点误判。

  4. 04

    回归

    恢复服务后再次交叉检查,并将步骤整理为后续故障演练的 Runbook 基线。

边界:当前项目仍在建设;图示与文案不把计划中的 Grafana、Alertmanager 或告警闭环写成已上线事实。