1. Prometheus的第一步

这篇教程介绍了Prometheus的安装、配置和基本使用。首先,你将下载并运行Prometheus服务器,配置抓取间隔和评估间隔。然后,通过启动Prometheus并监控其自身指标,了解如何使用表达式浏览器查看数据。最后,你将学习如何使用绘图界面和监控其他目标,如使用节点exporter监控主机指标。

原文:https://prometheus.io/docs/introduction/first_steps/

欢迎来到Prometheus! Prometheus是通过收集从被监控的目标上的HTTP endpoints来抓取指标的监控平台

本指南将向您展示如何Prometheus的安装、配置和监控我们的第一个资源。 您将下载,安装并运行Prometheus。 您还将下载并安装exporter,该工具可在主机和服务上显示时间序列数据。 我们的第一个exporter将是Prometheus本身,它提供有关内存使用,垃圾回收等的各种主机级别指标。

下载Prometheus

为您的平台下载最新版本的Prometheus,然后解压缩:

tar xvfz prometheus-*.tar.gz
cd prometheus-*

Prometheus server是一个称为prometheus(或Microsoft Windows上的prometheus.exe)的二进制文件。 我们可以运行二进制文件,并通过传递--help标志来查看有关其选项的帮助。

./prometheus --help
usage: prometheus [<flags>]

The Prometheus monitoring server

. . .

在启动Prometheus之前,让我们对其进行配置。

配置Prometheus
Prometheus配置文件为YAML格式。 Prometheus下载随附一个名为prometheus.yml的文件中的示例配置,是开始的好地方。

