Prometheus是一个开源的系统监控和报警工具,特色是php
多维数据模型(时序列数据由metric名和一组key/value组成)java
在多维度上灵活的查询语言(PromQl)node
不依赖分布式存储,单主节点工做.python
经过基于HTTP的pull方式采集时序数据docker
能够经过push gateway进行时序列数据推送(pushing)数据库
能够经过服务发现或者静态配置去获取要采集的目标服务器segmentfault
多种可视化图表及仪表盘支持缓存
Prometheus采集数据是用的pull也就是拉模型,经过HTTP协议去采集指标,只要应用系统可以提供HTTP接口就能够接入监控系统,相比于私有协议或二进制协议来讲开发、简单。ruby
对于定时任务这种短周期的指标采集,若是采用pull模式,可能形成任务结束了,Prometheus尚未来得及采集,这个时候可使用加一个中转层,客户端推数据到Push Gateway缓存一下,由Prometheus从push gateway pull指标过来。(须要额外搭建Push Gateway,同时须要新增job去从gateway采数据
)服务器
Prometheus server
主要负责数据采集和存储,提供PromQL查询语言的支持
客户端sdk
官方提供的客户端类库有go、java、scala、python、ruby,其余还有不少第三方开发的类库,支持nodejs、php、erlang等
Push Gateway
支持临时性Job主动推送指标的中间网关
PromDash
使用rails开发的dashboard,用于可视化指标数据
exporters
支持其余数据源的指标导入到Prometheus,支持数据库、硬件、消息中间件、存储系统、http服务器、jmx等
alertmanager
实验性组件、用来进行报警
prometheus_cli
命令行工具
其余辅助性工具
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']
scrape_interval
这里是指每隔15秒钟去抓取数据(这里
)
evaluation_interval
指的是计算rule的间隔
pushgateway有单独的镜像
docker pull prom/pushgateway
对于喜欢用push模式的应用来讲,能够专门搭建一个push gateway,来适配一下。
prometheus使用了G家的LevelDB来作索引(PromSQL重度依赖LevelDB
),对于大量的采样数据有本身的存储层,Prometheus为每一个时序数据建立一个本地文件,以1024byte大小的chunk来组织。
Prometheus在storage.local.path指定的路径存储文件,默认为./data。关于chunk编码有三种
type 0
第一代的编码格式,simple delta encoding
type 1
目前默认的编码格式,double-delta encoding
type 2
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两个指标值。
prometheus_local_storage_memory_chunks
The current number of chunks in memory, excluding cloned chunks # 目前内存中暴露的chunks的个数
Resident memory size in bytes # 驻存在内存的数据大小
介于0-1之间,当该值小于等于0.7时,prometheus离开rushed模式。
当大于0.8的时候,进入rushed模式
1表示进入了rushed mode,0表示没有。进入了rushed模式的话,prometheus会利用storage.local.series-sync-strategy以及storage.local.checkpoint-interval的配置加速chunks的持久化。
docker 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操做。