在提高触发 Kdump 的几率之前要先开启 Kdump：

正文：

步骤一：配置提高触发 Kdump 几率的参数
1.1 配置提高触发 Kdump 几率的参数

# vim /etc/sysctl.conf

添加以下内容：

......
kernel.softlockup_panic = 1

1.2 让刚刚配置的参数生效

# sysctl -p

（注意：此时每有一次软锁都会触发 Kdump）

步骤二：当 Kdmup 触发后分析奔溃的信息

步骤三；删除提高触发 Kdump 几率的参数 （重要）
3.1 删除提高触发 Kdump 几率的参数 （重要）

# vim /etc/sysctl.conf

删除以下内容：

......
kernel.softlockup_panic = 1

3.2 让刚刚删除参数的配置生效 （重要）

# sysctl -p

（注意：此时每有一次软锁都会触发 Kdump）

参考文献：

https://www.suse.com/support/kb/doc/?id=000019217

在触发 Kdump 之前要先开启 Kdump：

正文：

步骤一：在本地登陆系统

（步骤略）

步骤二：强制同步屏幕

同时按下 “Left” 键和 “Alt” 键和 “Print Screen” 键和 “s” 键

步骤三：触发 Kdump

同时按下 “Left” 键和 “Alt” 键和 “Print Screen” 键和 “c” 键

在排除 SFTP 登录记录只监控普通登录记录前要先开启 SFTP 日志：

介绍：

作者：朱明宇
名称：监控普通登录记录 （排除 SFTP 登录记录只监控普通登录记录）
作用：监控普通登录记录 （排除 SFTP 登录记录只监控普通登录记录）

使用方法：
1. 在此脚本的分割线内写入相应的内容
2. 给此脚本添加执行权限
3. 执行此脚本
4. 普通登录记录会同时记录在系统日志和 $logfile 里

脚本分割线里的变量：
1. logfile=logfile.txt #用户保存记录的文件
2. prompt=”and no sftp info” #记录里普通登录记录的文件

脚本：

#!/bin/bash

####################### Separator ########################

logfile=logfile.txt
prompt="and no sftp info"

####################### Separator ########################

checktime=`date +%Y-%m-%dT%H -d "-1 day"`

for i in `cat -n /var/log/messages | grep $check_time | grep 'Started Session' | grep -v 'root' | awk '{print $1}'`

do
   line=`sed -n $[i]p /var/log/messages`
   time=`echo $line | awk '{print $1}'`
   session=`echo $line | awk '{print $6}'`
   user=`echo $line | awk '{print $9}'`
   user=${user%.}

   message="ACCESS CHECK LOG: Time:$time Session:$session $user has accessed `hostname`, $prompt"

   let sftpline=i+3

   sed -n $[sftpline]p /var/log/messages | grep sftp-server &> /dev/null
   if [ $? -ne 0 ];then
           echo $message
           echo $message >> $logfile.txt
           logger $message
   fi
   echo
done

# logger [This is test message]

（补充：这里以往系统日志里写入一条包含 This is test message 内容的信息为例）

内容二：显示手动向系统日志写入信息

# grep "This is test message" /var/log/messages

（补充：这里在系统里查找一条包含 This is test message 内容的信息为例）

在分析 Kdump 内核奔溃信息之前要先开启 Kdump：

正文：

步骤一：确保 crash 和 kernel-debuginfo 两个软件包已安装

# rpm -qa | grep "crash|kernel-debug"

（注意：如果 crash 和 kernel-debuginfo 两个软件包已安装的话，这里会有 crash 和 kernel-debuginfo 信息的显示）

步骤二：进入存放 KDUMP 内核奔溃信息的目录

# cd /var/crash/<date>/

步骤三：解析 KDUMP 生成内核崩溃信息

# crash vmlinux-2.6.32.12-0.7-default vmcore

（补充：这里以使用 2.6.32.12-0.7-default 版本的 kernel-debuginfo 解析为例）

