LOG_SYS 系统日志表

记录用户操作、资源访问、后台处理及异常等事件，用于审计、业务过程查询和问题追踪。每条日志表示一个事件；同一调用链可以产生多条日志，通过 TRACE_ID 关联。

位置

模型路径：/sysdata/data/tables/sys/LOG_SYS.tbl

物理表名：SZSYS_5_LOG_SYS

通过数据模型查询时使用模型路径，通过数据库连接执行SQL时使用物理表名。以下字段说明用于读取和分析日志数据。

表结构

字段名	字段类型	用途与取值
LOG_ID	VARCHAR(36)	单条日志的唯一标识，主键。按此字段可以定位一条完整记录。
EVENT_NAME	VARCHAR(128)	事件编码，例如 sample.submit。用于筛选同一种业务事件，可关联事件目录取得显示名称。具体编码由系统功能或业务应用定义。
USER_ID	VARCHAR(64)	执行用户的ID，可关联用户信息查询执行人。没有用户身份的事件可为空。
SESSION_ID	VARCHAR(128)	登录会话标识，用于查询同一登录会话的事件与程序日志，与 HTTP_SESSIONS.SESSION_ID 是同一个值，可直接等值关联；无登录会话的事件为空。
TRIGGER_TYPE	VARCHAR(16)	事件发起来源，单值：USER、CLI、MCP、API、SCHEDULE、SYSTEM、UNKNOWN。未记录时为空，详细取值见下文。
PROJECT_NAME	VARCHAR(128)	事件发生时主业务对象或资源所属项目的项目名。用于按项目筛选；无项目归属时可为空。项目重命名前后的日志可能记录不同名称。
CLIENT_IP	VARCHAR(128)	来源客户端地址，通常为单个IPv4或IPv6地址文本。用于按访问来源排查；没有网络请求的事件可为空。
RES_PATH	VARCHAR(1024)	事件发生时所在资源的完整路径，例如 /LAB/app/sample/submit.afl，路径包含项目名。没有关联资源时可为空。
RES_TYPE	VARCHAR(32)	事件所在资源的类型，例如 afl（程序流）、spg（页面）、dash（仪表盘）、rpt（报表）。用于按资源类型筛选，具体类型随资源种类而定。
OBJECT_TYPE	VARCHAR(128)	操作针对的主业务对象类型码，例如 sample（样本）、expense（报销单）。类型码由业务应用定义，未记录时为空。
OBJECT_ID	VARCHAR(256)	主业务对象标识，例如 SP001。查询一个对象的日志时，应结合 PROJECT_NAME 和 OBJECT_TYPE，避免不同项目或对象类型中相同ID混淆。多对象操作的其他对象信息可在详情中查看。
TRACE_ID	VARCHAR(32)	调用链标识，32位小写十六进制字符串，不能全为0。同一调用链中的事件和程序日志使用相同值；不唯一。历史日志未记录时为空。
UPDATE_TYPE	VARCHAR(16)	数据操作类型，单值：INSERT、UPDATE、DELETE、CREATE、ALTER、DROP、TRUNCATE、READ、COMPOSITE、OTHER、UNKNOWN。既表示业务数据操作，也表示表或模型等结构操作。
OPERATION_STATE	VARCHAR(16)	操作结果，单值：OK（成功）、FAIL（业务失败）、EXCPT（异常）、ERROR（严重错误）。具体错误原因在 DETAIL_INFO 中查看。
LOG_LEVEL	NUMBER(1)	日志严重程度：0 OFF、1 FATAL、2 ERROR、3 WARN、4 IMPT、5 INFO、6 DEBUG、7 TRACE。详细说明见下文。
CLUSTER_NODE	VARCHAR(32)	记录日志的集群节点标识，用于定位处理该事件的服务器节点。
START_TIME	TIMESTAMP	事件或动作开始时间，用于时间范围筛选和排序。
END_TIME	TIMESTAMP	事件或动作结束时间。可结合开始时间计算耗时；此字段不是日志入库时间。
DETAIL_INFO	CLOB	JSON格式的日志详情，包括业务说明、具体错误码、异常消息、堆栈和其他上下文。内容随事件而异，可为空。

