[从零构建Prometheus监控] 第一节：设计思路与prometheus监控架构

引言

Prometheus是一款开源的系统监控和警报工具，最初由SoundCloud开发并贡献给开源社区，目前已成为云原生监控领域的主流工具。它能够收集、存储、查询和可视化各种系统和应用程序的度量数据，并提供强大的警报机制以及灵活的查询语言（PromQL）。

Prometheus采用pull方式，通过HTTP协议从被监控的目标实例中获取度量数据，因此能够适用于各种类型的系统和应用程序。它提供了一个简单易用的Web界面进行数据查询、可视化和警报管理，同时还支持与Grafana等其他系统监控和日志分析工具进行集成。

除了基本的度量数据监控，Prometheus还支持分布式追踪、长期存储、数据切分和分区等高级功能，能够帮助用户实现更加复杂的监控场景和数据管理需求。

调研

确定了以Prometheus监控体系为核心之后，我们围绕Prometheus周边生态来进行调研。

1. 数据采集器：Prometheus支持多种数据采集器，包括通过HTTP协议暴露的metrics端点、JMX exporter、Node exporter等。
2. 存储引擎：虽然Prometheus使用本地时序数据库存储采集到的数据，支持水平扩展。在调研过程中我们发现比Prometheus更适合作为存储引擎的VictoriaMetrics，它是一款高性能、易扩展、轻量级的时间序列数据库（TSDB）和监控系统。
3. 查询语言：PromQL是Prometheus的查询语言，支持聚合、筛选、计算等功能，可以生成图表、警报和仪表板。VictoriaMetrics同时兼容PromQL。
4. 监控组件：Prometheus提供了Grafana、Alertmanager等监控组件，可以用于数据可视化、告警管理等。但Alertmanager配置麻烦，我们选用更加易用的夜莺Nightingale来作为告警中心
5. 服务监控：Prometheus可以和Kubernetes、Docker、OpenTracing等生态系统进行整合，提供更加全面的监控和分析功能。为了更加全面的监控Kubernetes集群以及集群上的服务，我们需要单独在每个集群上都部署prometheus，并将远程存储配置为VictoriaMetrics

总的来说，Prometheus的生态系统比较完备，可以满足不同应用场景的监控需求。但是，Prometheus在存储数据、查询性能等方面还存在一些局限性，需要结合具体场景进行优化和规划。

监控架构

先出架构图

主要组件和解释：

1. 多数据中心或跨云:

   • AZ1 和 AZ2，可能代表两个不同的可用区或数据中心。

2. 组件:

   • VM: 代表虚拟机，有多种服务运行，如 solace, mysql, redis 等。
   • Exporter: 用于监控不同服务的指标导出器。例如，mysql_exporter 用于监控 mysql，redis_exporter 用于监控 redis 等。
   • node_exporter: 用于收集操作系统级别的指标。
   • k8s prometheus: Kubernetes 上的 Prometheus 服务，用于收集 Kubernetes 的指标。
   • VictoriaMetric: 用作存储解决方案，用于存储 Prometheus 的指标数据。
   • grafana: 可视化工具，用于展示监控指标。
   • 夜莺Nightingale: 告警与推送通知服务。

3. 工作流程:

   • 各种 exporter 从其关联的服务或 VM 中采集数据，并将这些数据发送到 prometheus。
   • prometheus 从所有这些 exporter 中收集数据，并可能将其存储在 VictoriaMetric 中。
   • kubernetes-prometheus作为一个单独的指标采集节点，负责kubernetes node/pod等运行在kubernetes上的服务。直接将指标存储至远程存储点VictoriaMetrics
   • grafana 从 VictoriaMetric 中读取数据，并为用户提供可视化界面。
   • 夜莺Nightingale从VictoriaMetric查询告警规则，并提供告警触发和消息推送。

4. 告警通知:

   • 通过夜莺Nightingale触发告警，配置邮件推送或自定义的推送方式

综上，这是一个典型的监控系统架构，其中涉及数据收集、存储和可视化，并具有警报功能。

---

更多具体实现，关注专栏：Prometheus监控