Prometheus
, ,
Source
Edit
History

Prometheus-AlertManager设置邮件发送告警信息

以网易163邮箱为例

修改alertmanager.yml文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
global:
  resolve_timeout: 5m # 当警报恢复后，等待这个时长才认为警报真正解决
  smtp_from: '[email protected]' # 发送警报邮件的发件人邮箱地址
  smtp_smarthost: 'smtp.163.com:465' # 邮件发送使用的SMTP服务器地址和端口
  smtp_auth_username: '[email protected]' # 用于SMTP认证的用户名，通常是发件人的邮箱地址
  smtp_auth_password: 'xxxxxxx' # 用于SMTP认证的密码，这里应该是邮箱的授权码（token），而非登录密码
  smtp_require_tls: false # 是否要求使用TLS加密邮件传输，这里设置为false表示不强制要求
  smtp_hello: '163.com' # SMTP连接时的HELO/EHLO标识，通常使用邮件服务商的域名

route:
  group_by: ['alertname'] # 按照警报名称对警报进行分组
  group_wait: 30s # 在将警报发送给接收者之前等待的时间，以便收集更多相关警报
  group_interval: 5m # 分组后，每隔这个时长检查一次是否有新警报加入同一分组
  repeat_interval: 1h # 对于同一个分组的警报，每隔这个时长重复发送一次通知
  receiver: '163email' # 默认的警报通知接收者，这里引用了下面定义的receivers中的一个

# receivers中定义了警报通知的接收者，包括他们的联系方式
receivers:
  - name: '163email' # 接收者的名称，用于在route中引用
    email_configs:
      - to: '[email protected]' # 接收警报邮件的邮箱地址
        send_resolved: true # 当警报恢复时，是否发送恢复通知邮件

查看更多
Prometheus
,
Source
Edit
History

Prometheus基于文件的自动发现

一、自动发现服务

每次修改Prometheus配置文件都需要重载服务，未免有些麻烦，而自动发现服务就是为了解决这种麻烦事儿的，自动发现服务又分为好几种，其中基于文件的服务发现是最通用的方式。这种方式不需要依赖于任何的平台或者第三方服务。Prometheus会定时从文件中读取最新的Target信息，因此，我们可以通过任意的方式将监控Target的信息写入即可。

二、配置

步骤1 修改prometheus.yml文件

1
2
3
4
- job_name: 'file_sd_default'
  file_sd_configs:
  - files: ['/etc/prometheus/config/sd_config/*.yml']
    refresh_interval: 5s

查看更多
Prometheus
,
Source
Edit
History

阿里云-使用Prometheus配置报警规则的最佳实践

使用Prometheus配置报警规则的最佳实践 - 阿里云

ACK从集群稳定性、集群节点异常、集群节点水位、应用容器副本异常、工作负载异常、存储异常、网络异常等多个方面，通过集群、应用的运维经验沉淀，总结梳理出以下Prometheus重要报警规则配置。

报警规则包含容器副本异常、工作负载异常等内容，分为以下级别。

查看更多
Prometheus
,
Source
Edit
History

node_exporter添加访问验证

假设你想要求所有访问Prometheus实例的用户提供用户名和密码。为了这个例子，使用admin作为用户名，并选择任何你喜欢的密码。

步骤1：密码哈希

首先，生成密码的bcrypt哈希值。为了生成哈希密码，我们将使用python3-bcrypt。让我们通过运行apt install python3-bcrypt来安装它，假设你正在运行类似debian的发行版。其他替代方案也存在来生成哈希密码；为了测试，你也可以使用网上的bcrypt生成器。

这里是一个使用python3-bcrypt的python脚本，它会提示你输入密码并对其进行哈希处理：

1
2
3
4
5
6
7
import getpass
import bcrypt
# 提示输入密码
password = getpass.getpass("password: ")
hashed_password = bcrypt.hashpw(password.encode("utf-8"), bcrypt.gensalt())
# 获取密码的哈希值
print(hashed_password.decode())

查看更多
Linux
,
Source
Edit
History

Debian脚本中使用了&>/dev/null，$?总是返回0

一、问题现象

在CentOS中编写了一段Shell脚本，作用很简单，就是监控nginx的配置文件是否发生了变化，如果发生了变化就自动reload一次，脚本如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#!/bin/bash
while true
do
  md5=`md5sum /etc/nginx/conf.d/port-to-domain.conf | awk '{print $1}'`
  grep ${md5} /tmp/md5result &>/dev/null
  if [ $? -ne 0 ];then 
    echo `date` 'Config File Change'
    echo `date` 'Command nginx -t exec'
    nginx -t
    if [ $? -eq 0 ];then
      echo `date` 'Command nginx -t exec success'
      nginx -s reload
      echo `date` 'Command nginx -s reload exec'
    else
      echo `date` 'Command nginx -t exec failed'
    fi
    
    echo ${md5} > /tmp/md5result
    echo `date` 'Change md5result'
  else
    echo `date` 'Config File NoChange'
  fi
  sleep 5
done

在CentOS中运行一切正常，但是在Debian中运行异常，具体是grep ${md5} /tmp/md5result &>/dev/null的返回值总是0

查看更多
Linux
,
Source
Edit
History

openEuler开启kdump失败

一、现象

openEuler启动kdump失败，显示No memory reserved for crash kernel

1
2
3
4
5
6
7
8
9
10
11
12
13
[root@kvm-hkcloud01 ~]# systemctl status kdump
 kdump.service - Crash recovery kernel arming
     Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2024-06-24 14:50:48 CST; 26min ago
    Process: 1004 ExecStart=/usr/bin/kdumpctl start (code=exited, status=1/FAILURE)
   Main PID: 1004 (code=exited, status=1/FAILURE)

Jun 24 14:50:47 kvm-hkcloud01 systemd[1]: Starting Crash recovery kernel arming...
Jun 24 14:50:48 kvm-hkcloud01 kdumpctl[1015]: No memory reserved for crash kernel
Jun 24 14:50:48 kvm-hkcloud01 kdumpctl[1015]: Starting kdump: [FAILED]
Jun 24 14:50:48 kvm-hkcloud01 systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE
Jun 24 14:50:48 kvm-hkcloud01 systemd[1]: kdump.service: Failed with result 'exit-code'.
Jun 24 14:50:48 kvm-hkcloud01 systemd[1]: Failed to start Crash recovery kernel arming.

二、问题分析

根据提示来看，应该是申请不到内存导致的，但从free的结果来看，是可以满足kdump的要求的

查看更多