时序数据库后端数据存储可观测性云原生【免费下载链接】mimirGrafana Mimir provides horizontally scalable, highly available, multi-tenant, long-term storage for Prometheus.项目地址https://gitcode.com/gh_mirrors/mimir/mimir点击查看免费下载本指南围绕 Grafana Mimir 官方监控体系中面向 Alertmanager 组件的 Alertmanager resources 资源监控面板展开介绍该面板在监控 Grafana Mimir 体系中的定位、逐面板的指标构成与底层 PromQL 查询、运行所需的额外资源指标与标签前提以及从预编译产物或 Jsonnet 源码安装和定制的方法。读完本文你将能够理解并部署一个可真实用于生产环境的 Alertmanager 资源观测视图并依据源码与编译产物自行裁剪面板。面板概览它监控什么、解决什么问题Grafana Mimir Alertmanager resources 面板集中展示 Alertmanager 组件的CPU、内存、磁盘和网络四类资源指标。它面向以下三个典型运维场景保障多租户 Mimir 集群中 Alertmanager 的性能与可靠性通过资源面板快速定位负载热点、OOMKilled 等异常事件实时监控资源消耗观察容器工作集内存、Go 堆内存、网络带宽与磁盘读写速率的即时变化规划未来的资源分配结合 CPU / 内存的 requests 与 limits 基线评估扩容或缩容所需的资源预算。该面板运行前有一个硬性前提需要集群中已采集 additional resources metrics即 cAdvisor、kubelet、Node Exporter、kube-state-metrics 暴露的容器与节点指标否则面板将无法渲染出任何曲线。下文第四节会详细说明这些前提。下图为官方文档给出的 demo 集群示例面板截图面板布局从 Jsonnet 源码看结构该面板并非手工绘制而是由 Mimir 官方监控 mixin 的 Jsonnet 源码定义生成定义文件位于 operations/mimir-mixin/dashboards/alertmanager-resources.libsonnet。从源码可以清楚地看到面板按行Row组织部分行还受配置开关控制行Row面板是否条件显示GatewayCPU / Memory (workingset) / Memory (go heap inuse)仅当gateway_enabled为 true_config.gem_enabled时显示AlertmanagerCPU / Memory (workingset) / Memory (go heap inuse)始终显示Instance mapperCPU / Memory (workingset) / Memory (go heap inuse)仅当alertmanager_im_enabled为 true 时显示NetworkReceive bandwidth / Transmit bandwidth始终显示DiskDisk writes / Disk reads始终显示无标题行Disk space utilization始终显示其中 Gateway 行针对 Grafana Enterprise MetricsGEM部署形态下的 gateway 组件Instance mapper 行针对 Grafana Cloud 的 alertmanager instance-mapper 组件二者默认关闭。在 operations/mimir-mixin/config.libsonnet 中可以看到这两个开关的默认值// Whether mimir gateway is enabled. The gateway is usually enabled in GEM deployments. gateway_enabled: $._config.gem_enabled, gateway_per_tenant_metrics_enabled: false, // Whether grafana cloud alertmanager instance-mapper is enabled alertmanager_im_enabled: false,因此预编译产物operations/mimir-mixin-compiled/dashboards/mimir-alertmanager-resources.json中实际只包含 Alertmanager、Network、Disk、Disk space utilization 四行Dashboard 标题为Mimir / Alertmanager resourcesUID 为a6883fb22799ac74479c7db872451092刷新间隔 5m。每个资源面板都通过dashboard-utils.libsonnet中通用的container*PanelByComponent(alertmanager)系列构造器生成这些构造器会依据 mixin 配置中的instance_names、container_names映射自动生成查询。例如 Alertmanager 对应的组件正则定义在 operations/mimir-mixin/config.libsonnetlocal componentNameRegexp { ... alertmanager: alertmanager, alertmanager_im: alertmanager-im, ... };面板逐个拆解指标构成与 PromQL 查询以默认 Kubernetes 部署方式编译出的面板为例各面板的完整查询如下以下表达式提取自 mimir-alertmanager-resources.json对应查询模板定义在 config.libsonnet 的resources_panel_queries.kubernetes。CPUCPU 面板同时绘制三组序列用于对照实际使用量与 Kubernetes 资源规格CPU 使用率sum by(pod) (rate(container_cpu_usage_seconds_total{cluster~$cluster, namespace~$namespace, container~alertmanager}[$__rate_interval]))单位shortCPU limitmin(kube_pod_container_resource_limits{...resourcecpu})在图上以红色虚线表示CPU requestmin(kube_pod_container_resource_requests{...resourcecpu})在图上以黄色虚线表示。limit 与 request 曲线来自 kube-state-metrics 指标因此该面板需要 kube-state-metrics 与 kubelet 指标同时存在。通过对比使用量与 request/limit 的差距可以判断 Alertmanager 是否面临 CPU 抢占或超额分配风险。Memory (workingset)内存面板绘制工作集内存working set memory及四组对照序列工作集内存max by(pod) (container_memory_working_set_bytes{container~alertmanager})内存 limitmin(container_spec_memory_limit_bytes{...} 0)内存 requestmin(kube_pod_container_resource_requests{...resourcememory})OOMKilled 事件利用kube_pod_container_status_last_terminated_reason{reasonOOMKilled}并通过unless ... offset $__interval技巧找出每次 OOM 的首次发生时刻在图上以红色散点标注。源码注释特别解释了内存查询使用max而非sum的原因见 config.libsonnetStatefulSet 滚动更新期间新旧 Pod 的指标会同时存在约 5 分钟sum会把新旧实例的内存相加造成虚高max则只取真实存活实例的最大值。Memory (go heap inuse)该面板显示 Alertmanager 进程的 Go 堆内存占用sum by(pod) (go_memstats_heap_inuse_bytes{container~alertmanager})。它来自 Mimir 自身的 Go runtime 指标可用于判断内存使用是否主要由堆分配驱动是区分业务内存增长与运行时开销的重要参考。Network网络行包含两个堆叠面积图Receive bandwidthsum by(pod) (rate(container_network_receive_bytes_total{cluster~$cluster, namespace~$namespace, pod~(.*mimir-)?alertmanager.*}[$__rate_interval]))Transmit bandwidthsum by(pod) (rate(container_network_transmit_bytes_total{...}[$__rate_interval]))。注意这里的实例匹配使用了(.*mimir-)?alertmanager.*这种 Helm 兼容正则由 config.libsonnet 的instanceMatcher包装生成可以同时匹配裸 Deployment 名与带mimir-前缀的 Helm Release 实例名。Disk磁盘行包含两个堆叠图聚合节点磁盘读写速率并仅保留 Alertmanager 所在 Pod 对应的设备Disk writessum by(instance, pod, device) (rate(node_disk_written_bytes_total[$__rate_interval])) ignoring(pod) group_right() (label_replace(...))Disk readssum by(instance, pod, device) (rate(node_disk_read_bytes_total[$__rate_interval])) ...。其实现思路是先用 Node Exporter 的node_disk_*_bytes_total按实例/设备聚合写入与读取速率再通过count by(instance, pod, device) (container_fs_writes_bytes_total{container~alertmanager})生成的关联矩阵做group_right()连接从而过滤出 Alertmanager Pod 实际使用的块设备。Disk space utilization最后一行是无标题的独立面板计算持久卷的容量使用率max by(persistentvolumeclaim) (kubelet_volume_stats_used_bytes{persistentvolumeclaim~.*(alertmanager).*} / kubelet_volume_stats_capacity_bytes{persistentvolumeclaim~.*(alertmanager).*})单位percentunit图例为{{persistentvolumeclaim}}。它依赖 kubelet 暴露的 volume stats 指标是判断 Alertmanager 状态存储卷是否接近饱和的关键面板。运行前提额外的资源指标与标签要求官方文档明确指出该面板requires additional resources metrics即依赖以下四个采集目标的指标详见 requirements.mdcAdvisor容器 CPU / 内存 / 网络指标如container_cpu_usage_seconds_total、container_memory_working_set_bytes、container_network_*_bytes_totalkubelet容器规格与卷指标如container_spec_memory_limit_bytes、kubelet_volume_stats_used_bytesNode Exporter节点级磁盘与网络指标如node_disk_written_bytes_total、node_disk_read_bytes_totalkube-state-metricsKubernetes 资源对象指标如kube_pod_container_resource_limits/requests。如果使用mimir-distributedHelm chart 的 metamonitoring 功能这些标签由 Helm chart 自动打上否则需要在 Prometheus 或 Grafana Alloy 的抓取配置中补齐标签。具体要求如下标签名是否可定制含义cluster是per_cluster_labelMimir 集群所在的 Kubernetes 集群或数据中心namespace是per_namespace_labelMimir 集群所在的命名空间job是job_prefix/per_job_label/job_names默认形如namespace/alertmanagerpod是per_instance_labelMimir 副本的唯一标识Kubernetes 下即 Pod IDinstance是per_node_label副本所在节点或机器的唯一标识其中 kubelet、kube-state-metrics、cAdvisor 的指标必须带与 Mimir 指标一致的cluster标签Node Exporter 与 cAdvisor 的指标必须带与 Mimir 指标相同的instance标签。此外预编译的 recording rules 与 alerts 要求抓取间隔不超过 1mPrometheus 与 mixin 默认值若放宽抓取间隔需以_config.scrape_interval重新编译 mixin保证rateInterval()窗口足够大。裸机部署与 Kubernetes 部署的差异面板默认面向 Kubernetes 容器化部署deployment_type: kubernetes。如果 Mimir 以裸机方式运行需要在 config.libsonnet 中将deployment_type改为baremetal并重新编译面板此时查询改用 Node Exporter 的node_cpu_seconds_total、node_memory_*、node_network_*_bytes_total、node_disk_*等节点级指标见resources_panel_queries.baremetal内存使用量由node_memory_MemTotal_bytes减去 Free/Buffers/Cached/Slab/PageTables/SwapCached 等计算得出limit / request 曲线不再适用resourceUtilizationAndLimitLegend只返回资源名本身磁盘空间利用率改用node_filesystem_avail_bytes/node_filesystem_size_bytes计算挂载点由instance_data_mountpoint默认/指定。安装与定制方式直接导入预编译产物mimir-distributed安装路径下可直接使用仓库中预编译好的 mimir-alertmanager-resources.json。在 Grafana 中通过 Import dashboard 上传该 JSON 即可同时将 rules.yaml 与 alerts.yaml 安装到 Prometheus。此方式使用默认标签名不支持定制完整步骤见 installing-dashboards-and-alerts.md。从源码编译需要定制标签名或部署形态时从 Jsonnet 源码编译# 克隆 Mimir 源码后 # 1. 按需修改 operations/mimir-mixin/config.libsonnet 中的 _config 字段 # 2. 编译 mixin产物输出到 operations/mimir-mixin-compiled/ make build-mixin编译完成后导入operations/mimir-mixin-compiled/dashboards/下的 JSON 文件并安装rules.yaml与alerts.yaml。以 Jsonnet mixin 方式引入若基础设施已采用 Jsonnet 管理可将 mixin vendor 进自己的仓库并覆盖_config(import github.com/grafana/mimir/operations/mimir-mixin/mixin.libsonnet) { _config:: { // 在此覆盖 Grafana Mimir mixin 配置例如 // per_instance_label: pod, // deployment_type: baremetal, }, }相关资源与延伸阅读面板 Jsonnet 定义alertmanager-resources.libsonnet面板通用构造器与资源查询模板dashboard-utils.libsonnet、config.libsonnet预编译产物mimir-alertmanager-resources.json资源指标前提与标签要求requirements.md安装与部署 mixininstalling-dashboards-and-alerts.md、deploying-monitoring-mixin.md姊妹面板Alertmanager 通用监控面板 alertmanager 仪表盘以及同一资源系列下的 overview-resources、reads-resources、writes-resources 等面板可在/dashboards目录下找到全部仪表盘入口dashboards 索引。赞分享时序数据库后端数据存储可观测性云原生【免费下载链接】mimirGrafana Mimir provides horizontally scalable, highly available, multi-tenant, long-term storage for Prometheus.项目地址https://gitcode.com/gh_mirrors/mimir/mimir点击查看免费下载相关推荐Orchard仪表盘与实时资源监控CPU、内存、网络、磁盘图表全解读Orchard仪表盘与实时资源监控CPU、内存、网络、磁盘图表全解读 Orchard 是 Apple Containers 与 o MLX 沙箱的原生应用Dnats-server资源监控CPU、内存、磁盘使用监控nats server资源监控CPU、内存、磁盘使用监控 概述 在现代分布式系统中实时监控消息中间件的资源使用情况至关重要。NATS服务器nats ser后端消息队列消息路由通信上一篇一学就会douyin-downloader 开源抖音下载神器保姆级上手教程下一篇LocalSend 的 AppImage 是怎么做到跨发行版双击就运行的创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考