【大数据运维监控】Prometheus 内置的一些 Metrics

本文深入探讨Prometheus监控系统自身的重要监控指标,包括运行时状态、规则运行状态、采集状态及存储状态,旨在帮助读者理解如何利用这些指标进行系统健康诊断。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在使用 Prometheus 的时候,我们总会遇到 Prometheus 自身的监控指标,有些指标是需要结合到这些 指标来进行分析的吗,这里简单的收集点 Prometheus 的自身的指标。

运行时的状态

Prometheus 是一个 Go 开发的程序,自然是包含了 Go 的一些基础指标,在 Prometheus 中,常见的 Go 的指标有:

  • go_goroutines
  • go_memstats_heap_alloc_bytes
  • go_memstats_heap_released_bytes

这些 metric 主要是在定位 prometheus 运行过程中内存或者 CPU 占用高的时候会比较有用,但是说实话,我用的不多,以为真的泄漏的时候,看这些 metric 还是不够的,需要结合 pprof 进行。

规则运行状态

在一个成熟的监控系统中,可能会设置很多不同的规则,但是,执行这些规则都是需要耗费系统资源的,所以,当有一些意外情况的时候,下面这些 metric 可能就能帮助上了:

  • prometheus_rule_evaluation_duration_seconds:所有的 rules(recording/alerting) 的计算的时间(分位值),这个可以用来分析规则是否过于复杂以及系统的状态是否繁忙
  • prometheus_rule_evaluation_duration_seconds_count:执行所有的 rules 的累积时长,没怎么用到
  • prometheus_rule_group_duration_seconds:具体的 rule group 的耗时
  • prometheus_rule_group_interval_seconds:具体的 rule group 的执行间隔(如果没有异常,应该和配置中的一致,如果不一致了,那很可能系统负载比较高)
  • prometheus_rule_group_iterations_missed_total:因为系统繁忙导致被忽略的 rule 执行数量
  • prometheus_rule_group_last_duration_seconds:最后一次的执行耗时

采集状态

这是一个比较重要的状态,例如我经常关心的是 prometheus 采集 exporter 是否正确,是否真的采集到了数据还是说 exporter 超时之类的异常,那么都是通过这个类别的 metric 来定位的。

这个类别的 metric 其实就 5 个,分别是:

  • up:对应的 scrape target 是否是健康的,0 表示不在线(采集失败了),1 表示正常
  • scrape_duration_seconds:采集这个 scrape target 花费的时间,这个可以用来定位 timeout
  • scrape_samples_post_metric_relabeling:在 metric 被 relabel 之后,还剩下的 sample 数量,关于 relabel 可以查看我的另外一篇文章。
  • scrape_samples_scraped:scrape target 暴露出来的 sample 数量
  • scrape_series_added:在 2.10 添加的新 metric,表示这个 scrape target 新增加的系列数

存储状态

在 Prometheus 中,用的是自己的存储引擎,并且它会进行内存缓存。所以,当发现查询数据不对或者内存占用偏高的时候,最后不妨怀疑一下是不是存储的问题,下面是一些可能有价值的数据:

  • prometheus_tsdb_blocks_loaded:当前已经加载到内存中的块数量
  • prometheus_tsdb_compactions_triggered_total:压缩操作被触发的次数(可能很多,但不是每次出发都会执行)
  • prometheus_tsdb_compactions_total:启动到目前位置压缩的次数(默认是 2 小时一次)
  • prometheus_tsdb_compactions_failed_total:压缩失败的次数
  • prometheus_tsdb_head_chunks:head 中存放的 chunk 数量
  • prometheus_tsdb_head_chunks_created_total:head 中创建的 chunks 数量
  • prometheus_tsdb_head_chunks_removed_total:head 中移除的 chunks 数量
  • prometheus_tsdb_head_gc_duration_seconds:head gc 的耗时(分位值)
  • prometheus_tsdb_head_max_time:head 中的有效数据的最大时间(这个比较有价值)
  • prometheus_tsdb_head_min_time:head 中的有效数据的最小时间(这个比较有价值)
  • prometheus_tsdb_head_samples_appended_total:head 中添加的 samples 的总数(可以看增长速度)
  • prometheus_tsdb_head_series:head 中保存的 series 数量
  • prometheus_tsdb_reloads_total:rsdb 被重新加载的次数
