An audit log system for cloud resource integrity operations

Abstract

The present invention discloses an audit log system applied to cloud resource integrity operation, which belongs to the field of operation audit management technology. The technical problem to be solved is how to realize the integrity operation of cloud computing audit, support the integrity verification of audit operation and link traceability. It includes: a log production module, which is used to organize log instance information based on Spring AOP and custom annotations, and import the generated log summary data into the log instance information of the organization, and is used to print the log information to a specified file under a specified directory; a log collection module, which is used to parse the collected log files to obtain log content, and is used to output the log content after authentication; a log storage module, which is used to store and retrieve log content based on an Elasticsearch cluster; a log analysis and display module, which is used to provide log link opening tasks and summary analysis tasks, and is used to display log analysis results.

Description

Technical Field

[0001] The present invention relates to the technical field of operation audit management, and in particular to an audit log system applied to cloud resource integrity operations. Background Art

[0002] Cloud computing is considered the fourth revolution in the IT industry, following mainframe computers, personal computers, and the internet. Adhering to the principle of "on-demand service," cloud computing provides users with elastic and highly available computing services. An increasing number of enterprises and individuals are choosing to deploy their business systems on public, private, or hybrid clouds. Because cloud computing typically provides IaaS, PaaS, and SaaS services through virtualization and a multi-tenant architecture, many implementation details are obscured. Actual users need to audit cloud resource specifications and operations to determine whether they comply with user-defined parameters, who set the parameters, when, how many sub-resources are involved in creating a cloud resource, and the specific reasons for resource creation failures. Existing cloud computing audits primarily focus on the security of databases, host systems, and cloud resources within the cloud. Some operational audits primarily focus on user login and logout operations and lack integrity verification or traceability.

[0003] How to achieve the integrity operation of cloud computing audit, support the integrity verification of audit operations and link traceability is a technical problem that needs to be solved. Summary of the Invention

[0004] The technical task of the present invention is to address the above shortcomings and provide an audit log system applied to cloud resource integrity operations to solve the technical problems of how to implement integrity operations of cloud computing audits, support integrity verification of audit operations, and link traceability.

[0005] An audit log system for cloud resource integrity operations according to the present invention includes:

[0006] Log generation modules, which are multiple and correspond one-to-one to the nodes where service products are deployed. Each log generation module is used to organize log instance information based on Spring AOP and custom annotations, and add the generated log summary data to the organized log instance information to obtain the final log information. The final log information is then printed to a specified file in a specified directory to generate a log file;

[0007] A log collection module, which interacts with the log production module to parse the collected log files to obtain log content and output the log content after authentication;

[0008] A log storage module, which interacts with the log collection module and is used to store and retrieve log content based on the Elasticsearch cluster;

[0009] The log analysis and display module interacts with the log storage module to provide log link opening tasks and summary analysis tasks, and to display log analysis results.

[0010] Preferably, the log production module includes:

[0011] A log production component, which is used to customize annotations, organize log instance information based on annotations and the ring-cutting technology in Spring AOP, calculate log summary data based on a method of first using national secret soft encryption and then using national secret hard encryption, and import the log summary data into the organized log instance information to obtain the final log information;

[0012] A log printing component is used to output the final log information into json format, flatten the log information in json format to obtain log information in a unified format, and print the log information in the unified format to a specified file in a specified directory to obtain a log file.

[0013] Preferably, the log production component is used to organize log instance information based on annotations and Spring AOP's ring cutting technology through the following steps:

[0014] Customize two annotations: operation annotation and resource result annotation;

[0015] Based on the loop cutting technology in Spring AOP, a cut point is established on the operation annotation, and a section is formed by adding annotations;

[0016] For a rest request, if the requestId can be obtained in the header, it means that the rest request is the callee, and the call flag is set to called; if the requestId cannot be obtained in the header, it means that the rest request is an active request, and the call flag is set to active;

[0017] After obtaining the client IP address and method parameters, call the annotated method to obtain its output parameters;

[0018] If the parsing method is set in the annotation, the obtained method input and output parameters are encapsulated into a Map object, and the configured parsing method is called using reflection technology to obtain the log information returned by the parsing method and organize the log instance information; otherwise, the log instance information is organized according to the input and output parameters.

