Prometheus常见问题

DevOps
留言

【监控】Prometheus(普罗米修斯)监控概述

最佳实践：4个黄金指标和USE方法

4个黄金指标: 延迟，通讯量，错误以及饱和度…


一、版本的选择

二、Prometheus 的局限

三、K8S集群中常用的 exporter

四、K8S核心组件监控与 Grafana 面板

五、采集组件 All IN One 六、合理选择黄金指标

七、K8S 1.16中Cadvisor的指标兼容问题

八、Prometheus采集外部K8S集群、多集群

九、GPU 指标的获取

十、更改 Prometheus 的显示时区

十一、如何采集LB后面的 RS的 Metric

十二、Prometheus大内存问题

十三、Prometheus 容量规划

十四、对 Apiserver 的性能影响

十五、Rate 的计算逻辑

十六、Prometheus 重启慢与热加载

十七、你的应用需要暴露多少指标

十八、node-exporter 的问题

十九、kube-state-metric的问题

二十、relabel configs与metric_relabel_configs

二十一、找到最大的metric或job

二十二、反直觉的 P95统计

二十三、慢查询问题

二十四、高基数问题 Cardinality

二十五、Prometheus的预测能力

二十六、alertmanager 的上层封装

二十七、错误的高可用设计

二十八、prometheus-operator 的场景

二十九、高可用方案

三十、容器日志与事件

一、版本的选择：


选择最新版本的Prometheus和相关组件，以获得最新的功能和修复的问题。


二、Prometheus的局限：


Prometheus在处理长期存储和处理高基数（高唯一度）数据时存在一些局限。它通常用于短期监控和警报，而不适用于长期存储和分析。


三、K8S集群中常用的exporter：


在Kubernetes集群中，常用的exporter包括node-exporter（主机指标）、kube-state-metrics（集群状态指标）、cAdvisor（容器指标）和kubelet等。


四、K8S核心组件监控与Grafana面板：


使用Prometheus可以监控Kubernetes的核心组件，如kube-apiserver、kube-controller-manager、kube-scheduler和etcd。通过配置相应的监控指标和Grafana仪表板，可以可视化这些组件的运行状态和性能指标。


五、采集组件All IN One：


Prometheus本身是一个全功能的指标采集、存储和查询系统，可以用于采集各种指标，包括主机、容器和应用程序指标。


六、合理选择黄金指标：


选择适合您的应用程序的关键性能指标作为黄金指标。这些指标应该能够准确反映应用程序的运行状态和性能，并帮助您判断应用程序是否正常运行。


七、K8S 1.16中cAdvisor的指标兼容问题：


在Kubernetes 1.16及更高版本中，kubelet默认启用了kubelet CRI（Container Runtime Interface）插件，将容器的监控指标收集交给容器运行时来处理，而不再由cAdvisor负责。因此，您需要相应地调整Prometheus的配置来采集这些指标。


八、Prometheus采集外部K8S集群、多集群：


您可以通过在Prometheus配置中添加额外的目标（target）来采集外部Kubernetes集群的指标。如果要监控多个集群，您可以在Prometheus中配置多个目标，并使用合适的标签（labels）来区分它们。


九、GPU指标的获取：


要获取GPU指标，您可以使用专门的exporter，如NVIDIA GPU Exporter或Prometheus NVIDIA GPU Exporter。这些exporter可以提供GPU的各种性能指标。


十、更改Prometheus的显示时区：


Prometheus默认使用UTC时区显示时间戳。要更改为其他时区，可以在Prometheus的配置文件中设置storage.tsdb.time-zone参数。


十一、如何采集LB后面的RS的Metric：


要采集负载均衡器（LB）后面的副本集（ReplicaSet）的指标，可以通过在负载均衡器和副本集之间的服务层级添加Prometheus的exporter。Exporter可以从副本集中收集指标，并使其可供Prometheus采集和监控。


十二、Prometheus大内存问题：


如果您在监控大规模环境或采集大量指标时遇到Prometheus的大内存问题，可以考虑以下解决方案：

  • 调整Prometheus的配置，限制样本保留时间和采样频率，以减少内存消耗。
  • 使用分布式Prometheus方案，如Thanos或M3DB，将数据存储在分布式存储系统中，减轻单个Prometheus实例的内存负担。
  • 考虑使用Prometheus的分片（sharding）功能，将指标数据分散到多个Prometheus实例中，以减少单个实例的负载。

十三、Prometheus容量规划：


进行Prometheus的容量规划时，需要考虑以下因素：

  • 预期的指标数量和采集频率。
  • 样本保留时间和数据压缩设置。
  • 高可用性和冗余存储需求。
  • 预计的查询负载和聚合操作。

根据这些因素，可以评估所需的存储空间、内存和计算资源，并相应地配置Prometheus实例。


十四、对Apiserver的性能影响：