LOG_ID 标识一条日志，TRACE_ID 关联一条调用链，SESSION_ID 关联一次登录会话，三者的查询范围不同。对象标识按字符串使用，例如 00123 与 123 不应自行合并。

历史记录或未采集相关信息的事件可能存在空字段。空值表示没有该项信息，不能据此判断“系统发起”“操作成功”或“没有数据变化”。

发起来源 TRIGGER_TYPE

值	含义	示例
USER	产品界面中的用户操作	用户点击按钮提交表单，随后执行程序流或脚本。
CLI	通过SuccApp CLI发起	手动运行CLI命令，或CI、自动化脚本直接调用CLI。
MCP	通过MCP工具调用发起	AI客户端调用MCP工具执行产品操作。
SCHEDULE	定时调度发起	定时运行数据加工或程序流。
API	其他外部接口调用	外部应用直接调用接口提交数据，不属于已识别的CLI或MCP来源。
SYSTEM	系统内部主动发起	系统内部维护任务。
UNKNOWN	来源无法确定	事件来源不能明确分类。

该字段表示最初发起来源，USER_ID 表示执行身份。使用用户凭证的CLI或MCP调用仍分别属于 CLI 或 MCP，不会因此归为 USER。

来源沿同一次调用传递：MCP工具内部调用CLI，再由CLI请求接口时，记录为 MCP；直接运行CLI则记录为 CLI。用户界面或产品调度器触发的操作即使经过脚本或接口执行，仍分别记录为 USER 或 SCHEDULE。CI直接调用CLI属于 CLI，不因CI具有定时能力而归为产品内部的 SCHEDULE。

来源以系统识别并传递的调用上下文为准，不能仅根据HTTP协议、用户名或任意客户端自报标签判断。NULL 表示未记录；查询未知来源时可同时包含 UNKNOWN 和空值。

数据操作类型 UPDATE_TYPE

值	含义	示例
INSERT	新增业务数据	新建报销单、新增样本记录。
UPDATE	修改业务数据	修改金额、更新审批状态。
DELETE	删除业务数据	删除样本，包括业务上的逻辑删除。
CREATE	创建表、模型等结构性对象	创建数据表；新增一条业务记录则属于 INSERT。
ALTER	修改结构或定义	增加表字段、修改模型定义、重命名表。
DROP	删除表、模型等结构性对象	删除数据表。
TRUNCATE	整体清空数据并保留结构	清空表数据。
READ	读取数据	查询业务数据。
COMPOSITE	无单一主操作的复合操作	一次处理同时新增和修改业务数据。
OTHER	已知但不属于上述类别的操作	未归入具体业务类型的授权或过程调用。
UNKNOWN	操作类型无法确定	记录中缺少足够信息判断操作类型。

每条日志只保存一个类型，可用等值条件或 IN 筛选。该字段描述业务操作，不要求与底层SQL关键字相同。例如逻辑删除可能通过SQL UPDATE 完成，业务日志仍记录为 DELETE。

操作类型与结果需要结合查看：UPDATE_TYPE = 'UPDATE' 表示修改操作，是否成功由 OPERATION_STATE 判断。修改失败或回滚的事件也可能标记为 UPDATE；不能仅凭操作类型统计实际变更行数。

操作状态 OPERATION_STATE

值	含义	示例
OK	成功	登录成功、业务操作成功。
FAIL	业务失败	用户凭证不正确、业务条件不满足。
EXCPT	执行异常	操作过程中发生异常，例如访问的表不存在。
ERROR	严重错误	对服务器运行产生影响的严重错误。

直接查询数据库时使用上述字符串。事件API中的数字状态 0/1/2/3 分别对应 OK/FAIL/EXCPT/ERROR，不应用数字条件查询本列。

取消、超时等情况可能记录为失败或异常，具体原因需查看详情。空值及无法识别的历史状态应单独处理，不能计入成功。详情中存在异常信息也不一定代表最终失败，应以本字段记录的结果为准。

日志级别 LOG_LEVEL