[0019] Preferably, the log production component is used to generate log summary data through the following steps:

[0020] Serialize the log instance information data;

[0021] Call the national encryption software to encrypt the serialized log data and obtain a 64-character ciphertext.

[0022] The encryption machine is called to encrypt the ciphertext using the national encryption SM3.

[0023] Preferably, the log printing component supports three log frameworks: log4j, log4j2 and logback, and the log printing component implements the layout components of the three log frameworks respectively;

[0024] The service product introduces the corresponding log printing component based on the log framework used, and sets the path where the log production component is located to print logs using the log printing component format, with the log level being warn and the log path being / icp / service product code / audit.log. The log file is rotated based on its size. When deploying the service product, the log path is mounted to the corresponding directory of the host node.

[0025] Preferably, the log collection module includes:

[0026] The collection end, which has multiple collection ends and corresponds to the log production module one by one, is used to uniformly collect log files through the JSON parser and output the parsed log content;

[0027] The aggregation end interacts with the collection end to aggregate the parsed log content, authenticate the log content uniformly, and distribute it to the log storage module.

[0028] Preferably, the log collection module is an open source component fluentd, which is deployed in the form of daemonset.

[0029] Preferably, the log analysis and display module includes:

[0030] A log analysis submodule, which is used for unified task scheduling based on xxl job, and for providing log link opening tasks and summary analysis tasks by executing a task list. The log link opening is used to connect log link data. The summary analysis tasks include user-based summary for summarizing the number of daily operations of each user according to the user dimension, operation result summary for summarizing the number of successful or failed operations according to the operation result dimension, operation summary for summarizing the number of each operation per day according to the operation dimension, daily summary for summarizing the number of all operations according to the daily dimension, and quarterly summary for summarizing the number of all operations according to the quarterly dimension;

[0031] The log display submodule is used to provide SQL-like queries, to display log analysis results through a graphical interface, and to provide report download services.

[0032] Preferably, the log link opening task includes the following process:

[0033] After receiving the task, the node obtains the log link thread pool and queries the database to obtain the latest timestamp of the completed link. If the latest timestamp is less than T hours away from the current time, the task is terminated. Otherwise, with this timestamp as the start time, T tasks are opened in hours to open the link data for the next T hours. Each task uses the rolling query API to query the original log data index, and uses the requestId to query the original data index one by one. All the queried data is stored in the link index in the link data format. After the query of T tasks is completed, the time period is stored in the database, the task is terminated, and the next execution notification is awaited.

[0034] The user aggregation task includes the following process:

[0035] After receiving a task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than the scheduled 24 hours away from the current time, the task is terminated. Otherwise, the node uses this timestamp as the starting time and queries the number of operations per user in the past 24 hours. The result is stored in the user operation index in a user-aggregated data format, and the time period of this aggregation is stored in the database. The task is terminated and the node awaits the next execution notification.

[0036] The task of summarizing the operation results includes the following process:

[0037] After receiving a task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than 24 hours away from the current time, the task is terminated. Otherwise, the node uses this timestamp as the start time and queries the number of successful and failed operations within 24 hours. The result is stored in the operation result index in the format of summary data by operation result, and the time period of this summary is stored in the database. The task is terminated and the node waits for the next execution notification.

[0038] The task of summarizing operations includes the following process:

[0039] After receiving a task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than 24 hours away from the current time, the task is terminated. Otherwise, the node uses this timestamp as the start time and queries the number of each operation in the past 24 hours. The result is stored in the operation index in the format of operation summary data, and the time period of this summary is stored in the database. The task is terminated and the node waits for the next execution notification.

[0040] The daily summary task includes the following processes:

[0041] After receiving a task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than 24 hours away from the current time, the task is terminated. Otherwise, the node uses this timestamp as the start time and queries the number of all operations in the past 24 hours. The result is stored in the daily summary index in the format of daily summary data, and the time period of this summary is stored in the database. The task is terminated and the node waits for the next execution notification.

[0042] The quarterly summary task includes the following processes:

