理解Linux日志等级的基本概念
Linux日志等级是对系统与应用产生信息的严重程度进行分级的机制，常见等级从最高的emerg到最低的debug，便于管理员按需筛选关注点。理解这一点，可以让你在遇到问题时快速定位根因并控制日志产出量。
在大多数实现中，等级与数值的对应关系是 0（emerg）到 7（debug），数字越小表示越严重，优先级越高。常用的组合是为了把“信息级别及以上”或“仅调试级别”日志输出到指定目的地，避免无用信息淹没关键告警。
实际运维中，一个应用既会产生高优先级告警，也会输出大量调试信息，因此需要通过日志配置来控制哪些等级的日志会被保存。本文将围绕“Linux日志级别怎么调？”这一主题，介绍各级别含义以及实战调参要点。
日志等级的核心含义与常见名称对照
在实际使用中，emerg、alert、crit、err、warning、notice、info、debug8个等级分别对应不同的告警强度。理解它们的用途有助于你决定在哪些场景保留哪些日志。例如，emerg/alert/crit/err通常用于明确的故障或不可用的状态，warning/notice适用于可预期但需要关注的异常，info、debug用来在排错时扩充信息。
在实施层面，很多系统采用“等级越低越严重”的规则。你可以通过配置日志框架来实现“输出 info 及以上等级的日志，但排除某些低优先级信息”，从而达到“信息丰富又不过载”的平衡。
重要点：无论你使用的是rsyslog、syslog-ng还是systemd-journald，核心思想都是对输出日志进行分级过滤，以便按场景取舍。
系统日志框架与等级在Linux中的实现
系统日志框架在Linux环境中通常包含rsyslog、syslog-ng和systemd-journald等实现。它们负责接收、过滤、持久化和转发日志。不同发行版的默认实现可能不同，但目标是一致的：提供可配置的等级控制、过滤规则及输出路径。
rsyslog和journald各有特点：rsyslog以灵活的过滤表达式著称，支持按设施、等级、程序名等多维度筛选；journald则与systemd紧密整合，偏向以结构化字段和单位（unit）来组织日志，同时支持向文件、远端目标等转发。
你可以通过直接查看日志查看器来观察效果，例如使用 journalctl 查看基于等级的日志输出，或在 rsyslog 配置中写出具体的等级筛选规则。"一文搞懂各级别的含义与实战调参要点" 的思路就体现在如何在这两大实现之间选择最合适的组合来达到目标输出。
rsyslog 与 journald 的核心差异
rsyslog的优势在于灵活的规则引擎和广泛的输出插件，适合复杂的日志收集与分发场景。通过配置文件中的规则，可以实现细粒度的等级控制和按源的分流。示例配置可以将 info 及以上等级输出到一个文件，将 debug 仅输出到单独的调试日志。
systemd-journald的优势在于与 systemd 的深度集成、结构化日志和高效的磁盘存储管理。它提供了诸如 Storage、RateLimit 等参数来控制日志的成长和吞吐，但对单独“按服务等级输出到文件”的粒度控制，需要结合如 rsyslog 或系统调用转发来实现。
实践要点是如果你的系统已经使用 systemd，优先考虑 journald 的容量与速率控制，再将必要的高等级告警转发到文件系统或外部日志中心，以实现统一治理。
如何调优rsyslog的日志等级
全局等级设置与常见规则
可以通过全局和条目级别的规则，指定默认输出等级以及对特定服务的例外。全局默认等级常见写法是将信息及以上等级输出到主日志，而对某些不重要的服务降低输出或禁用。以下示例展示了将 info 及以上日志写入 syslog，并为调试信息创建独立文件的思路。
要点：确保不要让调试信息占用过多存储，必要时将其单独落盘。
示例配置可结合实际需求进行微调，通常会包含对 mail、auth、cron 等默认排除，以及为某些组件开启调试输出的额外规则。
# rsyslog 配置示例
# 全局默认：日志等级为 info 及以上，排除部分不重要的设施
*.info;mail.none;authpriv.none;cron.none /var/log/syslog
# 认证日志单独输出
authpriv.* /var/log/auth.log
# 仅将调试信息输出到独立文件（用于排错）
*.=debug /var/log/debug.log
按服务/程序粒度的调参方法
对于特定服务或程序，可以为其设置独立的日志规则，以减少主日志的噪声，同时确保问题时能获取到充足信息。例如，针对 nginx、数据库等组件，可以单独指定日志等级和输出文件。
要点：使用程序名或单元名作为匹配条件，确保输出路径清晰、便于后续的日志轮转与存档。
# 使用 rsyslog 条件语句实现按服务日志
if $programname == 'nginx' then /var/log/nginx/error.log
& stop
基于输出目的地的分级策略
将高优先级告警输出到核心运维日志，而将调试信息保留在临时文件或单独的调试日志中，有助于快速定位问题又不过度消耗存储。你可以结合多个输出目标（文件、数据库、远端服务器）分别控制等级。
建议：对外部转发（如远端日志中心）的等级设定要比本地文件严格，以减少带宽与处理压力的影响。
按系统服务管理的日志等级调优（systemd-journald 视角）
journald 的基本配置与容量控制
systemd-journald 提供了对日志的集中化管理能力，Storage、SystemMaxUse、RuntimeMaxUse等参数决定了日志在磁盘上的存储策略。合理设置有助于控制磁盘占用，同时确保关键日志可追溯。
要点：开启 Storage=persistent，可以让日志在重启后仍然保留；设置合适的 SystemMaxUse/Runt imeMaxUse 防止单个服务日志占满磁盘。
一些组织还会为高优先级日志启用更高的保留优先级，确保在故障排查时近实时可用。
# systemd-journald.conf 示例
[Journal]
Storage=persistent
SystemMaxUse=2G
RuntimeMaxUse=1G
SystemMaxFileSize=200M
日志速率与抑制策略
为避免重复的无意义日志导致性能下降，可以在 journald.conf 使用 RateLimitIntervalSec 和 RateLimitBurst 等参数对重复条目进行抑制。这样既能控制吞吐，又不至于丢失关键告警。
要点：在高并发场景下，合理设置速率限制可以显著提升系统稳定性与可观测性。
# systemd-journald 限流示例
[Journal]
RateLimitIntervalSec=1
RateLimitBurst=1000
实战测试与验证方法
通过命令行测试日志输出与等级过滤
测试日志等级是否生效，最直接的办法是使用 logger 命令输出一个带等级的测试信息，然后再用查看工具验证输出范围。
要点：通过测试确认 dial-tone 是否如预期工作，以及不同等级是否能正确落地到目标文件或目标中心。
# 测试写入日志
logger -p local0.info "test message from shell"
# 查看最近的 journal 条目（若使用 journald）
journalctl -p info -n 50 --no-pager
针对服务单位的输出验证
如果你使用 systemd 服务，可以通过 journalctl -u 来查看特定单位的输出，并结合 -p 选项筛选等级，以验证进程内日志输出是否按配置等级落盘。
要点：确保对关键单位（如 nginx、postgres、redis）的日志等级设置正确，且与全局策略一致。
# 查看 nginx 单位的日志并按 info 及以上筛选
journalctl -u nginx -p info -f
结合应用层日志配置进行对比测试
除了系统日志框架的控制外，应用本身（如 nginx、MySQL、Redis、Java 应用）通常也有独立的日志级别设置。对比应用日志与系统日志的输出，可以帮助你验证等级控制的一致性，以及是否需要进一步的跨组件协同配置。
要点：在应用层配置中明确设定日志等级，并在系统层面保持相同的关注点，以避免信息不一致导致排错困难。
# nginx 日志等级（示例，通过应用配置控制）
error_log /var/log/nginx/error.log warn;