步骤四：确认生成了 vmlinux-2.6.32.12-0.7-default.gz 压缩包

# ls vmlinux-2.6.32.12-0.7-default.gz

（注意：如果这里生成了 vmlinux-2.6.32.12-0.7-default.gz 压缩包的话，这里会有 vmlinux-2.6.32.12-0.7-default.gz 信息的显示）

（补充：这里以确认 2.6.32.12-0.7-default 版本的 kernel-debuginfo 生成的压缩包为例）

步骤五：解压 vmlinux-2.6.32.12-0.7-default.gz 压缩包

# gzip -d vmlinux-2.6.32.12-0.7-default.gz

（补充：这里以解压 2.6.32.12-0.7-default 版本的 kernel-debuginfo 生成的压缩包为例）

步骤六：分析 KDUMP 生成的内核奔溃信息

（步骤略）

/var/run/utmp

内容二：所有的登录和登出记录

/var/log/wtmp

内容三：所有用户最有一次登录记录

/var/log/lastlog

内容四：所有错误登录尝试记录

/var/log/btmp

内容五：所有信息 （其中也包括登录相关的记录）

/var/log/messages

/var/log/cron

如果是 openSUSE & SLE：

/var/spool/mail/<user>

Linux 的 kernel 会把开机日子存储在 ring buffer 和 /var/log/message 中，其中 ring buffer 里的开机日志可以使用 dmesg 来显示，如果开机时的提示信息来不及阅读的话，可以通过 dmesg 命令来显示

内容二：dmesg 命令的选项

1) -c 显示 ring buffer 的日志后清空 ring buffer
2) -n 显示日志的层级
3) -cn 显示 ring buffer 的日志后清空 ring buffer，同时显示日志的层级
4) -s 设置缓冲区的大小，默认为 8196 与 ring buffer 的大小一样

内容三：dmesg 命令的使用案例
3.1 显示所有开机日志

# dmesg | less

3.2 显示所有日志，显示 ring buffer 的日志后清空 ring buffer，同时显示日志的层级

# dmesg -cn

3.3 显示所有失败的开机日志

# dmesg | egrep -i "fail|warn|error"

步骤一：规划拓扑
1.1 服务器列表
1.2 服务器列表简介

步骤二：系统环境要求

步骤三：配置 rsyslog 服务端
3.1 修改 rsyslog 配置文件的案例
3.1.1 案例一
3.1.2 案例二
3.1.3 案例三
3.1.4 案例四
3.1.5 案例五
3.2 重启 rsyslog 服务

步骤四：配置 rsyslog 客户端
4.1 修改 rsyslog 客户端的案例
4.2 重启 rsyslog 服务

步骤五：测试 rsyslog 服务
5.1 在 rsyslog 客户端上发送日志
5.2 在 rsyslog 服务端上显示日志

具体的操作步骤：

步骤一：规划拓扑
1.1 服务器列表

rsyslog 服务端 IP 地址:192.168.0.11
rsyslog 客户端 IP 地址:192.168.0.12

1.2 服务器列表简介

rsyslog 客户端将日志发送给 rsyslog 服务端，并实现分文件存储

步骤二：系统环境要求

1) 所有服务器的系统都需要是 CentOS 8 版本
2) 所有服务器都要关闭防火墙
3) 所有服务器都要关闭 SELinux
4) 需要按照拓扑图给对应的服务器配置好 IP 地址和主机名
5) 所有服务器都要可以相互 ping 通自己和对方的 IP 地址和主机名

步骤三：配置 rsyslog 服务端
3.1 修改 rsyslog 配置文件的案例
3.1.1 案例一

（只在 rsyslog 服务端执行以下步骤）

# vim /etc/rsyslog.conf

添加以下内容：

......
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

