事故调查配置参考

可用性：available

范围：现有事故应用

本页记录当前 API 与项目配置，用于事故 Web 应用。其中 PostgreSQL、Redis、唯一账号、项目凭据与 MENDRY_* 设置都不是中立 Agent Harness core 的前提。Local 与 Service Harness composition 会在对应阶段交付后提供独立的已验证配置契约。

事故应用配置分为进程环境与项目运行配置两个 scope。不要随意在两者之间移动 secret。

进程环境

范围	Key 示例	说明
Runtime	`MENDRY_ENVIRONMENT`、`MENDRY_HTTP_ADDR`、`MENDRY_PUBLIC_URL`	Public URL 用于生成 Webhook URL 与通知中的控制台链接；只使用一个绝对 origin
Data	`MENDRY_POSTGRES_URL`、`MENDRY_REDIS_URL`	PostgreSQL 持久保存；Redis 只保存 Session
Encryption	`MENDRY_ENCRYPTION_KEY`	32 字节的 base64；每个数据库保持稳定
Auth	`MENDRY_AUTH_SESSION_TTL`	默认 24 小时
HTTP	`MENDRY_HTTP_CORS_ALLOWED_ORIGIN`、body/time limit	CORS 只接受一个精确 console origin
Logging	`MENDRY_LOG_FORMAT`、`MENDRY_LOG_LEVEL`、`MENDRY_LOG_FILE`	production 默认 JSON；本地文件需由外部轮换
Remediation	`MENDRY_REMEDIATION_CONCURRENCY`、`MENDRY_REMEDIATION_RECOVERY_INTERVAL`、`MENDRY_REMEDIATION_MODEL_TIMEOUT`、存储目录、构建镜像摘要	控制修复任务并发上限、崩溃自动恢复、超时时限与隔离构建镜像

backend/.env.example 是当前完整 key/default 参考。MENDRY_* 是首选命名；迁移期间每个运行时 key 都接受对应的 FIXTHE_* 旧名，二者同时存在时优先使用 MENDRY_*，即使其值显式为空。Shell 中已导出的任一命名空间环境变量优先于 .env。

项目配置

每个项目最多保存一组当前 environment、repository、source、trigger、可选 LLM provider 与 remediation 修复策略。Draft 端点返回不完整状态，组件 PUT 只更新一个组件，不替换其 sibling。

Source kind 为 ssh、cloud 或 mcp；trigger kind 为 signed_webhook 或 custom_rule。保存某种配置并不等于其 runtime connector 已可用，请查看产品状态。

SSH 日志监控

选择 ssh source，使用 host deployment 和 tail mode，再选择 Managed log probe trigger（custom_rule）。该路径监控单个 Linux 普通日志文件，无需已有告警平台即可触发事故。在采集源表单中浏览远端文件，或填写可读文件的绝对路径。

先保存采集源和规则，再安装探针。主机需要 Python 3.6 或更新版本、运行中的 systemd、无交互 sudo -n，并能通过 HTTPS 访问 MENDRY_PUBLIC_URL。手工规则不依赖 LLM，AI 生成规则需要已保存的提供方配置。修改 trigger 或轮换 token 后，点击 Install or update 下发当前配置。

配置步骤、规则语义、验证方法与日志类型边界见 SSH 日志监控。

修复策略配置

项目修复策略（/configuration/remediation）定义了自动化修复的执行边界、预验证容器与代码交付方式：

executionMode：analysis_only（默认仅分析）或 auto_hotfix（Draft PR 模式）。
changePolicy：受限变更边界，包括 allowedPaths（1–64 个路径白名单）、deniedPaths（禁止修改清单与锁文件）、maxChangedFiles（1–30）与 maxChangedLines（1–5,000）。
publication：目标分支、Git 写凭据（gitCredentialSecretId）与仓库平台 API 令牌（scmTokenSecretId）。
validationProfile：可选的本地预验证沙箱（enabled、imageDigest、workingDirectory、requiredCommands）。

增强模式支持一键自动检测：

POST /api/v1/projects/{projectKey}/configuration/auto-hotfix/check 发起仓库检测。
GET /api/v1/projects/{projectKey}/configuration/auto-hotfix/check 轮询就绪状态。
POST /api/v1/projects/{projectKey}/configuration/auto-hotfix/enable 提交生成的验证配置。

详细机制与沙箱说明见自动修复与本地预验证。

签名 Webhook Provider

配置界面提供 Trigger type、Webhook provider 和只读的 Inbound webhook URL。必须先保存 signed webhook，才能生成或轮换 URL。支持的 provider 值为 generic、tencent_cls 和 aws_cloudwatch。

Generic 与腾讯 Trigger 使用 schema version 2，并提供有界 event type 和去重 key：

{
  "schemaVersion": 2,
  "provider": "generic",
  "eventTypes": ["alarm"],
  "deduplicationKey": "title"
}

AWS CloudWatch 会额外显示 SNS Topic ARN 字段。界面通过校验后才允许保存，并写入固定的 alarm_arn 去重契约：

{
  "schemaVersion": 3,
  "provider": "aws_cloudwatch",
  "eventTypes": ["alarm"],
  "deduplicationKey": "alarm_arn",
  "awsCloudWatch": {
    "topicArn": "arn:aws:sns:us-east-1:123456789012:mendry-alarms"
  }
}

Provider 限制、发送端设置、轮换与投递行为见签名 Webhook。

项目通知

每个项目还可以保存多个通知渠道，在 Configuration → Notifications 中独立配置。支持的平台为 telegram、feishu、wecom、slack、discord 和 whatsapp。渠道包含名称、启用状态与加密的平台凭据，不使用共享 Secret ID 配置表单。

部署包含通知功能的 API 前，需要应用迁移 000025_notifications。通知复用 MENDRY_ENCRYPTION_KEY 加密凭据，并使用 MENDRY_PUBLIC_URL 生成事故链接，无需新增消息代理或环境变量。凭据填写、事件条件、投递状态与重试行为见项目通知。

兼容性与 Telemetry

新 Session 使用 mendry_session Cookie。命名迁移期间，API 仍接受旧的 fixthe_session，并在登录或退出设置当前 Cookie 时清除旧 Cookie。OpenTelemetry instrumentation 与数据库连接池指标使用 mendry namespace，包括 mendry/backend、mendry.postgres.* 和 mendry.redis.*。

上述配置组件的 Credential 是独立项目记录，通过 ID 引用；通知凭据随渠道保存。读取响应从不返回明文 value。

核验依据

backend/.env.example
backend/README.md
backend/docs/automatic-hotfix.md
backend/docs/remediation-recovery.md