Prometheus是一个开源的系统监控和报警工具,特点是:
Prometheus采集数据是用的pull也就是拉模型,通过HTTP协议去采集指标,只要应用系统能够提供HTTP接口就可以接入监控系统,相比于私有协议或二进制协议来说开发、简单。
对于定时任务这种短周期的指标采集,如果采用pull模式,可能造成任务结束了,Prometheus还没有来得及采集,这个时候可以使用加一个中转层,客户端推数据到Push Gateway缓存一下,由Prometheus从push gateway pull指标过来。(需要额外搭建Push Gateway,同时需要新增job去从gateway采数据)
架构图如下:
docker exec -it a9bd827a1d18 less /etc/prometheus/prometheus.yml
得到
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Attach these labels to any time series or alerts when communicating with
# external systems (federation, remote storage, Alertmanager).
external_labels:
monitor: 'codelab-monitor'
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first.rules"
# - "second.rules"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9090']
pushgateway有单独的镜像
docker pull prom/pushgateway
对于喜欢用push模式的应用来说,可以专门搭建一个push gateway,来适配一下。
prometheus使用了G家的LevelDB来做索引(PromSQL重度依赖LevelDB),对于大量的采样数据有自己的存储层,Prometheus为每个时序数据创建一个本地文件,以1024byte大小的chunk来组织。
Prometheus在storage.local.path指定的路径存储文件,默认为./data。关于chunk编码有三种
第一代的编码格式,simple delta encoding
目前默认的编码格式,double-delta encoding
variable bit-width encoding,facebook的时间序列数据库Beringei采用的编码方式
prometheus在内存里保存了最近使用的chunks,具体chunks的最大个数可以通过storage.local.memory-chunks来设定,默认值为1048576,即1048576个chunk,大小为1G。 除了采用的数据,prometheus还需要对数据进行各种运算,因此整体内存开销肯定会比配置的local.memory-chunks大小要来的大,因此官方建议要预留3倍的local.memory-chunks的内存大小。
As a rule of thumb, you should have at least three times more RAM available than needed by the memory chunks alone
可以通过server的metrics去查看prometheus_local_storage_memory_chunks以及process_resident_memory_byte两个指标值。
The current number of chunks in memory, excluding cloned chunks 目前内存中暴露的chunks的个数
Resident memory size in bytes 驻存在内存的数据大小
run -p 9090:9090 \\
-v /tmp/prometheus-data:/prometheus-data \\
prom/prometheus \\
-storage.local.retention 168h0m0s \\
-storage.local.max-chunks-to-persist 3024288 \\
-storage.local.memory-chunks=50502740 \\
-storage.local.num-fingerprint-mutexes=300960
设定prometheus内存中保留的chunks的最大个数,默认为1048576,即为1G大小
用来配置采用数据存储的时间,168h0m0s即为24*7小时,即1周
用来控制序列文件rewrite的时机,默认是在10%的chunks被移除的时候进行rewrite,如果磁盘空间够大,不想频繁rewrite,可以提升该值,比如0.3,即30%的chunks被移除的时候才触发rewrite。
该参数控制等待写入磁盘的chunks的最大个数,如果超过这个数,Prometheus会限制采样的速率,直到这个数降到指定阈值的95%。建议这个值设定为storage.local.memory-chunks的50%。Prometheus会尽力加速存储速度,以避免限流这种情况的发送。
当prometheus server端在进行checkpoint操作或者处理开销较大的查询的时候,采集指标的操作会有短暂的停顿,这是因为prometheus给时间序列分配的mutexes可能不够用,可以通过这个指标来增大预分配的mutexes,有时候可以设置到上万个。
控制写入数据之后,何时同步到磁盘,有'never', 'always', 'adaptive'. 同步操作可以降低因为操作系统崩溃带来数据丢失,但是会降低写入数据的性能。 默认为adaptive的策略,即不会写完数据就立刻同步磁盘,会利用操作系统的page cache来批量同步。
进行checkpoint的时间间隔,即对尚未写入到磁盘的内存chunks执行checkpoint操作。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论