（
补充：
1) 使用 UDP 的 514 端口接收日志
2) 使用 TCP 的 514 端口接收日志
3) 此配置会将所有 rsyslog 客户端的日志存储在 rsyslog 服务端的 /var/log/message 里
）

3.1.2 案例二

（只在 rsyslog 服务端执行以下步骤）

# vim /etc/rsyslog.conf

添加以下内容：

......
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

$template DynFile,"/var/log/%HOSTNAME%.log"
*.* -?DynFile
& ~

（
补充：
1) 使用 UDP 的 514 端口接收日志
2) 使用 TCP 的 514 端口接收日志
3) 此配置会将每个 rsyslog 客户端的日志单独存储在 /var/log/ 下的一个文件里，此文件会以其所属系统名命名
）

3.1.3 案例三

（只在 rsyslog 服务端执行以下步骤）

# vim /etc/rsyslog.conf

添加以下内容：

......
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

$template DynFile,"/var/log/remotelog/%HOSTNAME%-%$YEAR%-%$MONTH%-%$DAY%-messages.log"
*.* -?DynFile
& ~

（
补充：
1) 使用 UDP 的 514 端口接收日志
2) 使用 TCP 的 514 端口接收日志
3) 此配置会将每个 rsyslog 客户端的日志单独存储在 /var/log/remotelog 下的一个文件里，此文件会以其创建时间和其所属系统名命名
）

3.1.4 案例四

（只在 rsyslog 服务端执行以下步骤）

# vim /etc/rsyslog.conf

添加以下内容：

......
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

$template DynFile,"/var/log/remotelog/%HOSTNAME%-%$YEAR%-%$MONTH%-%$DAY%-messages.log"
:fromhost-ip,!isequal,"127.0.0.1" -?DynFile
& ~

（
补充：
1) 使用 UDP 的 514 端口接收日志
2) 使用 TCP 的 514 端口接收日志
3) 此配置会将每个 rsyslog 客户端的日志单独存储在 /var/log/ 下的一个文件里，此文件会以其创建时间和其所属系统名命名
4) 此配置不会单独存储 rsyslog 服务端的日志
）

3.1.5 案例五

（只在 rsyslog 服务端执行以下步骤）

# vim /etc/rsyslog.conf

添加以下内容：

......
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

$template DynFile,"/var/log/syslog/system-%HOSTNAME%/messages.log"
*.* -?DynFile
& ~

（
补充：
1) 使用 UDP 的 514 端口接收日志
2) 使用 TCP 的 514 端口接收日志
3) 此配置会将每个 rsyslog 客户端的日志单独存储在 /var/log/ 下某个目录的 messages 文件里，此目录会以其所属系统名命名
）

3.2 重启 rsyslog 服务

（只在 rsyslog 服务端执行以下步骤）

# systemctl restart rsyslog

（
补充：
1) 使用 UDP 的 514 端口接收日志
2) 使用 TCP 的 514 端口接收日志
3) 需要在 3.1 修改 rsyslog 配置文件的案例中任选其一完成后在执行此步骤
）

步骤四：配置 rsyslog 客户端
4.1 修改 rsyslog 客户端的案例

（只在 rsyslog 客户端执行以下步骤）

# vim /etc/rsyslog.conf

添加以下内容：

......
*.emerg;*.alert;*.crit;*.err;*.warning;*.notice;*.info  @192.168.0.11

或者：

......
*.emerg;*.alert;*.crit;*.err;*.warning;*.notice;*.info  @@192.168.0.11

（
补充：
1) 这里的 192.168.0.11 是指 rsyslog 服务端的 IP 地址
2) IP 地址前一个 “@” 符后是指使用 UDP 端口 514 传输日志
3) IP 地址前两个 “@” 符后是指使用 TCP 端口 514 传输日志
）

4.2 重启 rsyslog 服务

（只在 rsyslog 客户端执行以下步骤）

# systemctl restart rsyslog

步骤五：测试 rsyslog 服务
5.1 在 rsyslog 客户端上发送日志