[0043] After receiving the task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than three months away from the current time, the task is terminated. Otherwise, the node uses this timestamp as the start time to query the number of all operations in the past three months, stores the result in the quarterly summary data format in the quarterly summary index, and stores the time period of this summary in the database. The task is terminated and waits for the next execution notification.

[0044] The audit log system for cloud resource integrity operations of the present invention has the following advantages:

[0045] 1. Log data is decoupled from log production, collection, aggregation, analysis, and display. Each service product only needs to add annotations to the interface that generates the operation audit. It is unaware of the log production process, separating business from logs, and has no impact on the business. Furthermore, the log production component does not need to pay attention to the services and content of the business.

[0046] 2. The log collection module includes a collection end and an aggregation end. The collection end collects and analyzes log content, and the aggregation end aggregates the parsed log content and distributes it to the log storage module after unified authentication. This realizes separate collection and unified aggregation, authentication and distribution, and separates the collection and authentication distribution functions. This makes the log storage end private and protects privacy.

[0047] 3. In terms of analysis and display, it provides log link connection and analysis summary of various dimensions. It adopts the method of pre-aggregating operation log data, which greatly reduces the waiting time for report query and eliminates the need for a large number of repeated aggregation operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0049] The present invention will be further described below with reference to the accompanying drawings.

[0050] Figure 1 This is a structural block diagram of an audit log system applied to cloud resource integrity operations in Example 1;

[0051] Figure 2 This is a flowchart of the workflow of a log production component in an audit log system applied to cloud resource integrity operations in Example 1. DETAILED DESCRIPTION

[0052] The present invention will be further described below with reference to the accompanying drawings and specific embodiments so that those skilled in the art can better understand the present invention and implement it. However, the embodiments given are not intended to limit the present invention. Unless there is a conflict, the embodiments of the present invention and the technical features in the embodiments may be combined with each other.

[0053] An embodiment of the present invention provides an audit log system applied to cloud resource integrity operations, which is used to solve the technical problems of how to implement integrity operations of cloud computing audits, support integrity verification of audit operations, and link traceability.

[0054] Example:

[0055] The present invention provides an audit log system for cloud resource integrity operations, such as Figure 1 As shown, the system includes a log production module, a log collection module, a log storage module, and a log analysis and display module.

[0056] There are multiple log production modules, which correspond one-to-one to the nodes where service products are deployed. Each log generation module is used to organize log instance information based on Spring AOP and custom annotations, and import the generated log summary data into the organized log instance information to obtain the final log information. The final log information is then printed to a specified file in a specified directory to generate a log file.

[0057] As a specific implementation, the log production module includes a log production component and a log printing component. The log production component is used to customize annotations, organize the log instance body based on annotations and the circular cutting technology in Spring AOP, calculate the log summary data based on the method of soft encryption first and then hard encryption, and import the log summary data into the organized log instance information to obtain log information; the log printing component is used to output the log information into json format, and flatten the log information in json format to obtain log information in a unified format, and print the log information in the unified format to a specified file in a specified directory to obtain a log file.

[0058] like Figure 2 As shown, the log production component workflow includes organizing log instance information and signing to generate log summary data.

[0059] Step 1: Organize log instance information:

[0060] The log production component uses annotations and Spring's AOP technology. First, two annotations are customized: operation annotations and resource result annotations.

[0061] Use the loop cutting technology in Spring AOP to establish a cut point on the operation annotation so that the method with the annotation can form a section;

[0062] For REST requests, get the requestId in the header. If it can be obtained, it means that the request is the callee, and the call flag is set to called; if it cannot be obtained, it means that the request is an active request, and the call flag is set to active.

[0063] After obtaining the client IP address and method parameters, the annotated method is called to obtain its output parameters. If a parsing method is set in the annotation, the obtained method input and output parameters are encapsulated into a Map object, and then the configured parsing method is called using reflection technology to obtain the log information returned by the parsing method and organize the log instance information; otherwise, the log production component organizes the log instance information based on the input and output parameters.

[0064] Since the length of the log data is unknown and the encryption machine has a length limit for the encrypted data, this embodiment uses a method of first soft encryption and then hard encryption to calculate the digest to protect the integrity of the log.

[0065] Step 2: Signature generates log summary data:

[0066] Serialize the log instance information data;

