关于prometheus:prometheus在项目中的使用

Prometheus 是什么

• 基于时序数据库的开源监控告警零碎，应用 go 语言
• 最后由在线音乐分享的平台 SoundCloud 开源，2016 年退出云原生计算基金会（CNCF，Cloud Native Computing Foundation）
• 宽泛用于 Kubernetes 集群的监控零碎中

时序数据的特点是：

• 增：须要频繁的进行写操作，而且是按工夫排序程序写入
• 删：不须要随机删除，个别状况下会间接删除一个工夫区块的所有数据
• 改：不须要对写入的数据进行更新
• 查：须要反对高并发的读操作，读操作是按工夫程序升序或降序读，数据量十分大，缓存不起作用

与监控数据地特点非常吻合

和 mysql、redis 相比，特点很显著：

• 多维度数据模型 - 由指标键值对标识的工夫序列数据组成（底层的数据结构是时序数列，能够对指标增加标签便于筛选）
• PromQL，一种灵便的查询语言。（在查问的时候组合条件进行筛选）
• 不依赖分布式存储; 单个服务器节点是自治的。部署不便
• 以 HTTP 形式，通过 pull 模式拉取工夫序列数据
• 反对通过两头网关推送工夫序列数据
• 通过服务发现或者动态配置，来发现指标服务对象
• 反对多种多样的图表和界面展现

目标：

• 目前的监控比拟少，现有的是健康检查，在 portainer 里看有没有失常的启用，还有在运行室配置的一些监控指标。并且大部分工夫服务都是失常运行的，不出事的话显得监控没什么意义，一旦出了问题，监控能够看呈现故障时刻的监控指标。交易数过多，内存，cpu 的状况。
• 事先预警，预先追踪
• 性能优化

架构：

组件：

• Prometheus server，用于抓取和存储工夫序列数据
• 用于检测利用程序代码的 client libraries
• 用于反对短期 jobs 的 push 网关
• 针对 HAProxy，StatsD，Graphite 等服务的特定 exporters
• 预警管理器来治理预警
• 各种反对工具

工作原理：
客户端装置 exporter，裸露监控指标的接口，prometheus 定期从客户端 pull 数据，通过 grafana 或 api clinet 进行查问。

实用场景：
记录任何纯数字工夫序列。它实用于以机器为核心的监控以及高度动静的面向服务架构的监控。在微服务的世界中，Prometheus 的多维度数据收集和查问十分弱小。
Prometheus 是为服务的可靠性而设计的，当服务呈现故障时，它能够使你疾速定位和诊断问题。每个 Prometheus 服务器都是独立的，不依赖于网络存储或其余近程服务。当基础架构的其余局部损坏时，您能够依赖它，并且您不须要设置大量的基础架构来应用它。
如果您须要 100%的准确度，例如按申请计费，Prometheus 不是一个好的抉择，因为收集的数据可能不够具体和残缺。在这种状况下，您最好应用其余零碎来收集和剖析数据以进行计费，并应用 Prometheus 进行其余监控。

Exporter
MySQL server exporter
ElasticSearch exporter
MongoDB exporter
Oracle DB Exporter
Redis exporter
RabbitMQ exporter
Node exporter
SNMP exporter

服务发现：
azure、consul、dns、ec2、openstack、file、gce、kubernetes、marathon、triton、zookeeper（nerve、serverset）

pull 拉取采样点的端点服务称之为 instance，通常对应一个过程（实例）。具备雷同目标的 instance，例如，为可伸缩性或可靠性而复制的流程称为 job。, 则形成了一个 job

