关于prometheus的一些资料收集

微服务 + 云环境 的特点：
监控对象动态可变，无法预先配置；
监控范围复杂，难以融合；
微服务之间调用复杂，排出故障困难；

Linux 基金会的云原生计算基金会（CNCF）（Cloud Native Computing Foundation）给出了云原生应用的三大特征：
容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。
动态管理：通过集中式的编排调度系统来动态的管理和调度。
面向微服务：明确服务间的依赖，互相解耦。

– Kubernetes ：集群中管理跨多台主机容器化应用的开源系统；
– Prometheus ：专注于时间序列数据，为客户端依赖及第三方数据消费提供广泛集成支持的开源监控解决方案；
– OpenTracing：与厂商无关的分布式追踪开源标准；
– Fluentd：创建统一日志层的开源数据收集器。

优点：
灵活的数据模型：监控数据由值、时间戳、标签；源数据记录在标签中，支持采集时对标签进行修改，从而使得其具有强大的扩展能力；
强大的查询能力：提供了大量的计算函数，大部分情况通过PromQL 查到需要的聚合数据；
健全的生态： 能支持常见的操作系统/中间件/数据库//编程语言的监控； 提供Java/golang/Ruby等的SDK，快速实现自定义监控；
良好的性能： 在硬件资源满足的情况下，Prometheus 单实例在每秒采集 10万条监控数据的情况下，在数据处理和查询方面依然有着不错的性能表现；
优秀的架构： 拉取模型，具体的拉取情况由服务器端决定，服务器端可以基于服务发现自动发现监控对象，多个服务端通过集群机制进行数据分片；

不足：
日志监控、分布式追踪、丢数据

从存储上来讲所有的监控指标metric都是相同的，但是在不同的场景下这些metric又有一些细微的差异。
例如，在Node Exporter返回的样本中指标node_load1反应的是当前系统的负载状态，随着时间的变化这个指标返回的样本数据是在不断变化的。
而指标node_cpu所获取到的样本数据却不同，它是一个持续增大的值，因为其反应的是CPU的累积使用时间，从理论上讲只要系统不关机，这个值是会无限变大的。

为了能够帮助用户理解和区分这些不同监控指标之间的差异，Prometheus定义了4中不同的指标类型(metric type)：Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）、Summary（摘要）。

后期的设想：

1. 服务发现
2. 同时支持黑盒与白盒监控：
   白盒能够了解其内部的实际运行状态，通过对监控指标的观察能够预判可能出现的问题，从而对潜在的不确定因素进行优化。
   黑盒监控，常见的如HTTP探针，TCP探针等，可以在系统或者服务在发生故障时能够快速通知相关的人员进行处理。
   • 长期趋势分析： 通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间增长率的判断，我们可以提前预测在未来什么时间节点上需要对资源进行扩容。
   • 对照分析：
3. 细化
   • 延迟： 服务请求所需时间
   • 通讯量： 监控当前系统的流量，用于衡量服务的容量需求。
   • 错误： 监控当前系统所有发生的错误请求，衡量当前系统错误发生的速率。
   • 饱和度： 衡量当前服务的饱和度。

由Prometheus负责收集需要的性能指标（如：当前链接的并发数，当前cpu的使用率等），根据定义好的告警规则生成告警事件，然后将告警事件传递给Alertmanager，由alertmanager触发webhook来实现最终的pod伸缩功能；

Prometheus server 定期从静态配置的 target 或者服务发现的 target 拉取数据。
当新拉取的数据大于配置内存缓存区的时候，Prometheus 会将数据持久化到磁盘。
Prometheus配置rule，然后定时查询数据，当条件触发的时候，会将 alert 推送到配置的 Alertmanager。
Alertmanager 收到警告的时候，可以根据配置，聚合、去重、降噪，最后发送警告。
可以使用 API、Prometheus Console 或者 Grafana 查询和聚合数据。

当前系统的CPU使用率？
avg(irate(node_cpu{mode!=“idle”}[2m])) without (cpu, mode)
CPU占用率前5位的主机有哪些？
topk(5, avg(irate(node_cpu{mode!=“idle”}[2m])) without (cpu, mode))
预测在4小时候后，磁盘空间占用大致会是什么情况？
predict_linear(node_filesystem_free{job=“node”}[2h], 4 * 3600)

其中avg()，topk()等都是PromQL内置的聚合操作，irate()，predict_linear()是PromQL内置的函数，irate()函数可以计算一段时间返回内时间序列中所有样本的单位时间变化率。predict_linear函数内部则通过简单线性回归的方式预测数据的变化趋势。

使用Blackbox进行黑盒监控

在前面的部分中，我们主要介绍了Node Exporter的使用，对于这类Exporter而言，它们主要监控服务或者基础设施的内部使用状态，即白盒监控。通过对监控指标的观察能够预判可能出现的问题，从而对潜在的不确定因素进行优化。
而从完整的监控逻辑的角度，除了大量的应用白盒监控以外，还应该添加适当的黑盒监控。
黑盒监控即以用户的身份测试服务的外部可见性，常见的黑盒监控包括HTTP探针、TCP探针等用于检测站点或者服务的可访问性，以及访问效率等。
黑盒监控相较于白盒监控最大的不同在于黑盒监控是以故障为导向当故障发生时，黑盒监控能快速发现故障，而白盒监控则侧重于主动发现或者预测潜在的问题。
一个完善的监控目标是要能够从白盒的角度发现潜在问题，能够在黑盒的角度快速发现已经发生的问题。
这里类比敏捷中著名的敏捷测试金字塔，对于完整的监控而言，我们需要大量的白盒监控，用于监控服务的内部运行状态，从而可以支持有效的故障分析。
同时也需要部分的黑盒监控，用于检测主要服务是否发生故障。
Blackbox Exporter是Prometheus社区提供的官方黑盒监控解决方案，其允许用户通过：HTTP、HTTPS、DNS、TCP以及ICMP的方式对网络进行探测。
用户可以直接使用go get命令获取Blackbox Exporter源码并生成本地可执行文件。

