【linux服务】服务器报错日志记录分析，自用可参考

泽灯

已于 2024-01-24 13:47:11 修改

阅读量1.4k

点赞数 28

分类专栏： linux 文章标签：服务器 linux 运维

于 2024-01-24 11:36:57 首次发布

本文链接：https://blog.csdn.net/qq_45181681/article/details/135817053

版权

linux 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

用的docker镜像部署：
查看服务日志方法**（空格不能省略）**：

如果知道具体日志文件的路径，执行如下命令：

tail -200f 你的路径
#举例：
tail -200f /data/logs/system.log

直接查看容器日志，执行如下命令：

#先查看当前运行的容器，使用如下命令
docker ps 
#查看容器服务的日志：
docker logs -f --tail 300 你的容器号/容器名字
#容器号复制CONTAINER ID
#容器名称复制NAME

日志概述（这部分是参看别的博主的，需要请直接点击查看）

1，日志作用

在项目开发或测试过程中，项目运行一旦出现问题，记录日志信息就显得尤为重要。主要通过日志来定位问题，就好比侦探人员要根据现场留下的线索来推断案情。
2，日志级别

代码在运行的过程中会出现不同的情况，如调试信息、警告信息、报错等，那么采集日志时就需要对这些日志区分级别管理，这样才能更精确地定位问题。
日志级别一般分类如下（以严重程度递增排序）：
日志级别排序为：CRITICAL > ERROR > WARNING > INFO > DEBUG
志采集时设置低级别的日志，能采集到更高级别的日志，但不能采集到更低级别的日志。

例如：设置的日志级别为info级别，就只能采集到info、warning、error、critical级别的日志，不能采集到debug级别的日志。设置的日志级别为debug级别的话则能采集到所有级别的日志。默认设置级别为WARNING。
在自动化测试项目中，通常在一般情况时使用info日志，预计报错则使用error日志。

3，日志格式

将日志格式化是为了提高日志的可阅读性，比如：时间+模块+行数+日志级别+日志具体信息的日志格式。如果输出的日志信息杂乱无章，就不利于问题的定位。如下所示就是日志格式化输出，非常便于阅读查看。

2020-09-30 10:45:05,119 logging_test.py[line:7] DEBUG this is debug message.
2020-09-30 10:45:05,119 logging_test.py[line:9] INFO this is info message.
2020-09-30 10:45:05,119 logging_test.py[line:11] WARNING this is warning message.
2020-09-30 10:45:05,120 logging_test.py[line:13] ERROR this is error message.

分析报错信息

找到报错日志文件后，接下来需要对日志信息进行分析，找出问题所在。一般来说，报错信息中包含了一些关键字，可以通过关键字来找出报错原因。以下是一些常见的报错信息及其解决方法：

“Permission denied”：
可能是由于文件或目录的权限设置错误导致的。可以通过chmod命令修改文件或目录的权限。
“Connection refused”：
可能是由于服务未启动或端口被占用导致的。可以使用netstat命令查看端口占用情况，并用systemctl启动或重启相关服务。
“Segmentation fault”：
可能是由于程序代码错误导致的。建议升级或重新编译程序。
“Out of memory”：
可能是由于系统内存不足导致的。可以通过top命令查看内存使用情况，并优化应用程序的内存

还有一个博客可以参考，讲的比较细也比较全