prometheus
prometheus是继k8s之后，第二个被托管到CNCF的项目，是一个开源的监控报警系统。
1.prometheus支持多维数据模型，每一个时间序列数据都由metric度量指标名称和它的标签label组成一组键值对。
2.Prometheus有自己的PromQL查询语言。
3.Prometheus可以直接在本地部署，不依赖分布式存储。
4.基于HTTP的pull方式采集时序数据。
5.可以通过中间网关pushgateway的方式把时间序列数据推送到Prometheus server端。
6.可以配置动态静态的服务发现。
7.搭配granfa进行可视化。
8.高效存储，每个采样数据占3.5 bytes左右。
9.可以对数据做异地备份，实现高可用。
prometheus结构
下图为Prometheus的结构，可以看到retrieval用来收集数据，要么是从例如sql、nginx等有自己exporter的服务里面收集，要么是从一些动态创建的jobs里面收集，这些生命周期较短的job会把自己的数据推送到pushgateway，然后统一由retrieval收集。
TSDB全称为time series database，是存储时序数据的数据库，由promQL语言进行操作
HTTP server 是一个关键组件，它主要负责处理外部的 HTTP 请求。这包括接收来自用户（通过 Prometheus 的 Web UI）、API 客户端（如 Grafana）或其他系统（如 Alertmanager）的查询和命令。
服务发现：可以配置静态的服务发现如file_sd，或者动态的服务发现如k8s集群中的服务发现。
TSDB可以配置报警规则，但是真正报警的是alertmanager。
zbbix
zbbix是一个发展了十年的监控插件。prometheus是用go开发的，zbbix是用C++开发的。zbbix用的是关系型数据库，而Prometheus使用的是时序数据库，更适合数据聚合。Prometheus安装比较复杂，而zbbix安装比较简单。
部署方式
基本高可用：每个节点部署一个Prometheus，共享数据，但是一旦一个节点上的Prometheus坏掉，就会导致数据丢失。这种方式在Prometheus server前面放置一个elastic load balancer，用来负载均衡。基本的 HA 模式只能确保 Promthues 服务的可用性问题，但是不解决 Prometheus Server 之间的数据 一致性问题以及持久化问题(数据丢失后无法恢复)，也无法进行动态的扩展。因此这种部署方式适合监 控规模不大，Promthues Server 也不会频繁发生迁移的情况，并且只需要保存短周期监控数据的场景。
高可用+远程存储：在解决了 Promthues 服务可用性的基础上，同时确保了数据的持久化，当 Promthues Server 发生宕 机或者数据丢失的情况下，可以快速的恢复。 同时 Promthues Server 可能很好的进行迁移。因此，该 方案适用于用户监控规模不大，但是希望能够将监控数据持久化，同时能够确保 Promthues Server 的可 迁移性的场景。
基本高可用+远程存储+联邦集群：Promthues 的性能瓶颈主要在于大量的采集任务，因此用户需要利用 Prometheus 联邦集群的特性， 将不同类型的采集任务划分到不同的 Promthues 子服务中，从而实现功能分区。
三种方式如下图
数据类型
counter：只能增加的指标，一般用于计数。重启进程后会被重置。
gauge: 是一个可以增加也可以减小的类型，常用于度量当前的数值，如当前内存使用量、正在处理的任务数量或温度。重启进程后会被重置。
histogram: 柱状图。
summary: 用于表示一段时间内的数据采样结果（通常是请求持续时间或响应大小等），但它直接存储了分位数（通过客户端计算，然后展示出来），而不是通过区间来计算。
Prometheus对k8s的监控
对于k8s而言，资源可以分为以下几类：
基础设置层(Node):集群节点，为整个集群和应用提供运行时资源。
容器基础设置(Container):为应用提供环境。
用户应用(Pod): 包含一组容器。
内部负载均衡(Service): 在集群内通过Service暴露应用功能，集群内应用和应用之间访问时提供内部的负载均衡。(可以对外暴露端口，但是功能比较单一)
外部访问入口(Ingress): 通过ingress提供集群外的访问入口，从而可以使外部客户端访问到部署在kubernetes中的服务。
-
service
- 内部负载均衡：默认情况下（ClusterIP 类型），Service 提供集群内部的负载均衡和服务发现。
- 外部暴露：可以使用 NodePort 或 LoadBalancer 类型来暴露服务，使其可以从集群外部访问，但这些方法相对简单，适用于特定场景。
-
Ingress
- 外部访问入口：Ingress 提供了一个更灵活和强大的方式来管理外部流量。通过 Ingress 资源，可以定义复杂的路由规则，并通过 Ingress Controller（如 Nginx Ingress Controller）来管理这些规则。
- 高级功能：支持基于路径和主机名的路由、SSL 终结等高级功能。
基于以上分析，在不考虑k8s本身组件的情况下，对它进行监控要考虑以下5个方面：
- 集群节点状态的监控：获取最基本的节点运行状态。
- 节点资源用量监控：通过daemonset的形式在各个节点部署node exporter，采集节点资源的使用情况。
- 容器运行情况的监控：通过内置在container中的cadvisor来监控容器。
- 对Prometheus内置的监控pod的数据采集
- k8s本身的kubelet等组件进行监控。
NodeExporter对node监控
在每个节点上部署node-exporter，以daemonset的方式
[root@master prometheus]# cat node-export.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: node-exporter
namespace: monitor-sa
spec:
selector:
matchLabels:
app: node-exporter
template:
metadata:
name: node-exporter
labels:
app: node-exporter
spec:
hostIPC: true
hostPID: true
hostNetwork: true
# hostNetwork、hostIPC、hostPID 都为 True 时，表示这个 Pod 里的所有容器，
# 会直接使用宿主机的网络，直接与宿主机进行 IPC（进程间通信）通信，
# 可以看到宿主机里正在运行的所有进程。
containers:
- name: node-exporter
image: prom/node-exporter:v0.16.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9100
securityContext:
privileged: true
resource:
requests:
cpu: 0.15
args:
- --path.procfs
- /host/profc
- --path.sysfs
- /host/sys
- --controller.filesystem.ignored-mount-points
- '"^/(sys|proc|dev|host|etc)($|/)"'
volumeMounts:
- name: dev
mountPath: /host/dev
- name: proc
mountPath: /host/proc
- name: sys
mountPath: /host/sys
- name: rootfs
mountPath: /rootfs
tolerations:
- key: "node-role.kubernetes.io/master"
effect: "NoSchedule"
operator: "Exists"
volumes:
- name: proc
hostPath:
path: /proc
- name: dev
hostPath:
path: /dev
- name: sys
hostPath:
path: /sys
- name: rootfs
hostPath:
path: /
proc和sys、dev里面有node的实时运行信息。
运行成功后，可以通过metrics查看node信息，比如过滤 node_cpu_seconds,node_load等信息。
[root@master prometheus]# curl http://100.64.252.90:9100/metrics > 1.txt
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 104k 100 104k 0 0 17.7M 0 --:--:-- --:--:-- --:--:-- 20.3M
[root@master prometheus]# curl http://100.64.252.90:9100/mtrics | grep node_load
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 150 100 150 0 0 187k 0 --:--:-- --:--:-- --:--:-- 146k
