日志管理
摘要
本发明涉及应用系统日志管理技术领域，提供了一种日志管理方法和系统，所述方法包括如下步骤：S1：初始化系统业务功能列表和业务功能方法列表；S2：将业务操作中的具体操作信息与系统日志表和历史数据日志表直接相关联；S4：根据业务操作自动记录日志信息。本发明从整体考虑整个应用系统的日志信息与业务操作挂接，用户在运行时可以根据当前的需要，选择某业务操作是否需要记录日志，并且在业务操作界面能即时将相关的日志信息调出来，不需要再跑到专门的日志查询界面，大大简化了用户的操作。
技术领域
[0001] 本发明涉及应用系统日志管理技术领域，特别涉及一种系统日志与业务操作的无 缝挂接日志管理方法及系统。
背景技术
[0002] 要保护和提高计算机用户的网络安全，由各种操作系统、应用程序、设备和安全产 品的日志数据能够帮助用户提前发现和避开灾难，并且找到安全事件的根本原因。目前，基 本上每个应用系统都有自己的日志信息，日志数据对于实现网络安全的价值有多大取决于 两个因素：第一，用户的系统和设备必须进行合适的设置以便记录你需要的数据。第二，用 户必须有合适的工具、培训和可用的资源来分析收集到的数据。
[0003] 在能够分析日志数据之前，显然要收集数据。更重要的是，记录数据的程序或者设 备要设置为收集需要的数据。一旦收集完日志数据，需要解决的问题就是如何有效地利用 这些数据。
[0004] 对用户来讲操作日志最通用的做法是把日志信息与业务操作隔离，在实现上常采 用如下方式：
[0005] 1)构造系统日志表
[0006] 系统日志表一般包含如下字段：
[0007]
[0008] 另外，不同的系统根据框架的不同，可以增加一些框架相应的属性或者一些冗余 字段，但是核心的字段就如上表所列。
[0009] 2)业务功能在执行操作时，通过代码记录日志
[0010] 在用户执行某项操作时，如新增销售订单，对应系统中会有一个方法来进行数据的处理，如插入销售订单数据表。在插入完成后，会调用一个公共的日志记录方法，将操作 情况记录到步骤1)中的系统日志表。
[0011] 根据框架的不同，在使用上会存在差异，有些系统是框架自动去记录日志，但是操 作方式与原理是一样的。
[0012] 3)查询日志信息
[0013] 在应用系统的“系统管理”子系统下面挂一个日志查询的模块，用户可以在查询界 面输入查询条件，如功能、操作时间范围、操作者等；确定后，系统就从步骤1)的系统日志 表将符合条件的日志记录显示出来。
[0014] 以上方式对用户来讲特别不友好，需要从现有业务操作界面切换到日志查询界 面，而且还要根据组合条件才能匹配到目标业务数据。如在修改销售订单001时，想查看其 对应的日志信息，则需要切换到“系统管理”子系统下的日志查询界面，并输入“功能名称= 销售订单，操作实例=001”才能查到。而有些系统甚至没有专门的“操作实例”字段，这样 查询出来的结果要再一次定位，增加了系统处理流程。
[0015] 对普通的只注重操作结果的业务来讲，以上方式基本上能满足应用要求；但是对 注重操作过程的业务来讲，上述操作方式无法使用户了解到业务数据曾经发生过什么样的变化。
[0016] 有些应用系统为日志管理的单个功能点增加历史数据查询的功能，即增加一个专 门的数据表用来维护历史数据的变更，或者增加一个日志联查的功能，能在当前界面查询 到操作日志。但上述功能的增加不是基于一个日志查询系统整体的考虑，而且以后想为其 它功能再增加历史数据查询或者日志联查功能，或者取消当前的日志联查，就需要增加数 据表并修改代码了，增加了系统日志管理的复杂性。
发明内容
[0017] 本发明目的是要解决日志信息与业务操作挂接的问题，将系统日志与业务关联起 来，并且将日志分类，使用户不必从统一的日志信息表中查询符合条件的记录，并且能够决 定在哪些重要数据上记录其历史变动的详细信息。
[0018] 为解决上述技术问题，本发明提供了一种日志管理方法，包括如下步骤：
[0019] Sl ：初始化系统业务功能列表和业务功能方法列表；
[0020] S2 ：创建系统日志表和历史数据日志表；
[0021] S3 ：将业务操作中的具体操作信息与系统日志表和历史数据日志表直接相关联；
[0022] S4 ：根据业务操作自动记录日志信息。
[0023] 其中，系统业务功能列表中至少包括如下字段：业务功能ID、功能编码、功能名 称，还可以包括功能描述、层次、上级功能节点、是否可用字段。
[0024] 业务功能方法列表至少包括如下字段：业务功能方法ID、功能ID、功能方法名、方 法类型、日志记录方式；其中功能ID对应系统业务功能列表中的ID。
[0025] 优选的，在步骤Sl之后，还包括设置日志记录方式的步骤；所述日志记录方式有 三种：记录操作、记录历史数据、不记录；默认为记录操作。
[0026] 另一方面，本发明提供一种日志管理系统，由客户端和服务器端组成，
[0027] 所述服务器端包括：列表初始化单元，用于初始化系统业务功能列表和业务功能方法列表；日志表创建单元，用于创建系统日志表和历史数据日志表；数据关联单元，将业 务操作中的具体操作信息与系统日志表和历史数据日志表直接相关联；日志记录单元，用 于根据业务操作自动记录日志信息。
[0028] 其中，所述客户端包括：业务操作单元，用于客户端的业务操作；
[0029] 所述业务操作单元包括：日志记录方式设置单元，用于根据业务功能方法列表提 供的方式设置日志记录方式。
[0030] 与现有技术相比，本发明从整体考虑整个应用系统的日志信息与业务操作挂接， 用户在运行时可以根据当前的需要，选择某业务操作是否需要记录日志，以及是否需要记 录历史数据的变动过程；并且，用户在业务操作界面能即时将相关的日志信息调出来，不需 要再跑到专门的日志查询界面，大大简化了用户的操作。
附图说明
[0031] 图1是本发明实施例的系统日志与业务操作挂接的总体流程示意图；
[0032] 图2是本发明实施例的应用系统根据用户业务操作记录日志信息的过程示意图；
[0033] 图3表示本发明所述日志管理系统实施例的逻辑结构示意图。
具体实施方式
[0034] 为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实 施方式对本发明作进一步详细的说明。
[0035] 图1为本发明日志管理方法中系统日志与业务操作挂接的总体流程示意图，其中 上半部分表述用户操作，下半部分描述应用系统针对用户操作对日志的处理过程。如图1 所示，首先需要在应用系统处理层面初始化系统业务功能列表和业务功能方法列表，以便 提供界面供用户在具体功能的具体方式上设置日志记录方式，也便于后期将用户的业务操 作与系统日志衔接。然后将用户针对每个功能方法设置的日志记录方式存储至业务功能 方法列表的日志记录方式字段，创建系统日志表以及历史数据日志表，用于记录业务处理 的操作日志信息以及业务数据的变动过程；当用户对应用系统进行业务操作时，应用系统 根据日志记录方式将操作日志或数据变动信息存至系统日志表和/或历史数据日志表，藉 此，用户就可以通过在客户端在业务处理界面调用日志查询模块来查询系统日志或者历史 数据信息，了解系统数据发生了哪些变化。
[0036] 下面对图1的流程作进一步细化描述：
[0037] 1)初始化系统业务功能列表
[0038] 系统业务功能列表，用来记录应用系统提供的所有业务功能。系统业务功能列表 包含如下字段：
[0039]
[0040] 在上述字段中，前三个字段（ID、功能编码、功能名称)是必须具备的，根据系统的 不同，可以选择性的添加其他的辅助性字段，如上述示例列表中的“功能描述”、“层次”等字 段，还可以设置关联字段，与系统中具体的界面操作类关联，以便在点击菜单时，打开对应 的操作界面。在此仅以上表所列的核心的基本字段为例进行说明。
[0041] 其中，ID是系统业务功能列表的主键，是用来唯一表示一条数据的字段，其值不能 重复，每个ID唯一定位一条记录，比如，在上述业务功能列表中，对于功能名称字段为“销 售订单”的记录，有唯一对应的ID和功能编码，其中ID用于应用系统内部数据管理时对该 业务功能的内部唯一性标识，功能编码则是面向用户和系统管理员的对于该业务功能的外 部唯一性标识。
[0042] 在本发明的一个实施例中采用自动编号主键，就是新建一个ID字段，自动增长， 非常方便也满足主键的原则，优点是：数据库自动编号，速度快，而且是增量增长，聚集型主 键按顺序存放，对于检索非常有利；数字型的主键占用空间小，易排序，在程序中传递也方 便；通过非系统增加记录（比如手动录入，或是用其他工具直接在表里插入新记录，或老系 统数据导入）时，也非常方便，不用担心主键重复问题。当然，也可以采用其它如Max加一、 自制加一、⑶ID等方式设计主键，这些都属于本领域技术人员所熟知的技术，在此不再赘 述。
[0043] 功能编码字段表示应用系统提供的每一业务功能的唯一编码，用于标识应用系统 所提供的业务功能。如前所述，在该系统业务功能列表中，每一功能编码都唯一对应相应的 功能名称和功能描述，功能名称和功能描述字段是为了用户和系统管理人员管理、查询理 解上的方便而设置的，功能名称是对于业务功能的命名，如“销售订单”、“采购出库单”、“采 购单”、“物料需求计划”、“人力资源类型管理”等；功能描述是对业务功能的作用或者所能 实现目的的详细表述。层次字段表示当业务前功能在业务功能清单中所处的层次，如0表 示根节点，即应用系统，1表示子模块，2表示子模块下的功能...等。上级功能节点字段表 示当前业务功能的父节点。是否可用字段表示对于当前业务功能的控制能否被用户使用， 默认为“是”。
[0044] 2)初始化业务功能方法列表
[0045] 针对前述系统业务功能列表中的业务功能，初始化每项业务功能所对应的方法， 如系统业务功能列表中功能名称为“销售订单”，方法列表中就相应针对销售订单的操作 (如新增、修改、审核等）作一系列限定和描述。业务功能方法列表所包含的字段如下：
[0046]
[0047] 在上述字段中，前四个字段（ID、功能ID、功能方法名和方法类型）和“日志记录方 式字段”是必须具备的，根据系统的不同，还可以选择性的添加其他的辅助性字段，如上述 示例列表中的“功能方法描述”、“功能方法路径”字段。
[0048] 其中，ID是业务功能方法列表的主键，唯一定位一条功能方法的记录。功能ID对 应系统业务功能列表中的主键ID，从而建立起系统业务功能列表与业务功能方法列表之间 的联系；还是以系统业务功能列表中功能名称为“销售订单”为例，其对应于功能方法列表 中的功能方法名可以有add、delete, modify三种，所对应的功能方法描述分别为新增、删 除、修改。功能方法路径是当前方法所对应类的路径。
[0049] 方法类型分为以下两类：
[0050] a)状态变更类
[0051] 状态变更类主要有两种情况，一种是数据不发生变动，仅仅是状态改变，此时不需 要记录它的数据变动，只记录操作即可，如审核；一种是数据被删除，此时只在系统日志表 中记录删除操作即可，如删除销售订单。有一个例外就是新增操作，由于在系统可以记录历 史数变动过程，所以对新增操作同样不需要记录历史数据，也就是说如果该数据未发生改 变，则当前值就是新增时的值，因此，业务数据的新增操作也属于状态变更类，只需记录操 作即可。
[0052] b)数据变更类
[0053] 即数据发生变动且未被删除，此时除了记录操作外，还需要记录历史数据的变动， 如修改、变更销售订单。
[0054] 日志记录方式表示当前方法记录日志的方式，可以为以下三种方式之一：记录操 作、记录历史数据、不记录。其中，记录操作仅仅记录应用系统的操作结果，即用户只能知道 某某日期，某个用户针对某个功能作了什么操作，如“XX日期，系统管理员新增用户”，在存 储的时候是将相应的内容拆开存储在后述“系统日志表”的相应字段中。记录历史数据，除 记录操作外，还记录数据的变化过程，其存储方式见后述“历史数据日志表”。不记录，表示 不记录操作，也不记录历史数据。
[0055] 3)针对每个功能方法，设置日志记录方式[0056] 系统提供日志记录方式设置界面，显示内容如前述“业务功能方法列表”的记录， 用户可以选中具体的某个业务功能的某个方法名，设置日志的记录方式，提供的选项为“记 录操作”、“记录历史数据”和“不记录”；默认为“记录操作”。
[0057] 4)存储功能方法列表日志记录方式字段
[0058] 根据用户在日志设置界面的操作结果，将用户设置的日志记录方式存储在“业务 功能方法列表”的“日志记录方式”字段，以便后期用户进行业务操作过程中根据应用系统 用户的需求进行相应的日志记录工作。
[0059] 5)创建系统日志表及历史数据日志表
[0060] 系统日志表用于记录用户对应用系统的操作结果，传统日志表如背景技术中“构 造系统日志表”所示，本发明优选实施方式之一所使用的系统日志表与传统日志表有一些 差别：
[0061] >增加记录ID、记录分录ID字段；
[0062] >删除“操作对象”以及“业务类型”字段；
[0063] >修改“功能名称”为“功能ID”，修改“操作类型”为“方法ID”。
[0064] 具体如下：
[0065]
[0066] 同样，系统日志表中的ID是系统日志表的主键，唯一定位一条系统日志的记录。 操作者、操作时间、IP地址、执行结果字段设置都和传统的日志表一样，在此不再多加描述。
[0067] 功能ID以及方法ID用来定位一个用户的具体业务操作，即在某个功能上作的什么操作，分别对应“业务功能表”、“业务功能方法表”的ID。
[0068] 记录ID表示操作对象即被操作的具体数据的ID，如“001号销售订单的ID”。记 录分录ID表示操作对象即被操作的具体数据的分录的ID，如“001号销售订单的第1条明 细的ID”;记录分录ID是一个必须的字段，如果该业务数据没有分录的时候，该记录分录ID 的字段内容是空。
[0069] 历史数据日志表所包含的字段如下表所示：
[0070]
[0071] 同样，历史数据日志表中的ID是历史数据日志表的主键，唯一定位一条历史数据 日志的记录。操作者、操作时间、IP地址、功能ID、方法ID、记录ID、记录分录ID分别与相 应系统日志表中的对应字段所记录的内容相同。历史数据日志表的重点在于变动的字段名 以及用于记录新旧值的“原值”、“修改值”字段，通过该字段名以及原值、修改值字段可以便 方便地查看当前业务数据发生过哪些变动。
[0072] 对于应用系统来说，一个功能名称（被操作的功能点）可能具有多条记录，而每一 条记录也可能具有多个分录，因此，在本发明中，系统日志表和历史数据日志表的记录细化 到每个功能点，每条记录的最小分支单位。
[0073] 下面以销售订单为例，详细说明每个表、每个字段的取值。
[0074] >业务功能列表
[0075]
[0076] >业务功能方法列表
[0077]
[0078] >销售订单表（仅做参考用，与实际业务系统可能有差异)
[0079]
[0080] >销售订单分录表
[0081]
[0082] >系统日志表
[0083]
[0084] >历史数据日志表
[0085]
[0086] 6)将业务操作中的具体操作信息与系统日志表和历史数据日志表直接相关联
[0087] 将用户在业务操作过程中所可能涉及的每一个业务功能、业务功能方法以及记录 ID、记录分录ID等业务操作信息都与相应的系统日志表和历史数据日志表的相应字段关 联起来，这些业务操作信息也是与相应的系统日志表和历史数据日志表相关的字段所对应 的操作信息。以便用户在执行业务操作过程中，不必另行调用日志查询界面，在业务操作界 面即能直接根据业务操作对象（业务功能、业务功能方法以及记录ID、记录分录ID、字段 名所具体涉及的内容等）与日志相关字段的关联性，查询与该业务操作对象相关的日志信 肩、ο
[0088] 为了避免混淆，对于上述列表和日志表的主键ID也可以分别表述为业务功能 ID(指业务功能列表中的主键ID)、业务功能方法ID(指业务功能方法列表中的主键ID)、 系统日志ID (指系统日志表中的主键ID)、历史数据日志ID (指历史数据日志表中的主键 ID)。
[0089] 比如，对于销售订单管理界面的001号销售订单，如果用户进入销售订单管理界 面，对001号销售订单进行修改销售订单操作，那么应用系统弹出修改销售订单录入界面， 用户将必要的数据（如业务日期、分录的物料、计量单位、金额等）录入完成后，选择确定， 然后通过应用系统向服务器端发出执行提交的申请。在上述操作过程中，所涉及的业务数 据依次为：业务功能---“销售订单”对应的业务功能ID、业务功能方法---“修改”对应的 业务功能方法ID、记录ID— “001号销售订单”对应的销售订单ID，记录分录ID— "001 号销售订单分录”对应的分录ID，以及其具体涉及的内容（销售订单编号、业务日期、分录 的物料、计量单位、金额等）。那么在应用系统处理层面，就需要预先将如上描述的“业务功 能”与系统日志表和历史数据日志表的“功能ID”字段相关联；将“业务功能方法”与系统日志表和历史数据日志表的“方法ID”字段相关联；将“记录ID”与系统日志表和历史数据 日志表的“记录ID”字段相关联；将“记录分录ID”与系统日志表和历史数据日志表的“记 录分录ID”字段相关联”；对历史数据日志表来说，需要查询具体字段的变动记录，还需要将 “字段名，，与历史数据日志表的“字段名，，对应，譬如“金额”字段。以此能找到具体的日志 fn息ο
[0090] 7)业务操作自动记录日志信息
[0091] 在应用系统端完成系统业务功能功能列表、系统业务功能方法列表的初始化和系 统日志表、历史数据日志表的创建后，当用户在应用系统中进行业务操作时，应用系统就会 根据用户的业务操作过程和内容，按照系统日志表和历史数据日志表的格式要求记录下应 用系统使用的相关信息以及历史数据信息。
[0092] 应用系统根据用户的业务操作记录系统日志或者历史数据日志的过程如图2所 示。用户在客户端执行业务操作后提交服务端处理，服务端接收到客户的执行请求后，除了 进行相应的应用系统业务数据处理外，还需要进行系统日志的处理。基于本发明的描述重 点在于对系统日志的记录处理，因此图2仅示出了应用系统根据用户的业务操作记录日志 信息的过程。
[0093] 以前述对销售订单的管理为例，用户在客户端进入销售订单管理界面，对001号 销售订单进行操作，选择修改销售订单，应用系统弹出修改销售订单录入界面，用户将必要 的数据（如业务日期、分录的物料、计量单位、金额等）录入完成后，选择确定，然后通过应 用系统向服务器端发出执行提交的申请。在用户选择录入的过程中，用户执行操作所涉及 的功能名称、功能方法名、被操作记录的ID(001号销售订单）、记录分录ID、原值以及修改 值等信息就相应被确定下来。
[0094] 服务器端从客户端传递的信息中获取相关参数：功能ID (销售订单对应的功能名 称ID)、功能方法ID (修改对应的功能方法ID)、销售订单对象（即修改之后的销售订单，包 括销售订单ID、订单编号、业务日期）、销售订单分录对象（即修改之后的销售订单分录，包 括分录ID、分录物料信息、分录金额信息等）、销售订单净变动对象（即哪些字段发生值变 化，由客户端生成，一般可由系统框架处理，包含字段名、原值、变动值、类型，其中类型为： 主表字段、明细表字段，对多明细的单据，通过再增加类型值来区分）等，然后根据相关参 数中功能ID、功能方法ID从业务功能方法列表中得到“日志记录方式”，根据日志记录方式 判断应用系统下一步要进行的关于日志记录方面的操作。
[0095] 如果“日志记录方式”是不记录，则不对系统日志表和历史数据日志表作任何改变。
[0096] 如果“日志记录方式”是记录历史数据，则从功能方法列表中取到“方法类型”，如 前所述，分为两类，如果属于“数据变更类”，则将操作者、操作时间IP地址、功能ID、方法 ID、执行结果、记录ID、记录分录ID等系统日志表需要记录的信息插入系统日志表的相应 记录字段，然后，再将操作者、操作时间、IP地址、功能ID、方法ID、记录ID、记录分录ID(根 据字段类型，如果为“主表字段”则此字段为空）、字段名、原值、修改值等历史数据日志表要 记录的信息插入历史数据日志表的相应记录字段。如果属于“状态变更类”，则仅需要对系 统日志表进行修正，将操作者、操作时间IP地址、功能ID、方法ID、执行结果、记录ID、记录 分录ID等系统日志表需要记录的字段信息插入系统日志表中。[0097] 如果“日志记录方式”是记录操作，则仅需要对系统日志表进行修正，将操作者、操 作时间IP地址、功能ID、方法ID、执行结果、记录ID、记录分录ID等系统日志表需要记录的 字段信息插入系统日志表中。
[0098] 经过以上记录日志的过程，应用系统就完成了针对用户一个业务操作的日志记 录，用户可以在客户端的业务操作界面通过选择的操作对象（如：001号销售订单）、借助功 能ID以及功能方法ID与日志表之间的对应关系直接查询相应的系统日志信息或者历史数 据日志信息。
[0099] 8)从系统日志表及历史数据日志表中查找当前ID对应日志或历史记录
[0100] 根据用户在业务操作界面选择的操作数据，如001号销售订单，应用系统取出功 能ID、功能方法ID ( —般在代码中，每个功能点定义一个功能ID及多个方法ID的常量，具 体调用时引用这些常量即可），这里为“销售订单”和“新增”，按照当前操作记录ID(001号 销售订单对应的ID)、记录分录ID(第1条明细）从步骤5)的系统日志表中查找该条记录 对应的系统日志信息。
[0101] 如果用户选择查看历史数据，则根据功能ID、功能方法ID、记录ID、记录分录ID、 字段名与历史数据日志表匹配，取到相应数据，并将相同日期的多条记录合并成一条，形 如：
[0102]
[0103] 对应于前述对系统日志进行管理的方法，本发明还提供一种相应于前述日志管理 方法的日志管理系统，其逻辑结构如图3所示，该日志管理系统由客户端1和服务器端2组 成，其中客户端1包括用于客户端的业务操作的业务操作单元11 ；服务器端2包括列表初 始化单元21、日志表创建单元22、数据关联单元23、日志记录单元M和业务操作单元25。 其中，列表初始化单元21用于初始化系统业务功能列表和业务功能方法列表；日志表创建 单元22用于创建系统日志表和历史数据日志表；数据关联单元23用于将业务操作中的具 体操作信息与系统日志表和历史数据日志表直接相关联；日志记录单元M用于根据业务 操作自动记录日志信息。
[0104] 业务操作单元11又包括日志记录方式设置单元111，用于根据业务功能方法列表 提供的方式设置日志记录方式。
[0105] 基于与前述日志管理方法的对应性，在此不再对本发明的日志管理系统各逻辑组 成之间的关系及工作流程作详细说明，本领域技术人员从前述对日志管理方法的实施例表 述中，不用付出创造性的劳动即可得出实现上述日志管理系统的更为详细的技术方案。
[0106] 以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。对于 本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的 保护范围内。
相关阅读
今天来讲一下如何提高Facebook的用户参与度这个问题。在facebook上衡量参与度的重要指标就是reach率。现在很多人反映在Facebook
2019 月 6 月 30 日，音乐流媒体平台豆瓣 FM 发布了全新的 6.0 版本 APP，iOS 及各安卓渠道同步上线。据了解，新版豆瓣 FM 定位聚焦音
在新媒体时代的今天，中国的很多企业开始进行结构性的调整，主要采用信息化的方式来提高企业的竞争力，很多中小企业都跃跃欲试，想要抓住
衡量你的用户体验指标应该选择哪个？是留存率、满意度还是NPS？文章作者对这三个指标展开对应的分析解读，希望你能够找到一个适合你家
1.环境搭建 环境那个建 2.了解MVC模型 model–view–controller 3.搭建登陆页面