值	名称	含义
0	OFF	关闭日志的配置值，不作为常规业务日志级别。
1	FATAL	致命级别。
2	ERROR	错误级别。
3	WARN	警告级别。
4	IMPT	重要信息。
5	INFO	一般信息。
6	DEBUG	调试信息。
7	TRACE	跟踪信息。

数值越小，级别越高，OFF 除外。例如筛选警告及以上日志使用 LOG_LEVEL BETWEEN 1 AND 3。日志级别与操作状态分别表示严重程度和执行结果；查询失败操作应使用 OPERATION_STATE，不能仅筛选错误级别。

发生位置与操作对象

例如用户在程序流中修改样本，一条日志可以包含：

EVENT_NAME      = sample.update
TRIGGER_TYPE    = USER
PROJECT_NAME    = LAB
RES_PATH        = /LAB/app/sample/submit.afl
RES_TYPE        = afl
OBJECT_TYPE     = sample
OBJECT_ID       = SP001
UPDATE_TYPE     = UPDATE
OPERATION_STATE = OK

RES_PATH/RES_TYPE 说明事件发生在哪个资源中，OBJECT_TYPE/OBJECT_ID 说明操作针对哪个对象。同一资源可以处理多个对象，一个对象也可能经过不同资源。

日志详情 DETAIL_INFO

详情是JSON文本，各事件的属性可能不同。常见属性包括 logs（日志说明）、message（消息）、exception（异常堆栈）、className（异常类名），也可能包含业务自定义的错误码、对象摘要、登录方式等。

下面是业务事件详情示例，其中 errorCode 是示例应用提供的属性，并非每条日志都有：

{
  "logs": ["修改样本失败"],
  "errorCode": "sample.invalidStatus",
  "message": "当前状态不允许修改"
}

按需读取详情，并在解析时处理空值、缺失属性及无法解析的历史内容。不同数据库对CLOB和JSON的查询函数不同；需要提取JSON属性时，使用所连接数据库支持的函数，或在应用中读取并解析。

登录会话与程序日志关联

通过登录会话、业务调用和事件三个层次，可以从用户操作记录定位对应的程序日志：

登录会话（SESSION_ID = S1）
  ├─ 业务调用 A：TRACE_ID = A
  │    ├─ 事件日志 L1：SESSION_ID = S1，TRACE_ID = A
  │    ├─ 事件日志 L2：SESSION_ID = S1，TRACE_ID = A
  │    └─ 程序日志：session_id = S1，trace_id = A
  └─ 业务调用 B：TRACE_ID = B
       ├─ 事件日志 L3：SESSION_ID = S1，TRACE_ID = B
       └─ 程序日志：session_id = S1，trace_id = B

查询范围	日志表字段	程序日志中的关联项	用法
同一登录会话	SESSION_ID	session_id	从会话标识查找该会话中的操作及程序日志。一个会话可能包含多次并发调用。
同一调用链	TRACE_ID	trace_id	从一条事件记录定位该调用的其他事件及程序日志。
单条事件记录	LOG_ID	不要求每行程序日志包含此值	查询事件详情。同一调用链可以产生多条事件，不能将Trace ID当作日志主键。

图中的S1、A、B为便于阅读的简写；会话标识与Trace ID都应作为不透明字符串使用，Trace ID为32位小写十六进制字符串。会话标识可从 HTTP_SESSIONS.SESSION_ID 或已有事件记录中取得，两个表的 SESSION_ID 是同一个值，可直接等值关联。

找到需要排查的事件后，使用其 TRACE_ID 搜索程序日志中的 trace_id，或使用 SESSION_ID 搜索 session_id。结合节点和时间范围选择日志文件；调用跨节点时，需要查询相关节点的日志。

下面是包含关联项的程序日志格式示例：

2026-09-10 10:30:00.123 INFO  [127.0.0.1,S1,A] [worker-1] c.s.Foo - ...

实际可搜索的关联项以所用版本及日志输出配置为准。只有程序日志输出了相同标识，才能按标识关联；日志级别过滤或文件过期清理也可能导致找不到对应内容。这些标识用于定位已有日志，不表示每条事件一定对应一行程序日志。