Prometheus对Apiserver的性能影响通常较小。Apiserver本身具有高度可扩展性和并发处理能力。Prometheus通过定期轮询Apiserver的指标端点来获取指标数据，并不会对Apiserver的核心功能产生重大影响。但在大规模部署中，如果Prometheus的轮询频率过高，可能会对Apiserver的性能产生轻微影响。因此，需要根据具体情况调整Prometheus的轮询间隔。


十五、Rate的计算逻辑：


在Prometheus中，Rate函数用于计算指标的速率（rate）或变化率。它基于指标样本之间的时间间隔和值的差异来计算速率。Rate函数可以根据指标的时间序列数据自动处理样本间隔不均匀的情况，从而提供相对稳定的速率计算。


十六、Prometheus重启慢与热加载：


Prometheus在重启时需要重新加载和处理存储的时间序列数据，因此在处理大规模数据集时可能会导致较长的重启时间。为了解决这个问题，可以考虑以下方法：

  • 使用持久化存储：将Prometheus的时间序列数据存储到持久化存储中，例如使用TSDB（时间序列数据库）或远程存储方案。这样，在重启后可以快速加载已保存的数据，减少启动时间。
  • 使用热加载：Prometheus支持热加载配置文件，即在运行时重新加载配置文件而无需重启整个进程。可以通过发送SIGHUP信号给Prometheus进程来触发热加载，使新的配置生效，而无需停止和启动Prometheus。

十七、你的应用需要暴露多少指标：


应用程序需要暴露的指标数量取决于您的监控需求和对应用程序性能的关注点。通常，应该选择那些对于监控应用程序的关键性能方面至关重要的指标。避免暴露大量不必要或冗余的指标，以减少资源消耗和管理复杂性。重点关注对于问题排查、性能优化和容量规划至关重要的关键指标。


十八、node-exporter的问题：


如果您在使用node-exporter时遇到问题，可以考虑以下解决方法：

  • 检查配置：确保您正确配置了node-exporter的参数，例如监听的端口、采集的指标等。
  • 检查权限：确保node-exporter运行的用户或服务账户具有足够的权限来访问系统信息和指标。
  • 日志调试：查看node-exporter的日志文件，以了解是否有任何错误或异常情况。
  • 版本兼容性：确保您使用的node-exporter版本与您的操作系统和Prometheus版本兼容。

十九、kube-state-metric的问题：


如果您在使用kube-state-metric时遇到问题，可以考虑以下解决方法：

  • 检查配置：确保您正确配置了kube-state-metric的参数，例如监听的端口、与Kubernetes API的连接等。
  • 检查权限：确保kube-state-metric运行的用户或服务账户具有足够的权限来访问Kubernetes API并获取集群状态信息。
  • 日志调试：查看kube-state-metric的日志文件，以了解是否有任何错误或异常情况。
  • 版本兼容性：确保您使用的kube-state-metric版本与您的Kubernetes版本兼容。

二十、relabel_configs与metric_relabel_configs：


relabel_configs和metric_relabel_configs是Prometheus配置中用于对指标进行重标签（relabel）或重命名的配置选项。它们允许您修改指标的标签，包括删除、替换、保留或添加新的标签。relabel_configs适用于对所有指标生效，而metric_relabel_configs仅适用于指定的指标。


二十一、找到最大的metric或job：


要找到Prometheus中最大的指标或作业（job），您可以使用PromQL查询来获取相关指标的信息，并使用函数如topk()或max()来筛选最大值。例如，要找到最大的指标值，可以使用以下查询：topk(1, metric_name)。要找到具有最多指标值的作业，可以使用类似的查询，将metric_name替换为count(metric_name) by (job)。


二十二、反直觉的P95统计：


P95（95th percentile）是指超过95%观测值的度量值。在某些情况下，P95统计可能出现反直觉的情况，即它的值比平均值或其他百分位数更高。这通常是由于极端值或异常值对P95的影响所致。P95统计更关注极端情况，而不受整体分布的中心趋势影响。因此，在分析和解释P95统计时，需要注意可能存在的异常值和极端情况。


二十三、慢查询问题：


慢查询问题通常涉及到查询性能较差或延迟较高的情况。对于Prometheus中的慢查询问题，可以考虑以下解决方法：
  • 优化PromQL查询：确保查询语句使用高效的PromQL语法和函数，并避免不必要的计算和过滤操作。
  • 提高资源配置：增加Prometheus实例的资源配置，例如内存和CPU，以提高查询性能和响应速度。
  • 减少查询范围：尽量缩小查询范围，例如通过限制时间范围、过滤标签或减少查询返回的数据量来减少查询的复杂性。
  • 分布式查询：考虑使用分布式查询方案，如Thanos或M3DB，将查询负载分散到多个Prometheus实例中，以提高查询性能和可伸缩性。

如果仍然遇到慢查询问题，可以使用Prometheus的查询日志和监控工具进行进一步的调试和分析。


