OpenSRE 60 集成如何运转新手看懂目录、注册表与选择器的完整指南【免费下载链接】opensreBuild your own AI SRE agents. The open source toolkit for the AI era.项目地址: https://gitcode.com/GitHub_Trending/op/opensreOpenSRE是一个构建 AI SRE Agent 的开源工具包The open source toolkit for the AI era它能连接 Grafana、Datadog、AWS、Sentry、Slack 等 60 多个可观测性与协作平台。这么多集成是如何被统一管理、按需启用的本文带你拆解 integrations/ 模块下的三大核心组件目录Catalog、注册表Registry与选择器Selectors的设计思路无需阅读大量代码即可理解其运转逻辑。为什么需要一套集成管理框架当你只连接一个监控系统时直接写死配置就够了。但 OpenSRE 要同时支持 60 平台而且每个平台还可能有多个实例比如生产环境和测试环境各有一个 Grafana。这带来三个问题怎么知道哪些集成可用—— 需要一个总目录怎么把零散配置变成统一格式—— 需要一个分类/解析流程怎么从多个实例里挑出对的那一个—— 需要一个选择器OpenSRE 的答案就是下面这套三层结构分别对应 integrations/catalog.py、integrations/registry.py 和 integrations/selectors.py。第一层注册表Registry——所有集成的户口本打开 integrations/registry.py你会看到一个叫IntegrationSpec的数据结构它是每个集成的户口卡记录了字段含义通俗版service集成服务名如grafana、awsaliases用户可能输入的别名如postgres→postgresql、k8s→kubernetesfamily_members家族成员如grafana_local归入grafana家族has_verifier是否支持连接验证setup_order/verify_order配置向导与验证的先后顺序注册表还有两个巧妙的设计1. 所有查询表都是原地更新。文件底部的INTEGRATION_SPECS_BY_SERVICE、SUPPORTED_VERIFY_SERVICES等查找表在插件注册后会就地修改而不是整体替换见 _rebuild_registry。这样其他模块已经引用的表对象不会失效避免插件注册了但查不到的隐蔽 bug。2. 插件不能抢注内置名称。第三方包可以通过 register_integration_spec 注册自己的集成但如果它想占用grafana、k8s这类已被内置集成含别名认领的键注册会直接报错。这防止了插件悄悄劫持一个官方集成的配置与验证流程。第二层目录Catalog——把零散配置翻译成统一格式集成的凭证有两个来源本地存储文件~/.opensre/integrations.json由 integrations/store.py 管理和环境变量。integrations/catalog.py 是对外暴露的门面把两条来源合并、分类后交给各功能使用。核心流程由 resolve_effective_integrations 串起四步读取从本地存储与环境变量各自加载集成记录合并merge_local_integrations 按服务名去重本地存储的条目优先分类classify_integrations 把原始凭证交给各服务的分类器输出统一的结构化配置解析生成生效集成effective integrations视图并标注每条配置来自local env还是local store。几个值得注意的细节多实例统一输出分类结果里resolved[service]始终是默认第一个实例的扁平配置保证老代码不受影响当存在多个实例时会额外挂一个_all_{service}_instances键保存全部实例见 selectors.py 顶部注释。健康检查不骗人configured_integration_health 会区分存在和可用——比如一个 Hosted MCP 记录只填了 URL 没填 API Token就会被标记为incomplete欢迎横幅不会让你误以为它已连通。严格模型兜底integrations/effective_models.py 用 Pydantic 声明了每个内置集成的字段拼写错误能在验证阶段被发现同时extraallow保证仓库外注册的插件集成不会被丢弃。第三层选择器Selectors——从多个实例中精准取数假设你配置了两个 Grafana 实例prod标签env: prod和staging。当 Agent 调查生产事故时应该查哪个integrations/selectors.py 给出了干净的答案核心是 select_instance按名字找 → 按标签找 → 找不到默认就报错绝不悄悄回退到默认实例。这个宁缺毋滥的设计很关键如果用户明确指定了prod却查不到悄悄改用staging会让 Agent 拿错误环境的数据下结论。配套的辅助函数也很克制get_instances列出某服务的全部实例单实例时会自动合成一个默认项让调用方无需区分单/多实例两种情况get_instances_by_tag按标签批量筛选适合查所有env: prod实例这类场景所有函数永不修改入参查不到就返回None或[]。一次完整查询的数据流回顾把三层串起来Agent 每次使用某个集成时的路径是注册表回答这个服务名或别名对应哪个集成目录回答它当前的生效配置是什么、来自哪里、有哪些实例选择器回答具体该用哪个实例的凭证。各平台的真实 API 调用逻辑则分散在 integrations/ 下的子目录中例如 integrations/grafana/、integrations/aws/、integrations/github/它们都消费上面三层产出的统一配置。文件导航想深入阅读从哪里开始想了解看这里集成元数据与插件注册机制integrations/registry.py配置合并、分类与健康检查integrations/catalog.py分类与解析的具体实现较长integrations/_catalog_impl.py多实例选择逻辑integrations/selectors.py本地凭证存储格式v2 多实例结构integrations/store.py生效集成的严格数据模型integrations/effective_models.py各集成的环境变量清单docs/configuration/environment-variables.mdx添加新集成/工具的官方指引docs/adding-tools-and-integrations.md小结这套设计教我们什么元数据集中逻辑分散注册表只描述有哪些集成、它们叫什么、什么顺序真正的连接逻辑留在各自子模块新增集成时改动面最小单一事实来源~/.opensre/integrations.json与环境变量合并后有且只有一个生效视图欢迎横幅、健康检查、工具调用看到的永远是同一份状态向后兼容是显式设计扁平的默认实例视图 严格的严格模型 只读的存储迁移让 60 集成和插件生态都能平稳演进。理解了这三层你就掌握了 OpenSRE 集成体系的骨架——无论是排查为什么我的集成没生效还是给项目贡献一个新集成都可以从这里出发。【免费下载链接】opensreBuild your own AI SRE agents. The open source toolkit for the AI era.项目地址: https://gitcode.com/GitHub_Trending/op/opensre创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考