[0067] Call the national encryption software to encrypt the serialized log data and obtain a 64-character ciphertext.

[0068] Call the encryption machine to use the national encryption SM3 to encrypt the ciphertext in the previous step.

[0069] Generate log summary data through the above three steps, put it into the log instance information, and then call the log printing component to print the log content to the specified file.

[0070] The log printing component supports three log frameworks: log4j, log4j2 and logback. This component implements the layout components of the three log frameworks respectively, converts the log content into JSON output, and flattens the JSON content to generate log content in a unified format.

[0071] The service product includes the corresponding log printing component based on the logging framework used. The path where the log production component resides is configured to print logs using the log printing component's format. The log level is set to warn, the log path is / icp / service product code / audit.log, and log file rotation is configured based on size. When deploying the service product, mount the log path to the corresponding directory on the host node.

[0072] The log collection module uses the open source component fluentd, which is deployed using daemonset to ensure that it is deployed on all app nodes (app nodes are nodes where service products are deployed). A JSON parser is then used to uniformly collect / icp / * / audit.log files (* represents a fuzzy match, meaning that audit.log files in any subdirectory under the / icp directory are collected). These files are then uploaded to the aggregation end fluentd, which performs unified authentication, distribution, and delivery to the log storage module. The collection end only needs to focus on collection and is unaware of the storage module. The aggregation end only needs to passively wait for the collection end to upload log data and then deliver the log data to the storage end. The aggregation end also has a buffer zone, which can cache log data if the storage module fails and wait for the storage module to respond before delivering it, preventing log data loss. This deployment method helps reduce the number of connections to the storage module while protecting the storage module from external exposure.

[0073] The log storage module uses an open-source Elasticsearch cluster. Elasticsearch is a distributed, highly scalable, and highly real-time search and data analysis engine. It easily enables search, analysis, and exploration of large amounts of data. Leveraging Elasticsearch's horizontal scalability makes data more valuable. First, the raw log data is stored in an index aliased as audit, which serves as the foundation for subsequent log analysis. Using Elasticsearch's word segmentation and highlighting features, we seamlessly address the challenge of indexing logs by keyword. We specify an analyzer in the index that matches keywords using all lowercase letters, ignoring case-sensitive matching. For example, if log data is labeled "Error," a search for "error" will still correctly match it. This allows users to freely enter a keyword without worrying about case. Our cluster runs on three Elasticsearch nodes, with two index replicas, ensuring that even if a node fails, log data is not affected. Should data volume surge, we can scale horizontally by adding more nodes.

[0074] The log analysis and display module is divided into a log analysis submodule and a log display submodule. Since this module has multiple copies, the log analysis submodule does not use scheduled tasks to perform log analysis operations. Instead, it relies on XXL jobs for unified task scheduling. The task list is: log link opening, aggregation by user, aggregation by operation results, aggregation by operation, aggregation by day, and aggregation by quarter.

[0075] The purpose of the log link connection task is to connect log link data. The overall implementation method is as follows:

[0076] After receiving the task, the node obtains the log link thread pool and queries the database for the latest timestamp of the completed link. If the latest timestamp is less than four hours away from the current time, the task is terminated. Otherwise, using this timestamp as the starting time, four tasks are initiated, each hourly, to complete the link data for the next four hours. Each task uses the rolling query API to query the raw log data index, querying the raw data index using the requestId one by one, and storing all the queried data in the link index in link data format. After the four tasks are queried, the time period is stored in the database, the task is terminated, and the next execution notification is awaited.

[0077] The purpose of the user aggregation task is to aggregate the number of daily operations of each user by user dimension. The overall implementation method is as follows:

[0078] After receiving the task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than 24 hours away from the current time, the task is terminated. Otherwise, the node uses this timestamp as the start time to query the number of operations of each user in the past 24 hours, stores the result in the user operation index in the format of user-aggregated data, and stores the time period of this aggregation in the database. The task is terminated and waits for the next execution notification.

[0079] The task of summarizing operations by results is used to summarize the number of successful or failed operations per day based on the operation result dimension. The overall implementation is as follows:

[0080] After receiving the task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than 24 hours away from the current time, the task is terminated. Otherwise, the timestamp is used as the start time to query the number of successful and failed operations in the past 24 hours. The result is stored in the operation result index in the format of summary data by operation result, and the time period of this summary is stored in the database. The task is terminated and waits for the next execution notification.

[0081] The purpose of the operation summary task is to summarize the number of each operation per day by operation dimension. The overall implementation method is as follows:

[0082] After receiving the task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than 24 hours away from the current time, the task is terminated. Otherwise, the timestamp is used as the start time to query the number of each operation in the past 24 hours. The result is stored in the operation index in the format of operation summary data, and the time period of this summary is stored in the database. The task is terminated and waits for the next execution notification.

[0083] The daily summary task is used to summarize the number of all operations by day. The overall implementation is as follows:

[0084] After receiving the task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than 24 hours away from the current time, the task is terminated. Otherwise, the timestamp is used as the start time to query the number of all operations in the past 24 hours. The result is stored in the daily summary index in the format of daily summary data, and the time period of this summary is stored in the database. The task is terminated and waits for the next execution notification.

[0085] The quarterly summary task is used to summarize the number of operations by quarter. The overall implementation is as follows:

[0086] After receiving the task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than 3 months away from the current time, the task is terminated. Otherwise, the node uses this timestamp as the start time to query the number of all operations in the past 3 months, stores the result in the format of quarterly summary data in the quarterly summary index, and stores the time period of this summary in the database. The task is terminated and waits for the next execution notification.

[0087] The log display submodule provides users with SQL-like query and analysis log capabilities, while providing a graphical interface to display aggregated analysis data to users and providing users with the function of downloading reports.

[0088] The system of this embodiment includes a log production module, a log collection module, a log storage module, and a log analysis and presentation module. The log production module, referenced by each cloud service product, produces operation logs in a specified format and generates signatures. The log collection module collects operation logs and delivers the collected content to the log storage module. The log storage module stores operation logs and provides retrieval services. The log analysis and presentation module displays log links and log analysis results. Through coordinated cooperation between these modules, a complete service resource operation audit system solution is provided to the cloud platform.

[0089] The present invention has been shown and described in detail above through the accompanying drawings and preferred embodiments. However, the present invention is not limited to these disclosed embodiments. Based on the above multiple embodiments, those skilled in the art can know that the means in the above different embodiments can be combined to obtain more embodiments of the present invention, and these embodiments are also within the scope of protection of the present invention.

Claims

1. An audit log system for cloud resource integrity operations, characterized in that include: A log production module, wherein there are multiple log production modules, and each of the log production modules corresponds to a node where a service product is deployed. The log production module includes a log production component and a log printing component. The log production component is used to customize annotations, organize log instance information based on annotations and the ring cutting technology in Spring AOP, generate log summary data, and import the log summary data into the organized log instance information to obtain the final log information; the log printing component is used to output the final log information in json format, flatten the log information in json format, obtain log information in a unified format, and print the log information in the unified format to a specified file in a specified directory to obtain a log file; A log collection module, which interacts with the log production module and is used to parse the collected log files to obtain log contents, and to output the log contents after authentication; A log storage module, which interacts with the log collection module and is used to store and retrieve log content based on an Elasticsearch cluster; A log analysis and display module, which interacts with the log storage module, is used to provide log link opening tasks and summary analysis tasks, and is used to display log analysis results; The log production component is used to organize log instance information based on annotations and Spring AOP ring cutting technology through the following steps: Customize two annotations, namely operation annotation and resource result annotation; Based on the loop cutting technology in Spring AOP, a cut point is established on the operation annotation, and a section is formed by adding annotations; For a rest request, if the requestId can be obtained in the header, it means that the rest request is the called party, and the call flag is set to the called party; if the requestId cannot be obtained in the header, it means that the rest request is an active request, and the call flag is set to the active caller; After obtaining the client IP address and method parameters, call the annotated method to obtain its output parameters; If the parsing method is set in the annotation, the obtained method input and output parameters are encapsulated into a Map object, and the configured parsing method is called using reflection technology to obtain the log information returned by the parsing method and organize the log instance information; otherwise, the log instance information is organized according to the input and output parameters; The log production component is used to generate log summary data through the following steps: Serialize the log instance information data; Call the national encryption software encryption component to encrypt the serialized log data and obtain a 64-character ciphertext; The encryption machine is called to encrypt the ciphertext using the national encryption SM3.

