nehecodes/observeX
GitHub: nehecodes/observeX
这是一个集中式可观测性与可靠性平台,用于统一监控指标、日志和追踪,并自动化告警与事件响应。
Stars: 0 | Forks: 0
# observeX — 生产级可观测性平台
由 **Vivian** 和 **Nehemiah** 作为 DevOps 阶段 6 的一部分构建。
## 平台概述
该平台为任何工程团队提供:
- 在单一 Grafana 实例中统一查看指标、日志和链路追踪
- 基于剩余错误预算和消耗速率的 SLO 合规性跟踪
- 从 GitHub Actions 提取的 DORA 指标(部署频率、交付周期、变更失败率、平均恢复时间)
- 结构化的 Slack 告警,路由至 `#DevOps-Alerts` 并包含 Runbook 链接
- 完整的日志到链路追踪下钻分析:指标峰值 → Loki 日志 → Tempo 追踪 → 根本原因
## 技术栈
| 组件 | 版本 | 端口 | 用途 |
|---|---|---|---|
| Prometheus | 2.51.2 | 9090 | 指标抓取与存储 |
| Loki | 2.9.6 | 3100 | 日志聚合 |
| Tempo | 2.4.1 | 3200 | 分布式链路追踪 |
| Grafana | 最新稳定版 | 3000 | 统一可观测性 UI |
| Alertmanager | 0.27.0 | 9093 | 告警路由与去重 |
| Node Exporter | 1.7.0 | 9100 | 系统指标(CPU、内存、磁盘、网络) |
| Blackbox Exporter | 0.24.0 | 9115 | HTTP 探针与 SSL 过期监控 |
| OTel Collector | 0.97.0 | 4317/4318 | 遥测管道(日志 → Loki,链路 → Tempo) |
| Pushgateway | 1.8.0 | 9091 | 从 GitHub Actions 接入 DORA 指标 |
| Demo App | — | 8080 | 已插桩的 Flask 应用(指标 + 链路) |
所有服务作为 **systemd** 管理的原生 Linux 二进制文件运行。无 Docker。
## 一键部署
```
# 1. 将仓库克隆到服务器上的预期路径
git clone https://github.com/nehecodes/observeX.git
# 2. 在部署前设置 Slack webhook URL
sed -i "s/replace this/YOUR_SLACK_WEBHOOK_URL/" /home/admin/observeX/alertmanager/alertmanager.yml
# 3. 运行 Terraform
cd /home/ubuntu/observeX/terraform
terraform init && terraform apply -auto-approve
```
Terraform 调用 `scripts/install.sh`,该脚本将:
1. 为每个服务创建专用的系统用户
2. 下载并安装所有带有版本固定的二进制文件
3. 将仓库中的配置文件复制到系统路径
4. 编写并启用 systemd 单元文件
5. 启动所有服务并验证每个服务的健康状态
### 验证技术栈健康状态
```
systemctl is-active prometheus loki tempo grafana-server alertmanager \
node_exporter blackbox_exporter otelcol pushgateway demo-app
curl http://localhost:9090/-/healthy # Prometheus Server is Healthy.
curl http://localhost:3100/ready # ready
curl http://localhost:3200/ready # ready
# 或运行完整的自动健康检查(检查所有服务及 HTTP 端点):
sudo bash /home/admin/observeX/scripts/verify.sh
```
## 仓库结构
```
observeX/
├── .github/
│ ├── workflows/deploy.yml # CI/CD pipeline + DORA metric push
│ └── PULL_REQUEST_TEMPLATE.md
├── alertmanager/
│ ├── alertmanager.yml # Route tree + inhibition rules
│ └── templates/slack.tmpl # Structured Slack notification template
├── game-day/
│ ├── scenario-1-deployment-failure.md
│ ├── scenario-2-latency-injection.md
│ └── scenario-3-resource-pressure.md
├── grafana/
│ ├── dashboards/
│ │ ├── dora-metrics.json
│ │ ├── slo-error-budget.json
│ │ ├── node-exporter.json
│ │ ├── blackbox-exporter.json
│ │ └── unified-observability.json
│ └── provisioning/
│ ├── dashboards/dashboards.yml
│ └── datasources/datasources.yml
├── loki/
│ └── loki-config.yml
├── otel-collector/
│ └── otel-collector-config.yml
├── prometheus/
│ ├── prometheus.yml
│ └── rules/
│ ├── infrastructure.yml # CPU, memory, disk, host down, SSL
│ ├── slo-burn-rate.yml # Multi-window fast/slow burn rate rules
│ └── cicd.yml # CFR, MTTR, pipeline activity rules
├── runbooks/
│ ├── cpu-high.md
│ ├── memory-high.md
│ ├── disk-high.md
│ ├── server-down.md
│ ├── ssl-cert-expiry.md
│ ├── slo-fast-burn.md
│ ├── slo-slow-burn.md
│ ├── high-cfr.md
│ ├── cfr-threshold-exceeded.md
│ └── mttr-exceeded.md
├── slo/
│ ├── slo-definitions.md
│ └── error-budget-policy.md
├── tempo/
│ └── tempo-config.yml
```
## 仪表板
所有仪表板均以 JSON 形式提供——从不通过 Grafana UI 配置。
| 仪表板 | 文件 | 描述 |
|---|---|---|
| DORA 指标 | `dora-metrics.json` | 部署频率、交付周期、变更失败率、平均恢复时间,带精英/高/中/低分类 |
| SLO 与错误预算 | `slo-error-budget.json` | SLI 仪表、剩余预算、消耗速率时间序列 |
| Node Exporter | `node-exporter.json` | CPU(总计 + 每核)、内存、磁盘 I/O、网络 I/O、平均负载 |
| Blackbox Exporter | `blackbox-exporter.json` | 正常运行时间线、HTTP 响应时间(p50/p90/p99)、SSL 过期倒计时 |
| 统一可观测性 | `unified-observability.json` | 指标 → Loki 日志 → Tempo 追踪下钻分析 |
## 告警规则
所有规则都作为版本控制的 `.yml` 文件存放在 `prometheus/rules/` 中。
### 基础设施告警
| 告警 | 条件 | 持续时间 | 严重性 |
|---|---|---|---|
| CPUWarning | CPU > 80% | 5 分钟 | 警告 |
| CPUCritical | CPU > 90% | 10 分钟 | 严重 |
| MemoryWarning | 内存 > 80% | 5 分钟 | 警告 |
| MemoryCritical | 内存 > 90% | 5 分钟 | 严重 |
| DiskWarning | 磁盘 > 75% | 5 分钟 | 警告 |
| DiskCritical | 磁盘 > 90% | 5 分钟 | 严重 |
| HostDown | 探测失败 | 2 分钟 | 严重 |
| SSLCertExpiryWarning | 证书过期 < 30 天 | 1 小时 | 警告 |
| SSLCertExpiryCritical | 证书过期 < 7 天 | 1 小时 | 严重 |
### SLO 消耗速率告警(多窗口)
| 告警 | 消耗速率 | 窗口 | 严重性 |
|---|---|---|---|
| SLOFastBurn | > 14.4 倍 | 1 小时 + 5 分钟 | 严重 |
| SLOSlowBurn | > 5 倍 | 6 小时 + 30 分钟 | 警告 |
| AvailabilityFastBurn | > 14.4 倍 | 1 小时 | 严重 |
| AvailabilitySlowBurn | > 5 倍 | 6 小时 | 警告 |
| LatencyFastBurn | > 14.4 倍 | 1 小时 | 严重 |
| LatencySlowBurn | > 5 倍 | 6 小时 | 警告 |
### CI/CD 告警
| 告警 | 条件 | 严重性 |
|---|---|---|
| CFRThresholdExceeded | 7 天内变更失败率 > 10% | 严重 |
| CFRThresholdWarning | 7 天内变更失败率 > 5% | 警告 |
| MTTRExceeded | 平均恢复时间 > 60 分钟 | 警告 |
| NoPipelineActivity | 7 天内无部署 | 警告 |
## SLO
定义在 `slo/slo-definitions.md` 中。均使用滚动 30 天窗口。
| SLO | 目标 | 错误预算 |
|---|---|---|
| 可用性 | 99.5% | 216 分钟/月 |
| 延迟 (< 500ms) | 95% 的请求 | 5% 的请求 |
| 错误率 | 99% 成功 | 432 分钟/月 |
| CPU 饱和度 | < 80% p95 | — |
### 错误预算策略
| 预算消耗 | 操作 |
|---|---|
| 0–25% | 正常运营 |
| 25–50% | 下个 Sprint 进行可靠性评审 |
| 50–75% | 功能交付速度降低 20% |
| 75–100% | 功能冻结 |
| 100% | 全面可靠性 Sprint。SLO 满足 7 天前禁止部署 |
## DORA 指标
GitHub Actions 在每次管道运行时将部署指标推送到 Prometheus Pushgateway。
| 指标 | 精英 | 高 | 中 | 低 |
|---|---|---|---|---|
| 部署频率 | 多次/天 | 每天 | 每周 | 每月 |
| 交付周期 | < 1 小时 | < 1 天 | < 1 周 | > 1 周 |
| 变更失败率 | 0–5% | 5–10% | 10–15% | > 15% |
| 平均恢复时间 | < 1 小时 | < 1 天 | < 1 周 | > 1 周 |
需要设置的 GitHub Actions 密钥:`PUSHGATEWAY_URL`, `GRAFANA_URL`
## 告警通知
所有告警都路由到 Slack 的 `#DevOps-Alerts` 频道,结构化载荷包括告警名称、严重性、主机、指标值、Grafana 仪表板链接和 Runbook 链接。
### 抑制规则
- `HostDown` 抑制同一实例的所有 CPU、内存、磁盘和 SLO 告警
- `CPUCritical` 抑制同一实例的 `CPUWarning`
- `MemoryCritical` 抑制同一实例的 `MemoryWarning`
- `SLOFastBurn` 抑制同一 SLO 的 `SLOSlowBurn`
### 所需密钥
在 `alertmanager/alertmanager.yml` 中将 `slack_api_url` 设置为你的 Slack 传入 Webhook URL。
## 运行手册
每个告警规则在 `runbooks/` 中都有对应的 Runbook。每个 Runbook 涵盖:告警含义、可能原因、3 个调查步骤、解决方案、回滚决策和上报路径。
## 混沌工程演练日
`game-day/` 中记录了三个混沌场景:
1. **部署失败** — 触发失败的管道,确认变更失败率告警在 Slack 中触发
2. **延迟注入** — 注入 600ms 延迟,跟随完整的指标 → 日志 → 追踪下钻分析
3. **资源压力** — CPU 压力测试,确认警告在严重之前触发,确认恢复
标签:Alertmanager, API集成, Blackbox Exporter, DORA指标, DORA指标工具, ECS, Flask, GET参数, Grafana, Loki, Node Exporter, OISF, OpenTelemetry, Pushgateway, SLO监控, SLO跟踪, SRE, systemd, Tempo, Terraform, 事件响应平台, 事件响应自动化, 交付时间, 代理支持, 偏差过滤, 分布式追踪, 分布式追踪系统, 变更失败率, 可观测性, 可观测性平台, 可靠性工程, 告警, 告警管理, 告警路由, 基础设施监控, 平均恢复时间, 性能监控, 指标收集, 故障排查, 日志管理, 日志管理工具, 日志聚合, 燃烧率, 特权提升, 监控, 监控平台, 统一仪表板, 自动化部署, 自定义请求头, 追踪分析, 部署频率, 错误预算