数据模型：
从根本上存储的所有数据都是工夫序列: 具备工夫戳的数据流只属于单个度量指标和该度量指标下的多个标签维度。除了存储工夫序列数据外，Prometheus 还能够生成长期派生的工夫序列作为查问的后果。
每一个工夫序列数据由 metric 度量指标名称和它的标签 labels 键值对汇合惟一确定。
这个 metric 度量指标名称指定监控指标零碎的测量特色（如：http_requests_total- 接管 http 申请的总计数）。metric 度量指标可能蕴含 ASCII 字母、数字、下划线和冒号，他必须配正则表达式 a -zA-Z_:*。
labels 开启了 Prometheus 的多维数据模型：对于雷同的度量名称，通过不同标签列表的联合, 会造成特定的度量维度实例。(例如：所有蕴含度量名称为 /api/tracks 的 http 申请，打上 method=POST 的标签，则造成了具体的 http 申请)。这个查询语言在这些度量和标签列表的根底上进行过滤和聚合。扭转任何度量上的任何标签值，则会造成新的工夫序列。

• counter 是示意单个枯燥递增计数器的累积度量，其值只能在重启时减少或重置为零。Eg：申请数
• gauge 是一个度量指标，它示意一个既能够递增, 又能够递加的值。Eg：cpu 内存占用
• histogram，对察看后果进行采样（通常是申请持续时间或响应大小等），并将其计入可配置存储桶中。它还提供所有察看值的总和。
• summary 是采样点分位图统计(通常是申请持续时间和响应大小等)。尽管它还提供察看的总数和所有观测值的总和，但它在滑动工夫窗口上计算可配置的分位数。

Pull 和 push
基于 Http 形式的 pull 模型提供了一下长处：

• 当开发变动时，能够运行监控
• 如果指标实例挂掉，能够很容易地晓得
• 能够手动指定一个指标，并通过浏览器查看该指标实例的监控情况

在我的项目的利用：

• 服务的革新：

  • 通过 actuator 和 prometheus，对外裸露端点
  • Security 对裸露的端点进行爱护，每个服务增加 filter，爱护 /actuator/** 并放行 /actuator/health，以便健康检查能够通过。辨别 mvc 和 webflux 利用

• 服务发现：

  • 通过服务对外裸露的 IP:port，多正本状况下无奈获取每个容器的指标
  • 通过 eureka-consul 进行服务发现，能够获取注册到 eureka 上的所有服务。须要将 prometheus 部署到服务网络，通过外部 ip:port 获取

Prometheus server：
监控 SIT/QA/UAT 环境：

• 通过一个 prometheus 监控不同环境，通过标签（job_name）进行辨别。不可行
• Push gateway，架构简单，须要保障 pushgateway 的高可用；无奈获取各个服务的状态
• 每个环境均搭建 prometheus，grafana 共用一个，在 grafana 通过选取不同的数据源展现不同环境的数据，

Openapi 服务 监控性能

1. Grafana 中 boot，Mysql，Redis 的模板
2. 下载对应 exporter，批改配置，
3. Prometheus 批改配置，增加 exporter 监控
4. Grafana 导入模板

和时序数据库的区别：
心愿部署和保护十分不便。

在微服务架构中，不同维度有不同的监控形式。

• 健康检查。健康检查是对利用自身健康状况的监控，查看服务是否还失常存活。
• 日志。日志是排查问题的次要形式，日志能够提供丰盛的信息用于定位和解决问题。
• 调用链监控。调用链监控能够残缺的呈现出一次申请的全副信息，包含服务调用链路、所耗时间等。
• 指标监控。指标是一些基于工夫序列的离散数据点，通过聚合和计算后能反映出一些重要指标的趋势。

应用服务监控
根底监控数据次要是指应用服务实例的运行时状态、资源应用状况等度量指标。Micrometer 默认提供了十分丰盛的利用度量指标，只有接入了 Micrometer 就能够间接采集到这些数据，次要包含：

• 零碎信息，包含运行工夫、CPU 使用率、零碎负载等；
• 内存应用状况，包含堆内存应用状况和非堆内存应用状况；
• 线程应用状况，包含线程数、守护线程数、线程峰值等；
• 类加载信息；
• GC 信息，包含 GC 次数、GC 耗费工夫等；
• HTTP 申请状况，形容 HTTP 申请的性能指标，是十分重要的监控指标，在统计 HTTP 服务的 QPS、响应工夫和成功率时必不可少。