CentOS 7中的监控神器普罗米修斯(Prometheus)是一个开源的系统监控和警报工具包。它由SoundCloud公司开发,主要用于收集、存储和查询时间序列数据,以便对系统进行监控和分析。普罗米修斯的核心特点包括:
1. **多维数据模型**:普罗米修斯使用多维数据模型来存储和查询指标,这使得它能够灵活地处理和展示数据。
2. **查询语言**:普罗米修斯提供了一个强大的查询语言(PromQL),允许用户编写复杂的查询来分析和可视化数据。
3. **拉取(Pull)模型**:普罗米修斯通过拉取(Pull)模型从目标(如服务器、应用程序等)收集数据,而不是推(Push)模型。这意味着普罗米修斯服务器主动请求数据,而不是等待数据被推送过来。
4. **可扩展性**:普罗米修斯支持多种服务发现机制,如Kubernetes、Consul、DNS等,这使得它能够轻松地扩展监控范围。
5. **可视化**:普罗米修斯通常与Grafana等可视化工具结合使用,Grafana提供了丰富的图表和仪表板,帮助用户直观地展示和分析监控数据。
6. **社区支持**:普罗米修斯有一个活跃的社区,提供了大量的文档、教程和第三方导出器(exporters),这些导出器可以用于监控各种服务和应用程序。
在CentOS 7上安装普罗米修斯通常涉及以下步骤:
1. **安装Go语言环境**:由于普罗米修斯是用Go编写的,所以需要先安装Go环境。
2. **下载并安装普罗米修斯**:从普罗米修斯官网下载适用于CentOS的二进制文件,并解压到指定目录。
3. **配置普罗米修斯**:编辑`prometheus.yml`配置文件,设置监控目标和服务发现机制。
4. **启动普罗米修斯**:使用命令行启动普罗米修斯服务。
5. **安装和配置可视化工具**:如Grafana,用于创建仪表板和可视化监控数据。
6. **添加监控目标**:在普罗米修斯配置文件中添加需要监控的系统或服务的地址和端口。
7. **启动监控**:普罗米修斯将开始收集数据,并通过Grafana等工具展示监控结果。
普罗米修斯因其强大的功能和灵活性,在系统监控领域得到了广泛应用,尤其是在容器化和微服务架构的环境中。
普罗米修斯(Prometheus)的原理和组成基于以下几个关键组件:
1. **客户端库**:普罗米修斯提供了多种语言的客户端库,如Go、Java、Python等,这些库允许应用程序在运行时生成和暴露指标,这些指标随后可以被普罗米修斯服务器采集。
2. **导出器(Exporters)**:这些是专门的服务,用于从各种系统和服务中导出指标。例如,Node Exporter用于从Linux系统导出指标,MySQL Exporter用于从MySQL数据库导出指标。导出器通常提供一个HTTP端点,普罗米修斯可以通过这个端点拉取指标数据。
3. **普罗米修斯服务器(Prometheus Server)**:这是普罗米修斯的核心组件,负责从客户端库和导出器中拉取指标数据,存储这些数据,并提供查询接口。普罗米修斯服务器使用一种称为时间序列数据库(TSDB)的存储方式来保存指标数据。
4. **服务发现(Service Discovery)**:普罗米修斯支持多种服务发现机制,如静态配置、Consul、DNS、Kubernetes等。这些机制帮助普罗米修斯自动发现新的监控目标,无需手动添加。
5. **查询语言(PromQL)**:普罗米修斯查询语言(PromQL)是一个强大的表达式语言,用于查询和操作时间序列数据。用户可以使用PromQL来创建复杂的查询,生成警报规则,以及在仪表板上展示数据。
6. **告警规则(Alerting Rules)**:普罗米修斯允许用户定义告警规则,当指标满足特定条件时触发警报。这些规则可以基于PromQL查询结果。
7. **告警管理器(Alertmanager)**:这是一个独立的组件,用于处理普罗米修斯生成的警报。它负责对警报进行分组、抑制重复警报、以及通过各种渠道(如邮件、Slack、Webhook等)发送通知。
8. **仪表板和可视化(Dashboarding and Visualization)**:虽然普罗米修斯本身不提供可视化界面,但它通常与Grafana等第三方可视化工具结合使用。Grafana可以连接到普罗米修斯服务器,使用PromQL查询数据,并创建丰富的仪表板来展示监控信息。
普罗米修斯的架构设计为分布式和水平可扩展,这意味着它可以轻松地扩展以监控大规模的系统。这种设计使得普罗米修斯成为现代云原生应用和微服务架构中的首选监控解决方案。
prometheus-server--- #服务端
•--config.file= #指定配置文件
•--storage.tsdb.path=/prometheus #指定tsdb路径/ssd
•--storage.tsdb.retention.time=24h #指定数据存储时间
•--web.enable-lifecycle ##提供类似nginx的reload功能
•--storage.tsdb.no-lockfile #如果用k8s的deployment管理要开启
配置文件详解:
exporter
•node_export##主机监控
•Redis/memcache/mongo/mysql/kafka/rabbitmq等db及缓存
•Blackbox_export一些http/tcp/ping/dns监控等等
•haproxy_exporter/
•consul_exporter##支持外接配置中心
•graphite_exporter/##第三方数据源
Prometheus的特点
多维度数据模型。
灵活的查询语言。
不依赖分布式存储,单个服务器节点是自主的。
通过基于HTTP的pull方式采集时序数据。
可以通过中间网关进行时序列数据推送。
通过服务发现或者静态配置来发现目标服务对象。
支持多种多样的图表和界面展示,比如Grafana等。
server主要负责数据采集和存储,提供PromQL查询语言的支持。
Alertmanager警告管理器,用来进行警报。
Plush Gateway 支持临时性Job主动推送指标的中间网关。
新建一个目录:
递归创建目录然后进到目录里边去
mkdir -p /data/prometheus
cd /data/prometheus/
cd切到这个目录的时候--直接从桌面上 把这个压缩包拖入到你创建的普罗米修斯这个目录里面-然后解压缩
普罗米修斯获取链接:下载 |普罗 米修斯 (prometheus.io)
也可在百度寻找下载地址
tar zxvf prometheus-2.48.0.linux-386.tar.gz
现在还没有完全完成,需要我们进一步配置成系统服务
进入到目录下,编写文件
cd /usr/lib/systemd/system
vim prometheus.service
编写内容如下
[Unit]
Description=https://prometheus.io[Service]
Restart=on-failure
ExecStart=/root/prometheus/prometheus --config.file=/root/prometheus/prometheus.yml[Install]
WantedBy=multi-user.target
添加完之后,使其生效一下-----重新启动
systemctl daemon-reload
systemctl start prometheus.service
关闭为stop
启动完成后进入到解压后的文件夹,开始前台的启动服务
cd /data/prometheus/prometheus-2.48.0.linux-386/
./prometheus --config.file=prometheus.yml
# 后台启动prometheus,并且重定向输入日志到当前目录的prometheus.out
nohup ./prometheus --config.file=prometheus.yml >> /data/prometheus/prometheus-2.28.1.linux-amd64/prometheus.out 2>&1 &
//Mark 修改端口
./prometheus --config.file=prometheus.yml --web.listen-address=:9091
启动完成后,修改端口
然后进行访问:默认端口9090
如果此时报错,原因是:系统的默认时间不匹配
使用一下命令解决
yum install ntpdate -y
ntpdate -u ntp.aliyun.com
# 此片段指定的是prometheus的全局配置,比如采集间隔,抓取超时时间等。如果有内部单独设定,会覆盖这个参数。
global:
scrape_interval: 15s # 抓取间隔,默认继承global值(默认15s 全局每次数据收集的间隔)
evaluation_interval: 15s # 评估规则间隔(规则扫描时间间隔是15秒,默认不填写是1分钟)
# scrape_timeout 抓取超时时间,默认继承global值。
# 此片段指定告警配置,这里会设定alertmanager这个报警插件。
alerting:
alertmanagers:
- static_configs:
- targets: ['localhost:9093']
# 此片段指定报警规则文件,按照设定参数进行扫描加载,用于自定义报警规则,其报警媒介和route路由由alertmanager插件实现。
rule_files:
- "rules/*.yml"
# - "first_rules.yml"
# - "second_rules.yml"
# 此片段指定抓取配置。配置数据源,包含分组job_name以及具体target。又分为静态配置和服务发现。
scrape_configs:
- job_name: 'prometheus'
# metrics_path defaults to '/metrics' # 监控项访问的url路径
# scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9090'] # 监控目标访问地址
- job_name: 'suyuan' # 任务目标名,可以理解成分组,每个分组包含具体的target组员。
scrape_interval: 30s # 这里如果单独设定的话,会覆盖global设定的参数,拉取时间间隔为30s
static_configs:
- targets: ['39.99.254.135:30101']
labels:
instance: 'bigdata(39.99.254.135:9000)'
- targets: ['39.99.254.135:30102']
labels:
instance: 'web(39.99.254.135:9999)'
- targets: ['39.99.254.135:30103']
labels:
instance: 'user(39.99.254.135:9003)'
告警配置 targets 和抓取配置 targets 的 localhost 最好替换成服务器的 ip,job_name 的名字对应的就是 grafana dashboard 的 job 的名称,instance 如果不通过 labels 单独指定,默认取的是 targets 的值,建议单独指定别名。
以上为静态规则,并没有进行自动发现的操作。
这种情况下增加主机需要自行修改规则,通过 supervisor reload 对应任务,也是缺点:每次静态规则添加都要重启prometheus服务,不利于运维自动化。
prometheus支持服务发现(也是运维最佳实践经常采用的):
文件服务发现
基于文件的服务发现方式不需要依赖其他平台与第三方服务,用户只需将 要新的target信息以yaml或json文件格式添加到target文件中 ,prometheus会定期从指定文件中读取target信息并更新
好处:
(1)不需要一个一个的手工去添加到主配置文件,只需要提交到要加载目录里边的json或yaml文件就可以了;
(2)方便维护,且不需要每次都重启prometheus服务端。
在更新完Prometheus的配置文件后,我们需要更新我们的配置到程序内存里,这里的更新方式有两种,第一种简单粗暴,就是重启Prometheus,第二种是动态更新的方式。如何实现动态的更新Prometheus配置。
步骤
第一步:首先要保证启动Prometheus的时候带上启动参数:-web.enable-lifecycle.
prometheus --config.file=/usr/local/etc/prometheus.yml --web.enable-lifecycle
第二步:去更新我们的Prometheus配置。
第三步:更新完配置后,我们可以通过POS请求的方式,动态更新配置。
curl -v--request PosT "http://localhost:9090/-/reload
原理
Prometheus在web模块中,注册了一个handler。
if o.Enablelifecycle {
router.Post("/-/quit", h.quit)
router.Put("/-/quit", h.quit)
router.Post("/-/reload",h.reload)//reload配需
router.Put("/-/reload",h.reload)
}
通过h.reload这个handler方法实现:这个handler就是往一个channle中发送一个信号。
func(h *Handler)reload(w http.ResponseWriter, r *http.Request){
rc := make(chan error)
h.reloadch<-rc //发送一个信号到channe了中
if err :=<-rc; err != nil {
http.Error(w, fmt.Sprintf("failed to reload config:%s",err), http.statusInternalserverError)
}
}
在main函数中会去监听这个channel,只要有监听到信号,就会做配置的reload,重新将新配置加载到内存中。
case rc := <-webHandler.Reload():
if err := reloadConfig(cfg.configFile, cfg.enableExpandExternalLabels, cfg.tsdb.EnableExemplarStorage, logger, noStepSubqueryInterval, reloaders...); err != nil {
level.Error(logger).Log("msg", "Error reloading config", "err", err)
rc <- err
} else {
rc <- nil
}