系统任务和未登录请求可能没有登录会话，仍可通过 TRACE_ID 关联。会话失效或清理后，日志中已记录的会话标识仍可用于检索日志，但当前会话信息可能已无法查询。不同登录会话不会仅因属于同一用户而自动合并；查询用户跨会话操作时使用 USER_ID。

TRACE_ID 与W3C Trace Context中的Trace ID对应。HTTP服务之间通过标准 traceparent 传播调用上下文。一次登录会话可以包含多个Trace；无会话的调度任务也可有Trace。跨时间、跨多次独立操作的业务过程通过对象标识查询，不要求共用一个Trace。

会话关联使用 LoginUtils.hash(HttpSession.getId()) 生成的存储键，与 HTTP_SESSIONS.SESSION_ID 同值。HttpSession.getId() 本身是客户端凭据，不能直接记录；日志中的存储键不能作为 Cookie 或令牌使用。

程序日志中的会话标识与事件表的对应关系：数据库使用 SESSION_ID，日志JSON属性使用 sessionId，Logback输出 session_id。映射到OpenTelemetry属性时使用 session.id。该会话属性不属于W3C traceparent，不会随该头传给外部服务。

会话轮换（重新登录等）后会话标识变化，历史日志中的原标识仍可用于检索原日志。跨会话查询用户活动时使用 USER_ID 和时间范围。

历史字段与空值

升级前产生的记录可能没有发起来源、项目、对象或调用关联信息，按这些字段筛选时可能不包含相关历史记录。需要查询更早的数据时，可结合时间、事件编码、用户和资源路径。

部分升级数据库中还保留以下历史列。这些列不属于通用字段集合，编写跨环境查询前应检查实际表结构；新查询优先使用上文中的字段。

历史字段	类型	历史用途与读取说明
LOGIN_SESSION	VARCHAR(64)	历史原始登录会话ID，格式与 SESSION_ID 不同，不能直接相等关联。未记录 SESSION_ID 的历史记录不会命中 SESSION_ID 筛选。
OPTION1	VARCHAR(128)	不同事件可能记录IP、项目名、应用ID或其他业务标识。必须结合事件编码解释，不能将整列统一理解为对象ID。
OPTION2	VARCHAR(128)	不同事件可能记录业务错误码、登录方式、消息类型等，具体含义由对应事件决定。
OPTION3	VARCHAR(128)	部分事件记录SSO标识、消息内容类型等扩展信息。
SQL_MODE	VARCHAR(250)	事件登记的SQL类型摘要，例如 SELECT、CREATE,INSERT。可能含多个逗号分隔值，仅反映登记的SQL种类，不证明执行成功。
CONSISTENCY_INFO	VARCHAR(256)	历史扩展写入的完整性校验信息；仅有字段值不能证明日志完整性，其含义取决于原扩展。

直接执行SQL不会自动将 OPTION1 转成 CLIENT_IP，也不会自动将 SQL_MODE 转成 UPDATE_TYPE。只有确认事件含义和历史取值后，才能在查询中编写对应转换；不能对所有事件统一使用 COALESCE(CLIENT_IP, OPTION1)。历史列保留不表示所有新日志仍填写这些列。

表索引与查询建议

类型	名称	字段列表	是否唯一
主键	PRIMARY	LOG_ID	是
索引	IDX4_LOG_SYS_EVENT_NAME	EVENT_NAME	否
索引	IDX4_LOG_SYS_USER_ID	USER_ID	否
索引	IDX4_LOG_SYS_TIME	START_TIME, END_TIME	否
索引	IDX4_LOG_SYS_LOG_LEVEL	LOG_LEVEL	否

数据库中的实际索引可能随版本和部署配置不同。TRACE_ID 不是唯一字段，不能将其当作主键。组合索引是否适用于某个查询取决于过滤条件和数据库执行计划，不能仅根据字段出现在索引中就判断一定会使用索引。

查询大量日志时，优先限定时间范围，再增加项目、事件、用户等条件。读取用户或事件名称时使用可保留日志记录的关联方式，例如左连接，避免关联对象已删除导致历史日志被过滤。数据库直连查询使用数据库账号权限，不会自动应用产品页面中的项目访问权限。