通过时间窗口的形式保存所有的样本数据，可以明显提高Prometheus的查询效率，当查询一段时间范围内的所有样本数据时，只需要简单的从落在该范围内的块中查询数据即可。
而对于历史数据的删除，也变得非常简单，只要删除相应块所在的目录即可。
对于单节点的Prometheus而言，这种基于本地文件系统的存储方式能够让其支持数以百万的监控指标，每秒处理数十万的数据点。为了保持自身管理和部署的简单性，Prometheus放弃了管理HA的复杂度。
因此首先，对于这种存储方式而言，我们需要明确的几点：
Prometheus本身不适用于持久化存储长期的历史数据，默认情况下Prometheus只保留15天的数据。
本地存储也意味着Prometheus自身无法进行有效的弹性伸缩。
而当监控规模变得巨大的时候，对于单台Prometheus而言，其主要挑战包括以下几点：
服务的可用性，如何确保Prometheus不会发生单点故障；
监控规模变大的意味着，Prometheus的采集Job的数量也会变大（写）操作会变得非常消耗资源；
同时也意味着大量的数据存储的需求。

对于诸如Kubernetes这类容器或者云环境，对于Prometheus而言，需要解决的一个重要问题就是如何动态的发现部署在Kubernetes环境下的需要监控的所有目标。

对于Kubernetes而言，如上图所示，我们可以把当中所有的资源分为几类：
基础设施层（Node）：集群节点，为整个集群和应用提供运行时资源
容器基础设施（Container）：为应用提供运行时环境
用户应用（Pod）：Pod中会包含一组容器，它们一起工作，并且对外提供一个（或者一组）功能
内部服务负载均衡（Service）：在集群内，通过Service在集群暴露应用功能，集群内应用和应用之间访问时提供内部的负载均衡
外部访问入口（Ingress）：通过Ingress提供集群外的访问入口，从而可以使外部客户端能够访问到部署在Kubernetes集群内的服务

因此，在不考虑Kubernetes自身组件的情况下，如果要构建一个完整的监控体系，我们应该考虑，以下5个方面：
集群节点状态监控：从集群中各节点的kubelet服务获取节点的基本运行状态；
集群节点资源用量监控：通过Daemonset的形式在集群中各个节点部署Node Exporter采集节点的资源使用情况；
节点中运行的容器监控：通过各个节点中kubelet内置的cAdvisor中获取个节点中所有容器的运行状态和资源使用情况；
从黑盒监控的角度在集群中部署Blackbox Exporter探针服务，检测Service和Ingress的可用性；
如果在集群中部署的应用程序本身内置了对Prometheus的监控支持，那么我们还应该找到相应的Pod实例，并从该Pod实例中获取其内部运行状态的监控指标。

附录：什么是时序数据库？
上文提到 Prometheus 是一款基于时序数据库的监控系统，时序数据库常简写为 TSDB（Time Series Database）。很多流行的监控系统都在使用时序数据库来保存数据，这是因为时序数据库的特点和监控系统不谋而合。
增：需要频繁的进行写操作，而且是按时间排序顺序写入
删：不需要随机删除，一般情况下会直接删除一个时间区块的所有数据
改：不需要对写入的数据进行更新
查：需要支持高并发的读操作，读操作是按时间顺序升序或降序读，数据量非常大，缓存不起作用

随着heapster不再开发和维护以及influxdb 集群方案不再开源，heapster+influxdb的监控方案，只适合一些规模比较小的k8s集群。而prometheus整个社区非常活跃,除了官方社区提供了一系列高质量的exporter，例如node_exporter等。Telegraf(集中采集metrics) + prometheus的方案，也是一种减少部署和管理各种exporter工作量的很好的方案。
今天主要讲讲我司在使用prometheus过程中，存储方面的一些实战经验。

各自的监控特点？
监控对象动态变化，无法预先配置；监控范围复杂，难以监控；微服务之间调用复杂，排出困难；
配置方式？
图形化 配置文件
数据库？
关系型数据库 时间序列数据库
有zabbi的存在，为什么需要引入Prometheus ?
Prometheus 的时序型数据库在高并发的情况下，读写性能是远高过传统的关系型数据库的，另外还提供了很多内置的基于时间的处理函数，简化数据聚合的难度。

监控系统选型
Prometheus监控场景： 业务监控、性能监控、容器监控、微服务监控、部分应用监控（能够做的应用监控）
Zabbix监控场景：硬件监控、系统监控，网络监控，部分应用监控（如：Oracle）,其他监控（URL监控、端口监控）

语言扩展：Go/Java/Python/Ruby/Bash…
插件扩展：Database(Mysql/Mongo),Hardware(Node/Ibm)，MessageSys(Kafka/Rabbit),Http(apache/nginx)…
自定义：PushGateway(http_request_duration_seconds_bucket{le=“0.05”} 24054)

在分享的前半部分，缺少与同事的沟通，分享过程也比较沉静；后半部分，答疑和讨论较为活跃；希望后期如有分享能改进；

关于读写速度/磁盘性能的问题：

关于时间窗口的问题，小于scrape_interval

关于时间戳取值的问题：

关于图形化配置界面的问题：