介绍
我试着总结了一些被认为是运维所必需的命令。
我使用以下内容作为参考。
我参考了 LPIC Azuki Book 201 “Linux Textbook LPIC Level 2 Version 4.5 Compatible”。
我也在下面学习。
基础学院
https://infracollege.vamdemicsystem.black/linux/
查看日志的常用命令
少命令
*注意/etc下的日志只能由root用户查看。
由于经常使用“less”命令，因此它是最好的习惯命令。
一次显示一个屏幕。它是安全的，因为它是一个不可编辑的命令。
我从以下网站了解到。
https://www.wakuwakubank.com/posts/343-linux-less/
# less <ログファイル>
猫命令
cat 命令是显示所有行的命令。
在以下情况下，日志文件的所有行都通过管道传输，并在 grep 中搜索字符串。
经常使用以下命令，该命令在发生故障时仅从日志中提取错误部分。
最好记住。
grep i 选项用于不区分大小写的搜索。
# cat <ログファイル> | grep -i "<検索する文字列>"
以下は出力例です。
# cat /var/log/messages | grep -i "error"
Aug 6 10:20:29 localhost kernel: BERT: Boot Error Record Table support is disabled. Enable it by using bert_enable as kernel parameter.
Aug 6 10:20:30 localhost kernel: [drm:vmw_host_log [vmwgfx]] *ERROR* Failed to send host log message.
Aug 6 10:20:30 localhost kernel: [drm:vmw_host_log [vmwgfx]] *ERROR* Failed to send host log message.
cat 命令用于显示日志文件的所有行。
很少使用的命令
“view”命令是一次显示一个屏幕的命令。因为可以编辑，
不建议使用它来检查日志。
# view <ログファイル>
* 我有使用 cat 的经验，并且视图不正确。 cat 是全屏显示日志的命令。
view 是一次显示一个屏幕的命令，因此请注意不要出错。
日志管理
日志（/var/log/messages）
/var/log/messagesは、OSのログで「シスログ」と呼ばれます。
最好记住这些词，因为它们经常在该领域中使用。
检查此日志以查看发生故障时操作系统中发生的情况。
*这通常是发生故障时要检查的第一件事。
以下日志是操作系统重启时的日志。
[root@localhost log]# cat /var/log/messages | grep "Kernel"
May 30 07:30:36 localhost kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0-1160.el7.x86_64 root=/dev/mapper/centos-root ro crashkernel=auto spectre_v2=retpoline rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet LANG=ja_JP.UTF-8
May 30 07:30:36 localhost systemd[1]: Listening on udev Kernel Socket.
May 30 07:30:36 localhost systemd[1]: Starting Apply Kernel Variables...
May 30 07:30:36 localhost systemd[1]: Started Apply Kernel Variables.
May 30 07:30:36 localhost systemd: Starting udev Kernel Device Manager...
May 30 07:30:36 localhost systemd: Started udev Kernel Device Manager.
May 30 07:30:38 localhost systemd: Stopping udev Kernel Device Manager... ※カーネルの停止
May 30 07:30:38 localhost systemd: Stopped Apply Kernel Variables.
May 30 07:30:38 localhost systemd: Stopped udev Kernel Device Manager.
May 30 07:30:38 localhost systemd: Closed udev Kernel Socket.
May 30 07:30:38 localhost systemd: Started Remount Root and Kernel File Systems.
May 30 07:30:38 localhost systemd: Starting udev Kernel Device Manager...※カーネルの起動
May 30 07:30:38 localhost systemd: Started udev Kernel Device Manager.
日志（/var/log/boot.log）
这是操作系统启动时的日志。
个人看的不多，因为没有显示日志发生的日期和时间，所以很难理解。
我认为理解下面的日志需要一些技巧。
# less /var/log/boot.log
[ESC[32m OK ESC[0m] Started Show Plymouth Boot Screen.
[ESC[32m OK ESC[0m] Reached target Paths.
[ESC[32m OK ESC[0m] Started Forward Password Requests to Plymouth Directory Watch.
[ESC[32m OK ESC[0m] Reached target Basic System.
ESC%G[ESC[32m OK ESC[0m] Found device /dev/mapper/centos-root.
Starting File System Check on /dev/mapper/centos-root...
[ESC[32m OK ESC[0m] Started File System Check on /dev/mapper/centos-root.
[ESC[32m OK ESC[0m] Started dracut initqueue hook.
[ESC[32m OK ESC[0m] Reached target Remote File Systems (Pre).
[ESC[32m OK ESC[0m] Reached target Remote File Systems.
Mounting /sysroot...
日志（/var/log/cron）
这是执行 cron 时的日志输出。
cron 在下面的文章中进行了总结。如果你喜欢，请参考它。
https://qiita.com/gama1234/items/2df167899ebdd6c1c983
# less /var/log/cron
Aug 7 08:41:01 localhost run-parts(/etc/cron.daily)[1502]: starting man-db.cron
Aug 7 08:41:07 localhost run-parts(/etc/cron.daily)[11369]: finished man-db.cron
Aug 7 08:41:07 localhost anacron[1497]: Job `cron.daily' terminated
Aug 7 09:01:01 localhost anacron[1497]: Job `cron.weekly' started
Aug 7 09:01:01 localhost anacron[1497]: Job `cron.weekly' terminated
日志（/var/log/secure）
这是用户认证期间的日志输出。
这是从主机操作系统“192.168.0.14”ssh 到来宾操作系统时的日志。
然后我被提升为root。
# less /var/log/secure
#ssh接続のログ
Aug 14 10:35:05 localhost sshd[1353]: Accepted password for test from 192.168.0.14 port 53164 ssh2
Aug 14 10:35:05 localhost sshd[1353]: pam_unix(sshd:session): session opened for user test by (uid=0)
Aug 14 10:35:26 localhost sudo: test : TTY=pts/0 ; PWD=/home/test ; USER=root ; COMMAND=/bin/less /var/log/secure
#rootに昇格のログ
Aug 14 10:35:26 localhost sudo: pam_unix(sudo:session): session opened for user root by test(uid=0)
检查用户登录的命令
w 命令
查看当前登录的用户。
下面是一个示例输出。
$ w
11:00:46 up 1:25, 1 user, load average: 0.00, 0.01, 0.02
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
test pts/0 192.168.0.14 10:35 6.00s 0.01s 0.00s w
最后一个命令
检查过去的登录历史
下面是一个示例输出。
$ last
test pts/0 192.168.0.14 Sun Aug 14 10:35 still logged in
test pts/0 192.168.0.14 Sun Aug 14 09:36 - 10:34 (00:58)
reboot system boot 3.10.0-1160.el7. Sun Aug 14 09:35 - 10:54 (01:18)
root pts/0 192.168.0.14 Tue Aug 9 20:55 - crash (4+12:39)
reboot system boot 3.10.0-1160.el7. Tue Aug 9 20:55 - 10:54 (4+13:59)
root pts/2 10.0.0.1 Sun Aug 7 07:21 - 07:22 (00:00)
root pts/1 10.0.0.1 Sun Aug 7 07:19 - 07:40 (00:21)
test pts/0 192.168.0.14 Sun Aug 7 07:02 - 10:05 (03:02)
最后的日志命令
用户上次登录信息。
这是一个可以检查用户过去是否登录过的命令。
我参考了以下网站。
https://atmarkit.itmedia.co.jp/ait/articles/1903/29/news046.html
$ lastlog
Username Port From Latest
root pts/0 Sun Aug 14 09:36:19 +0900 2022
bin **Never logged in**
daemon **Never logged in**
adm **Never logged in**
lp **Never logged in**
sync **Never logged in**
shutdown **Never logged in**
halt **Never logged in**
mail **Never logged in**
operator **Never logged in**
games **Never logged in**
ftp **Never logged in**
nobody **Never logged in**
systemd-network **Never logged in**
dbus **Never logged in**
polkitd **Never logged in**
sshd **Never logged in**
postfix **Never logged in**
chrony **Never logged in**
test pts/0 192.168.0.14 Sun Aug 14 10:35:05 +0900 2022
nginx **Never logged in**
apache **Never logged in**
发生故障时检查命令
正常运行时间命令
您可以检查 CPU 平均负载以及操作系统上次停止的小时数或天数。
在下面的示例中，系统已经运行了 1 小时 36 分钟。
# uptime
11:12:21 up 1:36, 1 user, load average: 0.00, 0.01, 0.02
11:12:21 是当前时间 系统运行时间（1 小时 36 分钟） 用户连接期间用户负载平均
以下网站很有帮助。
https://wa3.i-3-i.info/word11667.html
关于平均负载
等待运行的进程数（1 分钟/5 分钟/15 分钟）
如果上述数量超过 CPU 核心数和 CPU 数量，则发生了某种处理等待
如果有 2 个 2 核的 CPU，如果平均负载超过 4，则存在某种等待
从上面可以看出CPU的负载情况。
我使用以下站点作为如何检查 CPU 内核数量的参考。
https://access.redhat.com/ja/solutions/2159401
以下是检查 CPU 核数等时的执行示例。
#論理プロセッサの数(有効なプロセッサーの数)
# cat /proc/cpuinfo | grep processor
processor : 0
#物理CPU数
# cat /proc/cpuinfo | grep physical.id
physical id : 0
#CPUコア数
# cat /proc/cpuinfo | grep "core"
core id : 0
cpu cores : 1
顶部命令
它是一个可以检查进程状态以及CPU和内存的负载状态的命令。
最好记住它，因为它经常用于商业。
1.系统正常运行时间
当前时间/正常运行时间（在下面的证据中增加了 2 分钟）/登录的用户数
*查看运行时间后，您可以查看操作系统上次重启的时间或天数。
2.负载情况
等待运行的进程数（1 分钟/5 分钟/15 分钟）
如果上述数字超过 CPU 内核数和 CPU 数，则发生了某种处理等待。
如果有 2 个 2 核的 CPU，如果平均负载超过 4，则存在某种等待
3. 内存满时使用交换。
这是 TOP 命令的执行示例。
添加了描述。 *如果描述中有任何错误，我深表歉意。
对于 top 命令，以下站点很有帮助。
https://atmarkit.itmedia.co.jp/ait/articles/1706/30/news018.html
※システム稼働時間、負荷状態
top - 08:46:10(現在の時刻) up 35 min(システム稼働時間), 2 users(ユーザー数), load average: 0.00(1分負荷), 0.01(5分負荷), 0.01(15分負荷)
※プロセスの状態
Tasks: 104 total(総合プロセス数), 2 running(プロセス実行数), 102 sleeping, 0 stopped, 0 zombie
※CPU状態
%Cpu(s): 0.0 us(ユーザープロセス割合), 0.0 sy(カーネル割合), 0.0 ni(優先度変更したプロセス割合),100.0 id(アイドル割合), 0.0 wa(ディス久IO割合), 0.0 hi(ハードウェア割り込み割合), 0.0 si(ソフトウェア割り込み割合), 0.0 st(ゲストOS未割当割合)
※メモリの状態
KiB Mem : 1014756 total(全部物理メモリ容量), 712528 free(空きメモリ容量), 175808 used(使用中メモリ容量), 126420 buff/cache(バッファとキャッシュサイズ)
KiB Swap: 839676 total(総合スワップ容量), 839676 free(空きスワップ容量), 0 used(使用中のスワップ容量). 700784 avail Mem(メモリ不足時に利用できるメモリ量)
※プロセスの状態
PID USER PR NI VIRT(仮想メモリ使用量) RES(実メモリ使用量) SHR S %CPU %MEM TIME+ COMMAND
1430 root 20 0 162084 2224 1560 R(実行可能状態) 0.3 0.2 0:00.28 top
1 root 20 0 125352 3880 2584 S(実行待ち状態) 0.0 0.4 0:00.65 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
4 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
5 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kworker/u2:0
6 root 20 0 0 0 0 S 0.0 0.0 0:00.06 ksoftirqd/0
7 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
为了确认 TOP 命令的操作，施加负载的命令如下。
这是一个简单地输出 yes 的命令。
# yes >> /dev/null
我检查了 TOP 命令，是的，该进程的 CPU 使用率为 99%。
# top
top - 12:07:01 up 2:31, 2 users, load average: 1.82, 0.57, 0.22
Tasks: 111 total, 2 running, 109 sleeping, 0 stopped, 0 zombie
%Cpu(s): 95.7 us, 4.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 1014756 total, 771064 free, 162808 used, 80884 buff/cache
KiB Swap: 839676 total, 839676 free, 0 used. 736536 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1582 root 20 0 108056 616 520 R 99.0 0.1 1:27.24 yes
1511 root 20 0 0 0 0 D 0.3 0.0 0:00.21 kworker/0:1
1 root 20 0 125352 3896 2584 S 0.0 0.4 0:02.14 systemd
df 命令
此命令允许您检查磁盘使用率。
# df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 484M 0 484M 0% /dev
tmpfs 496M 0 496M 0% /dev/shm
tmpfs 496M 6.8M 489M 2% /run
tmpfs 496M 0 496M 0% /sys/fs/cgroup
/dev/mapper/centos-root 6.2G 1.6G 4.7G 25% /
/dev/sda1 1014M 137M 877M 14% /boot
tmpfs 100M 0 100M 0% /run/user/1000
我尝试创建更大的文件并确认大小发生了变化。
下面的命令创建一个 1G 的文件。
指定 bs（块大小）/if（输入文件 /dev/zero 为空）/of（输出文件）
# dd if=/dev/zero of=1gfile bs=1M count=1024
# ls -ltr /tmp/1gfile
-rw-r--r-- 1 root root 1073741824 8月 14 11:39 /tmp/1gfile
我再次运行 df -h 命令。
安装位置“/”的使用从 1.6G 增加到 2.6G
# df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 484M 0 484M 0% /dev
tmpfs 496M 0 496M 0% /dev/shm
tmpfs 496M 6.8M 489M 2% /run
tmpfs 496M 0 496M 0% /sys/fs/cgroup
/dev/mapper/centos-root 6.2G 2.6G 3.7G 41% /
/dev/sda1 1014M 137M 877M 14% /boot
tmpfs 100M 0 100M 0% /run/user/1000
ps 命令
ps -ef 是一个分层显示所有进程的命令。
意识到您运行的命令在进程中也是可见的。
以下网站很有帮助。
https://atmarkit.itmedia.co.jp/ait/articles/1603/28/news022.html
下面的命令通过管道传输所有进程的状态，以按进程名称或脚本名称进行搜索。
作为使用示例，在重启服务之前，为了不中断脚本的处理，
您可以使用以下命令检查脚本是否正在运行。
# ps -ef | grep <プロセス名 or スクリプト名>
以下はnginxのプロセスが実行中であることを確認しました。
# ps -ef | grep nginx
root 1009 1 0 21:22 ? 00:00:00 nginx: master process /usr/sbin/nginx
nginx 1010 1009 0 21:22 ? 00:00:00 nginx: worker process
root 1266 1244 0 21:23 pts/0 00:00:00 grep --color=auto nginx
监视命令
以下网站很有帮助。
https://atmarkit.itmedia.co.jp/ait/articles/1806/29/news037.html
以下命令每秒使用 watch 命令显示搜索到的进程。
由于 grep 命令的进程显示是不必要的，所以用 grep -v 将其隐藏。
# watch -n <秒> "ps -ef | grep <プロセス名 or スクリプト名> | grep -v grep"
以下のコマンドは、1秒ごとにnginxのプロセスを表示するコマンドです。
# watch -n 1 "ps -ef | grep nginx | grep -v grep"
下面是执行结果。
补充。
下面是检查 nagios 进程是否正在运行的命令。
# watch -n 1 "ps -ef | grep nagios | grep -v grep"
nagios 进程未运行，因为它仅显示您运行的 ps 命令。
如果 nagios 进程正在运行，您将看到如下内容：
概括
可能缺少一些命令，但我在本文中列出了所有必要的命令。
如果没有经验，发生故障时要检查什么日志以及使用什么命令
它可能不会马上出来。
记录您遇到的警报和
为了让任何人在出现未知警报时都能立即做出响应，
我个人认为最好准备一个日志列表和命令集合。
我希望你觉得这篇文章有帮助。
原创声明：本文系作者授权爱码网发表，未经许可，不得转载;
原文地址：https://www.likecs.com/show-308623373.html