如果有一天，你按需求配置完了环境，检查完交付别组使用，过几天那组的家伙找过来说他们折腾了一通之后现在ssh加了密钥登陆还是得输密码，那么，你需要按照以下步骤解决问题：

1. 检查sshd端口和服务
2. 检查密钥文件以及目录，以及他们所在的位置
3. 检查.ssh及.ssh/*的权限是否为700，600
4. 检查.ssh及.ssh/*的属主是否是对应的用户
5. 告诉他们这是他们自己折腾出来的问题，不在你的负责范围内

last\w确定重启时间

/var/log/messages

dmesg -d -T

journalctl -k --list

journalctl -k -l 重启前的日志号

如果以上都看不出任何问题的话，可能是别的一些棘手的情况，比如这次遇到的就是内核上的bug，messages日志无异常且journalctl丢失重启前的所有日志

某应用的两台机器8088不通，8080通，检查情况

登上这两台机器，互telnet，不通，这两台机器在同一网段，说明不是外部防火墙权限问题。lsof -i查看，8088有应用在监听，iptables --list -n | grep 8088未找到规则，8080的有，vi /etc/sysconfig/iptables ，把8080的规则复制一份给8088加上，重启iptables，问题解决

prometheus上线一个应用，部分监控报Multiple Series Error，检查后考虑对象可能一台机器就可以报集群内所有机器信息，于是只保留一台，下架多余的机器监控。下架后部分数据恢复，但是仍有一些监控项报Multiple Series Error

手动执行promQL，发现数据获取正常，考虑可能是旧错误数据干扰，勾选instant后恢复正常

cpu、内存、进程

top
ps -aux

硬盘

df -h
du -h --max-depth
lsblk
snmpwalk

网络

ip查询

mtr

mtr xxx.com :用来检测发出数据包的主机到目标主机之间经过的网关数量，及网络质量、丢包、延时.主要看loss值，只有在目标那一跳丢包才是真的丢包，中间有丢包很正常不用管(首选)

ping

ping xxxx.com :探测到对端网络质量有无丢包，可以获取域名解析的 IP 地址

traceroute

traceroute :用来检测发出数据包的主机到目标主机之间经过的网关数量，及网络质量

traceroute -n xxx.cn
traceroute -n -T -p [$Port] [$Host]
traceroute -n -T -p 443 xxx.com (探测端口)

• -n：直接使用IP地址而非主机名称（禁用DNS反查）。
• -T：通过TCP探测。
• -p：设置探测的端口号。
• [$Port]：需要探测的端口号，比如"80"。
• [$Host]：需要探测的目标服务器地址，比如“10.10.1.1”。

curl

请求耗时长可以使用此工具判断一个请求每个歩聚的时间

curl -so /dev/null -w '   
namelookup: %{time_namelookup}
connect: %{time_connect}
appconnect: %{time_appconnect}
pretransfer: %{time_pretransfer}
redirect: %{time_redirect}
starttransfer: %{time_starttransfer}
-------
total: %{time_total}
' baidu.com -d 'a=b'

   namelookup: 0.004 //dns解析
      connect: 0.036 //建立链接时间
   appconnect: 0.000 //ssl建立时间
  pretransfer: 0.036 //准备传输时间
     redirect: 0.000 //重定向时间
starttransfer: 0.070 //传输时间
               -------
        total: 0.070  //共计

tcpdump

https://blog.csdn.net/qq_51574197/article/details/116171604

嗅探80端口

日志

dmesg
journalctl
/var/log/