为什么日志需要分类和分级
你在查一个线上问题，打开日志文件，满屏都是info、debug、error混在一起的信息，像极了你家衣柜里没整理的衣服——什么季节的都有，找一件T恤得翻半天。这就是没有做日志分类分级的典型场景。
系统运行过程中产生的日志量巨大，如果不加管理，关键时刻根本没法快速定位问题。通过合理的分类和分级，可以把日志从“噪音”变成“情报”。
日志分类：按业务或模块划分
分类是把不同来源的日志分开。比如电商系统里，订单、支付、用户登录应该各自有独立的日志类别。
你可以用日志中的tag字段或logger名称来区分：
logger.info("[ORDER] 创建订单成功", order_id=1001);
logger.warn("[PAYMENT] 支付超时", transaction_id=889);
logger.error("[LOGIN] 密码错误次数过多", user_id=2045);这样在排查问题时，直接过滤[ORDER]就能看到所有订单相关记录，效率提升明显。
日志分级：按严重程度打标签
分级是给日志信息“定级”，常见的级别有：DEBUG、INFO、WARN、ERROR、FATAL。它们像是天气预警信号，告诉你事情有多紧急。
DEBUG 用于开发调试，生产环境通常关闭；INFO 记录正常流程节点，比如“用户登录成功”；WARN 表示潜在风险，比如“磁盘使用率超过80%”；ERROR 是明确的故障，如“数据库连接失败”；FATAL 则是致命错误，可能导致服务中断。
配置日志框架时，可以按级别控制输出：
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<filter class="ch.qos.logback.classic.filter.LevelFilter">
<level>ERROR</level>
<onMatch>ACCEPT</onMatch>
<onMismatch>DENY</onMismatch>
</filter>
</appender>这样错误日志单独保存，方便监控系统实时抓取报警。
结合分类与分级的实际应用
一个API网关每天处理百万请求，如果所有日志都写进一个文件，运维人员等于在垃圾堆里找钥匙。合理做法是：
按接口类型分类，比如/auth、/order、/query 分别记录；同时保留级别控制。当发现某个接口响应变慢，先看对应分类的WARN和ERROR日志，几分钟内就能判断是下游超时还是参数异常。
再比如，在ELK（Elasticsearch + Logstash + Kibana）体系中，可以通过field将category和level传入，配置不同的索引策略和告警规则。高优先级错误即时推送企业微信，低级别日志定期归档。
避免常见误区
有人把所有异常都打成ERROR，结果告警邮件刷屏，真出事时反而没人点开看。这就像天天拉防空警报，大家习惯了就麻木了。
还有人不分类，所有模块共用一个logger，一旦出问题就得全文搜索关键词，效率极低。正确的做法是每个核心模块拥有独立命名空间，配合结构化日志输出（JSON格式），便于机器解析。
日志不是越多越好，而是越有用越好。分类分级的本质，是把信息按需组织，让不同角色各取所需——开发关注DEBUG，运维紧盯ERROR，产品可能只看INFO里的行为统计。