做 SAP 运维这些年被问得最多的问题之一就是“帮我查一下某某用户昨天登录了系统没有他到底跑了哪些事务码”每次接到这类需求我第一反应就是打开 SM19 和 SM20 这对组合。很多顾问平时不太碰这两个事务码觉得它们属于安全审计的领域等真正出了权限纠纷、合规检查、接口报错才想起来要查日志结果又不知道从哪里下手。这篇文章就把用户对话、登录、接口、事务码、程序这几类日志怎么配置、怎么查询、怎么读懂结果完整梳理一遍适合 SAP 运维、安全审计顾问和刚接触 ABAP 开发的人直接参考。1. 什么情况下你会用到 SM19 和 SM201.1 最常见的三类查日志需求先别急着上手操作搞清楚“什么时候需要这两个事务码”比会点按钮更重要。我实际工作中碰到的需求基本可以归成三类每类的思路和侧重点都不一样。第一类是账号安全与登录异常。典型场景是某用户说自己在凌晨没有登录过系统但系统里有操作记录或者一个账号在短时间内连续登录失败疑似有人在试密码。这种问题要查的是“对话登录”和“RFC 登录”事件重点看登录时间、登录成败、来源终端。只要 SM19 里开启了登录审计SM20 一过滤就能拉出完整的登录时间线比翻数据库表快得多。第二类是权限审计与合规检查。年底内部审计或者外部合规检查时领导要求提供“某段时间内谁执行了敏感事务码、谁跑过大批量程序”的操作清单。这类需求必须按“事务码”和“ABAP 程序”两个审计对象去配置配合用户名过滤基本能还原出操作轨迹。审计日志里会记录每次执行的用户名、客户端、时间戳这些就是合规报告里最有力的证据。第三类是接口与程序异常追踪。外围系统通过 RFC 调用 SAP 功能某天接口报错业务部门把问题抛过来说“肯定是 SAP 这边的问题”。这时候需要查 RFC 登录和 RFC 调用审计事件结合外围系统日志的时间戳判断是 SAP 拒绝了登录还是调用本身出了故障。ABAP 程序被后台 Job 调度执行后结果异常也能通过审计日志找到执行记录和结果代码。1.2 为什么安全审计日志选 SM19/SM20而不是 SM21 或 STAD有同事一听“查日志”就直奔 SM21这其实是个误区。SM21 看的是系统日志System Log记录的是程序崩溃、更新模块错误、锁冲突、数据库连接异常这类“系统内部状态”。它回答不了“某用户在几点几分登录、点击了哪个事务码”这种用户行为问题。SM19 和 SM20 是安全审计日志Security Audit Log的配置与查询入口专门记录用户层面的操作行为。这两个事务码的分工我后面会细讲先拿一张表把三者的区别说清楚对比维度SM19/SM20 安全审计日志SM21 系统日志主要记录内容用户操作登录、事务码、程序、RFC 调用系统事件错误、警告、更新、锁等待主要用途安全审计、权限追溯、合规报告系统故障排查、错误定位数据入口SM19 配置、SM20 查询SM21 查询数据保留方式按审计策略写入审计日志文件可归档内存循环覆盖系统重启后旧日志易丢失适用对象用户、事务码、ABAP 程序、RFC 调用系统组件、后台任务、数据库连接至于 STAD它更多是工作负载与性能统计的场景告诉你某个事务码跑了多少次、平均执行时间是多少但拿它当审计证据是不够的。统计记录不会保留完整的“谁在哪个客户端做了什么”的审计上下文外审人员通常只认安全审计日志。所以一旦涉及用户行为和权限合规SM19/SM20 才是正解。2. 安全审计日志的底层链路日志到底从哪里来2.1 审计日志不是默认全开的很多人以为 SAP 系统会默认记录所有用户操作这是个危险的误解。安全审计默认处于“关闭”或“最低级别”状态必须先通过 SM19 告诉系统“要记什么”用户操作才会被写进审计日志。打个比方这就像给机房装了监控摄像头但摄像头默认没有开录像功能。你必须在 SM19 里设置好“哪几个画面要录、录成功率还是失败率”系统才开始工作。等真出了事才想起来要开监控那前面前段时间的录像必然是空白。审计事件触发后系统会把一条审计消息写入本地审计日志文件。日志文件按天滚动同时受最大文件大小限制。SM20 的作用就是去读这些文件按条件筛选展示。所以整个链路可以概括成SM19 配置过滤条件 → 用户操作发生 → 审计消息写入日志文件 → SM20 读取并展示。2.2 SM19 管“记什么”SM20 管“怎么看”这是新手最容易绕晕的地方其实一句话就能记住SM19 是写配置的SM20 是看结果的。SM19 里定义的是审计对象、审计级别、过滤条件SM20 里做的是查询、解读和导出。配置没做好SM20 自然查不到数据这不是查询方式不对而是源头没开。SM19 中有多个审计对象Audit Class每种对象负责记录一类事件。常用对象包括对话登录Dialogue Logon、RFC 登录RFC Logon、事务码调用Transaction、ABAP 程序执行Report、RFC 调用RF Call另外还有面向用户User和文件File相关的参数对象。每个对象都有独立的审计级别开关你可以只开自己关心的那几类。2.3 日志文件写到哪里为什么有时换日期就查不到审计日志文件存放在 SAP 应用服务器本地文件系统的审计目录下不是默认直接写进业务数据库表里。文件名通常包含日期信息按天生成配置了最大文件大小时还会继续滚动生成新卷。这也是为什么有时在 SM20 里把查询日期往前调却发现查不到内容。SM20 默认读的是当前活动卷更早的历史日志可能需要手动切换“卷”Volume才能看到。卷的切换入口在 SM20 界面的顶部区域会列出当前系统可读取的日志文件卷点选对应日期或卷名后再执行查询老数据才会出现。3. 一步一步配置 SM19日志能不能查到八成都在这3.1 进入 SM19 前要先想清楚的事打开 SM19 之前先列一个“审计对象清单”。不要一上来就把所有对象全开成“全部审计”生产系统全量审计会明显增加应用服务器的 I/O 和 CPU 开销直接影响前台对话响应速度。实操中建议按下面的优先级来开对话登录追踪用户的登录成功与失败几乎必开RFC 登录追踪外围系统、后台接口的登录涉及接口必开事务码调用记录敏感事务码的执行权限审计必备ABAP 程序执行记录直接执行的报表和程序排查数据异常走这条RFC 调用记录接口调用细节接口故障定位靠它审计级别怎么选取决于目的。查账号是否被盗用登录成功和失败都要看查接口为什么连不上重点看 RFC 登录的失败记录做敏感事务码审计则要记录“成功”执行的结果因为失败的调用通常不是关注重点。3.2 主审计级别与过滤条件的设置细节SM19 界面左侧是审计对象树右侧是选中对象的当前参数。顶部工具栏有一个“主审计级别”Master Audit Level按钮点开后是四档选项无审计No Audit什么都不记仅审计失败Only Failures只记录失败操作适合兜底仅审计成功Only Successes只记录成功操作适合敏感操作追踪全部审计All Categories成功失败都记录数据量最大主审计级别是所有对象的默认底色。实际操作时我建议先把主审计级别设成“仅审计失败”保证异常操作至少能留痕然后再对敏感对象单独拉高级别。比如把对话登录、RFC 登录设成“全部审计”因为登录行为本身频率不高全量记录性能影响有限但不要把事务码对象全局设为“全部审计”否则系统里所有事务操作都被记录日志量会非常吓人。在具体对象上还可以设置过滤值。比如“Transaction”对象中填入敏感事务码清单系统就只审计这几个事务码“User”对象中填入指定用户名就只审计该用户的操作。过滤条件设置得越精准审计文件里的有效信息密度越高后续排查的效率也越高。3.3 保存、激活与验证三步缺一不可配置完成后先保存再点“激活”按钮。很多人在这里翻车以为保存就生效了结果第二天查不到任何日志。SM19 的配置必须激活后新的审计设置才真正注入到运行系统里。激活之后还要做一次验证换一个测试用户登录系统执行一个事务码或程序然后到 SM20 里查刚才那一段时间的记录确认审计消息确实产生了。建议在测试环境先整个流程走一遍再上生产机改配置。生产机上首次开启审计尽量选业务低峰期避免大量审计事件集中写入造成性能抖动。4. 在 SM20 里把日志捞出来查询条件与结果解读4.1 查询条件的组合技巧SM20 的初始查询界面里主要字段包括日期范围、用户名、客户端、审计类Audit Class。默认日期范围是“昨天到今天”实际排查时最好手动放宽因为日志按天滚动跨天场景很容易漏数据。我常用的组合思路查登录问题日期范围选准用户名可留空审计类选“对话登录”或“RFC 登录”查具体用户的全量行为用户名填进去日期放宽审计类留空先把该用户所有审计事件拉出来查某个事务码谁在用审计类选“事务码”用户名留空配合事务码过滤值输出全局使用清单查接口调用审计类选“RFC 调用”或“RFC 登录”再配合客户端和 RFC 目标字段收窄范围一个原则第一次查询宁宽勿窄。先把类型和时间段确定用户名、客户端这类字段能不加就不加等看到全貌后再逐步追加条件过滤。上来就加一堆条件容易漏掉关键线索。4.2 结果列表的关键字段怎么读SM20 执行后返回的结果列表每一行就是一条审计事件。不同版本字段名称略有差异但核心字段基本一致字段含义读法日期时间事件发生的精确时间用来串联操作时间线用户名操作者账号定位问题对象客户端登录的 SAP 客户端号区分前端对话与后台作业审计类事件类型登录、事务码、程序等先确认类型是否对口事件 ID具体审计事件的编号用于深挖明细对象 / 对象 ID事务码代码、程序名等知道具体做了什么结果代码成功或失败标识判断操作结果附加信息RFC 目标、终端、逻辑端口等接口场景重点看这里读列表时建议按三步走先看“结果代码”区分成功和失败再看“对象 ID”对应到具体事务码或程序名最后按日期时间排序把同一用户的多条事件串成时间线。串时间线是最有价值的动作能直观还原“用户从登录到执行操作再到退出”的完整路径。4.3 把审计日志导出到本地文件审计报告通常要交付给安全团队或外部审计SM20 支持把查询结果导出。在结果列表的菜单里找到“保存/下载”功能可以存成文本或表格格式再转成 Excel 加工成报告。导出时有几个细节要注意。第一大结果集导出会卡住对话建议先加筛选条件再导出不要一次性导几十万行。第二导出文件应保留原始审计事件的时间戳、用户名、结果代码等内容不要手工合并或删减否则审计证据的效力会打折扣。第三文件名建议包含查询日期范围和系统编号方便后续追溯。5. 实战视角登录、事务码、程序、接口日志分别怎么查5.1 用户登录与对话日志的追踪最常见的场景是用户登录追踪。在 SM20 里把审计类锁定为“对话登录”选好日期范围用户名可以填也可以留空。查询结果会区分成功和失败的登录事件成功登录一般会记录客户端和终端信息失败登录同样有时间戳和用户名。如果怀疑账号被暴力破解可以按时间升序排列所有失败登录事件看多次失败尝试的间隔是不是接近。这里有个技巧不要只看用户名还要看客户端。同一个人在同一客户端连续失败是记错密码从不同客户端轮流尝试大概率是扫描攻击。这类细节在实际排查中能帮你少走很多弯路。5.2 事务码与 ABAP 程序的执行追踪事务码审计回答的是“谁在什么时候执行了什么敏感操作”。先在 SM19 里把“事务码”对象打开审计级别设为“全部审计”过滤值里填上 SE16、SE01、SU01 这类敏感或数据访问型事务码。然后在 SM20 里按审计类“事务码”筛选输出字段中会包含用户名、时间、客户端和事务码代码。ABAP 程序执行追踪与事务码类似走“Report / ABAP 程序”审计对象。要注意的是直接通过 SE38 执行程序和通过后台 Job 调度程序审计记录的上下文不完全一样。如果查 SE38 直接执行时发现数据缺失检查一下该对象是否单独开启以及主审计级别是否被过滤条件限制了。5.3 接口RFC调用日志的追踪方法接口日志要分两个维度看RFC 登录和 RFC 调用。RFC 登录关心的是“外围系统有没有成功接入 SAP”RFC 调用关心的是“某个功能模块被哪个来源调用了”。查到一条 RFC 审计事件时重点看附加信息里的 RFC 目标、逻辑端口、来源客户端这几个字段能帮你定位到具体的集成对象。有一次我排查财务接口报错外围系统说“SAP 拒绝登录”本地网络测试都是通的。最后在 SM20 里查到那段时间的 RFC 登录失败事件附加信息里明确指向了一个过期的连接用户问题五分钟就定位了。没有审计日志这种接口问题就只能靠两边反复对时间、对报错非常低效。6. 运行维护里容易踩的坑以及我自己的习惯做法6.1 配置了却查不到数据的五类原因整理了这些年遇到过的“SM20 查不到日志”的真实原因其中最典型的是下面五类配置没有激活SM19 改完只保存了没有任何作用过滤条件设置过严比如在 User 对象里填了一个永不匹配的表达式系统以为你不需要记录查询卷不对SM20 默认读当前活动卷跨日期数据要被忽略日期范围太窄查询区间正好落在日志滚动的间隙里审计对象选错事件实际属于“RFC 登录”却按“对话登录”去查碰到“查不到”先别急着怀疑系统有问题回去看 SM19 该对象是否开启、级别是否合适。SM19 端没有采集SM20 端再精心组合条件也是白搭。6.2 审计日志与系统日志对不上的排查思路有时 SM21 里能看到接口报错SM20 里却找不到对应审计事件这不一定是谁出了问题。系统日志记录的是系统层面的事实安全审计日志记录的是用户层面触发的事实。接口报错发生在 SAP 侧数据库连接异常SM21 有记录但该异常是由外围系统发起没有成功建立会话SM20 的 RFC 登录审计可能就看不到对应事件。排查时不要执着于“两边必须完全吻合”。正确姿势是先用 SM21 定位系统异常时间段再用 SM20 定位该时间段内用户行为把两条线放在同一时间轴上对齐。很多时候故障要还原成完整故事才能确定根因单独看任何一边都可能被误导。6.3 日志保留策略与磁盘空间管理审计日志文件会持续增长尤其是开了“全部审计”的系统单日文件几百 MB 很常见。如果不规划保留策略审计目录被写满之后新的日志可能写不进去这比“没开审计”还危险——你会在最需要日志的时候发现日志停在昨天。我个人的习惯是每月用 SM20 把重要审计事件导出归档一次检查服务器审计目录的空间占用确认日志文件按预期在产生。归档之后可以清理已归档的旧日志文件但保留周期定多长要结合行业要求不能随手删。金融、制造这些行业对审计数据留存时间通常有明确要求删错了就是合规事故。最后再分享一个我自己的默认配置习惯平时把主审计级别设为“仅审计失败”作为全系统兜底再把登录、RFC 接入、敏感事务码这几个对象单独拉高到“全部审计”。这样既不把生产系统拖垮又能保证关键时刻拿得出完整证据。每季度随手用 SM20 抽查一次确认审计链路还在正常工作远比出事之后追悔莫及要省心。