prometheus
介绍
优缺点
优点：
1. 采集精度细，采集精度细分到1-5秒，缺点存储数据大
2. 嵌入服务内部，采集更精准
3. 结合granfa图形高大上
缺点：
1. 不支持集群
2. 2.0之前偶尔发现数据丢失
组件
prometheus server：prometheus服务端
exporter：收集监控端，如一个node节点，mysql，redis上都可以部署exporter，监控数据收集。
push_gateway:
可以安装在任何节点，采用被动推送获取监控的插件
手动编写脚本，推送监控数据至pushgateway
脚本文件重点：
存在instance变量名
存在lables名称
存在values名称
pushgateway的缺点：
1. 单点瓶颈，多个脚本同时发送给一个pushgateway的进程，进程如果没了，数据全都踩不到了。
2. 不能对脚本进行智能判断，脚本如果出现问题，发送给pushgateway，照单全收发送给prometheus。
prometheus-storage:
1. 采用时间序列的方式，以一种自定义的格式存储在本地硬盘上
2. prometheus的本地T-S(time-series)数据库以每两小时为间隔分为block块存储，每个块又分为多个chunk文件，chunck文件用来存放采集过来的数据的T-S数据，metadata和索引文件(index)
3. index文件是对metrices(prometheus 中一次K/V采集数据，叫做一个metric)和labels标签进行索引，之后存储在chunk中，chunk是作为存储的基本单位，index and metadata是作为子集。
4. prometheus平时是将采集过来的数据都先存放在内存中，以类似缓存的方式，用于加快搜索和访问
5. 当出现宕机时，prometheus有一种保护机制，叫做WAL，可以将数据定期存入硬盘，以chunk来表示，并在重启时，用以恢复内存。
alertmanager：
功能缺陷，使用granfana的功能也可以实现告警
监控设计:
`监控分类：`
1. 业务级别监控，qps，dau日活，访问状态，业务接口
2. 系统监控：cpu/内存/硬盘/io/tcp连接/流量等
3. 网络监控：丢包率，延迟
4. 日志监控：网络设备，用户行为，soft，日志包含种类繁多
5. 程序监控：采集程序日志，程序嵌入接口
服务发现方式：
`静态收集(当新增target，需要在prometheus定义target地址，然后重载服务)`
通过在prometheus中指定收集job
`自动发现（新增target，无需修改prometheus配置文件重载，直接可以收集`
1. 基于文件服务发现：
file_sd_config
在prometheus中定义文件服务发现，并指定读取文件路径，在指定路径中，写入yaml文件，yaml文件中定义收集target地址，及标签。
2. DNS的服务发现：
3. k8s的API的服务发现机制，支持API Server中Node，service，Endpoint、Pod和Ingress等资源类型下相应的各资源对象视作target
4. 等等。。。
数据采集方式：
`pull 主动拉取`
通过http get访问每个节点上的exporter并采样回需要的数据。
`push 被动推送`
将监控数据组织成K/V的形式，metrics形式，发送给pushgateway之后，promethues再从pushgateway拉取数据。
手动编写脚本，推送监控数据至pushgateway
脚本文件重点：
存在instance变量名
存在lables名称
存在values名称
通过echo key：value的方式|curl http://prometheus:port/metrics/job/pushgateway job名/instance/$instance_name
说明：最后的$instance_name为脚本中定义的变量名，获取的值为主机名。
配置参数
配置文件拆分
主要组成部分如下：
global： 全部配置，采样间隔，抓取超时时间。
scrape_configs： 有静态配置和服务发现两种。抓取指标数据源配置。
rule_files： 告警规则，prometheus根据这些规则，将匹配的告警信息推送至alertmanager。
alerting： 告警配置，指定prometheus将告警信息推送至哪个alertmanager实例地址。
remote_write: 指定后端存储的写入api地址。
remote_read: 指定后端存储的读取api地址。
配置文件标签
1. 删除标签：
drop或者keep
drop：正则能匹配到target上的source_labels各标签值时，删除该target。
keep：regex不能匹配到target上的source_labels上的各标签值，则删除该target。
2. 创建或删除标签：
labelmap：正则匹配标签名，将标签名修改，但值还是原来的值。
labeldrop：匹配到的标签删除
labelkeep：不能匹配的标签进行删除。
2. 替换标签值
重新创建标签名，正则匹配源标签的值，将此值赋予给新标签。replace
重新创建标签名，正则匹配源标签的值，将值进行hash计算，赋予给新标签。
`例:`
replace:(替换标签值)
- source_labels: [__address__] # 配置的原始标签，匹配地址
regex: '(.*):10250' # 匹配带有10250端口的ip:10250
replacement: '${1}:9100' # 把匹配到的ip:10250的ip保留替换成${1}
target_label: __address__ # 新生成的地址
action: replace
replace：(正则匹配值的结果，赋予新标签名的值)
- source_labels: [__meta_kubernetes_node_name]
regex: (.+)
target_label: __metrics_path__
replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
replace:
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
action: replace
target_label: __scheme__
regex: (https?) # 重新设置scheme，匹配源标签__meta_kubernetes_service_annotation_prometheus_io_scheme也就是prometheus.io/scheme annotation，如果源标签的值匹配到regex，则把值替换为标签__scheme__对应的值。
keep：(#正则匹配到的默认空间下的service名字是kubernetes，协议是https的endpoint类型保留下来，其余的没有匹配到的标签值，改target被删除)
- source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
action: keep
regex: default;kubernetes;https
keep:(# 重新打标仅抓取到的具有 "prometheus.io/scrape: true" 的annotation的端点，意思是说如果某个service具有prometheus.io/scrape = true annotation声明则抓取)
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep
regex: true
annotation本身也是键值结构，所以这里的源标签设置为键，而regex设置值true，当值匹配到regex设定的内容时则执行keep动作也就是保留，其余则丢弃。
metrics
metrics数据类型
metrics：采集过来的数据，统一称为metrics数据，对数据总称，不代表某一种具体数据格式，是一种对于度量计算单位的抽象。
`度量指标：`
gauges：只有一个简单的返回值，记录瞬时状态，如内存，硬盘，随机变化数值。
counters：计数器，从0开始累积。
Histograms：数据请求图状显示。按比例分布。如按照区间显示值。
promql函数
increase():
increase(): 增长,针对Counter这种持续增长的数值，截取其中一段时间的增量
`例：`
increase(node_cpu[1m])：获取CPU总时间时间在1分钟内的增量
increase(node_cpu{mode='idle'}[1m]): 空闲CPU 1分钟内的增量
sum():
sum():结果集相加
`例：`
sum(increase(node_cpu[1m]): 针对CPU多核环境，对cpu数量相加，并获取cpu总时间在1分钟内的增量。
sum(increase(node_cpu{mode='idle'}[1m])): 不加sum是针对所有cpu核数结果显示，增加sum表示所有CPU核数相加，结果显示，会把所有机器CPU也进行相加。
by(instance): instance表示机器名，针对上面所有CPU相加显示问题，进行强行拆分
sum(increase(node_cpu{mode='idle'}[1m])) by(instance): 按照机器名区分，查询空闲cpu1分钟内的增量。
sum(increase(node_cpu[1m])) by(instance): 全部CPU时间1分钟增量
`空闲CPU百分比计算`
sum(increase(node_cpu{mode='idle'}[1m])) by(instance) / sum(increase(node_cpu[1m])) by(instance) = 空闲CPU的百分比
`CPU使用率计算`
1 - (sum(increase(node_cpu{mode='idle'}[1m])) by(instance) / sum(increase(node_cpu[1m])) by(instance)) * 100 = CPU的使用率
例：用户态单独一个cpu在1分钟内cpu的使用率：
sum(increase(node_cpu{mode='user'}[1m])) by (instance)/ sum(increase(node_cpu[1m])) by (instance)
例：根据code分组求和,例如状态码200的有多少，状态码500的有多少
sum(http_requests_total) by(code)
rate():
速率函数，专门搭配counter类型数据使用的函数，它的功能，按照设置一个时间段，取counter在这个时间段中，每秒平均增量。
`increase函数和rate函数的使用场景：`
rate(): 适合取秒的场景，内存，硬盘，io网络流量等。如写1，是取1分钟增量总量除以60秒。也就是对每秒取值。
increase(): 适合取分钟的场景，如写1，是取1分钟的场景
针对rate()取1分钟还是5分钟，需要看对监控数据的敏感度。
topk():
取前几位的最高值(在prometheus中只适合在console中查看)
`例：`
Gauge类型的使用：topk(3,metrics名称)
Counter类型的使用：topk(3,rate(metrics名称[20m]))
count():
count：模糊监控判断，用来累积和，如找出当前TCP等待数大于200的机器数量。
count(metrics名称 > 200)
predict_linear()
线性预测，如内存可用空间急剧降低，虽然还有可用空间，但线性预测会根据当前速度进行预测，按照当前速度，未来5分钟内，
内存肯定空间不足，那么在还剩余百分之20的时候，就开始报警。
delta():
计算范围向量中每个时间序列元素的第一个值与最后一个值之差，从而展示不同时间点上的样本值的差值。可以针对Gauge类型的指标类型数据。
delta(cpu_temp_celsius{host="web01"}[2h])：返回服务器上CPU温度与2小时之间的差异
histogram_quantile():
专门针对histogram直方图分位数计算函数。可以用于分析因异常值而引起的平均值过大的问题。
针对直方图，有求和sum，求总数counter，求每个区间值bucket
histogram_quantile(0,90,rate(prometheus_tsdb_compaction_duration_seconds_bucket[1d])): 求出百分之90的区间值是多少秒
avg_over_time():
例：在2分钟内，求出http请求为500的值，并求出平均值
aut_over_time(http_requests_total{code="500"}[2m])
bool判断
例：bool类型，取0或者1，查询http请求小于20的，小于20结果为0，大于20结果为1
http_request_total < bool 20
bottomk()
bottomk：顺序返回分组内的样本最小的前K个时间序列及其值
quantile():
分位数用于评估数据的分布状态，该函数会返回分组内指定的分位数值，即数值落在小于等于指定的分位区间的比例。
count_values():
对分组内的时间序列的样本值进行数据统计。
PromQL的数据类型：
# PromQL的数据类型
1. 即时向量：特定或全部时间序列集合上，具有相同时间戳的一组样本。
2. 范围向量：特定或全部时间序列集合上，在指定同一范围内的所有样本值。
3. 标量：一个浮点型的数据值
4. 字符串：支持使用单引，双引，反引进行引用，但反引中不会对转义字符进行转义。