ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

OneUptime Kubernetes 监控实战:从集群指标采集到告警模板的完整指南

OneUptime Kubernetes 监控实战:从集群指标采集到告警模板的完整指南 OneUptime Kubernetes 监控实战从集群指标采集到告警模板的完整指南【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptimeOneUptime 的 Kubernetes 监控功能允许你实时观察集群的健康状况与性能表现覆盖节点、Pod、工作负载与 control plane 组件。本文以官方文档为主体结合仓库内指标目录、监控步骤类型定义与告警模板实现系统讲解监控器的创建流程、全部配置项、常用指标语义与内置告警模板帮助你在一站式可观测平台上落地 Kubernetes 监控与告警。概述Kubernetes 监控能做什么Kubernetes 监控器从你的集群中采集指标并与你配置的判定标准进行比对从而为基础设施提供深入洞察。核心能力包括监控集群、namespace、工作负载、节点与 Pod 的健康状况追踪跨资源的 CPU、内存、磁盘与网络用量检测 Pod 崩溃crash、重启restart与调度失败监控 Deployment 副本可用性针对 control plane 问题etcd、API server、scheduler发出告警追踪资源 requests 与 limits在仓库中这些能力由一套完整的数据模型支撑。KubernetesCluster.ts 定义了集群实体通过clusterIdentifier来自 OTel 的k8s.cluster.name资源属性、providerEKS/GKE/AKS/self-managed、otelCollectorStatus与agentVersion等字段记录集群状态集群由 OneUptime Kubernetes agent 上报指标时自动发现也可手动注册。创建 Kubernetes 监控器在 OneUptime Dashboard 中创建 Kubernetes 监控器进入 OneUptime Dashboard 的监控Monitors页面点击创建监控Create Monitor选择Kubernetes作为监控类型选择要监控的集群与资源范围resource scope配置资源过滤器与指标查询metric queries按需配置监控判定标准criteria在代码层面每个 Kubernetes 监控步骤对应 MonitorStepKubernetesMonitor.ts 中定义的接口包含clusterIdentifier、resourceScope、resourceFilters、metricViewConfig与rollingTime五个核心字段默认使用Cluster范围与Past 1 Minute滚动窗口。配置项详解集群Cluster选择要监控的 Kubernetes 集群。集群必须通过 OpenTelemetry 与 OneUptime 集成。从源码实现看集群的唯一标识来自 OTel 的k8s.cluster.name资源属性即 KubernetesCluster.ts 中的clusterIdentifier字段数据库层通过(projectId, clusterIdentifier)唯一索引保证同一集群不会因 agent 并发上报而重复创建。资源范围Resource Scope选择资源被监控的层级Scope描述Cluster监控整个集群Namespace监控指定 namespace 内的资源Workload监控特定 Deployment、StatefulSet、DaemonSet、Job 或 CronJobNode监控特定集群节点Pod监控特定 Pod该枚举定义于 MonitorStepKubernetesMonitor.tsKubernetesResourceScope。资源过滤器Resource Filters使用可选过滤器缩小范围Filter描述适用 ScopeNamespaceKubernetes namespaceNamespace、Workload、PodWorkload Typedeployment、statefulset、daemonset、job、cronjobWorkloadWorkload Name工作负载名称WorkloadNode Name节点名称NodePod NamePod 名称Pod对应源码为 MonitorStepKubernetesMonitor.ts 中的KubernetesResourceFilters接口。指标查询Metric Queries配置一条或多条待评估的指标查询每条查询指定Metric name— 要查询的 Kubernetes 指标Aggregation聚合方式— 指标值如何聚合Filters— 基于属性的附加过滤此外还可以创建公式formulas通过数学表达式组合多条指标查询。仓库中的 KubernetesAlertTemplates.ts 提供了两个构建器佐证这一能力buildKubernetesMonitorConfig构造单查询监控配置并支持groupByAttributeKeys实现按序列分组per-series——集群中 200 个 Pod 若各自异常会分别产生事故而非合并去重buildKubernetesRatioMonitorConfig构造(numerator / denominator) * 100形式的比值监控如节点 CPU 利用率 节点 CPU 使用 ÷ 节点可分配 CPU分子与分母分别作为两条查询再以公式合成结果。滚动时间窗口Rolling Time Window选择指标评估的时间窗口最近 1 分钟最近 5 分钟最近 10 分钟最近 15 分钟最近 30 分钟最近 60 分钟该枚举定义于 RollingTime.ts实际支持从 1 分钟到 365 天的完整时间跨度。常用 Kubernetes 指标仓库中的 KubernetesMetricCatalog.ts 维护了一份完整的指标目录KubernetesMetricDefinition每条定义包含metricNameOTel 指标名、friendlyName、categoryPod/Node/Container/Workload/HPA、defaultAggregation、defaultResourceScope与unit。以下结合该目录还原文档中的四类指标。Pod 指标指标描述底层 metricNamePod CPU Usage每个 Pod 的 CPU 用量k8s.pod.cpu.utilizationPod Memory Usage每个 Pod 的内存用量k8s.pod.memory.usagePod Filesystem Usage每个 Pod 的磁盘用量k8s.pod.filesystem.usagePod Network Receive/Transmit网络流量k8s.pod.network.ioPod Phase当前 Pod 阶段Running、Pending、Failed 等k8s.pod.phase值得注意的源码细节k8s.pod.cpu.utilization尽管名字带 utilizationkubeletstats 实际以核数gauge 上报0.18 表示 0.18 核而非 18%换算百分比需除以容器 CPU limit 或节点可分配 CPUk8s.pod.phase是分类值而非数值1Pending、2Running、3Succeeded、4Failed、5Unknown因此绝不能用 Sum 聚合建议用 Max 捕获最差阶段或用 Min 配合等于 1捕获卡在 Pending 的 Pod。Node 指标指标描述底层 metricNameNode CPU Usage每个节点的 CPU 利用率k8s.node.cpu.utilizationNode Memory Usage每个节点的内存利用率k8s.node.memory.usageNode Filesystem Usage每个节点的磁盘用量k8s.node.filesystem.usageNode Disk I/O读/写操作—Node Ready Condition节点是否就绪k8s.node.condition_ready源码提示k8s.node.condition_ready以 1就绪/0不就绪编码默认聚合为 Min配合等于 0即可实现 Node Not Ready 告警见下文模板。Container 指标指标描述底层 metricNameContainer Restarts容器重启次数k8s.container.restartsContainer CPU/Memory Limits资源 limitsk8s.container.cpu_limit/k8s.container.memory_limitContainer CPU/Memory Requests资源 requestsk8s.container.cpu_request/k8s.container.memory_requestContainer Ready Status容器是否就绪k8s.container.ready工作负载指标指标描述底层 metricNameDeployment Available/Unavailable Replicas副本数量k8s.deployment.available_replicas/k8s.deployment.unavailable_replicasDaemonSet Misscheduled Nodes调度问题k8s.daemonset.misscheduled_nodesStatefulSet Ready Replicas就绪副本数量k8s.statefulset.ready_replicasJob Active/Failed/Succeeded PodsJob 状态k8s.job.failed_pods/k8s.job.successful_pods此外指标目录还包含 HPA 类指标k8s.hpa.current_replicas、k8s.hpa.desired_replicas、k8s.hpa.min_replicas、k8s.hpa.max_replicas可用于监控自动伸缩状态。监控判定标准Criteria可用的检查类型检查类型描述Metric Value已配置指标查询或公式的数值聚合类型聚合方式描述Average时间窗口内的平均值Sum所有值的总和Maximum Value时间窗口内的最大值Minimum Value时间窗口内的最小值All Values所有值都必须满足条件Any Value至少一个值满足条件过滤类型大于Greater Than、小于Less Than、大于等于Greater Than or Equal To、小于等于Less Than or Equal To、等于Equal To基线异常检测Baseline Anomaly Detection基线异常检测无需设置阈值——表单会显示敏感度Sensitivity与基线窗口Baseline Window并将每次测量与上周同一小时的基线进行比较异常高Anomalously High— 数值上升到预期区间之上异常低Anomalously Low— 数值下降到预期区间之下异常Anomalous— 数值向两个方向偏离预期区间异常条件在积累至少所选择的基线窗口历史数据之前不会触发任何告警学习模式Learning mode。预置告警模板OneUptime 为常见 Kubernetes 监控场景提供了开箱即用的告警模板。以下表格来自官方文档模板的完整实现可见 KubernetesAlertTemplates.ts模板描述阈值CrashLoopBackOff 检测容器重启计数 5 次重启Pod 卡在 PendingPending 阶段的 Pod 0 个 PodNode Not Ready节点就绪状态 0未就绪高节点 CPU节点 CPU 利用率 90%高节点内存节点内存利用率 85%Deployment 副本不一致不可用副本 0 个副本Job 失败Job 中的失败 Pod 0 个失败etcd 无 Leaderetcd 集群缺少 Leader 0无 LeaderAPI Server 限流丢弃的 API 请求 0 个请求Scheduler 队列积压Scheduler 中的 Pending Pod 0 个 Pod高节点磁盘占用节点文件系统占用 90%DaemonSet 不可用错误调度的节点 0 个节点源码实现中有几个值得借鉴的工程细节按序列分组groupByCrashLoopBackOff 模板按resource.k8s.namespace.name、resource.k8s.pod.name、resource.k8s.container.name分组使每个崩溃循环的 Pod 独立触发事故Node Not Ready 按resource.k8s.node.name分组实现每个未就绪节点一个事故。分组键必须是 ClickHouse 中存储的带resource.前缀的属性名否则匹配不到任何序列。阈值语义API Server 限流模板使用apiserver_current_inflight_requestsgauge而非累加计数器并采用大于等于 200——200 恰好是--max-mutating-requests-inflight的默认上限严格大于会永远无法触发恢复阈值通过 10% 死区dead band推导如 180避免控制平面停在临界值附近时监控在相邻评估中反复翻转。适用范围说明etcd 与 Scheduler 模板依赖 agent 的 control plane 抓取controlPlane.enabledEKS/GKE/AKS 等托管集群不暴露 etcd 的 metrics 端点因此这些监控在这些集群上永远不会收到数据点。部署前提安装 Kubernetes Agent使用 Kubernetes 监控前必须在集群中安装 OneUptime Kubernetes agent。Agent 通过 OTLP 将集群指标、事件、Pod 日志发送到 OneUptime并且默认还会发送通过eBPF捕获的应用 traces 与 HTTP RED 指标——无需任何代码改动或逐个应用安装 SDK即可看到服务级别的流量。安装指南见 Kubernetes Agent 安装文档核心要点包括通过 Helm 一条命令完成安装使用preset选项为集群选择正确的配置standard、GKE Autopilot、EKS Fargate使用ebpf.features.*开关分别控制各信号族HTTP RED 指标、服务地图 service map、网络流 network flows、TCP 统计。Agent 上报后集群会在 KubernetesCluster.ts 对应的列表中以自动发现方式出现otelCollectorStatus字段反映 agent 连接状态connected/disconnectedlastSeenAt记录最近一次收到指标的时间可据此判断数据链路是否健康。小结OneUptime 的 Kubernetes 监控是一条完整链路集群中安装 agent 通过 OTLP 采集与上报指标 → 平台自动发现集群并落库 → 在 Dashboard 中创建 Kubernetes 监控器配置资源范围、过滤器、指标查询/公式与滚动窗口→ 通过 Metric Value 标准阈值或基线异常检测评估 → 命中条件后触发事故与告警。若想深入理解底层实现建议进一步阅读 KubernetesMetricCatalog.ts指标清单与单位语义、MonitorStepKubernetesMonitor.ts监控步骤数据模型与 KubernetesAlertTemplates.ts12 个模板的完整实现与判定逻辑。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表