Linux 日志级别

本文介绍了Linux内核的8个日志级别,从KERN_EMERG到KERN_DEBUG,详细阐述了每个级别的用途和严重性。通过检查/proc/sys/kernel/printk或使用sysctl命令可以查看当前日志级别。若需更改,默认控制台日志级别可通过修改/proc/sys/kernel/printk或在grub配置中持久化设置。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


前言

`

本教程的目的是了解各种 linux 内核日志级别、它们的组织方式,以及我们如何根据消息的严重性设置应在控制台上显示哪些消息。


一、Linux 内核日志级别简介

1.介绍

Linux 内核日志文件的管理是服务器管理的一个重要方面:日志可以简单地通知我们守护程序的状态,或者显示关键消息或警告。在本教程中,我们将看到 linux 内核使用的各种类型的日志级别,它们如何划分严重性,以及如何根据日志级别过滤控制台上显示的消息。

2. Linux 内核日志级别

基本上有八个日志级别,由linux内核发送消息,日志级别从高到低,level 0 ~ level 7 。

级别简述:

 0 KERN_EMERG 
 这是按严重性排序的最高级别:它被有关系统不稳定或即将崩溃的消息采用。

 1 KERN_ALERT    
 此级别用于立即需要用户注意的情况。

 2 KERN_CRIT
 此严重性级别用于通知与硬件或软件相关的严重错误。

 3 KERN_ERR
 通常用于通知用户非关键错误,例如设备识别失败或有问题,或者更一般的驱动程序相关问题。

 4 KERN_WARNING
 或 loglevel 它是大多数 Linux 发行版中通常用作默认值的日志级别。此级别用于显示有关非即将发生的错误的警告或消息。

 5 KERN_NOTICE
 此级别的消息是关于可能值得注意的事件。

 6 KERN_INFO
 此级别的消息用于有关内核执行的操作的信息性消息的日志级别。

 7 KERN_DEBUG
 此级别的消息主要用于调试。

3.如何检查当前默认日志级别

检查系统上使用的默认日志级别非常容易。我们要做的就是检查文件的内容。它实际上并不在磁盘上,而是由内核创建并在内存中维护的系统状态的可视化表示。在这种情况下,我们可以运行以下命令来查询有关系统中设置的默认控制台日志级别的信息。

运行

[root@localhost ~]# cat /proc/sys/kernel/printk
4	4	1	7

[root@localhost ~]# sysctl kernel.printk
kernel.printk = 4	4	1	7

这是命令的典型输出:

4       4       1       7

输出介绍

第一个值:	第一个值是电流,这就是我们正在寻找的信息:在本例中,该值表示当前使用的日志级别。如前所述,这意味着只有采用高于其严重性级别的消息才会显示在控制台上。console_loglevel4

第二个值:	此值自动用于没有特定日志级别的消息:如果消息未与日志级别关联,则将使用此消息。default_message_loglevel

第三个值:	它指示可用于 的最低日志级别。这里使用的级别是,最高。minimum_console_loglevelconsole_loglevel 1

最后的值:	这是引导时使用的默认日志级别。default_console_loglevelconsole_logleve l

4.更改默认控制台日志级别

在某些情况下,我们可能想要更改该值,让我们看看如何更改。

我们可以使用最直接的方法是将新值写入文件。但是,这是一个临时解决方案,新设置计算机重新启动不会保留。假设我们要将默认控制台日志级别更改 ,以下是我们要运行的内容:

$ echo "3" | sudo tee /proc/sys/kernel/printk

或者,直接使用该帐户:root

echo "3" > /proc/sys/kernel/printk

通过查看文件的内容,我们可以验证loglevel现在是否是我们在命令中指定的级别:

$ cat /proc/sys/kernel/printk
3       4       1       7

我们可以使用以下命令获得相同的结果:

sudo sysctl -w kernel.printk=3

要以持久的方式更改默认日志级别,我们必须修改文件,在启动时将参数传递给内核命令行:

vim /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="loglevel=3 resume=UUID=df5a0685-43f8-433a-8611-57335a10ca8d"
GRUB_DISABLE_RECOVERY="true"

上面是 /etc/default/grub 文件的内容,主要修改的内容是:loglevel=3

GRUB_CMDLINE_LINUX="loglevel=3"

修改文件并保存更改后,重新加载 grub,以便在下次重新启动时应用新配置:执行此操作的命令取决于我们正在运行的发行版。

$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

在基于 Debian 的发行版上,使用以下命令:

$ sudo update-grub

grub 配置将被更新,在下次重新启动时,指定的日志级别将被采用为默认值。

结论

在本教程中,我们学习了如何根据其严重性级别组织 linux 内核日志。我们还看到了如何更改默认设置,以便使用相同的条件在控制台上仅显示内核发送的某些消息。最后,我们看到了如何持久化这些更改。

<think>我们正在处理用户的问题:如何修改客户端应用的日志级别。根据提供的引用内容,我们有几种不同的方法可以实现动态修改日志级别。引用[1]提到使用Zookeeper来动态更改日志级别。具体做法是:利用Zookeeper的监听机制,为一个节点添加监听器,当节点发生变化时,更改日志级别。这样,多个服务(如本机和虚拟机上的服务)连接同一个Zookeeper服务,通过修改Zookeeper上节点的值,就可以动态更改项目中日志级别。引用[3]和引用[4]则提供了通过编程接口动态修改日志级别的方法:-引用[4]展示了一个Spring MVC的Controller接口,通过HTTP请求传递日志级别(如DEBUG,INFO,WARN等),然后获取LoggerContext,设置根日志记录器(rootlogger)的级别。-引用[3]则提供了一个更具体的方法`setDegradationLoggerLevel`,它通过`loggingSystem`来修改指定类(这里是工具类自身)的日志级别,并做了安全校验(检查级别是否支持,当前级别是否已相同等)。引用[5]提到可以通过配置来动态修改特定Logger的日志级别,例如将`com.hollis.degradation.core.logger.LoggerLevelSettingService`的日志级别修改为WARN。根据用户的问题,用户想调整的是“客户端应用程序”的日志输出详细程度,即修改日志级别。我们可以提供以下几种方法:方法1:通过配置文件修改(静态)-在应用的配置文件中(如application.yml或application.properties)设置日志级别。例如,在SpringBoot应用中,可以在application.yml中添加:```yamllogging:level:root: INFO#设置根日志级别com.example:DEBUG#设置特定包下的日志级别```但这种方法需要重启应用。方法2:通过编程接口动态修改(无需重启)-如引用[4]所示,我们可以创建一个HTTP接口,通过调用该接口来动态修改日志级别。示例代码如下(SpringBoot环境):```javaimportorg.slf4j.LoggerFactory;import ch.qos.logback.classic.Level;import ch.qos.logback.classic.LoggerContext;importorg.slf4j.Logger;importorg.springframework.web.bind.annotation.PathVariable;importorg.springframework.web.bind.annotation.RequestMapping;importorg.springframework.web.bind.annotation.RestController;@RestControllerpublicclass LogLevelController{private staticfinal Loggerlogger =LoggerFactory.getLogger(LogLevelController.class);@RequestMapping("/logLevel/{logLevel}")public StringchangeLogLevel(@PathVariable("logLevel") StringlogLevel) {try{LoggerContextloggerContext= (LoggerContext) LoggerFactory.getILoggerFactory();//修改根日志记录器的级别ch.qos.logback.classic.LoggerrootLogger= loggerContext.getLogger(org.slf4j.Logger.ROOT_LOGGER_NAME);rootLogger.setLevel(Level.valueOf(logLevel));return"日志级别已修改为:" +logLevel;} catch(Exceptione){logger.error("修改日志级别失败",e);return"修改失败:" +e.getMessage();}}}```这样,通过访问`http://localhost:8080/logLevel/DEBUG`就可以将根日志级别设置为DEBUG。方法3:使用外部配置中心(如Zookeeper)动态修改-如引用[1]所述,我们可以将日志级别配置存储在Zookeeper的某个节点上,并在应用启动时读取该节点的值作为初始日志级别,同时监听该节点的变化。当节点值变化时,应用自动更新日志级别。-实现步骤:1.在Zookeeper上创建一个节点,例如`/app/logLevel`,初始值可以是`INFO`。2.在应用中,使用Zookeeper客户端(如Curator)连接Zookeeper,获取节点初始值并设置日志级别。3.为节点添加监听器(Watcher),当节点数据变化时,重新设置日志级别。方法4:使用SpringBoot Actuator(如果应用是SpringBoot)-Spring BootActuator提供了`loggers`端点,可以动态查看和修改日志级别。需要先添加依赖并启用端点。-添加依赖(Maven):```xml<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-actuator</artifactId></dependency>```-配置application.yml:```yamlmanagement:endpoints:web:exposure:include:loggersendpoint:loggers:enabled:true```-然后,可以通过HTTP请求来修改日志级别:查看所有日志级别:GET/actuator/loggers查看特定Logger的级别:GET/actuator/loggers/{name}修改日志级别:POST /actuator/loggers/{name}请求体:{"configuredLevel":"DEBUG"}根据用户的需求,如果用户希望动态修改(无需重启),推荐使用方法2(自定义接口)或方法4(使用Actuator)或方法3(使用配置中心)。注意:不同的日志框架(如Logback、Log4j2)可能有不同的API,以上代码示例是基于Logback的。如果使用其他日志框架,需要调整相应的API。因此,我们可以总结如下:要修改客户端应用的日志级别,有两种主要方式:1.静态修改:通过配置文件,修改后需要重启应用。2.动态修改:-自定义HTTP接口(如方法2)-使用配置中心(如Zookeeper,如方法1)-使用SpringBoot Actuator(如方法4)用户可以根据自己的应用环境和需求选择合适的方法。相关问题:1.如何通过SpringBoot Actuator动态修改日志级别?2.使用Zookeeper动态修改日志级别的具体实现步骤是什么?3.修改日志级别时,如何确保只修改特定包或类的日志级别?4.动态修改日志级别后,如何恢复为初始配置?5.除了Zookeeper,还有哪些配置中心可以实现动态修改日志级别?</think>### 如何修改客户端应用的日志级别 调整日志级别是优化应用监控和调试的关键操作。以下是三种主流方法,根据你的技术栈选择合适方案: #### 方法1:配置文件修改(静态) 在应用配置文件中直接指定日志级别(需重启生效): ```yaml # application.yml 示例 logging: level: root: WARN # 全局日志级别 com.example.client: DEBUG # 指定包路径的日志级别 ``` - **生效条件**:应用重启后加载新配置 - **适用场景**:预发布环境、不需实时调整的场景 - **注意事项**:不同框架配置路径可能不同(如Log4j2用`log4j2.xml`) #### 方法2:HTTP接口动态修改(无需重启) 通过REST API实时调整日志级别(基于Spring Boot示例): ```java @RestController public class LogLevelController { @PostMapping("/logLevel/{level}") public String changeLogLevel(@PathVariable String level) { try { // 获取日志上下文 LoggerContext loggerContext = (LoggerContext) LoggerFactory.getILoggerFactory(); // 设置ROOT日志级别 loggerContext.getLogger("ROOT").setLevel(Level.valueOf(level)); return "日志级别已切换至: " + level; } catch (Exception e) { return "修改失败: " + e.getMessage(); } } } ``` - **调用方式**:`POST /logLevel/DEBUG` - **支持级别**:`TRACE`, `DEBUG`, `INFO`, `WARN`, `ERROR` - **优势**:实时生效,无需中断服务[^4] - **扩展**:可指定特定类名 `loggerContext.getLogger("com.example.Client").setLevel(...)` #### 方法3:配置中心动态管理(分布式场景) 使用Zookeeper实现集群级日志级别同步: ```java // Zookeeper监听器示例 public class LogLevelWatcher implements CuratorWatcher { @Override public void process(WatchedEvent event) { String newLevel = zkClient.getData("/config/logLevel"); loggingSystem.setLogLevel("ROOT", LogLevel.valueOf(newLevel)); } } ``` - **操作流程**: 1. 在Zookeeper创建节点 `/config/logLevel` 2. 应用启动时注册监听器 3. 通过zkClient修改节点值触发级别更新[^1] - **适用场景**:微服务架构、多实例统一配置 ### 注意事项 1. **级别继承**:子包日志器默认继承父包级别,显式设置可覆盖 2. **性能影响**:`TRACE/DEBUG`级别在高并发场景可能影响性能 3. **热更新局限**:部分低版本Log4j需配合`JMX`实现动态更新 4. **安全控制**:开放动态接口时需添加权限验证 > 最佳实践:生产环境建议采用 **方法3(配置中心)** + **方法2(应急接口)** 的组合方案,既保证统一管理又保留紧急调试能力[^1][^4]。 --- ### 相关问题 1. 动态修改日志级别后如何持久化到配置文件? 2. 在微服务架构中如何批量修改所有服务的日志级别? 3. 日志级别从DEBUG切回INFO后,为什么仍有DEBUG日志输出? 4. 如何通过JMX不重启应用修改日志级别? 5. 高并发场景下开启DEBUG日志有哪些性能优化方案? [^1]: 使用Zookeeper动态更改日志级别。利用Zookeeper监听机制,为一个节点添加监听器,当该节点发生变化时,更改日志级别 [^4]: 自定义一个给定日志级别的接口,外部直接通过调用接口来改变级别
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值