第1章风控日志体系概述

一、风控日志体系概述：日志的价值、日志分类与级别定义

大家好，我是老赵。做风控系统这些年，我见过太多团队在排查问题时抓耳挠腮——日志打了一堆，关键时刻却找不到关键信息。说白了，日志就是系统的「黑匣子」，平时不起眼，一出事它就是救命稻草。

今天咱们就聊聊风控日志体系的基础。别小看这部分，我见过不少资深工程师，日志级别都定义不清楚，结果线上出问题，翻半天日志全是 DEBUG 信息，真正有用的 ERROR 反而被淹没了。嗯，咱们从根上捋一遍。

日志的价值，我总结为三个层面：

问题定位：系统出故障了，日志是第一现场。我记得有一次线上风控引擎突然超时，查了半小时代码没头绪，最后翻日志发现是外部数据源接口响应变慢了。没有日志，你连问题在哪都不知道。
行为审计：风控系统涉及资金、用户隐私，每一步操作都得有据可查。我曾经帮一个客户复盘数据泄露事件，就是靠操作日志锁定了内部人员的异常查询行为。
性能分析：日志里的时间戳、耗时数据，能帮你发现系统的瓶颈。比如某个规则执行时间突然变长，日志里一对比就出来了。

核心观点：日志不是写给机器看的，是写给人看的。尤其是风控系统，每一行日志都可能成为后续追责或优化的关键证据。

风控日志我习惯分成三类。为什么这么分？因为排查问题时，你关注的点完全不同。

这类日志记录的是「业务发生了什么」。比如用户提交了订单、触发了哪条风控规则、最终决策是放行还是拦截。说白了，这是风控系统的「业务流水账」。

我在项目中遇到过最典型的场景：用户投诉说「我正常下单为什么被拦截了？」。这时候你翻业务日志，就能看到具体是哪条规则命中、命中时的上下文是什么。没有业务日志，你只能对着代码猜。

业务日志的关键字段通常包括：

系统日志关注的是「系统运行得怎么样」。比如内存使用率、接口响应时间、数据库连接池状态、线程池排队情况等。这类日志是运维和架构师最关心的。

你想想看，风控引擎突然变慢了，业务日志可能看不出问题，但系统日志会告诉你：哦，原来是数据库连接池满了，或者某个外部接口超时了。我曾经有一次排查线上故障，就是靠系统日志发现 Redis 集群的一个节点挂了，导致缓存穿透。

安全日志记录的是「谁在什么时候做了什么操作」。包括登录日志、权限变更日志、敏感数据访问日志等。这类日志在风控系统中尤其重要，因为风控系统本身也是攻击目标。

我记得有个案例：攻击者通过 SQL 注入试图篡改风控规则。安全日志记录了异常 SQL 语句和执行时间，我们第一时间定位并封堵了漏洞。没有安全日志，这种攻击可能持续很久才发现。

个人建议：三类日志最好分开存储。业务日志存 Elasticsearch，系统日志存时序数据库（比如 Prometheus + Grafana），安全日志存专门的审计系统。混在一起，查询效率会大打折扣。

日志级别这事儿，看起来简单，但实际项目中乱象丛生。我见过有人把所有信息都打 INFO，也见过有人把业务异常打 WARN 而不是 ERROR。嗯，这里我给出一个风控场景下的推荐定义。

级别	含义	风控场景示例	我的建议
DEBUG	调试信息，开发阶段使用	规则引擎内部变量值、中间计算结果	生产环境关闭，除非临时排查问题
INFO	正常业务流程的关键节点	用户请求到达、规则命中、决策结果	业务日志的主力级别，别滥用
WARN	预期内的异常或降级	外部接口超时后降级、数据源切换	需要关注但不紧急，别打太多
ERROR	系统功能受损或数据异常	数据库连接失败、规则执行抛出异常	必须立即处理，配合告警
FATAL	系统不可用，需要人工介入	风控引擎核心模块崩溃、配置中心不可用	极少使用，一旦出现就是 P0 故障

避坑指南：我曾经在一个项目里看到，有人把「用户命中黑名单」这种业务逻辑打成了 ERROR 级别。结果告警系统天天报警，运维都麻木了，真正出问题时反而没人关注。记住：ERROR 只用于系统异常，不是业务异常。

下面这张图是我自己梳理的风控日志体系结构，你可以把它当作后续学习的导航图。

这张图把日志分类和级别串在了一起。你从中心出发，左边是业务日志，中间是系统日志，右边是安全日志。底部是日志级别，从 DEBUG 到 FATAL，越往右越严重。我个人习惯把这张图贴在工位上，每次打日志前看一眼，避免打错级别。

一个小技巧：日志级别不是死的。比如线上排查问题时，可以临时把某个模块的日志级别降到 DEBUG，问题解决后立刻改回来。我一般用配置中心动态调整，不用重启服务。

好了，这一章就聊到这儿。日志体系是风控系统的地基，地基打不牢，后面排查问题会非常痛苦。下一章咱们会深入业务日志的实战分析，包括怎么设计日志字段、怎么用 ELK 做可视化。到时候见。