<think>嗯,用户问的是大数据开发和大数据运维的区别。我需要先回忆一下这两个领域的核心职能和技能要求。大数据开发主要负责构建和处理数据平台,编写数据处理程序,可能涉及数据采集、清洗、存储和分析。而大数据运维可能更关注系统的稳定性、性能优化和故障处理,比如集群的监控、调优和灾备。 接下来要确认两者的技术栈是否有重叠或差异。开发可能需要Hadoop、Spark、Flink这些框架,以及编程语言如Java、Scala、Python。运维可能需要熟悉集群管理工具,比如Ambari、Cloudera Manager,还有监控工具如Prometheus、Grafana,以及自动化运维脚本。 职业发展方向也需要区分,开发可能走向数据工程师、架构师,运维可能转向系统运维专家或DevOps。但用户可能想知道更具体的区别,比如日常任务的不同,或者技能要求的侧重点。 还要考虑用户可能的背景,是否在考虑职业选择,或者项目分工。需要给出实际场景的例子,比如开发搭建ETL流程,运维确保集群高可用。同时,两者的协作关系也很重要,避免让用户觉得完全割裂。 需要检查是否有遗漏点,比如数据安全、成本管理是否属于运维职责,而数据建模、算法实现是否属于开发。另外,是否需要提到对编程能力的重视程度,开发更注重编码,运维可能更注重脚本和自动化。 最后,确保结构清晰,分点对比,帮助用户逐步理解两者的区别,并给出职业建议。避免使用过于专业的术语,保持口语化但准确。</think>大数据开发与大数据运维是数据领域中两个紧密关联但职责分明的方向,以下是逐步对比与分析: --- ### **1. 核心目标对比** - **大数据开发** - **目标**:设计、构建和维护数据处理系统,解决数据采集、存储、计算及分析需求。 - **典型任务**: - 编写ETL(数据抽取、转换、加载)流程 - 开发分布式计算程序(如Spark、Flink作业) - 设计数据仓库或数据湖架构 - 实现数据建模与算法(如推荐系统) - **大数据运维** - **目标**:保障大数据平台稳定、高效运行,优化资源利用率并快速响应故障。 - **典型任务**: - 集群部署与扩容(如Hadoop、Kafka集群) - 监控系统健康状态(CPU、内存、磁盘、网络) - 调优性能瓶颈(如调整YARN资源分配) - 制定灾备方案与数据安全策略 --- ### **2. 技术栈差异** #### **大数据开发** - **编程能力**: - 需精通Java/Scala/Python等语言,熟悉面向对象与函数式编程。 - 示例代码: ```python # Spark数据处理示例 df = spark.read.parquet("hdfs://data/logs") result = df.groupBy("user_id").agg(F.sum("clicks")) ``` - **核心技术**: - 计算框架:Spark、Flink、MapReduce - 存储系统:HDFS、HBase、Kafka - 数据处理:Hive、Presto、Airflow #### **大数据运维** - **系统管理能力**: - 熟悉Linux系统调优、Shell脚本编写。 - 示例命令: ```bash # 监控HDFS磁盘使用率 hdfs dfsadmin -report | grep "Used%" ``` - **核心技术**: - 集群管理:Ambari、Cloudera Manager - 监控工具:Prometheus、Grafana、Zabbix - 自动化运维:Ansible、Kubernetes --- ### **3. 工作场景示例** - **开发场景**: - 需求:搭建实时用户行为分析系统。 - 步骤: 1. 用Kafka接入实时数据流 2. 开发Flink作业清洗数据 3. 将结果写入HBase供查询 - **运维场景**: - 问题:Hadoop集群频繁出现节点宕机。 - 排查: 1. 通过监控发现磁盘IO过高 2. 优化HDFS副本策略 3. 增加监控告警阈值 --- ### **4. 职业发展路径** - **大数据开发**: - 初级 → 中级:数据工程师 → 高级:数据架构师/算法专家 - 关键能力:代码设计、分布式系统原理、算法优化 - **大数据运维**: - 初级 → 中级:运维工程师 → 高级:SRE(站点可靠性工程师)/DevOps专家 - 关键能力:故障定位、容量规划、自动化体系建设 --- ### **5. 协作关系** 两者需紧密配合: - 开发需遵循运维制定的资源规范(如避免OOM导致集群崩溃)。 - 运维需理解业务逻辑(如调整Kafka分区数以匹配数据处理吞吐量)。 --- ### **总结选择建议** - **选开发**:若热衷编程、算法,喜欢从零构建系统。 - **选运维**:若擅长系统调优,对稳定性保障有强烈责任感。 - **趋势**:云原生时代,运维需掌握Kubernetes等云技术,开发需关注Serverless架构。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值