shivapreetham/prod-watchdog-env

title: prod-watchdog-env emoji: 🚨 colorFrom: red colorTo: red sdk: docker app_port: 7860 tags: - openenv short_description: 用于 OpenEnv 的生产环境突发事件响应 SRE 环境 # ProdWatchdog — 生产环境突发事件响应环境 一个模拟真实 SRE（站点可靠性工程）值班工作的 OpenEnv 环境。 AI agent 会接收生产环境警报，使用日志和指标调查微服务故障， 通过熔断器控制故障爆炸半径，并从根本上修复问题。 有关更深入的系统概述，请参阅 [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md)。 由 **labwale** 团队为 **Meta × Hugging Face OpenEnv 黑客松，第一轮 (2026)** 构建。 ## 环境描述 ### 动机 生产环境突发事件是工程师执行的 stakes 最高、时间最关键的任务之一。 此环境测试 agent 是否能在不确定性下进行推理，抵抗嘈杂的误导信号， 在真实的服务依赖图谱中追踪因果链，并采取有针对性的纠正措施——所有这些技能 对于现实世界的 AI 可靠性工具都至关重要。 ### 服务依赖图 (11 个服务) ``` nginx-lb ──────────────────────────────────────→ api-gateway redis-cache ────────────────────────────────────→ api-gateway │ ┌─────────────────────────────┤ │ │ auth-service order-service │ / \ postgres-primary payment-service inventory-service │ │ notification-service postgres-replica │ kafka-broker ``` 故障会向下游蔓延：如果 `kafka-broker` 宕机，除非修复根本原因或应用了熔断器， 否则 `order-service` 和 `notification-service` 最终会崩溃。Agent 必须识别出根本原因， 而不能仅仅治标不治本。 ## 动作空间 | `action_type` | 需要指定 `service` | 描述 | | ------------------------ | ------------------ | --------------------------------------------------- | | `query_logs` | 是 | 读取某个服务的近期日志 | | `check_metrics` | 是 | 检查 CPU/内存/错误率/延迟指标 | | `restart_service` | 是 | 重启服务（修复数据库泄漏、内存 OOM、JVM） | | `rollback_deploy` | 是 | 回滚上次部署或从快照恢复 | | `enable_circuit_breaker` | 是 | 隔离服务以阻止级联故障传播 | | `scale_up` | 是 | 增加实例/内存（修复 OOM、CPU 飙升） | | `flush_cache` | 是 | 清空缓存内容（针对缓存问题的部分修复） | | `promote_replica` | 是 | 将数据库副本提升为主库 | | `rebalance_partitions` | 是 | 重新平衡 Kafka 分区 | | `declare_resolved` | 可选 | 结束回合并声明突发事件已解决 | **动作 JSON 格式：** ``` { "action_type": "query_logs", "service": "kafka-broker" } ``` ## 观察空间 | 字段 | 类型 | 描述 | | -------------------- | ---------------- | ------------------------------------------------------- | | `alerts` | `List[str]` | 激活的 PagerDuty 样式警报消息 | | `service_health` | `Dict[str, str]` | 每个服务的健康状态：`healthy` / `degraded` / `down` | | `last_action_result` | `str` | 上一步动作的输出（日志、指标、命令结果） | | `step_count` | `int` | 当前回合已执行的步数 | | `available_actions` | `List[str]` | 当前步骤的有效动作类型 | | `done` | `bool` | 回合是否已结束 | | `reward` | `float` | 单步奖励信号 | ## 任务 ### 任务 1 — 中等：Redis 缓存 OOM — 惊群效应 - **场景：** `redis-cache` 已达到内存 OOM（利用率 100%），导致 100% 的缓存未命中率。每个请求都直接打到数据库。`api-gateway` 显示出高错误率——这是一个下游症状。如果在第 6 步之前未修复，`nginx-lb` 将开始丢弃连接。 - **修复：** `scale_up(redis-cache)` - **最大步数：** 12 - **评分器：** `diagnosed_redis(0.25) + first_inv_correct(0.15) + fix(0.25) + final_state(0.20) + efficiency(0.15)` ### 任务 2 — 简单：nginx-lb 错误配置部署 - **场景：** `nginx-lb` 收到了一个错误的配置部署，将 `worker_connections` 设置为了 4（原为 4096）。`nginx-lb` 丢弃了 99% 的流量。所有后端服务实际上是健康的。关键洞察：当所有服务看似处于降级状态时，应首先检查入口点。 - **修复：** `rollback_deploy(nginx-lb)` - **最大步数：** 10 - **评分器：** `diagnosed_lb(0.30) + first_inv_quality(0.20) + fix(0.30) + final_state(0.20)` ### 任务 3 — 简单：Kafka Broker 分区故障 - **场景：** `kafka-broker` 在经历 47 秒的 JVM GC 停顿后，分区 leader 选举失败。`order-service` 的生产者静默超时（订单在内存中排队）。`notification-service` 的消费者组积压了 84.7 万条未投递消息。误导线索：notification 消费者延迟看似主要原因，order 的内存飙升看似内存泄漏。级联故障：order 在第 8 步崩溃，notification 在第 12 步崩溃。 - **修复：** `restart_service(kafka-broker)` - **最大步数：** 15 - **评分器：** `diagnosed_kafka(0.20) + inv_speed(0.15) + fix(0.30) + final_state(0.20) + efficiency(0.15)` ### 任务 4 — 困难：Postgres 副本 WAL 损坏 - **场景：** `postgres-replica` 在操作系统级别的强制停止后出现损坏的 WAL 段。`inventory-service` 的读取全部失败。`order-service` 无法验证库存可用性。误导线索：`order-service` 的错误率看似根本原因。 - **修复：** `restart_service(postgres-replica)` - **最大步数：** 15 - **评分器：** `diagnosed_replica(0.25) + right_track_first(0.15) + fix(0.30) + final_state(0.20) + efficiency(0.10)` ### 任务 5 — 中等：Auth 服务 JWT 内存泄漏 - **场景：** `auth-service` 的 JWT 验证缓存存在长达 7 天的内存泄漏，导致 GC 停顿和延迟飙升。`api-gateway`、`order-service` 和 `payment-service` 都显示身份验证失败。误导线索：`redis-cache` 延迟看似可疑，`payment-service` 的错误率看似根本原因。 - **修复：** `enable_circuit_breaker(api-gateway)` → `restart_service(auth-service)` - **最大步数：** 20 - **评分器：** `diagnosed_auth(0.25) + circuit_breaker_gw(0.20) + fix(0.30) + final_state(0.15) + efficiency(0.10)` ### 任务 6 — 困难：Postgres 主库磁盘已满 + 脑裂 (3 步修复) - **场景：** `postgres-primary` 故障（磁盘占用 100%）。自动故障转移提升了 `postgres-replica`，但其 `postgresql.conf` 仍处于 `read-only` 模式（脑裂）。`payment-service` 的写入事务因 `ReadOnlyDatabaseException` 失败。需要按顺序进行 3 步修复。误导线索：`auth` 显示 23% 的错误率（JWT 密钥问题），`order` 的内存看似泄漏。级联故障：inventory 在第 7 步降级，order 在第 12 步崩溃，auth 在第 16 步崩溃。 - **修复（有序）：** `enable_circuit_breaker(payment-service)` → `rollback_deploy(postgres-primary)` → `restart_service(payment-service)` - **最大步数：** 25 - **评分器：** `diagnosed_pg(0.20) + circuit_breaker_payment(0.20) + primary_fix(0.25) + secondary_fix(0.15) + final_state(0.10) + efficiency(0.10)` ## 奖励函数 奖励使用**基于势能的塑造**（Ng 1999）在每一步提供密集信号： ``` step_reward = action_reward + γ × Φ(s') − Φ(s) − 0.02 ``` 其中 `Φ(s)` 是服务健康分数的严重性加权平均值。 | 事件 | 奖励 | | --------------------------------------------- | ---------- | | 在根本原因服务上查询日志（首次） | +0.20 | | 在根本原因服务上检查指标 | +0.15 | | 在非根本原因服务上查询/检查指标 | −0.05 | | 重复查询（已查看过的） | 0.00 | | 正确的修复动作 | +0.30–0.60 | | 正确的熔断器 | +0.20–0.30 | | 正确的 `declare_resolved` | +0.50 | | 在健康服务上执行错误动作 | −0.10 | | 单步惩罚（效率） | −0.02 | 回合得分 (0.0–1.0) 在回合结束后由特定任务的评分器计算。 对于需要复杂多步推理的任务，得分上限设为 0.99。 ## 基线得分（专家策略） 专家策略会调查根本原因服务，应用正确的修复顺序，并声明已解决： | 任务 | 难度 | 得分 | 步数 | | ----- | ---------- | ------ | ----- | | task1 | 中等 | 0.9900 | 3 | | task2 | 简单 | 0.9900 | 3 | | task3 | 简单 | 0.9900 | 3 | | task4 | 困难 | 0.9900 | 3 | | task5 | 中等 | 0.9900 | 4 | | task6 | 困难 | 0.9900 | 6 | ## API 端点 | 方法 | 路径 | 描述 | | ------ | ----------- | ------------------------------------------------------------------------ | | POST | `/reset` | 重置环境。请求体：`{"task_id": "task1"}` | | POST | `/step` | 执行动作。请求体：`{"action": {"action_type": ..., "service": ...}}` | | GET | `/state` | 当前状态：episode_id, step_count, observation, reward, done | | GET | `/health` | 健康检查 → `{"status": "healthy"}` | | GET | `/schema` | 动作/观察/状态 JSON schemas | | POST | `/mcp` | MCP JSON-RPC 端点 | | WS | `/ws` | 用于有状态会话的 WebSocket | | GET | `/tasks` | 列出所有 6 个任务及其描述和动作 schema | | POST | `/grader` | 评估已完成的回合。参数：`?task_id=task1` | | POST | `/baseline` | 在所有 6 个任务上运行专家基线，返回得分 | ## 设置与使用 ### 本地开发 ``` git clone cd prod-watchdog-env # 安装依赖 pip install -r server/requirements.txt # 运行服务器 uvicorn server.app:app --host 0.0.0.0 --port 7860 ``` ### Docker ``` cd prod-watchdog-env # 构建 docker build -t prod-watchdog-env . # 运行 docker run -p 7860:7860 prod-watchdog-env ``` ### 运行推理 Agent ``` export API_BASE_URL=https://api.groq.com/openai/v1 export MODEL_NAME=llama-3.3-70b-versatile export HF_TOKEN= # 确保服务器正在运行，然后： python inference.py ``` 推理脚本运行一个带有两层回退机制的 LLM agent： 1. 主要：通过 `API_BASE_URL` 的 LLM（HF 路由或任何兼容 OpenAI 的 API） 2. 次要：Groq（`GROQ_API_KEY` 环境变量），在主要接口触发限流时使用 3. 最终回退：基于确定规则的专家策略（永不崩溃，始终能得分） ### 快速测试 ``` # 健康检查 curl http://localhost:7860/health # 列出任务 curl http://localhost:7860/tasks # 为 task1 重置 curl -X POST http://localhost:7860/reset \ -H "Content-Type: application/json" \ -d '{"task_id": "task1"}' # 采取行动 curl -X POST http://localhost:7860/step \ -H "Content-Type: application/json" \ -d '{"action": {"action_type": "query_logs", "service": "redis-cache"}}' # 在 episode 后获取 grader 分数 curl -X POST "http://localhost:7860/grader?task_id=task1" # 在所有 6 个任务上运行 expert baseline curl -X POST http://localhost:7860/baseline ``` ## 项目结构 ``` prod-watchdog-env/ ├── inference.py # LLM agent (primary + Groq fallback + rule-based fallback) ├── client.py # HTTP client for environment API ├── models.py # Pydantic Action + Observation types ├── openenv.yaml # OpenEnv manifest (6 tasks, action/obs space) ├── pyproject.toml # Package definition ([project.scripts] server = ...) ├── Dockerfile # Single Dockerfile for HF Spaces deployment ├── uv.lock # Locked dependencies └── server/ ├── __init__.py ├── app.py # FastAPI app + /tasks /grader /baseline endpoints ├── environment.py # Core env logic, graders, scenarios, reward shaping └── requirements.txt ``` ## 团队 **团队：** labwale 为 Meta × Hugging Face OpenEnv 黑客松，第一轮（2026 年 3 月 - 4 月）构建。

标签：AIOps, Docker, Hackathon, Hugging Face, Meta, OpenEnv, SRE, Sysdig, 人工智能, 偏差过滤, 安全防御评估, 容错机制, 影响范围控制, 指标监控, 故障诊断, 智能运维, 服务依赖图, 根因分析, 模块化设计, 熔断机制, 生产环境监控, 用户模式Hook绕过, 站点可靠性工程, 系统架构, 级联故障, 自动化修复, 请求拦截, 运维自动化, 逆向工具