2. An audit log system for cloud resource integrity operations according to claim 1, characterized in that The log printing component supports three log frameworks: log4j, log4j2 and logback, and the log printing component implements the layout components of the three log frameworks respectively; The service product introduces the corresponding log printing component according to the log framework used, and sets the path where the log production component is located to print logs using the log printing component format. The log level is warn, the log path is / icp / service product code / audit.log, and the log file is rotated according to the size. When deploying the service product, mount the log path to the corresponding directory of the host node.

3. An audit log system for cloud resource integrity operations according to claim 1, characterized in that The log collection module includes: The collection end has multiple collection ends and corresponds to the log production module one by one, and is used to uniformly collect log files through the JSON parser and output the parsed log content; The aggregation end interacts with the collection end to aggregate the parsed log content, and uniformly authenticate the log content and distribute it to the log storage module.

4. An audit log system for cloud resource integrity operations according to claim 3, characterized in that The log collection module is an open source component fluentd, which is deployed in the form of daemonset.

5. The audit log system for cloud resource integrity operations according to claim 1, characterized in that The log analysis and display module includes: A log analysis submodule, which is used for unified task scheduling based on xxl job, and for providing log link opening tasks and summary analysis tasks by executing a task list. The log link opening is used to connect log link data. The summary analysis tasks include a user summary task for summarizing the number of daily operations of each user according to the user dimension, an operation result summary task for summarizing the number of successful or failed operations per day according to the operation result dimension, an operation summary task for summarizing the number of each type of operation per day according to the operation dimension, a daily summary task for summarizing all operation times according to the daily dimension, and a quarterly summary task for summarizing all operation times according to the quarterly dimension; The log display submodule is used to provide SQL-like queries, to display log analysis results through a graphical interface, and to provide report download services.

6. An audit log system for cloud resource integrity operations according to claim 5, characterized in that The log link opening task includes the following process: After receiving the task, the node obtains the log link thread pool and queries the database to obtain the latest timestamp of the completed link. If the latest timestamp is less than T hours away from the current time, the task is terminated; otherwise, this timestamp is used as the start time, and T tasks are opened in hours to open the link data for the next T hours. Each task uses the rolling query API to query the original log data index, and uses requestId to query the original data index one by one. All the queried data is stored in the link index in the link data format. After the query of T tasks is completed, the time period is stored in the database, the task is terminated, and the next execution notification is waited for; The task of summarizing tasks by user includes the following process: After receiving the task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than the scheduled 24 hours from the current time, the task is terminated. Otherwise, use this timestamp as the start time, query the number of operations of each user in the past 24 hours, store the result in the user operation index in the format of user summary data, and store the time period of this summary in the database, end this task, and wait for the next execution notification; The task of summarizing the operation results includes the following process: After receiving the task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than 24 hours away from the current time, the task is terminated. Otherwise, use this timestamp as the start time, query the number of successful and failed operations within 24 hours, store the results in the operation result index in the format of summary data by operation result, and store the time period of this summary in the database, end this task, and wait for the next execution notification; The task of summarizing operations includes the following process: After receiving the task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than 24 hours away from the current time, the task is terminated. Otherwise, use this timestamp as the start time, query the number of each operation in the past 24 hours, store the result in the operation index in the format of operation summary data, and store the time period of this summary in the database, end this task, and wait for the next execution notification; The daily summary task includes the following processes: After receiving the task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than 24 hours away from the current time, the task is terminated. Otherwise, use this timestamp as the start time, query the number of all operations in the past 24 hours, store the result in the daily summary index in the format of daily summary data, and store the time period of this summary in the database, end this task, and wait for the next execution notification; The quarterly summary task includes the following processes: After receiving the task, the node queries the database to obtain the latest completed timestamp. If the latest timestamp is less than three months away from the current time, the task is terminated. Otherwise, use this timestamp as the start time to query the number of all operations in the past three months, store the results in the quarterly summary index in the format of quarterly summary data, and store the time period of this summary in the database, end this task, and wait for the next execution notification.

Images