（只在 rsyslog 客户端执行以下步骤）

# logger "This is our test log"

（补充：这里以发送 This is our test log 信息为例）

5.2 在 rsyslog 服务端上显示日志

（只在 rsyslog 服务端执行以下步骤）

# cat /var/log/* | grep test

# vim /etc/default/grub

在这一行里：

.....
GRUB_CMDLINE_LINUX_DEFAULT="......"
.....

确保有：

.....
GRUB_CMDLINE_LINUX="crashkernel=auto......"
.....

并确保此文件其他地方没有和 crashkernel= 相关的参数

（补充：这里的 auto 代表系统会根据内存大小自动设置一个值，也可以指定一个值，例如：crashkernel=crashkernel=128M,high、crashkernel=crashkernel=256M,high 等等，但是建议设置成 crashkernel=crashkernel=512M,high）

1.1.2 让刚刚修改的内核参数生效

# grub2-mkconfig -o /boot/grub2/grub.cfg

# reboot

1.2 方法二：通过 yast 工具修改 crashkernel 参数
1.2.1 通过 yast 工具修改 crashkernel 参数

# yast kdump

之后将 –Start-Up 中的 Kdump Low Memory [MiB] (72 – 3069) 修改为 256，将 –Start-Up 中的 Kdump High Memory [MiB] (0 – 7168) 修改为 512，之后再选择 [ OK ]

（补充：当 Kdump Low Memory 设置为 256，Kdump High Memory 设置为 512 时更易触发 Kdump）

（注意：方法二只有 openSUSE & SUSE 可以使用）

1.2 让刚刚修改的内核参数生效

# reboot

步骤二：修改 Kdump 的配置信息
2.1 修改 Kdump 的配置文件

# vim /etc/kdump.conf

将以下内容：

......
path /var/crash
core_collector makedumpfile -l --message-level 1 -d 31
......

修改为：

......
path /var/crash
core_collector makedumpfile -c -l --message-level 1 -d 31
default reboot
......

（
补充：
1) path /var/crash
2) -c 参数会对搜集的内核崩溃时的信息进行压缩
3) default reboot 参数会让 KDUMP 收集完内核崩溃时的信息后重启
）

2.2 让刚刚修改的 Kdump 配置文件生效

# systemctl enable --now kdump.service

步骤三：测试 Kdump
3.1 造成系统内核崩溃

# echo 1 > /proc/sys/kernel/sysrq ; echo c > /proc/sysrq-trigger

（注意：此时系统会自动崩溃并重启）

3.2 显示 Kdump 生成内核崩溃信息

# ls /var/crash/<date>/vmcore

（补充：这里的内核崩溃信息存放目录 /var/crash/，是刚刚在 /etc/kdump.conf 文件里指定的）

（
补充：
1) /etc/logrotate.d/messages 这个配置文件里的设置会影响到日志文件 /var/log/messages
2) 在配置文件里添加 /var/log/secure 参数则代表会将 /var/log/secure 日志文件里的内容添加到 /var/log/messages 日志文件里
3) 在配置文件里添加 delaycompress 参数则代表会将归档的日志进行压缩
4) 在配置文件里添加 rotate 5 参数则代表只会保留最近的 5 次的日志压缩文件
5) 在配置文件里添加 weekly 参数则代表每周会压缩一次日志文件
6) 在配置文件里添加 create 755 root root 参数则代表日志文件的所属主和所属组都是 root，权限是 755
）

步骤一：显示原来的 last 记录

步骤二：清除原来的 last 记录
2.1 确认原有 last 记录的日志文件
2.2 将原有 last 记录的日志文件移走
2.3 创建新的 last 记录的日志文件
2.4 给新创建的 last 记录的日志文件对应的权限

步骤三：显示 last 记录有没有被成功清除

具体的操作步骤：

步骤一：显示原来的 last 记录

# last

