Smana/runlore

RunLore 是一个开源的 SRE agent，负责调查任何事故——*发生了什么变化？出了什么问题？* ——并将带有置信度评分的根本原因发布到聊天工具中（Slack、Matrix 等）。它**默认只读**： 它读取你的 cluster、指标、日志和网络流量——它唯一的写入操作是通过经过审查的 PR 提交到 Git。 它的与众不同之处在于：它会学习**你的**平台。每次调查都会在你拥有的 Git 仓库中发起一个 PR；由人类合并，从而构建起关于你的事故和上下文的知识库。下次遇到相同模式时，你会得到即时的答案——无需重新调查。 **学习你的平台 · 单个 Go 二进制文件 · 在你的 cluster 中运行 · 使用你的模型。** **适用人群** —— 希望让其事故知识**可移植且自主托管**（无锁定，你的模型，你的数据），并且宁愿让 agent 说“*我不知道*”也不愿让它瞎猜的 **SRE 和平台团队**。如果你运行 **GitOps**（Flux/Argo CD），它会大放异彩——RunLore 将“*发生了什么变化？*”转化为精确的 Git diff——但 GitOps 并不是必需的：每个数据源都是可插拔的，未设置的数据源只会禁用其对应的工具。 ## 运行效果 一次真实交付到 Slack 的 RunLore 调查：一份结论优先的总结——包含可执行的操作判定（无需操作 / 建议 / 必须 / 无法确定）、带置信度评分的根本原因、告警元数据和复发情况、首要原因的“为什么”、建议的后续步骤、被排除的假设和数据缺口，以及它在你的知识库中发起的 pull request 链接。在使用 Slack **bot token** 时，完整的分析会作为该总结下方的 threaded reply 发送。 ## 工作原理 ``` flowchart LR A["Incident
any alert · event"] -->|"trigger policy
(prod · critical · ns…)"| B subgraph B["🔎 Investigate"] direction TB W["what changed?
deploys · infra · certs · scaling
(GitOps → exact Git diff)"] C["what's wrong?
saturation · network · nodes · deps"] end B --> R["🎯 Root cause
+ confidence + evidence"] R --> D["💬 Chat
(Slack · Matrix…)
findings + suggested fix"] R -. learn .-> K[("📚 GitHub PR
draft entry in your KB")] K -. instant recall .-> B ``` 1. **事件触发** —— 一个可插拔的*源*触发 RunLore：Alertmanager webhook、GitOps 失败事件，或任何你注册的 adapter。 2. **RunLore 调查** —— 它读取你的 cluster、指标、日志和网络流量。 3. **调查结果发送至聊天** —— 按置信度排序的根本原因、证据链和建议的后续步骤，通过可插拔的*通知器*（Slack、Matrix、通用 webhook 等）交付。 4. **在你的 KB repo 中开启一个 PR** —— RunLore 将其发现起草为一条知识库条目。 5. **人类审查并合并** —— 在添加解决上下文后，该 PR 被合并。 该条目会被索引：下次发生相同事故时会得到即时的答案，无需重新调查。 ## 📚 学习循环 ``` flowchart LR R["🔎 Retrieve
recall a past answer"] --> C["🧪 Capture
record what happened"] C --> U["📝 Curate
write the entry (PR)"] U --> P["♻️ Compound
merged note re-indexed"] P --> R classDef s fill:#eef,stroke:#557,stroke-width:1px,color:#113; class R,C,U,P s; ``` 自主的 *alert → RCA → chat* 循环已经非常普遍。不寻常的是：一个**在你拥有的目录中不断积累**的知识库。每一个被合并的 PR 都会成为一条可搜索的条目——它是你控制的 Git 仓库中的纯 markdown，经过 PR 审查，并具有完整的来源。能够持续解决事故的知识会赢得信任；不断失败的知识则会衰退。 → **[学习循环的工作原理](docs/learning-loop.md)** · **[审查与批准知识](docs/reviewing-knowledge.md)** ## 🔌 支持的集成 每个后端都在接口之后可插拔——**接入你运行的工具；未设置的源只会禁用其对应的工具。** GitOps（Flux / Argo CD）构成了*发生了什么变化*的核心骨干；其他所有内容都是可选和附加的。完整的设置详情见**[数据源](docs/data-sources.md)**。 | 类别 | 支持项 | 配置 | |---|---|---| | **GitOps** — *发生了什么变化* | Flux · Argo CD | `gitops.engine` | | **Metrics** | VictoriaMetrics · Prometheus *(PromQL)* | `metrics.url` | | **Logs** | VictoriaLogs *(LogsQL)* | `logs.url` | | **Network flows** | Cilium Hubble · AWS VPC Flow Logs · GCP Firewall Logs | `network.provider` | | **Cloud** | AWS — CloudTrail + EC2 / ASG / EKS | `cloud.provider` | | **Kubernetes** | client-go — pod 状态、事件、controller 日志 | *(in-cluster)* | | **LLM** | Anthropic · Google Gemini · 任何兼容 OpenAI 的工具 *(vLLM、Ollama、OpenRouter 等)* | `model.provider` | | **Triggers** *(sources)* | Alertmanager webhook · GitOps 失败 · PagerDuty webhook *(新)* | `sources.*` | | **Notifiers** | Slack *(bot token: threaded 总结 + 细节; 可选的 👍/👎 反馈按钮为学习循环提供反馈)* · Slack incoming webhook / Matrix / 通用 webhook *(单条结论优先消息)* | `notify.*` | | **Knowledge base** *(git forge)* | GitHub *(App auth)* | `forge.*` | ## ⚡ 一分钟试用 —— 无需 cluster，无需密钥 在接入 cluster 之前，亲自看看流水线的前端。这会在本地运行 `lore serve`，使用无需密钥的演示配置，并向其发送一批模拟的 Alertmanager 告警——不需要 Kubernetes，不需要 LLM，也不需要凭证。你只需要 Go 和 `curl`： ``` hack/demo.sh ``` 它会构建二进制文件，启动服务器，将 [`examples/alertmanager-webhook.json`](examples/alertmanager-webhook.json) POST 到 webhook，并打印决定哪些告警成为事故的**触发策略**： ``` === trigger-policy decisions === msg=incident alert=HarborProbeFailure severity=critical namespace=apps investigate=true reason="matched trigger policy" msg=incident alert=HarborProbeFailure severity=critical namespace=apps investigate=false reason="deduplicated (still-firing)" msg=incident alert=NoisyWarn severity=warning namespace=apps investigate=false reason="filtered by trigger policy" msg=incident alert=StagingCrit severity=critical namespace=apps investigate=false reason="filtered by trigger policy" msg=incident alert=Watchdog severity=critical namespace=apps investigate=false reason="filtered by trigger policy" ``` 这就是一个被接纳的告警（critical + prod），其余的被正确去重、严重性过滤、环境过滤，并被加入忽略列表——这正是控制生产环境中噪音和 LLM 成本的精确门控。演示到此为止：一次完整的调查（根本原因 → 聊天 → PR）需要真实的 cluster、LLM 和知识库，也就是下面的生产环境安装。要在一次性 cluster 上端到端测试每个功能，`hack/e2e-k3d.sh` 会使用 [k3d](https://k3d.io/) 启动一个。 ## 🚀 快速开始（生产环境安装） 准备好让它面对真实的事故了吗？RunLore 作为单个 Go 二进制文件在你的 Kubernetes cluster 中运行，通过 Helm 部署。在安装之前，你需要： - **数据源** —— 至少接入一个源（每个都是可插拔的，未设置的源只会禁用其对应的工具）；作为*发生了什么变化*的锚点，需要运行 Flux 或 Argo CD 的 cluster，以及可选的 Prometheus/VictoriaMetrics、VictoriaLogs、Hubble 以获取更丰富的信号 - **一个 LLM** —— 任何兼容 OpenAI 的 endpoint、Anthropic 或 Gemini（集群内或外部） - **一个知识库仓库** —— 一个私有的 GitHub 仓库 + 一个作用域受限的 GitHub App；这是 RunLore 提交其学到知识的地方 - **一个通知目的地** —— 一个可插拔的通知器：Slack、Matrix、通用的传出 webhook，或者你自定义的工具 将你的凭证接入 Kubernetes `Secret` 中，通过 `values.yaml`（GitOps 引擎、LLM endpoint、KB 仓库、通知）指向它们，然后进行安装： ``` helm install runlore deploy/helm/runlore -n runlore --create-namespace -f values.yaml ``` 然后将某个源指向 RunLore —— 例如，将你的 Alertmanager 告警路由到 `http://runlore.runlore.svc:8080/webhook/alertmanager` —— 它就会立即开始调查。 **→ [完整的入门指南](docs/getting-started.md)** —— KB repo 设置、GitHub App、凭证、完整的 `values.yaml` 参考、数据源和验证步骤。 ## 为什么选择 RunLore | | 它是什么 | RunLore 增加了什么 | |---|---|---| | [**k8sgpt**](https://github.com/k8sgpt-ai/k8sgpt) | 一个 *detector* —— 分析器 + LLM 解释 | 调查循环、跨信号关联、真实的 Git diff 以及学习功能 | | [**HolmesGPT**](https://github.com/HolmesGPT/holmesgpt) | 最强大的开源调查 agent | 依赖于*你*手动维护的 runbook（它不会学习）；RunLore 以“发生了什么变化”为先，并且是自我改进的 | | [**kagent**](https://github.com/kagent-dev/kagent) | 一个通用的集群内 agent *框架* | 一个专注的、有自己见解的 SRE agent（RunLore 以后可以*在* kagent 上运行） | RunLore 是 **GitOps 引擎无关的**（Flux + Argo CD），**指标后端无关的**（VictoriaMetrics + Prometheus），并且具有可插拔的日志和 CNI 无关的网络信号。感知变更的 RCA 并不独特——商业工具（Komodor、Anyshift）也会对变更进行 diff（[先前技术](

标签：EVTX分析, GitOps, Go, Ruby工具, SRE, 偏差过滤, 子域名突变, 故障排查, 日志审计, 自定义请求头, 自托管模型, 运维