Cloudprober 目标发现机制静态、文件、Kubernetes 与 GCP 动态目标配置【免费下载链接】cloudproberAn active monitoring software to detect failures before your customers do.项目地址: https://gitcode.com/gh_mirrors/clo/cloudproberCloudprober 是一款开源主动监控软件它的核心价值在于目标发现自动发现并持续追踪需要探测的主机、端点与云资源在故障影响用户之前提前告警。本文为你详解 Cloudprober 目标发现的四种主流方式——静态目标、文件目标、Kubernetes 目标与 GCP 动态目标配置帮助新手快速上手动态目标配置让监控配置从此告别手工维护。为什么要用目标发现传统的监控工具要求你手写一份目标清单服务器增删后就得改配置、重启进程。而 Cloudprober 不同目标发现机制可以定时、自动地从 Kubernetes、GCP 等源头拉取最新资源列表Pod 扩容、节点故障、实例变更都无需人工干预。所有目标类型都在 targets/proto/targets.proto 的TargetsDef中统一定义一次学会四处通用。静态目标配置最快速的上手方式静态目标是 Cloudprober 目标发现机制里最简单直接的一种适合小规模、目标稳定的场景。在 probe 配置中直接写入host_names用逗号分隔多个主机即可probe { name: web-check type: HTTP targets { host_names: www.example.com,api.example.com } }Cloudprober 会对列表中的每个目标并行探测。你还可以用endpoint字段做更精细的静态目标配置直接指定 URL 和显示名称targets { endpoint { name: frontend_main url: https://web.example.com/url1 } endpoint { name: cms.example.com } }文件目标让目标列表可维护 当目标数量变大、变化频繁时把目标写死在配置里就不够灵活了。Cloudprober 支持文件目标把目标清单放在独立文件中并定时重新加载。targets { file_targets { file_path: /var/run/cloudprober/vips.json re_eval_sec: 30 # 每 30 秒检查一次文件变化 } }文件内容使用 JSON 或 textproto 格式可携带 IP、端口和自定义标签{ resource: [ { name: switch-xx-1, ip: 10.1.1.1, port: 8080, labels: {device_type: switch, cluster: xx} } ] }相比静态目标文件目标还能直接指定目标 IP避免依赖 DNS 解析特别适合内网设备监控。Kubernetes 目标发现动态环境的最佳实践 ☸️在 Kubernetes 集群中Pod 的 IP 随时可能变化手工维护目标几乎不可能。Cloudprober 内置K8s 目标直接通过 Kubernetes API 发现资源支持的资源类型包括Services服务Endpoints端点PodsPodIngresses入口例如下面配置会探测名为cloudprober的 Endpoints等价于kubectl get ep cloudprober并且自动使用目标发现的端口probe { name: pod-to-endpoints type: HTTP targets { k8s { endpoints: cloudprober } } http_probe { relative_url: /status } }K8s 目标过滤技巧Cloudprober 的 K8s 目标发现提供强大的过滤能力全部字段见 K8sTargets 定义name按名称正则过滤如endpoints: .*-servicenamespace按命名空间过滤如只监控prod环境labelSelector按标签过滤语法与kubectl -l一致例如labelSelector: rolefrontendportFilter按端口名或端口号过滤如portFilter: http-.* 注意K8s 目标发现需要为 Cloudprober 容器配置只读的 RBAC 权限ServiceAccount ClusterRole详细步骤参见 k8s_targets.md。GCP 动态目标配置云原生监控利器 ☁️Cloudprober 起源于 GCP对 Google Cloud 资源的支持自然非常完善。通过gce_targets可以动态发现以下资源GCE 实例Instances可指定公网/私网 IP、按标签过滤转发规则Forwarding Rules支持区域级与全局级Cloud Pub/Sub通过消息流下发目标主机列表targets { gce_targets { project: my-project instances { label: app:backend-.* } } }实例目标的 IP 解析、网络接口选择等选项参见 targets/gce/proto/config.proto。多个 Probe 还可以通过shared_targets共享同一份 GCP 目标减少 API 调用。RDS大规模部署的集中式目标发现 当你运行成百上千个 Cloudprober 实例时每个实例都去请求云厂商 API 会很快耗尽配额。Cloudprober 提供了RDSResource Discovery Service资源发现服务把目标发现集中到少数几个服务端客户端通过 gRPC 获取目标列表。probe { targets { rds_targets { rds_server_options { server_address: rds-service:9314 } resource_path: gcp://gce_instances filter { key: name value: ins-cf-.* } } } }resource_path的格式为provider://资源类型/相对路径例如k8s://pods、gcp://gce_instances/project。RDS 的完整配置说明与独立服务端部署方式可参考 rds/index..md。总结如何选择目标配置方式场景推荐方式特点目标固定、数量少静态目标配置简单开箱即用目标在文件中维护文件目标支持定时重载与标签Kubernetes 环境K8s 目标自动发现Pod 变更零干预GCP 云资源GCP 目标实例/转发规则自动发现超大规模部署RDS 服务集中发现节省 API 配额无论你选择哪种方式Cloudprober 的目标发现机制都会持续刷新目标列表即使某次刷新失败也会继续使用旧目标保证监控不中断。建议新手从静态目标开始熟悉配置后逐步迁移到 Kubernetes 或 GCP 动态目标配置让主动监控真正主动起来。【免费下载链接】cloudproberAn active monitoring software to detect failures before your customers do.项目地址: https://gitcode.com/gh_mirrors/clo/cloudprober创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