二十四、高基数问题（Cardinality）：


高基数问题指的是在指标或标签中存在大量唯一值（高基数）的情况。这可能会导致Prometheus的存储和查询性能下降。为了应对高基数问题，可以考虑以下方法：

  • 减少标签数量：评估指标和标签的必要性，尽量减少不必要的标签，以降低基数。
  • 使用合理的标签：确保使用具有实际意义和较低基数的标签，避免使用高基数的标签。
  • 聚合数据：使用Prometheus的聚合功能，如sum、avg、max等，将数据聚合为更高层次的指标，以减少存储和查询的数据量。

二十五、Prometheus的预测能力：


Prometheus本身并不提供直接的预测功能。它主要用于监控和度量数据的收集、存储和查询。然而，通过与其他工具和库的集成，可以利用Prometheus的数据来进行预测分析。例如，可以使用外部数据分析工具（如Python的NumPy和Pandas）来分析Prometheus收集的时间序列数据，并应用时间序列分析算法进行预测。


二十六、Alertmanager的上层封装：


Alertmanager是Prometheus生态系统中的组件，用于处理和发送警报通知。上层封装通常是指使用其他工具或系统对Alertmanager进行进一步的包装和集成，以满足特定的需求或增加功能。这可能包括使用消息队列、自动化工具或监控平台与Alertmanager的集成，以提供更灵活和综合的警报处理能力。


二十七、错误的高可用设计：


错误的高可用设计可能包括以下问题：

  • 单点故障：没有充分考虑系统中可能存在的单点故障，并未采取适当的冗余措施。
  • 不恰当的容错机制：没有实施合适的容错机制，如故障转移、负载均衡和故障恢复策略。
  • 不完善的监控和警报：没有足够的监控和警报机制来及时发现和应对故障情况。
  • 不合理的容量规划：未对系统容量进行合理规划，导致性能瓶颈和资源耗尽的问题。

二十八、prometheus-operator的场景：


prometheus-operator适用于以下场景：

  • Kubernetes环境：prometheus-operator是为Kubernetes设计的，可以方便地在Kubernetes集群中部署和管理Prometheus实例及其相关组件。
  • 自动化管理：prometheus-operator通过自动化的方式管理Prometheus配置和部署，简化了Prometheus的运维工作，提高了部署效率和一致性。
  • 服务发现和监控：prometheus-operator集成了服务发现功能，能够自动发现和监控Kubernetes集群中的服务和应用程序。
  • 可扩展性和高可用性：prometheus-operator支持水平扩展和高可用配置，可以在需要时轻松扩展Prometheus实例，并通过自动备份和故障转移实现高可用性。

二十九、高可用方案：


在Prometheus中实现高可用性可以采用以下策略：

  • 复制Prometheus实例：使用多个Prometheus实例进行复制和故障转移，以确保在单个实例故障时仍然能够提供监控数据。
  • 使用分布式存储：将Prometheus的存储数据存储在分布式存储系统中，如分布式文件系统（例如NFS或GlusterFS）或对象存储（如S3），以实现数据的持久性和高可用性。
  • 使用远程写入器（remote write）：将Prometheus实例的数据写入到远程存储中，例如使用Thanos或VictoriaMetrics进行远程写入，以实现数据的冗余备份和故障转移。
  • 配置警报管理器（Alertmanager）的高可用性：使用多个Alertmanager实例进行复制和故障转移，以确保在单个实例故障时仍然能够发送警报通知。

三十、容器日志与事件


在容器化环境中，容器日志和事件是非常重要的信息来源，用于监控和故障排除。以下是在Prometheus中处理容器日志和事件的一些常见方法：

  • 日志聚合：使用日志收集工具（如Fluentd、Logstash、Filebeat等）将容器日志聚合到集中式日志存储系统（如Elasticsearch、Graylog、Splunk等）。这样可以通过查询和分析集中式日志数据来获取有关容器的详细信息。

  • 日志导入：将关键的日志信息导入到Prometheus中。这可以通过使用Prometheus的插件或exporter实现，例如Promtail exporter，它专门用于收集和导入日志到Prometheus。

  • 事件监控：使用Kubernetes提供的事件 API 或使用kube-state-metrics等工具来监控容器事件。这些工具可以提供有关容器的事件信息，例如容器的启动、停止、重启等事件。

  • 日志和事件的关联：通过在Prometheus中使用标签匹配功能，可以将容器指标与其相关的日志和事件进行关联。例如，可以使用容器的标签（如容器名称、Pod名称等）将指标数据与日志或事件关联起来，从而更好地理解容器的运行状况和行为。

需要注意的是，Prometheus本身并不是专门用于处理日志的工具，而是更适合于时间序列数据的监控和度量。因此，对于较大规模的日志收集和分析，可能需要结合其他专门的日志管理工具来完成更复杂的日志处理需求。