可观测性指标监控【免费下载链接】windows_exporterPrometheus exporter for Windows machines项目地址https://gitcode.com/gh_mirrors/wi/windows_exporter点击查看免费下载导读container采集器是 windows_exporter 中专门面向Hyper-V 计算系统HCS上运行的容器的指标采集组件能够输出容器在 CPU、内存、网络、存储四个维度上的运行时指标并支持将 Kubernetes 的namespace/pod/container标签附着到指标上是监控 Windows 节点上 Pod 运行状态的利器。本文以官方文档 docs/collector.container.md 为主线结合仓库源码逐项讲解该采集器的指标语义、启用方式、工作原理、查询实践与告警现状读完即可在真实环境中采集并关联 Windows 容器指标。采集器总览先给出官方文档对container采集器的定位描述属性值指标名前缀container数据来源HCSHost Compute Service默认是否启用否Enabled by default? No指标名前缀与命名空间文档指出该采集器的指标名前缀为container。在源码中所有指标通过prometheus.BuildFQName(types.Namespace, Name, ...)构建其中命名空间常量定义为windows见 internal/types/const.goName container见 internal/collector/container/container.go因此最终暴露的指标形如windows_container_*。数据来源HCS文档明确标注数据来源为 HCSHost Compute Service。从源码看采集器通过 internal/headers/hcs/hcs.go 封装的两条核心调用链完成数据获取hcs.GetContainers()向 HCS 发送{Types:[Container]}查询枚举当前主机上所有容器计算系统Compute Systemhcs.GetContainerStatistics(containerID)对单个容器发送{PropertyTypes:[Statistics]}属性查询获取其统计信息。两条路径都通过CreateOperation/WaitForOperationResult超时 1000ms与 HCS 通信并用 JSON 反序列化结果。统计数据的类型定义见 internal/headers/hcs/types.go包含Processor、Memory、Storage三个子结构分别对应 CPU、内存、存储指标。默认不启用该采集器默认不启用。这与源码中的默认采集器列表一致默认启用的采集器为cpu,memory,logical_disk,physical_disk,net,os,service,system见 pkg/collector/types.gocontainer不在其中需要手动启用。启用方式Flags 与 YAML 配置Flags文档中的 Flags 一节注明None即该采集器本身没有必需的命令行开关。不过从源码看它注册了两个可选的专属 flag见 internal/collector/container/container.goFlag说明默认值--collector.container.enabled逗号分隔的子采集器列表未指定时默认全部启用hcs,hostprocess--collector.container.containerd-state-dircontainerd 状态目录路径用于定位容器注解与 host process 容器C:\ProgramData\containerd\state\io.containerd.runtime.v2.task\k8s.io\源码中的对应默认值定义见 internal/collector/container/container.govar ConfigDefaults Config{ CollectorsEnabled: []string{ subCollectorHCS, // hcs subCollectorHostprocess, // hostprocess }, ContainerDStateDir: C:\ProgramData\containerd\state\io.containerd.runtime.v2.task\k8s.io\, }CollectorsEnabled支持的两个合法子采集器是hcs与hostprocess源码中定义为subCollectorHCS与subCollectorHostprocess见 internal/collector/container/container.go。在Build阶段若配置中出现这两个取值之外的名称会直接返回unknown collector错误见 internal/collector/container/container.go。注意--collector.container.enabled控制的仅是 container 采集器内部的两个子采集器与全局的--collectors.enabled是两回事——后者负责决定container采集器整体是否加载。启用 container 采集器由于container默认不启用需要在启动时把它加入全局启用列表。官方 README 提供了[defaults]占位符语法见 README.md.\windows_exporter.exe --collectors.enabled [defaults],process,container该命令会在全部默认采集器的基础上追加process与container两个采集器。YAML 配置文件方式windows_exporter 支持--config.file指定 YAML 配置文件见 README.md。配置文件中的collector段由 pkg/collector/config.go 定义结构其中Container container.Config \yaml:container表明container采集器的配置位于collector.container 下。对应 YAML 片段collectors: enabled: [defaults],container collector: container: enabled: hcs,hostprocess containerd-state-dir: C:\ProgramData\containerd\state\io.containerd.runtime.v2.task\k8s.io\配置文件中的 YAML 键会被扁平化后映射为对应的 CLI flag见 internal/config/config.go因此collector.container.enabled等价于--collector.container.enabled。完整的配置示例可参考 docs/example_config.yml。注意配置解析使用yaml.Decoder.KnownFields(true)未知字段会导致校验失败见 internal/config/config.go。指标清单与语义详解以下为官方文档列出的全部指标本文在保留原文表格的基础上补充了类型与标签说明。指标名描述类型标签windows_container_available容器是否可用存在且运行中countercontainer_id,namespace,pod,container,hostprocesswindows_container_count容器数量gauge无windows_container_cpu_usage_seconds_kernelmode内核态运行时间秒countercontainer_id,namespace,pod,containerwindows_container_cpu_usage_seconds_usermode用户态运行时间秒countercontainer_id,namespace,pod,containerwindows_container_cpu_usage_seconds_total总运行时间秒countercontainer_id,namespace,pod,containerwindows_container_memory_usage_commit_bytes内存提交字节数Commit Bytesgaugecontainer_id,namespace,pod,containerwindows_container_memory_usage_commit_peak_bytes内存提交峰值字节数gaugecontainer_id,namespace,pod,containerwindows_container_memory_usage_private_working_set_bytes私有工作集字节数gaugecontainer_id,namespace,pod,containerwindows_container_network_receive_bytes_total接口接收字节数countercontainer_id,namespace,pod,container,interfacewindows_container_network_receive_packets_total接口接收包数countercontainer_id,namespace,pod,container,interfacewindows_container_network_receive_packets_dropped_total接口丢弃的入站包数countercontainer_id,namespace,pod,container,interfacewindows_container_network_transmit_bytes_total接口发送字节数countercontainer_id,namespace,pod,container,interfacewindows_container_network_transmit_packets_total接口发送包数countercontainer_id,namespace,pod,container,interfacewindows_container_network_transmit_packets_dropped_total接口丢弃的出站包数countercontainer_id,namespace,pod,container,interfacewindows_container_storage_read_count_normalized_total归一化读次数countercontainer_id,namespace,pod,containerwindows_container_storage_read_size_bytes_total读字节数countercontainer_id,namespace,pod,containerwindows_container_storage_write_count_normalized_total归一化写次数countercontainer_id,namespace,pod,containerwindows_container_storage_write_size_bytes_total写字节数countercontainer_id,namespace,pod,container指标分组与源码对应从源码看这些指标按维度分组定义见 internal/collector/container/container.go可用性与数量windows_container_available、windows_container_count内存三个memory_usage_*指标CPUruntimeTotal/runtimeUser/runtimeKernel对应cpu_usage_seconds_total、cpu_usage_seconds_usermode、cpu_usage_seconds_kernelmode网络六个network_*指标额外携带interface标签存储四个storage_*指标。标签含义绝大多数指标携带container_id、namespace、pod、container四个标签网络指标额外增加interfacewindows_container_available还额外携带hostprocess标签。这些标签的来源与生成方式在下一节“工作原理”中说明。关于 counter 类型的说明文档将windows_container_available标注为 counter。从源码看它在容器被采集到时固定输出值1见 internal/collector/container/container.go本质上是一个“存在性”标记指标用于判断某个容器当前是否在线windows_container_count则输出当前运行中的容器数量gauge。示例指标解读官方文档给出了一个网络接收字节数的示例windows_container_network_receive_bytes_total{container_iddocker://1bd30e8b8ac28cbd76a9b697b4d7bb9d760267b0733d1bc55c60024e98d1e43e,interface822179E7-002C-4280-ABBA-28BCFE401826} 9.3305343e07该指标的含义是容器docker://1bd30e8b8ac28cbd76a9b697b4d7bb9d760267b0733d1bc55c60024e98d1e43e在其网络接口822179E7-002C-4280-ABBA-28BCFE401826上累计接收了约9.3305343e079330 万字节。从这个示例可以观察到两个重要细节container_id带运行时前缀示例中是docker://前缀。从源码看容器 ID 前缀由getContainerIdWithPrefix根据容器Owner字段决定——owner 为containerd-shim-runhcs-v1.exe时返回containerd://ID否则默认返回docker://ID见 internal/collector/container/container.go。这与 kubelet 上报的container_id如docker://...或containerd://...格式一致是后续做标签关联的天然 join 键。interface是端点 GUID 的大写形式源码在输出网络指标前执行strings.ToUpper(endpoint.ID)见 internal/collector/container/container.go因此interface标签值形如822179E7-002C-4280-ABBA-28BCFE401826。工作原理从 HCS 到 Prometheus 指标整体采集流程Collect方法根据启用的子采集器分两路采集见 internal/collector/container/container.gohcs子采集器collectHCS面向 HCS 管理的普通 Hyper-V 容器如 Windows Server 容器 / 进程隔离容器hostprocess子采集器collectJobContainers面向基于 Win32 Job Object 的 host process 容器不被 HCS 管理的容器例如 Windows 主进程容器。两路错误通过errors.Join合并返回。HCS 容器采集细节collectHCS的流程见 internal/collector/container/container.go调用hcs.GetContainers()枚举所有容器计算系统仅处理State Running的容器对每个运行中的容器先从 containerd 状态目录下读取 OCIconfig.json中的注解annotations提取io.kubernetes.cri.sandbox-namespace、io.kubernetes.cri.sandbox-name、io.kubernetes.cri.container-name三个键分别填充namespace、pod、container标签注解读取结果缓存到annotationsCacheHCS避免重复 IO调用hcs.GetContainerStatistics(containerID)获取统计信息逐项输出内存、CPU、存储指标跳过 pause 容器有pod注解但container注解为空见 internal/collector/container/container.go通过 HCN 列出所有网络端点endpoint对每个端点获取GetHNSEndpointStats统计按SharedContainers归属到对应容器并输出网络指标见 internal/collector/container/container.go清理缓存中已不在运行的容器条目。其中 HCN 网络端点与端点统计分别通过hnsCall(GET, /endpoints/)与hnsCall(GET, /endpointstats/id)完成见 internal/headers/hcn/hcn.go底层直接调用vmcompute.dll的HNSCall导出函数。CPU 时间单位换算HCS 返回的 CPU 运行时间单位为 100ns字段名TotalRuntime100ns、RuntimeUser100ns、RuntimeKernel100ns。源码在输出时乘以pdh.TicksToSecondScaleFactor换算为秒见 internal/collector/container/container.go该常量定义为1 / 1e7见 internal/pdh/const.go即 1 秒 10^7 个 100ns 刻度。host process 容器采集细节collectJobContainers面向 host process 容器见 internal/collector/container/container.go以--collector.container.containerd-state-dir指定的目录为根用fs.WalkDir遍历 containerd 状态目录若目录不存在仅记录 Warn 日志而非报错对每个子目录读取 OCIconfig.json检查注解microsoft.com/hostprocess-container是否为true命中则视为 host process 容器并提取 Kubernetes 注解写入annotationsCacheJob缓存container_id统一使用containerd://ID前缀对每个 host process 容器通过kernel32.OpenJobObject(Global\\JobContainer_ containerID)打开对应的 Win32 Job Object见 internal/headers/kernel32/job.go再用QueryInformationJobObject分别查询基本/IO 记账信息与内存使用信息输出指标时hostprocess标签固定为trueHCS 容器则为false。Job Object 相关数据结构定义在 internal/headers/kernel32/types.goJobObjectBasicAndIOAccountingInformation提供 CPU 与 I/O 记账IoInfo.ReadOperationCount、ReadTransferCount、WriteOperationCount、WriteTransferCountJobObjectMemoryUsageInformation提供JobMemory与PeakJobMemoryUsed。私有工作集大小则通过JobObjectBasicProcessIDList枚举 Job 内所有进程逐个调用NtQueryInformationProcess汇总PrivateWorkingSetSize计算得到见 internal/collector/container/container.go。实现约束从源码看整个采集器internal/collector/container/container.go与 HCS/HCN 头文件internal/headers/hcs、internal/headers/hcn均带有//go:build windows构建标签且依赖vmcompute.dll、kernel32.dll等 Windows 原生 API因此该采集器仅能在 Windows 主机上编译与运行这一点与文档“Hyper-V 系统上的容器”的定位一致。实战查询为 Windows 容器指标附加 Kubernetes 标签官方文档在 Useful queries 一节给出了一个非常实用的查询技巧将 kube-state-metrics 的kube_pod_container_info指标与 windows_exporter 的容器指标做标签关联为仅有container_id的指标附加namespace/pod/container标签。其背景是kube_pod_container_infokube-state-metrics 的指标带有namespace、pod、container、container_id标签而 windows_exporter 的容器指标虽然内部采集了这些信息并输出到自身标签但在部分场景下例如只有container_id可用时仍需要通过 join 查询来对齐 Windows Pod 数据。官方给出的 PromQL 如下windows_container_network_receive_bytes_total * on(container_id) group_left(namespace, pod, container) kube_pod_container_info{container_id!}该查询的含义on(container_id)仅以container_id作为连接键group_left(namespace, pod, container)从右侧的kube_pod_container_info引入namespace、pod、container三个标签到左侧的 Windows 容器指标上{container_id!}过滤掉container_id为空的样本避免空值 join 产生无意义结果。执行后原本形如windows_container_network_receive_bytes_total{container_iddocker://...,interface...}的指标会额外携带namespace、pod、container标签从而可以直接按 Pod 维度做聚合查询例如sum by (namespace, pod, container) (rate(windows_container_network_receive_bytes_total[5m]))这一模式对 Windows 节点上的 Pod 网络流量监控非常有用也是将container采集器纳入 Kubernetes 监控体系可参考仓库中的 kubernetes/windows-exporter-daemonset.yaml 与 kubernetes/windows-exporter-podmonitor.yaml后的常用查询方式。测试与验证仓库为该采集器提供了单元测试与基准测试见 internal/collector/container/container_test.goTestCollector通过testutils.TestCollector采集指标并断言windows_container_available指标分别带有hostprocesstrue容器名hostprocess与hostprocessfalse容器名nanoserver两组标签覆盖了 HCS 容器与 host process 容器两条采集路径BenchmarkCollector对采集过程做性能基准测试。由于代码带有//go:build windows构建约束测试同样需要在 Windows 环境或具备 HCS 的 Hyper-V 主机上运行。这从侧面印证了文档所述“容器运行在 Hyper-V 系统上”的前提。告警示例现状官方文档最后注明This collector does not yet have alerting examples, we would appreciate your help adding them!即该采集器目前尚未提供官方告警规则示例社区欢迎贡献。结合文档中的指标与查询实践可以自行构建一些基础的告警方向例如基于windows_container_memory_usage_commit_bytes与容器内存上限对比监控内存接近耗尽基于rate(windows_container_cpu_usage_seconds_total[5m])监控 CPU 使用率异常升高基于windows_container_available 0检测容器不可用。需要注意的是这些仅为基于指标语义的通用思路并非仓库官方提供的告警规则使用时需结合自身环境验证阈值。总结container采集器是 windows_exporter 面向 Windows 容器场景的专用采集组件数据来源HCSHost Compute Service枚举容器计算系统与统计信息网络部分走 HCN 端点覆盖维度CPU用户态/内核态/总计、内存Commit/Peak/私有工作集、网络收发字节、包、丢包、存储读写次数与字节两种容器形态HCS 管理的普通容器与基于 Win32 Job Object 的 host process 容器通过--collector.container.enabled控制Kubernetes 友好自动读取 OCI 注解填充namespace/pod/container标签并可与kube_pod_container_info做 join 查询适用前提仅 Windows 主机、运行 Hyper-V 容器的场景且需要手动将该采集器加入--collectors.enabled。如需进一步了解其他采集器或全局配置可查阅仓库 docs/README.md 中的采集器文档索引以及 README.md 的 Flags 与配置说明。赞分享可观测性指标监控【免费下载链接】windows_exporterPrometheus exporter for Windows machines项目地址https://gitcode.com/gh_mirrors/wi/windows_exporter点击查看免费下载相关推荐Telegraf Kubernetes Input Plugin 完整指南基于 Kubelet API 采集 Pod 与容器指标Telegraf Kubernetes Input Plugin 完整指南基于 Kubelet API 采集 Pod 与容器指标 本指南以 plugins/i可观测性指标监控运维OpenObserve容器监控Kubernetes日志与指标采集完整方案OpenObserve容器监控Kubernetes日志与指标采集完整方案 为什么选择OpenObserve监控K8s 容器化环境中日志与指标的采集存储往往可观测性日志分析指标监控链路追踪后端云原生Apache SkyWalking Windows 主机监控接入指南基于 windows_exporter 与 OpenTelemetry 采集链路Apache SkyWalking Windows 主机监控接入指南基于 windows_exporter 与 OpenTelemetry 采集链路 Apac可观测性后端微服务云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考