使用Prometheus监控企业级应用

39次阅读

问题描述

是一名初次接触Prometheus的用户，他已经阅读了关于Prometheus作为监控应用程序、容器和K8s对象的工具的流行性。然而，大多数博客在使用Prometheus监控关键应用程序时都只是做了非常基本的介绍，用户试图编制一个清单，列出SRE在将Prometheus设置为首选监控工具时需要了解的所有内容。

用户正在列出他目前的理解，如果有错误的地方，请随时纠正。他非常希望能从社区中了解到他人是如何最好地使用Prometheus的。

a) 安装Prometheus -> 安装Prometheus的理想位置在哪里？ 一些博客文章谈到将其安装在与应用程序部署在同一K8s集群上的位置。对用户来说，这听起来有些违反直觉，因为现在监控堆栈会消耗你的应用程序资源。或者，我们应该在其自己的单独K8s集群上部署Prometheus。在这种情况下，如何更改配置文件以自动抓取部署有两个不同应用程序的两个集群？

b) 你使用Prometheus收集了哪些数据？ 目前为止，用户已经收集了以下信息：
1. cAdvisor [用于收集运行容器的资源和使用情况数据]
2. kube-state-metrics [用于收集K8s对象状态的统计信息]
3. Node Exporters [用于收集与节点相关的指标]
4. Custom Exporters [用于将不以Prometheus格式发出指标的应用程序]

用户想知道还应该监控什么？

c) Prometheus的config.yaml文件是什么样的？ 监控上述插件/导出器时，Prometheus的config.yaml文件是什么样的？你是手动将它们添加到抓取目标的吗？在上述情况下，自动服务发现是如何工作的？是否有人可以分享用于生产场景的示例kubernetes_sd_config？（当然需要对应用程序或特定细节进行混淆）

d) 什么是用于存储时间序列数据的理想后端存储？ 应该存储多长时间的这些数据？有些可能是根据应用程序/组织的合规要求来决定的，所以在需要长期存储的情况下，有哪些度量保留的实践方法？

e) 如何为Prometheus规划灾难恢复（DR）策略？ 由于现在使用Prometheus监控应用程序，如何确保这个系统有一个有效的灾难恢复计划？如何设计这个计划？

用户希望从有经验的Prometheus用户那里获得反馈，以及这个工具如何在他们的监控实践中帮助他们。

解决方案

请注意以下操作可能受版本差异影响，修改前请备份。

安装位置和集群部署

对于Prometheus的安装位置和部署方式，不同情况下可以有不同的策略。一种常见的做法是将Prometheus部署在应用程序集群中，以便更好地与应用程序一起管理。但这可能会导致资源竞争。另一种方法是在单独的集群中部署Prometheus，以避免资源冲突。要自动抓取不同集群的数据，可以使用Prometheus的服务发现机制，如Kubernetes的ServiceDiscovery。这允许Prometheus自动发现和抓取不同集群的目标。

数据收集

你已经列出了一些重要的数据收集目标，包括cAdvisor、kube-state-metrics、Node Exporters和Custom Exporters。此外，你还可以考虑收集应用程序日志、网络流量数据、数据库性能指标等。根据你的应用程序特点，选择合适的指标进行监控。

配置文件和自动服务发现

Prometheus的配置文件是一个重要的部分，它决定了如何收集和存储数据。你可以在config.yaml中定义抓取目标、告警规则和存储配置。对于自动服务发现，你可以使用Kubernetes的ServiceDiscovery配置来自动发现和抓取目标。以下是一个示例kubernetes_sd_config片段，用于从Kubernetes集群中发现目标：

scrape_configs:
  - job_name: 'kubernetes'
    kubernetes_sd_configs:
      - role: endpoints
    relabel_configs:
      - source_labels: [__meta_kubernetes_service_label_app]
        action: keep
        regex: your_app_label

在上面的示例中，我们定义了一个抓取作业kubernetes，它使用Kubernetes的ServiceDiscovery来发现目标。通过relabel_configs，我们可以根据需要对目标进行标签过滤和重命名。