时序数据库后端数据存储可观测性云原生【免费下载链接】mimirGrafana Mimir provides horizontally scalable, highly available, multi-tenant, long-term storage for Prometheus.项目地址https://gitcode.com/gh_mirrors/mimir/mimir点击查看免费下载Grafana Mimir 中部分客户端支持通过 DNS 服务发现DNS Service Discovery来定位所连接的后端服务地址避免在配置文件中写死 IP。本篇指南系统讲解 Mimir 支持的三类配置入口Memcached 地址、memberlist KV 的 join 地址、ruler 的 Alertmanager URL、三种发现模式前缀dns/dnssrv/dnssrvnoa的查询语义与差异并结合dskit/dns的解析器与 Provider 实现、ruler 的dns_sd发现机制源码说明地址解析的底层流程、失败回退缓存行为与相关监控指标帮助你为 Kubernetes 等动态环境正确配置 Mimir 的后端依赖地址。哪些 Mimir 客户端支持 DNS 服务发现在 Grafana Mimir 中以下客户端支持通过 DNS 服务发现来查找要连接的后端服务器地址引自 官方文档1. Memcached server 地址对应 配置参数参考 中 Memcached 一节-blocks-storage.bucket-store.chunks-cache.memcached.addresses-blocks-storage.bucket-store.index-cache.memcached.addresses-blocks-storage.bucket-store.metadata-cache.memcached.addresses-query-frontend.results-cache.memcached.addresses2. Memberlist KV store对应 Memberlist 一节-memberlist.join3. Ruler 中配置的 Alertmanager URL对应 Ruler 一节-ruler.alertmanager-url这些参数在 配置参数文档 中的取值说明是IP 地址、主机名或符合 DNS 服务发现格式的条目例如-memberlist.join的文档描述为# Other cluster members to join. Can be specified multiple times or as a # comma-separated list. It can be an IP, hostname or an entry specified in the # DNS Service Discovery format. # CLI flag: -memberlist.join [join_members: list of strings | default ]而 Memcached 侧还配套了两个高级调优参数引自 配置参数文档 的memcached.addresses条目# Comma-separated list of memcached addresses. Each address can be an IP # address, hostname, or an entry specified in the DNS Service Discovery format. # CLI flag: -prefix.memcached.addresses [addresses: string | default ] # (advanced) How often each address is resolved to an IP address or list of host # names. # CLI flag: -prefix.memcached.addresses-lookup-period [addresses_lookup_period: duration | default 30s] # (advanced) How many idle connections to the DNS resolver are kept open. 0 # disables keeping any idle connections open. # CLI flag: -prefix.memcached.addresses-lookup-pool-size [addresses_lookup_pool_size: int | default 0]其中addresses_lookup_period默认 30s控制每个地址被重新解析为 IP 列表的频率也就是说 DNS 服务发现是周期性轮询的后端成员变化后最多一个周期内生效。支持的发现模式dns、dnssrv、dnssrvnoa通过给地址添加不同的前缀可以选择 DNS 服务发现的查询模式引自 官方文档前缀查询语义示例dns前缀后的域名按A/AAAA 记录查询dnsmemcached.local:11211dnssrv前缀后的域名按SRV 记录查询随后每条 SRV 记录的目标再按 A/AAAA 记录解析dnssrv_memcached._tcp.memcached.namespace.svc.cluster.localdnssrvnoa前缀后的域名按SRV 记录查询不再做后续的 A/AAAA 查询dnssrvnoa_memcached._tcp.memcached.namespace.svc.cluster.local针对 Alertmanager URL 还有一条特殊规则URL 必须包含 scheme。例如dnshttp://alermanager.local:8080此外如果地址没有提供任何前缀则该 IP 或主机名将原样使用不会进行预解析。也就是说 DNS 解析交由底层连接时的常规名称解析完成Mimir 侧不做主动的周期性发现。重要限制不支持搜索域必须使用 FQDN使用 DNS 服务发现时不支持 DNS 搜索域search domains。因此所有域名都必须是完全限定域名FQDN。在 Kubernetes 环境中这意味着域名要写全例如memcached.namespace.svc.cluster.local而不能依赖客户端 DNS 配置自动补全域名。三种前缀在源码中的实现语义Mimir 的 DNS 服务发现能力来自其依赖的dskit库仓库中 vendored 的vendor/github.com/grafana/dskit/dns/目录包含完整实现。QType 前缀与解析器QType 常量定义 与文档中三种前缀一一对应const ( // A qtype performs A/AAAA lookup. A QType(dns) // SRV qtype performs SRV lookup with A/AAAA lookup for each SRV result. SRV QType(dnssrv) // SRVNoA qtype performs SRV lookup without any A/AAAA lookup for each SRV result. SRVNoA QType(dnssrvnoa) )Resolve 方法 的处理逻辑印证了文档描述的查询语义先拆出 scheme如http://或https://解析完成后会把 scheme 重新拼回每个解析结果见appendSchemeresolver.go#L140-L145这正是 Alertmanager URL 需要带 scheme 的原因再拆出 host 和 portdnsA 查询必须显式提供端口若缺少端口会直接报错missing port in address given for dns lookup因为 A 记录本身不携带端口信息这解释了为什么dnsmemcached.local必须写成dnsmemcached.local:11211dnssrv与dnssrvnoa通过LookupSRV查询 SRV 记录。端口规则是如果显式指定了端口则优先使用显式端口否则使用 SRV 记录中的端口resolver.go#L104-L109。二者的区别在于dnssrvnoa直接采用 SRV 记录中的Target主机名不再二次解析 A 记录而dnssrv会对每条 SRV 记录的Target再做一次LookupIPAddr。域名不存在NXDOMAIN 类错误不会直接失败而是记录 error 日志并返回空结果同时输出告警日志IP address lookup yielded no resultsresolver.go#L133-L135。Provider解析结果缓存、失败回退与监控指标dskit/dns 的 Provider 是异步 DNS 解析的状态缓存Memcached 客户端与 memberlist 等组件周期性调用其Resolve。几个关键行为provider.go#L118-L164GetQTypeName 按第一个拆分地址没有时前缀为空串地址被原样放入缓存对应文档中无前置前缀则不预解析的行为解析失败时回退到缓存值当某地址的 DNS 解析报错Provider 会保留上一轮的解析结果继续可用并记录失败计数保证 DNS 短暂抖动不会导致客户端整体失联暴露的监控指标包括dns_lookups_total解析尝试次数、dns_failures_total解析失败次数以及带addr标签的dns_provider_results每个已配置地址当前解析出的端点数便于排查地址解析不到任何实例这类问题底层解析器支持golangnet.DefaultResolver与miekgdns两种后端provider.go#L58-L71。在 Mimir 主程序中ruler 与 memberlist KV 两处分别创建了该 Provider均使用golang解析器ruler 模块初始化中modules.go#L1428-L1429 将dnsResolver注入ruler.NewDefaultMultiTenantManagermemberlist KV 模块初始化中modules.go#L1544-L1550 将dnsProvider传入memberlist.NewKVInitService供-memberlist.join的 DNS 条目解析使用。ruler 的 Alertmanager URL一个 Prometheus 风格的 dns_sd 发现机制ruler 对-ruler.alertmanager-url的处理比普通地址解析更进一步它向 Prometheus 的发现框架注册了一个名为dns_sd的自定义机制pkg/ruler/service_discovery.go#L20-L26按配置的刷新间隔周期性执行解析把结果转换为targetgroup.Groupresolve 方法。URL 的解析与校验逻辑在 sanitizedAlertmanagerURL先经dns.GetQTypeName拆出前缀只接受空串、dns、dnssrv、dnssrvnoa否则报invalid DNS service discovery prefix随后url.Parse要求 URL 格式合法且必须带 host否则报错提示improperly formatted alertmanager URL ... (maybe the scheme is missing?)——这与文档中Alertmanager URL 必须包含 scheme的要求相互印证。ruler 的测试用例 明确验证了三种前缀下实际传给解析器的地址格式{name: dns, qType: dns.A, host: localhost:123, expectedAddress: dnslocalhost:123}, {name: dnssrv, qType: dns.SRV, host: localhost:123, expectedAddress: dnssrvlocalhost:123}, {name: dnssrvnoa, qType: dns.SRVNoA, host: localhost:123, expectedAddress: dnssrvnoalocalhost:123},仓库中的真实配置示例Helm chart 的生成配置test-oss-values 生成的 mimir-config.yaml展示了三种入口在 Kubernetes 下的真实写法全部使用dnssrvnoa前缀配合集群内 FQDN# Memcached 缓存地址chunks/index/metadata/results cache 均是同一模式 addresses: dnssrvnoatest-oss-values-mimir-chunks-cache.citestns.svc.cluster.local.:11211 # Ruler 的 Alertmanager URLdnssrvnoa 前缀之后是带 scheme 的 URL # SRV 查询名采用 _service._proto.host 形式 alertmanager_url: dnssrvnoahttp://_http-metrics._tcp.test-oss-values-mimir-alertmanager-headless.citestns.svc.cluster.local./alertmanager这里有两个值得注意的实战细节dnssrvnoa后面的域名可以直接带显式端口如:11211此时会覆盖 SRV 记录中的端口见前述端口优先级规则Alertmanager 的 SRV 名遵循_端口-名._协议.主机的 SRV 记录命名习惯_http-metrics._tcp.headless-service且路径/alertmanager保留在 URL 中不被解析过程丢弃。实战建议Memcached 集群 headless Service 的组合store-gateway 组件文档 给出了与 DNS 服务发现直接相关的推荐部署组合。由于 Memcached 客户端使用 jump hash 算法在服务器集群间分片缓存条目Memcached 服务器不能放在负载均衡器后面扩缩容时服务器应始终添加/移除在列表两端在 Kubernetes 中通常的做法是使用 StatefulSet 部署 Memcached 集群为该 StatefulSet 创建 headless ServiceMimir 的 Memcached 客户端地址使用dnssrvnoa服务发现前缀配置例如-blocks-storage.bucket-store.index-cache.memcached.addresses。采用dnssrvnoa而非dnssrv的原因可以从源码语义得到解释SRV 记录的Target本身就是 StatefulSet Pod 的稳定 DNS 名无需再做一次 A 记录解析减少一轮查询且避免额外的解析失败面。小结与排查要点Mimir 中仅 Memcached 地址4 个*.memcached.addresses参数、-memberlist.join与-ruler.alertmanager-url支持 DNS 服务发现前缀三种前缀对应 A/AAAA、SRVAAAA、纯 SRV 三种查询语义dns必须显式带端口SRV 类前缀可用显式端口覆盖 SRV 记录端口Alertmanager URL 必须带 scheme无 scheme 会在启动/解析阶段报错所有 DNS 服务发现域名必须为 FQDN不支持搜索域解析失败不会立刻失效Provider 会回退到上一次缓存结果并结合dns_lookups_total、dns_failures_total、dns_provider_results指标带component/addr标签可定位某地址解析为空的问题解析周期由 Memcached 侧addresses_lookup_period默认 30s等参数控制后端成员变更后地址列表的收敛时间以此为上限。赞分享时序数据库后端数据存储可观测性云原生【免费下载链接】mimirGrafana Mimir provides horizontally scalable, highly available, multi-tenant, long-term storage for Prometheus.项目地址https://gitcode.com/gh_mirrors/mimir/mimir点击查看免费下载相关推荐Atlas多智能体并行实战:3个Tab同时跑AI编程助手,一个都不掉线Atlas多智能体并行实战:3个Tab同时跑AI编程助手,一个都不掉线 Atlas 是一款多智能体并行编程工具它让你在一个桌面应用里同时运行 Claude C桌面应用开发工具AI 应用代码智能体Agent 记忆人工智能智能代理技术演进Hermes Agent如何重塑AI自动化工作流智能代理技术演进Hermes Agent如何重塑AI自动化工作流 在当今快速发展的AI技术生态中开发者面临着日益复杂的自动化需求。传统AI代理系统往往局限于AI Agent人工智能AI 应用工具调用Agent 记忆交互助手RAG任务调度MCP 服务smallnest/rpcx动态服务发现DNS与mDNS的应用场景smallnest/rpcx动态服务发现DNS与mDNS的应用场景 你是否还在为微服务架构中的服务注册与发现烦恼当服务实例频繁扩缩容时如何让客户端自动感知后端RPC框架微服务上一篇OptiScaler终极指南打破显卡限制一工具实现AI超分辨率自由切换下一篇彻底解决Enumerize项目9大痛点从入门到精通的完整指南 创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考