步骤二：清除原来的 last 记录
2.1 确认原有 last 记录的日志文件

# ls -arlt /var/log/wtmp
-rw-rw-r--. 1 root utmp 294920 Jul 20 09:57 lastlog

2.2 将原有 last 记录的日志文件移走

# mv /var/log/wtmp /var/log/wtmp.backup

2.3 创建新的 last 记录的日志文件

# touch /var/log/wtmp

2.4 给新创建的 last 记录的日志文件对应的权限

# chown root:utmp /var/log/wtmp

步骤三：显示 last 记录有没有被成功清除

# last

wtmp begins Mon Jul 20 10:07:11 2020

服务器系统配置好可用的软件源

步骤二：安装 cockpit

# yum -y install cockpit cockpit-dashaboard

（补充：cockpit 是管理单台主机的程序，cockpit-dashaboard 是管理多台主机的程序）

步骤三：启动 cockpit

# systemctl start cockpit

步骤四：登录 cockpit

使用浏览器登录：https://<服务器的/ IP 地址>:9090

# histroy

（注意：默认情况下 history 只会记录 1000 条历史命令）

1.2 显示 Linux 已归档的历史命令

# cat ~/.bash_history

内容二：使用 Linux 历史命令
2.1 直接使用第 23 条历史命令

# !23

2.2 直接使用最近的一条以 h 开头的历史命令

# !h

开启 core dump 之后，如果出现了 C 语言程序的 crash，则会将 crash 的结果记录到一个文件里

步骤二：临时开启 core dump
2.1 设置可生成 core dump 大小的参数
2.1.1 显示当前允许生成 core dump 的大小

# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 31722
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 31722
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

2.1.2 将允许生成 core dump 大小的参数设置为无限大

# ulimit -c unlimited

2.1.3 确认修改结果

# ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 31722
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 31722
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

2.2 设置 core dump 生成的位置

# sysctl -w kernel.core_pattern=/tmp/corefile/core-%e-%p

步骤三：此时如果有 C 语言的程序 crash 了，则会被自动记录

/var/log/messages

内容二：显示系统对应优先级的日志的方法

# grep -i <priority> /var/log/messages

内容三：日志消息的优先级

（注意：优先级是按照从紧急到无所谓的顺序进行排列的）

内容一：journalctl 日志工具的常用用法
1.1 显示包含某 1 个服务名的关键字的日志
1.2 显示某 1 个服务某一个优先级的日志
1.3 显示某 1 个编号的日志
1.4 显示从某 1 个日期开始到某 1 个日期结束的日志

内容二：journalctl 日志工具的使用案例
2.1 案例一：显示最近 5 条重要程度在 ERR 及以上的日志信息
2.2 案例二：显示所有与服务 httpd 相关的日志信息
2.3 案例三：显示前 5 个小时内的日志信息
2.4 案例四：在紧急模式下显示系统日志

具体的内容：

内容一：journalctl 日志工具的常用用法
1.1 显示包含某 1 个服务名的关键字的日志

# journalctl | grep <server name keywords>

1.2 显示某 1 个服务某 1 个优先级的日志

# journalctl -u <service> -p <priority>

1.3 显示某 1 个编号的日志

# journalctl -n <number of messages>

1.4 显示从某 1 个日期开始到某 1 个日期结束的日志

# journalctl --since="<yyyy-mm-dd> <HH:MM:SS>" --until="<yyyy-mm-dd> <HH:MM:SS>"

内容二：journalctl 日志工具的使用案例
2.1 案例一：显示最近 5 条重要程度在 ERR 及以上的日志信息

# journalctl -p err -n 5

2.2 案例二：显示所有与服务 httpd 相关的日志信息

# journalctl -u httpd

2.3 案例三：显示前 5 个小时内的日志信息

# journalctl --since "2019-05-01 14:00" --until "2019-05-01 19:00"

2.4 案例四：在紧急模式下显示系统日志

# journalctl -xb