我们删除了示例文件中的大多数注释,以使其更加简洁(注释是带有#前缀的行)。

global:
  scrape_interval:     15s
  evaluation_interval: 15s

rule_files:
  # - "first.rules"
  # - "second.rules"

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ['localhost:9090']

示例配置文件中包含三个配置块:global,rule_files和scrape_configs。

- global块控制Prometheus server的全局配置。我们有两个选项。首先,scrape_interval控制Prometheus多久抓取一次目标。您可以为单个目标覆盖此参数。在这种情况下,全局设置是每15秒抓取一次。

- Evaluation_interval选项控制Prometheus多久评估一次规则。 Prometheus使用规则来创建新的时间序列并生成警报。

- rule_files块指定我们要Prometheus server加载规则的位置。目前,我们还没有任何规则。

最后的scrape_configs块控制Prometheus监视哪些资源。由于Prometheus还将有关自身的数据公开为HTTP端点,因此它可以抓取并监视自身的运行状况。在默认配置中,有一个称为prometheus的job,它会抓取Prometheus server公开的时间序列数据。该job在端口9090上包含一个静态配置的目标localhost。Prometheus希望指标可用于/metrics路径上的目标。因此,此默认job是通过以下网址进行抓取:http://localhost:9090/metrics

返回的时间序列数据将详细说明Prometheus server的状态和性能。

有关配置选项的完整说明,请参阅配置文档

 

启动Prometheus

要使用我们新创建的配置文件启动Prometheus,请将目录切换到包含Prometheus二进制文件的目录并运行:

./prometheus --config.file=prometheus.yml

Prometheus应该启动了。 您还应该能够在http://localhost:9090上浏览到有关其自身的状态页。 给它大约30秒的时间,以从其自己的HTTP指标终结点收集有关自身的数据。

您还可以通过导航到自己的指标终结点:http://localhost:9090/metrics来验证Prometheus是否正在提供有关其自身的指标。

使用表达式浏览器

让我们尝试查看Prometheus收集的有关自身的一些数据。 要使用Prometheus的内置表达式浏览器,请导航至http://localhost:9090/graph,然后在“Graph”选项卡中选择“Console”视图。

正如您可以从http://localhost:9090/metrics收集的那样,Prometheus导出的有关其自身的一个指标称为promhttp_metric_handler_requests_total(Prometheus服务器已处理的/ metrics请求总数)。 继续并将其输入到表达式控制台中:

promhttp_metric_handler_requests_total

这将返回多个不同的时间序列(以及每个时间序列的最新值),所有时间序列的度量标准名称均为promhttp_metric_handler_requests_total,但标签不同。 这些标签指定不同的请求状态。

如果我们只对导致HTTP代码200的请求感兴趣,则可以使用此查询来检索该信息:

promhttp_metric_handler_requests_total{code="200"}

要计算返回的时间序列数,您可以编写:

count(promhttp_metric_handler_requests_total)

有关表达语言的更多信息,请参见表达语言文档

 

使用绘图界面

要绘制图形表达式,请导航至 http://localhost:9090/graph并使用“Graph”选项卡。

例如,输入以下表达式以图形化显示在自抓取的Prometheus中发生的每秒HTTP请求速率返回状态代码200:

rate(promhttp_metric_handler_requests_total{code="200"}[1m])

您可以尝试使用图形范围参数和其他设置。

 

监控其他目标

仅从Prometheus收集指标并不能很好地说明Prometheus的功能。 为了更好地了解Prometheus可以做什么,我们建议您浏览有关其他exporter的文档。 使用节点exporter监控Linux或macOS主机指标的指南是一个不错的起点。

 

摘要
在本指南中,您安装了Prometheus,配置了Prometheus实例以监视资源,并了解了在Prometheus表达式浏览器中使用时间序列数据的一些基础知识。 要继续学习Prometheus,请查看“概览”以获取有关接下来要探索的内容的一些想法。

<think> 我们分析的关键点在于日志中的这一行: /usr/bin/galera_recovery:行 71: 2747028 已放弃 /usr/libexec/mysqld --user=mysql --wsrep_recover --disable-log-error 这表明在执行galera_recovery脚本的第71行时,尝试以恢复模式启动mysqld进程(使用--wsrep_recover参数)被放弃了(进程被终止)。这通常是由于Galera集群在节点启动时尝试恢复状态失败。 可能的原因: 1. **数据不一致或损坏**:Galera在恢复时需要读取事务状态(gtid),如果数据文件损坏或者不一致,可能导致恢复失败。 2. **磁盘空间不足**:如果磁盘空间不足,MySQL无法启动恢复过程。 3. **内存不足**:在恢复过程中需要足够的内存,如果系统内存不足,进程可能被OOM killer终止(日志中显示“已放弃”通常表示进程被系统终止,常见于资源不足或主动kill)。 4. **配置错误**:例如,wsrep_cluster_address配置错误,导致无法连接到集群,或者wsrep_data_home_dir指向的目录权限问题。 5. **Galera内部错误**:如grastate.dat文件中的seqno为-1(表示节点关闭时不在同步状态)且safe_to_bootstrap为0,这时需要手动决定引导节点。 修复步骤: 1. **检查磁盘空间和内存**: 使用命令: ```bash df -h # 检查磁盘空间,特别是MySQL数据目录所在分区 free -m # 检查内存和交换空间使用情况 ``` 如果磁盘空间不足,清理空间(如删除旧的日志文件、备份文件等)。如果内存不足,考虑增加交换空间或释放内存。 2. **检查Galera状态文件**: Galera在数据目录(通常是/var/lib/mysql)下保存一个`grastate.dat`文件,查看其内容: ```bash cat /var/lib/mysql/grastate.dat ``` 关注两个关键字段: - `seqno: -1` 表示节点关闭时没有记录最后的事务序列号,无法自动恢复。 - `safe_to_bootstrap: 0` 表示当前节点不应被引导(即不应作为第一个启动节点)。 如果所有节点都关闭且需要重新启动集群,必须选择一个节点作为引导节点(bootstrap)。注意:只能选择一个节点进行引导,通常是最后关闭的节点(seqno最大的节点)。如果所有节点的seqno都是-1,那么需要手动选择一个节点引导。 3. **手动引导集群**: 如果确定该节点应该是引导节点(例如,它是集群中唯一关闭的节点,或者它是最后关闭的节点),则进行以下操作: - 修改`grastate.dat`,设置`safe_to_bootstrap: 1`。 - 然后使用`--wsrep-new-cluster`选项启动该节点的MariaDB: ```bash mysqld_safe --wsrep-new-cluster & ``` 或者使用systemd(如果使用systemd管理服务): ```bash systemctl start mariadb@bootstrap.service # 某些系统可能是mariadb bootstrap ``` 具体服务名可能因发行版而异。 注意:如果集群中有多个节点,其他节点应该正常启动(不需要引导参数)。 4. **如果节点不是引导节点,强制恢复seqno**: 如果该节点不是引导节点,但有其他节点在线,可以尝试清除本地的事务状态,以便从集群中同步最新状态。但需谨慎操作,因为可能导致数据丢失。步骤如下: - 停止MariaDB(如果正在运行): ```bash systemctl stop mariadb ``` - 备份数据目录(非常重要): ```bash cp -r /var/lib/mysql /var/lib/mysql_backup ``` - 删除Galera状态文件并重置事务: ```bash rm /var/lib/mysql/gvwstate.dat /var/lib/mysql/grastate.dat # 注意:此操作会重置节点状态,使其重新加入集群时重新同步数据 ``` - 启动MariaDB服务: ```bash systemctl start mariadb ``` 5. **检查错误日志**: MariaDB的错误日志通常位于`/var/log/mariadb/mariadb.log`或`/var/log/mysql/error.log`。查看日志以获取更详细的错误信息: ```bash tail -f /var/log/mariadb/mariadb.log ``` 6. **检查配置**: 检查`/etc/mysql/my.cnf`或`/etc/my.cnf`中的Galera配置,确保`wsrep_cluster_address`指向正确的集群节点(如果是第一个节点,则设置为空集群地址`gcomm://`,否则设置为集群中至少一个活动节点的地址)。 7. **如果问题仍然存在**: 尝试以安全模式启动mysqld进行恢复: ```bash mysqld_safe --skip-grant-tables --skip-networking --wsrep_on=OFF & ``` 然后尝试修复表: ```mysql mysqlcheck --all-databases --repair --use-frm ``` 完成后正常重启。 8. **考虑升级或修复软件包**: 如果问题是由软件bug引起的,考虑升级MariaDB和Galera相关软件包。 由于日志中显示内核版本为特定的Kylin系统(ky10),需要确认该版本与MariaDB的兼容性。已知该内核版本(4.19.90)较旧,可能存在兼容性问题。建议查看MariaDB官方文档关于系统兼容性的部分。 注意:以上操作涉及集群恢复,操作前务必备份全部数据。 如果上述步骤无法解决问题,请提供更多日志信息(尤其是MariaDB错误日志中的相关错误)。 §§相关问题§§ 1. Galera集群节点无法启动时如何确定引导节点? 2. 如何解决Galera集群节点状态不一致问题? 3. MariaDB启动过程中磁盘空间不足应如何处理? 4. 如何诊断和修复Galera集群中的脑裂问题? 5. Kylin Linux系统上运行MariaDB有哪些注意事项? </think> ### MariaDB启动失败原因分析及修复方法 #### 问题定位(基于系统日志) 日志关键信息: ``` /usr/bin/galera_recovery:行 71: 2747028 已放弃 /usr/libexec/mysqld --user=mysql --wsrep_recover --disable-log-error ``` 此错误表明Galera集群恢复脚本(`galera_recovery`)在执行到71行时,`mysqld`进程被系统强制终止(状态码"已放弃")。结合Galera恢复参数`--wsrep_recover`,故障核心是**Galera集群状态恢复失败**。 #### 根本原因分析 1. **Galera状态文件损坏** `wsrep_recover`模式启动时需读取`grastate.dat`文件恢复事务状态。文件损坏或`seqno=-1`会导致恢复失败[^1]。 2. **磁盘空间或内存不足** 系统内核版本`4.19.90-52.22.v2207.ky10.x86_64`显示为KylinOS(麒麟系统),资源监控缺失可能导致: - `/var/lib/mysql`分区空间耗尽 - OOM Killer终止mysqld进程(日志"已放弃"的典型原因) 3. **集群节点状态不一致** Galera要求所有节点状态一致。若该节点关闭时未同步: ```bash # 检查节点状态 cat /var/lib/mysql/grastate.dat ``` 出现`safe_to_bootstrap: 0`且`seqno: -1`时无法自动恢复[^2]。 4. **权限或配置文件错误** `--user=mysql`参数执行失败可能因为: - `/var/lib/mysql`目录所有权非mysql用户 - `my.cnf`中`wsrep_cluster_address`配置错误 #### 修复步骤 **第一步:检查系统资源** ```bash # 检查磁盘空间 df -h /var/lib/mysql # 检查内存使用(OOM Killer触发点) free -m && grep -i "killed" /var/log/messages ``` **第二步:修复Galera状态文件** ```bash # 备份状态文件 cp /var/lib/mysql/grastate.dat{,.bak} # 手动设置引导节点(若需强制恢复) sudo galera_recovery --force # 自动尝试恢复 ``` 若自动恢复失败,手动修改`grastate.dat`: ```ini # 修改为 safe_to_bootstrap: 1 seqno: [从其他节点获取最新seqno] ``` **第三步:安全启动集群** ```bash # 作为新集群引导节点启动 mysqld_safe --wsrep-new-cluster & # 正常节点加入集群 systemctl start mariadb ``` **第四步:验证与权限修复** ```bash # 检查数据目录所有权 chown -R mysql:mysql /var/lib/mysql # 查看错误日志 tail -f /var/log/mariadb/mariadb.log ``` **第五步:集群完整性检查** ```sql -- 在MySQL客户端执行 SHOW GLOBAL STATUS LIKE 'wsrep%'; ``` 确认`wsrep_ready=ON`且`wsrep_cluster_size`符合节点数。 #### 预防措施 1. 添加监控告警:检测`/var/lib/mysql`分区使用率(>90%触发) 2. 配置计划任务:定期备份`grastate.dat` 3. 优化内核参数:增加`vm.overcommit_memory=2`防止OOM Killer误杀 4. 升级Galera版本:修复已知恢复流程缺陷[^3] > **关键提示**:麒麟系统(`ky10`)需验证与Galera的兼容性,建议测试环境验证内核更新。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值