Server cross-domain event timing alignment method, apparatus, device, and medium

Abstract

The application provides a server cross-domain event timing alignment method and device, equipment and medium, and relates to the technical field of servers. The method comprises the following steps: at the beginning of each running period, a BMC of a server generates a running period identifier corresponding to the current running period, and constructs and maintains a monotonic timer corresponding to the current running period; in response to the BMC detecting a target BMC event, the target BMC event is written into a first log generated by the BMC, and a running period identifier and a clock count value of the monotonic timer are additionally written into the first log; in response to a system end of the server detecting a target system event, the target system event and a corresponding original clock timestamp are written into a second log generated by the system end; a read-only query interface provided by the BMC is called to obtain a query result; fields included in the query result are additionally written into the second log; and the first log and the second log are sent to a management end to generate an evidence chain corresponding to the server. The application improves the reliability of the fault event evidence chain.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to a method, apparatus, device and medium for aligning cross-domain events on a server. Background Technology

[0002] Server fault analysis typically requires combining hardware events from the BMC side and software events from the system side to reconstruct the sequence and causal relationship of the fault occurrence. The BMC side usually records hardware events such as voltage, fan speed, temperature, and power status, while the system side typically records kernel, driver, and service anomaly events.

[0003] Existing technologies generally use the raw clock time from the logs of each domain for alignment. However, the raw clock time is prone to distortion in the following scenarios: First, in time synchronization transition scenarios, time synchronization mechanisms such as NTP and Chrony may cause the clock time to jump back or jump abruptly, failing to guarantee strict monotonic increment; Second, in the early stages of BMC startup, the time synchronization mechanism has not yet started or completed time synchronization, but the BMC has already begun recording events, resulting in event timestamps that may be empty, default values, or uncalibrated times.

[0004] In the aforementioned situations, it is difficult to accurately determine the chronological order of BMC events and system-level events. Root cause analysis of failures easily relies on empirical inferences, the chain of evidence is difficult to prove itself, and external reports are easily questioned. Therefore, existing technologies suffer from the inability to accurately determine the chronological order of cross-domain events. Summary of the Invention

[0005] This application provides a method, apparatus, device, and medium for cross-domain event timing alignment on a server, which enables cross-domain timing alignment of BMC events and system-side events without relying on the original clock time of each domain as a strict sorting criterion.

[0006] This application provides a server cross-domain event timing alignment method, applied to a server. The method includes: at the beginning of each operating cycle, the server's Baseboard Management Controller (BMC) generates an operating cycle identifier corresponding to the current operating cycle, and constructs and maintains a monotonic timer corresponding to the current operating cycle, wherein the monotonic timer monotonically increases within the current operating cycle; in response to the BMC detecting a target BMC event, the target BMC event is written to a first log generated by the BMC, and the operating cycle identifier and the clock count value of the monotonic timer are appended to the first log; in response to the server's system side detecting a target system event, the target system event and its corresponding original clock timestamp are written to a second log generated by the system side; a read-only query interface provided by the BMC is invoked to obtain a query result; if the query result includes at least one of the operating cycle identifier and the clock count value of the monotonic timer, the fields included in the query result are appended to the second log; the first log and the second log are sent to a management terminal to generate an evidence chain corresponding to the server; wherein the evidence chain includes at least the logs corresponding to the target BMC event and the target system event, used to reflect the timing relationship between the target BMC event and the target system event.

[0007] According to one embodiment of this application, generating the operating cycle identifier corresponding to the current operating cycle includes: in response to the power-on or reset of the BMC, generating the operating cycle identifier in any of the following ways: generating the operating cycle identifier based on a random number of preset digits; or, generating the operating cycle identifier based on a combination of a random number of preset digits and a counter value; the operating cycle identifier remains unchanged within the current operating cycle, and different operating cycles correspond to different operating cycle identifiers.

[0008] According to one embodiment of this application, the construction and maintenance of the monotonic timer corresponding to the current running cycle includes: at the beginning of the current running cycle, constructing a corresponding monotonic timer based on the internal hardware timer of the BMC; the monotonic timer increments from a set initial value according to a preset resolution, wherein the preset resolution is a preset fixed time unit; the monotonic timer remains monotonically increasing within the current running cycle to characterize the chronological order of events occurring within the current running cycle.

[0009] According to one embodiment of this application, before calling the read-only query interface provided by the BMC, the method further includes: the BMC providing the read-only query interface to the system, wherein the read-only query interface is used to respond to the call from the system and return query results; the query results, when successfully obtained, include the running cycle identifier, the current clock count value of the monotonic timer, the resolution unit, and a status flag; the query results, when failing to obtain or with missing fields, include at least one of a status flag, an error code, and a missing field identifier.

[0010] According to one embodiment of this application, the step of calling the read-only query interface provided by BMC to obtain query results includes: obtaining a pre-set event set, wherein the event set includes at least one target system event; in response to the system triggering the target system event in the event set, calling the read-only query interface to obtain at least one of the running cycle identifier and the clock count value of the monotonic timer.

[0011] According to one embodiment of this application, the method further includes: obtaining preset retry parameters corresponding to the target system event and interface call control parameters corresponding to the read-only query interface; calling the read-only query interface based on the interface call control parameters to obtain a query result; in response to the query result lacking at least one of the running cycle identifier and the clock count value of the monotonic timer, retaining the target system event and the original clock timestamp already written in the second log, and writing the error code and missing identifier into the second log; wherein, the missing identifier is used to characterize the missing field in the query result; calling the read-only query interface again within a limited number of times based on the retry parameters; if the missing field is obtained before the second log is reported, then the subsequently obtained field is written into the second log; if the missing field is obtained after the second log is reported, then a supplementary log associated with the second log is generated, and the supplementary log is sent to the management terminal.

[0012] This application also provides a server cross-domain event timing alignment method, applied to a management terminal. The method includes: receiving a first log and a second log sent by a server; wherein the first log is generated by the server's BMC and includes a target BMC event, a runtime identifier, and a clock count value of a monotonic timer; the second log is generated by the server's system terminal and includes at least one of a runtime identifier and a clock count value of a monotonic timer, a target system event, and an original clock timestamp; based on the runtime identifier in the log, segmenting and aggregating the first log and the second log including the runtime identifier to obtain a log timeline corresponding to each runtime; wherein the first log and the second log with the same runtime identifier are grouped into the same log timeline; based on the clock count value of the monotonic timer, sequentially sorting the event logs including the clock count value within each log timeline to obtain an evidence chain; wherein the evidence chain includes at least the logs corresponding to the target BMC event and the target system event, and the evidence chain is used to reflect the timing relationship between the target BMC event and the target system event; and outputting the evidence chain.

[0013] According to one embodiment of this application, the step of segmenting and aggregating the first log and the second log including the running cycle identifier based on the running cycle identifier in the log includes: dividing the first log and the second log corresponding to the same running cycle identifier into the same log timeline, so that the target BMC event and the target system event are in the same running cycle corresponding to the same time coordinate; each log timeline corresponds to one running cycle, and the unified time coordinate in the log timeline is jointly determined by the running cycle identifier and the clock count value of the monotonic timer.

[0014] According to one embodiment of this application, the step of sequentially sorting the event logs including the clock count values ​​within each log timeline includes: calculating the difference between the clock count values ​​corresponding to the events to be sorted based on an unsigned difference comparison rule; determining the chronological order between the target BMC event and the target system event within the log timeline based on the difference; and sorting the event logs within each log timeline based on the chronological order to obtain a chain of evidence.

[0015] According to one embodiment of this application, the method further includes: when the clock count values ​​of two events are the same, sorting the logs corresponding to the two events based on log source priority and domain sequence number; when the second log includes a running cycle identifier but does not include the clock count value of a monotonic timer, merging the second log into the log timeline of the corresponding running cycle and marking it as a time-determined log; in response to receiving the clock count value corresponding to the time-determined log, sorting the time-determined log based on the received clock count value; when the second log does not include a running cycle identifier, marking the second log as a log to be assigned, and the log to be assigned does not participate in the sorting within the log timeline.

[0016] According to one embodiment of this application, the method further includes: adding the original clock timestamps corresponding to each event to the evidence chain; the original clock timestamps are used to characterize the original time information in the logs corresponding to the events and serve as auxiliary display fields.

[0017] This application also provides a server cross-domain event timing alignment device, applied to a server. The device includes: an identification and timing maintenance module, used to generate a runtime identifier corresponding to the current runtime at the beginning of each runtime, and to construct and maintain a monotonic timer corresponding to the current runtime, wherein the monotonic timer remains monotonically increasing within the current runtime; a BMC event log generation module, used to, in response to the BMC detecting a target BMC event, write the target BMC event into a first log generated by the BMC, and append the runtime identifier corresponding to the current runtime and the clock count value of the monotonic timer to the first log; and a system event log generation module, used to, in response to the system side of the server detecting... The system generates a target system event and writes the target system event and its corresponding original clock timestamp into a second log generated by the system. It then calls a read-only query interface provided by the BMC to obtain query results. If the query results include at least one of the running cycle identifier corresponding to the current running cycle and the clock count value of the monotonic timer, it appends the fields included in the query results to the second log. A log sending module sends the first log and the second log to the management end to generate an evidence chain corresponding to the server. The evidence chain includes at least the logs corresponding to the target BMC event and the target system event, reflecting the temporal relationship between the target BMC event and the target system event.

[0018] This application also provides a server cross-domain event timing alignment device, applied to a management terminal. The device includes: a log receiving module for receiving a first log and a second log sent by the server; wherein the first log is generated by the server's BMC and includes a target BMC event, a runtime identifier, and a clock count value of a monotonic timer; the second log is generated by the server's system terminal and includes at least one of a runtime identifier and a clock count value of a monotonic timer, a target system event, and an original clock timestamp; and a segmentation aggregation module for aligning the first log and the second log based on the runtime identifier in the log. The second log with the runtime cycle identifier is segmented and aggregated to obtain a log timeline corresponding to each runtime cycle; wherein, the first log and the second log with the same runtime cycle identifier are grouped into the same log timeline; the evidence chain sorting module is used to sort the event logs including the clock count value in each log timeline according to the clock count value of the monotonic timer to obtain an evidence chain; wherein, the evidence chain includes at least the logs corresponding to the target BMC event and the target system event, and the evidence chain is used to reflect the temporal relationship between the target BMC event and the target system event; the evidence chain output module is used to output the evidence chain.

[0019] This application also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and when the instructions are executed by the at least one processor, the at least one processor is able to perform the above-described method.

[0020] This application also provides a non-transitory computer-readable storage medium storing computer instructions that, when executed by a computer, cause the computer to perform the above-described method.

[0021] This application has at least the following beneficial effects: Firstly, the alignment and sorting are based on the unified timing coordinates provided by BMC, which can reduce the impact of original clock time rollbacks or jumps on the sorting of cross-domain events. Secondly, BMC can provide the running cycle identifier and the clock count value of the monotonic timer in the early stages of startup, which can avoid alignment distortion caused by default time or uncalibrated time; Third, when a critical event occurs, the system first records the event body and the original clock timestamp, and then adds the running cycle identifier and the clock count value of the monotonic timer, which can avoid event loss due to abnormal read-only query interface. Fourth, the management end segments the data according to the operating cycle and sorts it according to the clock count value of the monotonic timer, which can generate cross-domain evidence chains and reduce the reliance on human experience inference.

[0022] It should be understood that different embodiments can achieve one or more of the above-mentioned beneficial effects. Attached Figure Description

[0023] The above and other objects, features, and advantages of exemplary embodiments of this application will become readily understood by reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of this application are illustrated by way of example and not limitation, wherein the same or corresponding reference numerals denote the same or corresponding parts.

[0024] Figure 1 This illustration shows the processing flow of the server cross-domain event timing alignment method provided in an embodiment of this application. Figure 1 ; Figure 2 This illustration shows the processing flow of the server cross-domain event timing alignment method provided in an embodiment of this application. Figure 2 ; Figure 3 This paper illustrates a complete timing flow diagram of the server cross-domain event timing alignment method provided in an embodiment of this application; Figure 4 This illustration shows an application scenario of the server cross-domain event timing alignment method provided in an embodiment of this application. Figure 5 A schematic diagram of the server-side cross-domain event timing alignment device provided in an embodiment of this application is shown. Figure 6 This paper shows a schematic diagram of the structure of the cross-domain event timing alignment device for the management terminal provided in an embodiment of this application; Figure 7 A schematic diagram of the electronic device structure provided in an embodiment of this application is shown. Detailed Implementation

[0025] To make the objectives, features, and advantages of this application more apparent and easily understood, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are all within the protection scope of this application.

[0026] In the following description, the terms "first" and "second" are used only to distinguish different objects and are not used to specify the order. Unless otherwise defined, the technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art.

[0027] In this embodiment, the BMC (Baseboard Management Controller) is used for out-of-band management, sensor acquisition, alarms, and event logging. The BMC has independent processor and storage resources and does not rely on a server operating system. The system may include an operating system, kernel, drivers, and daemons running on the operating system. The runtime cycle identifier may include BMC_BootID; the clock count value of the monotonic timer may include BMC_Tick. The unified timing coordinate is composed of BMC_BootID and BMC_Tick, where BMC_BootID is used to distinguish different runtime cycles, and BMC_Tick is used to characterize the relative order of events within the same runtime cycle.

[0028] Figure 1 This illustration shows the processing flow of the server cross-domain event timing alignment method provided in an embodiment of this application. Figure 1 See Figure 1 The method includes steps S101 to S106.

[0029] In step S101, at the beginning of each running cycle, the baseboard management controller (BMC) of the server generates a running cycle identifier corresponding to the current running cycle, and constructs and maintains a monotonic timer corresponding to the current running cycle. The monotonic timer keeps monotonically increasing within the current running cycle.

[0030] In some embodiments, the server may include a BMC and a system terminal. The operating cycle may include the time period from the BMC's power-on startup or reset to the next power-off or reset. The operating cycle identifier remains unchanged within the current operating cycle, and different operating cycles correspond to different operating cycle identifiers. The operating cycle identifier may be generated based on a random number of preset bits, or based on a combination of a random number and a counter value. The preset bits may include 64 bits, 128 bits, or other bit widths sufficient to distinguish different operating cycles.

[0031] In this embodiment, BMC power-on startup can be either a power-on startup or a reset. Power-on startup refers to starting the BMC from a completely power-off state. Reset refers to restarting the BMC while it is still powered on. The preset bit width can be 64 bits, 128 bits, or other bit widths sufficient to distinguish different operating cycles. The method for generating the operating cycle identifier can include: generating BMC_BootID based on a 64-bit or 128-bit random number; or generating BMC_BootID based on a combination of a random number and a counter value.

[0032] As an example, taking the generation of a 64-bit BMC_BootID as an example, the generation of BMC_BootID based on the combination of a random number and a counter value can include: the first 32 bits include the count value of the startup counter, and the last 32 bits include the random number for this startup. Assume that the server's BMC has been started 104 times before. After this startup, the startup counter value becomes 105, which is hexadecimal 0x00000069. During this startup, a 32-bit random number is generated, for example, 0xA1B2C3D4. Then the BMC_BootID for this startup can be 0x00000069A1B2C3D4 (64 bits in total). Here, 0x00000069 represents that the BMC is starting for the 105th time. 0xA1B2C3D4 is the random number for this startup.

[0033] In some embodiments, the construction and maintenance of the monotonic timer corresponding to the current running cycle in step S101 includes: at the beginning of the current running cycle, constructing the corresponding monotonic timer based on the internal hardware timer of the BMC.

[0034] Specifically, the monotonic timer is built based on the BMC's internal hardware timer. Within the current running cycle, it monotonically increases from the initial value at a preset resolution. The preset resolution can be 1ms, 10ms, or other fixed time units. If the BMC's internal hardware timer natively supports a 64-bit counter, it can be used directly; if the hardware bit width is less than 64 bits, a 64-bit logic timer can be formed through high-bit extension.

[0035] As an example, when the BMC powers on, it retrieves the timer configuration file. The configuration file includes the hardware counter of the BMC's internal timer, which has a bit width of 64 bits and a resolution unit of 1ms. Based on the configuration file, the BMC's internal timer is initialized, configured to free-running counting mode, set to an initial value of 0, and set to a resolution unit of 1ms, resulting in a timer that monotonically increases within the current running cycle.

[0036] If the configuration file includes a hardware counter with a 32-bit width (denoted as LOW) for the timer within the BMC, its value range is from 0 to 4294967295. The BMC firmware maintains a 32-bit high-order variable HI at the software layer. The two are logically concatenated to form a 64-bit monotonic timer. Initially, HI=0 and LOW=0. As the BMC runs, when LOW increments to 4294967295, it will roll back to 0. At this point, the BMC firmware detects that the current reading is less than the previous reading, confirms that rollback has occurred, and then increments HI by 1 to 1. At this time, HI = 1 and LOW = 0. This expands the 32-bit hardware counter into a 64-bit logical timer.

[0037] As an example, during the reading process, HI and LOW may cause splicing errors due to unsynchronized winding. Specifically, suppose under normal circumstances: HI = 0, LOW = 4294967295, and after LOW winds back in the next clock cycle, it becomes: HI = 1, LOW = 0. If the reading time coincides with the winding time, it may be read that: HI = 0, LOW = 0. A splicing error occurs at this time.

[0038] To avoid splicing errors, the BMC firmware uses a double-reading method for consistent reading when reading the clock count value: read HI for the first time and record it as HI1, then read LOW, and finally read HI again and record it as HI2. If HI1 is equal to HI2, it indicates that no winding has occurred during the reading period, and at this time HI and LOW are spliced into the clock count value. If HI1 is not equal to HI2, re-read until HI1 is equal to HI2.

[0039] In some optional embodiments, when the internal hardware counter of the BMC is the low-order counter LOW, the BMC maintains the high-order variable HI at the software layer; when it is detected that LOW is wound, HI is incremented, and a 64-bit logical clock count value is generated based on the combination of HI and LOW. The clock count value of the monotonic timer can be expressed as: (HI<<N)|LOW, where N is the bit width of LOW.

[0040] In some optional embodiments, in order to avoid reading an inconsistent state during the winding process of LOW, a consistent reading manner may be adopted to obtain the clock count value. Specifically, HI may be read once to obtain HI1, then LOW is read, and then HI is read again to obtain HI2; when HI1 and HI2 are the same, the clock count value is generated based on HI and LOW; when HI1 and HI2 are different, the reading is re-executed until HI1 and HI2 are the same.

[0041] In step S102, in response to the BMC detecting a target BMC event, the target BMC event is written into the first log generated by the BMC, and the operation cycle identifier and the clock count value of the monotonic timer are additionally written into the first log.

[0042] In some embodiments, the target BMC event may include hardware events such as voltage abnormality, temperature abnormality, power supply abnormality, and fan abnormality. The first log is a structured log on the BMC side, and the operation cycle identifier and the clock count value of the monotonic timer are written into the first log as cross-domain time sequence alignment fields. As an example, the first log may include {BMC_BootID, BMC_Tick, event type, event content}.

[0043] In some embodiments, the first log may further include a BMC-side original clock timestamp. The BMC-side original clock timestamp is the log time field in the first log, used to characterize the original time information when the BMC records the target BMC event. In the early stages of BMC startup, if the BMC has not yet completed system time initialization or NTP synchronization, the BMC-side original clock timestamp can be empty, a default time, or an uncalibrated time; after the BMC completes system time initialization or NTP synchronization, the target BMC event can carry a valid BMC-side original clock timestamp. The BMC-side original clock timestamp is reserved as an auxiliary display field and is not used as the sorting basis for cross-domain event timing alignment and causal proof.

[0044] Step S103: In response to the system side of the server detecting the target system event, the target system event and the corresponding original clock timestamp are written into the second log generated by the system side; The system side may include the server's operating system. The system side can communicate with the BMC via in-band or out-of-band management channels. The raw clock timestamp is the log time field in the second log, used to characterize the original time information at the time the event was recorded.

[0045] Step S104: Call the read-only query interface provided by BMC to obtain the query results.

[0046] Step S105: If the query result includes at least one of the running cycle identifier and the clock count value of the monotonic timer, the fields included in the query result are appended to the second log.

[0047] In some embodiments, the system calls the BMC's read-only query interface to obtain query results, and adds at least one of the runtime identifier and the clock count value of the monotonic timer included in the query results to the second log.

[0048] In some embodiments, step S104 may include: obtaining a pre-defined event set, the event set including at least one target system event; in response to the system triggering the target system event in the event set, calling a read-only query interface to obtain at least one of the running cycle identifier and the clock count value of the monotonic timer.

[0049] In this embodiment, the system does not read BMC coordinates from all logs, but triggers the reading action when a critical event occurs. Critical events are a set of events with low trigger frequency but high location value, and the event set includes at least one target system event. Target system events may include panic, oops, reboot, watchdog, PCIe AER (PCIe Advanced Error Reporting Storm) events, IO timeouts, hot-limiting, etc.

[0050] In some embodiments, prior to step 104, the method further includes: the BMC providing a read-only query interface to the system, the read-only query interface being used to respond to system calls and return query results. When the query result is successfully obtained, it includes the runtime identifier corresponding to the current runtime, the clock count value of the current monotonic timer, the resolution unit, and a status flag. When the query result fails to obtain the data or a field is missing, it includes at least one of a status flag, an error code, and a missing field identifier. The read-only query interface can be implemented through an in-band driver interface, an IPMI OEM interface, or a Redfish OEM interface.

[0051] In some embodiments, the triggering methods for target system events may include kernel-mode triggering and user-mode triggering. Kernel-mode triggering is for severe faults such as panic, oops, and watchdog timers. It can directly call a read-only query interface in the kernel path and write the query results to the kernel log or persistent area. User-mode triggering is for scenarios where the system can still run normally. It can be achieved by a daemon process calling a read-only query interface and writing to a structured log after detecting a critical event.

[0052] In some embodiments, the method further includes: obtaining retry parameters corresponding to a preset target system event and interface call control parameters corresponding to a read-only query interface; and calling the read-only query interface based on the interface call control parameters to obtain query results. If the read-only query interface call fails, or if the returned query results do not contain at least one of the runtime identifier and the clock count value of the monotonic timer, the system retains the target system event and the original clock timestamp already written in the second log, and writes the error code and missing identifier into the second log to avoid event loss; wherein, the missing identifier is used to characterize the fields not obtained in the runtime identifier and the clock count value of the monotonic timer. At the same time, the system can call the read-only query interface again within a preset number of retries. If the retry is successful before the second log is reported, the system will fill in the missing fields obtained later into the second log before reporting; if the retry is successful after the second log has been reported, the system will generate a supplementary log associated with the second log, the supplementary log including at least the event association identifier and the missing fields obtained later, and send the supplementary log to the management end.

[0053] As an example, determine the retry parameters corresponding to the target system event, such as setting the maximum number of retries to 3; and determine the interface call control parameters for the read-only query interface, such as configuring it to lightweight lock mode. The system acquires a synchronization lock based on the interface call control parameters and calls the read-only query interface. If the query information returned initially does not contain the timer's clock count value, retain the target system event and the original clock timestamp already written in the second log, and write the error code and missing identifier (marking the running cycle identifier and the missing clock count value) to the second log to avoid event loss; Meanwhile, the system will initiate the call again after 100 milliseconds according to the preset number of retries. If the retry is successful before the second log is reported to the management end, the running cycle identifier and clock count value obtained later will be added to the second log and reported completely. If the retry is successful after the second log has been reported, the system will generate a supplementary log containing the event association identifier and the missing fields obtained later, and send the supplementary log to the management end.

[0054] Step S106: Send the first log and the second log to the management terminal to generate the evidence chain corresponding to the server; wherein, the evidence chain includes at least the logs corresponding to the target BMC event and the target system event, which are used to reflect the temporal relationship between the target BMC event and the target system event.

[0055] In some embodiments, the management end may include a log platform, a log aggregation end, or a cloud analytics platform. The chain of evidence includes at least the logs corresponding to the target BMC event and the target system event, reflecting the temporal relationship between them. The chain of evidence can be used for self-verification of the root cause of server failures and for external reporting.

[0056] As an example, after the BMC powers on, it generates a 128-bit random number as the runtime identifier for the current runtime cycle and starts a 64-bit monotonic timer that monotonically increases from 0 with a resolution of 1 millisecond. When the BMC detects a target BMC event, it writes the target BMC event, the runtime identifier, and the clock count value of the monotonic timer to the first log. When the operating system triggers a target system event, such as a PCIe AER storm, it first writes the target system event and its original clock timestamp to the second log, then calls the read-only query interface provided by the BMC to obtain the query result, and appends at least one of the runtime identifier and the clock count value of the monotonic timer included in the query result to the second log. Subsequently, the first and second logs are sent to the management terminal.

[0057] See Figure 2 The method includes steps S201 to S204.

[0058] Step S201: Receive the first log and the second log sent by the server; wherein, the first log is generated by the server's BMC and includes the target BMC event, the running cycle identifier and the clock count value of the monotonic timer; the second log is generated by the server's system side and includes at least one of the running cycle identifier and the clock count value of the monotonic timer, the target system event and the original clock timestamp.

[0059] Step S202: Based on the running cycle identifier in the log, the first log and the second log including the running cycle identifier are segmented and aggregated to obtain the log timeline corresponding to each running cycle; wherein, the first log and the second log with the same running cycle identifier are divided into the same log timeline.

[0060] In some embodiments, the management terminal groups the first and second logs corresponding to the same runtime identifier into the same log timeline, so that the target BMC event and the target system event are at the same timeline coordinate corresponding to the same runtime. Each log timeline corresponds to one runtime. The unified timeline coordinate in the log timeline is determined by the runtime identifier and the clock count value of the monotonic timer.

[0061] As an example, the first log received by the management terminal includes Log 1 and Log 2. Log 1 has a runtime identifier of A and a clock count value of 3, while Log 2 has a runtime identifier of B and a clock count value of 3. The second log received by the management terminal includes Log 3, which has a runtime identifier of A and a clock count value of 1. The management terminal assigns Log 1 and Log 3 to the same log timeline, and assigns Log 2 to a different log timeline, to align events in the BMC domain with events in the system domain to a unified timeline corresponding to the same runtime. This unified timeline can be a cross-domain alignment coordinate system determined by the runtime identifier and the clock count value.

[0062] In some embodiments, when the second log includes a runtime identifier but not the clock count value of the monotonic timer, the management terminal merges the second log into the log timeline of the corresponding runtime and marks it as a time-series pending log. In response to receiving the clock count value corresponding to the time-series pending log, the management terminal sorts the time-series pending log based on the received clock count value. When the second log does not include a runtime identifier, the management terminal determines it as a log to be assigned and does not participate in the segmented aggregation and evidence chain sorting based on the runtime identifier. For the time-series pending log and the log to be assigned, the management terminal can perform auxiliary analysis by combining the original clock timestamp, error code, and missing identifier in the second log and output a manual review prompt; the results of the auxiliary analysis are only for reading reference, problem investigation, or manual judgment and are not used as direct evidence for cross-domain time-series alignment and causal proof.

[0063] As an example, a timing-pending log could be a second log that has been merged into the corresponding runtime log timeline but temporarily lacks a valid clock count value. A log to be assigned to could be a second log that completely lacks a runtime identifier and whose runtime to which it belongs cannot be determined.

[0064] The management terminal receives a second log reported by the system terminal. Although it carries the runtime identifier A, it does not contain the clock count value of the monotonic timer because the interface call failed. Therefore, the management terminal merges the second log into the log timeline corresponding to runtime A and marks it as a timing pending log. After the system terminal reports the missing clock count value through supplementary logs, the management terminal sorts this timing pending log based on the received clock count value.

[0065] When the management system receives a second log entry that does not contain a runtime identifier or a clock count value, it marks this second log entry as a log to be assigned, thus temporarily preventing it from participating in any log timeline sorting and avoiding the mixing of events with unknown assignments into incorrect runtime cycles, which could lead to an incorrect chain of evidence.

[0066] In some embodiments, if a supplementary log associated with the second log is subsequently received, the management terminal associates and merges the supplementary log with the original second log based on the event association identifier, and updates the status of the second log; when the supplementary log includes a running cycle identifier and a clock count value of a monotonic timer, the second log is merged into the log timeline of the corresponding running cycle and participates in strict timing sorting; when the supplementary log only includes a running cycle identifier, the second log is merged into the log timeline of the corresponding running cycle and maintained as a timing pending log.

[0067] Step S203: Based on the clock count value of the monotonic timer, sort the event logs including the clock count value within each log timeline in chronological order to obtain the evidence chain; wherein, the evidence chain includes at least the logs corresponding to the target BMC event and the target system event, and the evidence chain is used to reflect the chronological relationship between the target BMC event and the target system event.

[0068] In some embodiments, step S203 may include: calculating the difference between clock count values ​​corresponding to events to be sorted based on unsigned difference comparison rules; determining the chronological order between target BMC events and target system events within the log timeline based on the difference; and sorting the event logs within each log timeline based on the chronological order to obtain a chain of evidence.

[0069] In some embodiments, within the same operating cycle, the order of events can be determined directly based on the clock count value of the monotonic timer. To accommodate theoretically finite-width rollback scenarios, an unsigned difference comparison rule can also be used: the difference delta = (t2...t3...t4...t5...t6...t7...t8...t9 ... t1); when 0 <delta<2 63 When delta=0, the clock count values ​​of the two events are determined to be the same; otherwise, the event corresponding to t2 is determined to be no later than the event corresponding to t1.

[0070] In some embodiments, if two events have the same clock count value, they can be stably sorted based on log source priority and intra-domain sequence number. If at least one event has no clock count value, the management end performs downgrading processing according to the aforementioned processing method for logs with pending timing or logs awaiting attribution. Log source priority can be a predefined priority where logs from the BMC have a higher priority than logs from the system. Log source priority can also be other predefined priorities, which are not limited in this embodiment. Intra-domain sequence number represents the sequential number assigned to the event within the BMC or system; the auxiliary analysis results generated by downgrading processing are not used as direct evidence for cross-domain timing alignment and causal proof.

[0071] As an example, the first log timeline includes log 1, log 2, and log 3. The management end first calculates the difference in clock count values ​​based on the unsigned difference comparison rule and sorts log 3 first. If the clock count values ​​of log 1 and log 2 are the same, and log 1 is the first log and log 2 is the second log, based on the log source priority, i.e., the set BMC priority is higher than the system end, log 1 is sorted before log 2, thus obtaining the evidence chain of log 3, log 1, and log 2, so as to perform stable sorting of cross-domain events when the clock count values ​​are the same or missing.

[0072] If both Log 1 and Log 2 are first logs and have the same clock count, then the order of Log 1 and Log 2 is determined based on their domain sequence numbers. Log 1 has a domain sequence number of 1, and Log 2 has a domain sequence number of 2. Therefore, Log 1 is placed before Log 2, resulting in a chain of evidence consisting of Log 3, Log 1, and Log 2. This ensures stable ordering of cross-domain events when clock counts are the same or missing.

[0073] As an example, the management terminal receives a first log and a second log sent by the server. If the runtime identifier of the first log is the same as that of the second log, the clock count value of the first log is 1, corresponding to a BMC hardware error; the clock count value of the second log is 2, corresponding to a PCIe error. The management terminal divides the two logs into the same log timeline and determines that the BMC hardware error occurred before the PCIe error based on the clock count value of the monotonic timer, thereby generating an evidence chain reflecting the timing relationship between the two.

[0074] Step S204: Output the chain of evidence.

[0075] In some embodiments, the method further includes adding the original clock timestamps corresponding to each event to the evidence chain as auxiliary display fields. The original clock timestamps are only used to display the original time information in each event log and are not used as the sorting basis for cross-domain time alignment and causal proof.

[0076] As an example, when the management end outputs the evidence chain, it can extract the original clock timestamps corresponding to each event from the first and second logs. For example, event 1 corresponds to 2026-04-10 11:28:00, and event 2 corresponds to 2026-04-10 11:28:05. These original clock timestamps are added as auxiliary fields to events 1 and 2 included in the evidence chain. Finally, the evidence chain is output in a visual format, while the original clock timestamps are only used for reading assistance.

[0077] In some optional embodiments, the management terminal can also receive logs from multiple servers in the rack, and based on the generated evidence chains corresponding to each server, further align the evidence chains corresponding to multiple servers based on node coordinates or rack controller reference time to form a rack-level evidence chain, and output the rack-level evidence chain.

[0078] See Figure 3 , Figure 3 This paper illustrates the complete timing flow of the server cross-domain event timing alignment method provided in an embodiment of this application. In this embodiment, the BMC, system end, and management end collaboratively complete the recording, transmission, aggregation, and sorting of cross-domain events according to a unified timing coordinate. The method may include the following steps: Step S301: The BMC side generates the Boot ID, which corresponds to the current running cycle.

[0079] Step S302: The BMC side constructs and maintains the monotonic timer Tick corresponding to the current running cycle.

[0080] In step S303, in response to the target system event trigger, the system writes the target system event and the corresponding original clock timestamp into the second log generated by the system; wherein, the original clock timestamp is the log time field in the second log, which is used to characterize the original time information when the event is recorded.

[0081] In step S304, the system calls the read-only query interface provided by the BMC side to obtain the query results.

[0082] In step S305, the BMC side responds to the call of the read-only query interface and returns the query result to the system side; wherein, when the query result is successfully obtained, it includes at least one of the boot ID and the clock count value (Tick) of the monotonic timer, and when the acquisition fails or the field is missing, it includes an error code and a missing identifier.

[0083] Step S306: The system updates the second log based on the query results; when the query results include at least one of the running cycle identifier and the clock count value of the monotonic timer, the fields included in the query results are appended to the second log; when the query results lack the running cycle identifier or the clock count value of the monotonic timer, the error code and missing identifier are written to the second log.

[0084] In step S307, when the BMC side detects a target BMC event, it writes the target BMC event into the first log generated by the BMC, and appends the running cycle identifier corresponding to the current running cycle and the clock count value of the monotonic timer to the first log; the first log may also include the original clock timestamp of the BMC side.

[0085] Step S308: The BMC sends the first log to the management terminal.

[0086] Step S309: The system sends the second log to the management terminal.

[0087] In step S310, the management terminal performs segmented aggregation on the first log and the second log based on the running cycle identifier to obtain the log timeline corresponding to each running cycle.

[0088] Step S311: Based on the clock count value of the monotonic timer, the management terminal sorts the event logs with the clock count value in each log timeline in chronological order to generate a chain of evidence.

[0089] Step S312: The management terminal outputs the evidence chain.

[0090] In some embodiments, if the system continues to call the read-only query interface based on preset retry parameters after step S306, and obtains at least one of the running cycle identifier and the clock count value of the monotonic timer before the second log is reported, the system will fill the subsequently obtained fields into the second log before reporting it; if the retry is successful after the second log has been reported, the system will generate a supplementary log associated with the second log and send the supplementary log to the management terminal. The supplementary log includes at least the event association identifier and the subsequently obtained fields.

[0091] The method in this application embodiment provides clock count values ​​through a monotonic timer maintained by the BMC. When a critical event occurs, the system reads the clock coordinates corresponding to the clock count value and writes them to a second log. This ensures that the alignment and sorting of cross-domain events are based on a monotonically increasing clock count value, accurately determining the order of cross-domain events without being affected by clock time jumps or abrupt changes caused by Network Time Protocol (NTP) or Chrony synchronization, thus avoiding timing distortion within the synchronization transition window. At the beginning of each runtime cycle, the BMC generates a session identifier and constructs a timer. Early in the BMC startup process, it provides the system with the clock coordinates corresponding to the current runtime cycle through a read-only query interface, preventing alignment failures caused by the system using default or incorrect clock times. The BMC only needs to provide a read-only query interface and event-attached coordinate fields, and the system only needs to deploy a lightweight critical event tracker to achieve coordinate acquisition and log recording. This requires no large-scale modification of the existing log architecture, making the project feasible and having minimal impact on system performance. The management system aggregates the first and second logs based on session identifiers and generates an evidence chain by monotonically sorting the timer counts. A unified clock coordinate directly provides a strict chronological order for cross-domain events such as BMC events and system events, allowing for the reconstruction of the fault causal chain without empirical inference. The difference in clock counts is calculated using unsigned difference comparison rules to determine the event sequence, eliminating the need for post-event conversion to sort cross-domain events. When clock counts are identical or missing, sorting is based on log source priority and intra-domain sequence number, ensuring a stable and reproducible evidence chain output. The original clock timestamp is added as an auxiliary field to the evidence chain to assist users with time reference. It also supports marking credibility levels for runtime cycles with excessively high clock count missing rates, improving the user experience.

[0092] See Figure 4 , Figure 4This paper illustrates an application scenario of the server cross-domain event timing alignment method provided in this application embodiment. In this application scenario, the system may include a BMC (Browser Management Console), a system, and a management / logging platform. The BMC and system generate corresponding event logs and report them to the management / logging platform. The management / logging platform performs segmented aggregation and timing sorting of event logs from different domains based on the runtime identifier and the clock count value of the monotonic timer to generate an evidence chain timeline.

[0093] In this application scenario, the BMC (Boot Controller) generates the Boot ID corresponding to the current running cycle and maintains the Tick (Monotone Timer) for the current running cycle. When the BMC detects a target BMC event, it writes the target BMC event, the Boot ID, and the Tick to the first log and reports the first log to the management terminal / log platform. In some embodiments, the first log may also include the original clock timestamp on the BMC side; in the early stages of BMC startup, if the BMC has not yet completed system time initialization or NTP time synchronization, the original timestamp on the BMC side can be empty, a default time, or an uncalibrated time. The original timestamp is the original clock timestamp mentioned above. Therefore, the original clock timestamp on the BMC side is only used as an auxiliary display field and is not used as the sorting basis for cross-domain event timing alignment and causal proof.

[0094] The system-side is used to detect critical system events and record these events along with their corresponding original timestamps. Critical system events are the target system events mentioned above, which can include panic, oops, reboot, watchdog timer, PCIe AER (PCIe Advanced Error Reporting Storm) events, IO timeouts, and hot-limiting events. After recording a critical system event, the system-side calls the read-only query interface provided by the BMC (Boot Controller Center) to obtain at least one of the Boot ID and Tick timer corresponding to the current runtime cycle, and appends the fields included in the query result to the second log. If the read-only query interface call fails, or the query result lacks the Boot ID or Tick, the system-side writes an error code and a missing field identifier to the second log and reports the second log to the management / log platform; the missing field identifier is used to indicate the missing field in the query result.

[0095] The management / log platform receives the first and second logs, and aggregates them in segments based on the Boot ID to obtain the log timeline corresponding to each running cycle. The management / log platform also sorts the event logs with ticks within the same log timeline in chronological order, generating and outputting an evidence chain timeline. For second logs that include a Boot ID but lack a tick, the management / log platform can mark them as logs with pending timeline determination; for second logs lacking a Boot ID, the management / log platform can mark them as logs awaiting attribution, and perform auxiliary analysis or manual review according to the degradation processing method described in the aforementioned embodiments.

[0096] In some embodiments, the read-only query interface provided by the BMC to the system can be implemented through an in-band driver interface, an IPMI OEM interface, or a Redfish OEM interface. Figure 4 The application scenarios shown are merely examples. The embodiments of this application do not limit the specific deployment forms of the BMC end, system end, and management end / log platform. As long as cross-domain timing alignment of BMC events and system end events can be achieved based on the running cycle identifier and monotonic timer, it falls within the scope of implementation of this application.

[0097] See Figure 5 This application also provides a server-side cross-domain event timing alignment device 50, applied to a server. The server-side cross-domain event timing alignment device 50 may include: an identification and timing maintenance module 501, a BMC event log generation module 502, a system event log generation module 503, and a log sending module 504.

[0098] The identification and timing maintenance module 501 is used to generate the operating cycle identifier corresponding to the current operating cycle at the beginning of each operating cycle of the BMC, and to build and maintain the monotonic timer corresponding to the current operating cycle.

[0099] The BMC event log generation module 502 is used to generate a first log when the BMC detects a target BMC event. The first log includes the target BMC event, the runtime identifier, and the clock count value of the monotonic timer, and may include the original clock timestamp from the BMC side.

[0100] The system event log generation module 503 is used to generate a second log when a target system event is detected on the server's system side. The second log includes the target system event and the original clock timestamp, and is used to append at least one of the runtime identifier and the clock count value of the monotonic timer obtained through a read-only query interface. If the read-only query interface call fails, or if the returned result does not contain at least one of the runtime identifier and the clock count value of the monotonic timer, the system event log generation module 503 is also used to write an error code and a missing identifier to the second log; if a subsequent retry is successful, the system event log generation module 503 is also used to add subsequently obtained fields to the second log, or generate a supplementary log associated with the second log.

[0101] The log sending module 504 is used to send the first log and the second log to the management terminal; when a supplementary log is generated, it is also used to send the supplementary log to the management terminal.

[0102] See Figure 6 This application also provides a management-end cross-domain event timing alignment device 60, applied to a management end. The management-end cross-domain event timing alignment device 60 may include: a log receiving module 601, a segmentation aggregation module 602, an evidence chain sorting module 603, and an evidence chain output module 604.

[0103] The log receiving module 601 is used to receive the first log and the second log sent by the server; it is also used to receive the supplementary log associated with the second log.

[0104] The segmentation aggregation module 602 is used to segment and aggregate the first log and the second log based on the running cycle identifier to obtain the log timeline corresponding to each running cycle; it is also used to mark the second log as a timing-pending log when the second log includes the running cycle identifier but does not include the clock count value of the monotonic timer; and to mark the second log as a log to be assigned when the second log does not include the running cycle identifier. In some embodiments, when the log receiving module 601 receives supplementary logs, the segmentation aggregation module 602 is further used to associate and merge the supplementary logs with the corresponding second logs based on the event association identifier, and update the assignment status or sorting status of the corresponding second logs.

[0105] The evidence chain sorting module 603 is used to sort the event logs with the clock count value within each log timeline based on the clock count value of the monotonic timer to generate an evidence chain; it is also used to perform stable sorting based on log source priority and domain sequence number when the clock count values ​​of two event logs are the same.

[0106] The evidence chain output module 604 is used to output the evidence chain timeline sorted according to a unified temporal coordinate system; it is also used to output auxiliary analysis information or manual review prompts for logs with pending timelines and logs to be assigned. The auxiliary analysis information is not used as direct evidence for cross-domain temporal alignment or causal proof.

[0107] It should be noted that the server-side cross-domain event timing alignment device 50 and the management-side cross-domain event timing alignment device 60 provided in this application embodiment belong to the same inventive concept as the aforementioned method embodiment. Their implementation principles and technical effects can be found in the relevant descriptions in the aforementioned method embodiments, and will not be repeated here. For technical details not described in detail in the embodiments of this application, please refer to... Figures 1 to 4 Understand the methods, processes, and application scenarios shown.

[0108] In some embodiments, the modules in the above-described apparatus can be implemented by software, hardware, or a combination of both. The modules can be integrated or deployed separately in the BMC, system, or management terminal according to their actual functions.

[0109] According to embodiments of this application, this application also provides an electronic device and a non-transitory computer-readable storage medium.

[0110] Figure 7 A schematic block diagram of an electronic device 700 that can be used to implement the embodiments of this application is shown. The electronic device 700 can be a server, a management device, a log platform device, a log aggregation device, or other computing devices suitable for performing the methods described in the embodiments of this application. Figure 7 The components, connections, and functions shown are merely examples and are not intended to limit the implementation of this application.

[0111] like Figure 7 As shown, the electronic device 700 includes a computing unit 701. The computing unit 701 can perform corresponding actions and processes based on a computer program stored in the read-only memory (ROM) 702, or a computer program loaded from the storage unit 708 into the random access memory (RAM) 703. The RAM 703 can also store programs and data required for the operation of the electronic device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704, and an input / output interface 705 is also connected to the bus 704.

[0112] Multiple components in electronic device 700 are connected to input / output interface 705, including input unit 706, output unit 707, storage unit 708, and communication unit 709. Input unit 706 may include a keyboard, mouse, etc.; output unit 707 may include a display, speaker, etc.; storage unit 708 may include a disk, optical disk, solid-state drive, etc.; communication unit 709 may include a network card, modem, wireless communication transceiver module, etc. Communication unit 709 enables electronic device 700 to exchange information or data with other devices through computer networks or other communication networks.

[0113] The computing unit 701 can be a general-purpose processing component or a dedicated processing component with processing capabilities. As an example, the computing unit 701 may include a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a controller, a microcontroller, or other suitable processing devices. The computing unit 701 can execute the server cross-domain event timing alignment method described in any of the above embodiments.

[0114] In some embodiments, the above method can be implemented as a computer program tangibly contained in a machine-readable medium, such as storage unit 708. Part or all of the computer program can be loaded into electronic device 700 via ROM 702, storage unit 708, or communication unit 709. When the computer program is loaded into RAM 703 and executed by computing unit 701, one or more steps of the method described in any of the above embodiments can be performed. In other embodiments, computing unit 701 can also be configured by firmware or other suitable means to perform the method described in any of the above embodiments.

[0115] This application also provides a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium stores computer instructions, which, when executed by a processor, cause the processor to perform the server cross-domain event timing alignment method described in any of the above embodiments.

[0116] In some embodiments, the non-transitory computer-readable storage medium may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. As an example, the non-transitory computer-readable storage medium may include a read-only memory, a random access memory, flash memory, a hard disk, a solid-state drive, an optical disk, a magnetic disk, or other media capable of storing program instructions.

[0117] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for aligning the timing of cross-domain events on a server, characterized in that, Applied to a server, the method includes: At the beginning of each operating cycle, the server's Baseboard Management Controller (BMC) generates an operating cycle identifier corresponding to the current operating cycle and constructs and maintains a monotonic timer corresponding to the current operating cycle. The monotonic timer remains monotonically increasing within the current operating cycle. In response to the BMC detecting a target BMC event, the target BMC event is written to the first log generated by the BMC, and the running cycle identifier and the clock count value of the monotonic timer are appended to the first log. In response to the system side of the server detecting a target system event, the target system event and the corresponding original clock timestamp are written into the second log generated by the system side; Call the read-only query interface provided by BMC to obtain the query results; If the query result includes at least one of the running cycle identifier and the clock count value of the monotonic timer, the fields included in the query result are appended to the second log. The first log and the second log are sent to the management terminal to generate an evidence chain corresponding to the server; wherein, the evidence chain includes at least the logs corresponding to the target BMC event and the target system event, which are used to reflect the temporal relationship between the target BMC event and the target system event.

2. The method according to claim 1, characterized in that, The step of generating the runtime identifier corresponding to the current runtime includes: In response to the power-on or reset of the BMC, the operating cycle identifier is generated using any of the following methods: The running cycle identifier is generated based on a random number of preset digits; or, The running cycle identifier is generated based on a combination of a random number with a preset number of bits and a counter value; The operation cycle identifier remains unchanged within the current operation cycle, and different operation cycles correspond to different operation cycle identifiers.

3. The method according to claim 1, characterized in that, The construction and maintenance of the monotonic timer corresponding to the current running cycle includes: At the start of the current running cycle, a corresponding monotonic timer is constructed based on the internal hardware timer of the BMC; The monotonic timer increments from a set initial value according to a preset resolution, where the preset resolution is a preset fixed time unit; The monotonic timer increases monotonically within the current running cycle to represent the chronological order of events within the current running cycle.

4. The method according to claim 1, characterized in that, Before calling the read-only query interface provided by BMC, the method also includes: The BMC provides a read-only query interface to the system, wherein the read-only query interface is used to respond to the system's call and return the query result; When the query result is successfully obtained, it includes the running cycle identifier, the current clock count value of the monotonic timer, the resolution unit, and the status flag. The query results, when they fail to be retrieved or a field is missing, include at least one of the following: status flag, error code, and missing field identifier.

5. The method according to claim 4, characterized in that, The step of calling the read-only query interface provided by BMC to obtain query results includes: Obtain a pre-defined set of events, wherein the set of events includes at least one target system event; In response to the system triggering a target system event in the event set, the read-only query interface is invoked to obtain at least one of the running cycle identifier and the clock count value of the monotonic timer.

6. The method according to claim 5, characterized in that, The method further includes: Obtain the pre-defined retry parameters corresponding to the target system event and the interface call control parameters corresponding to the read-only query interface; Based on the interface call control parameters, the read-only query interface is called to obtain the query results; In response to the query result lacking at least one of the runtime identifier and the clock count value of the monotonic timer, the target system event and original clock timestamp already written in the second log are retained, and the error code and missing identifier are written to the second log; wherein, the missing identifier is used to characterize the field missing in the query result; Based on the retry parameters, the read-only query interface is called again within a limited number of times; If a missing field is obtained before the second log is reported, the subsequently obtained fields will be written into the second log. If a missing field is obtained after the second log is reported, a supplementary log associated with the second log is generated and the supplementary log is sent to the management terminal.

7. A method for aligning the timing of cross-domain events on a server, characterized in that, Applied to the management end, the method includes: The server receives a first log and a second log; wherein the first log is generated by the server's BMC and includes a target BMC event, a runtime identifier, and a clock count value of a monotonic timer; the second log is generated by the server's system and includes at least one of a runtime identifier and a clock count value of a monotonic timer, a target system event, and an original clock timestamp. Based on the runtime identifier in the log, the first log and the second log including the runtime identifier are segmented and aggregated to obtain the log timeline corresponding to each runtime; wherein, the first log and the second log with the same runtime identifier are divided into the same log timeline. Based on the clock count value of the monotonic timer, the event logs including the clock count value within each log timeline are sorted in chronological order to obtain an evidence chain; wherein, the evidence chain includes at least the logs corresponding to the target BMC event and the target system event, and the evidence chain is used to reflect the chronological relationship between the target BMC event and the target system event; Output the chain of evidence.

8. The method according to claim 7, characterized in that, The step of segmenting and aggregating the first log and the second log including the runtime identifier based on the runtime identifier in the log includes: The first and second logs corresponding to the same running cycle identifier are divided into the same log timeline, so that the target BMC event and the target system event are in the same time coordinate corresponding to the same running cycle; Each log timeline corresponds to a running cycle, and the unified timeline coordinates in the log timeline are jointly determined by the running cycle identifier and the clock count value of the monotonic timer.

9. The method according to claim 7, characterized in that, The step of sequentially sorting the event logs, including the clock count value, within each log timeline includes: Based on the unsigned difference comparison rule, calculate the difference between the clock count values ​​corresponding to the events to be sorted; Based on the difference, the chronological order between the target BMC event and the target system event within the log timeline is determined; Based on the aforementioned chronological order, the event logs within each log timeline are sorted to obtain a chain of evidence.

10. The method according to claim 7, characterized in that, The method further includes: When two events have the same clock count, the logs corresponding to the two events are sorted based on log source priority and domain sequence number. When the second log includes a running cycle identifier but does not include the clock count value of the monotonic timer, the second log is merged into the log timeline of the corresponding running cycle and marked as a timing pending log; in response to receiving the clock count value corresponding to the timing pending log, the timing pending log is sorted based on the received clock count value; When the second log does not include a runtime identifier, the second log is marked as a log to be assigned, and the log to be assigned is not included in the sorting within the log timeline.

11. The method according to claim 7, characterized in that, The method further includes: Add the original clock timestamps corresponding to each event to the evidence chain; The original clock timestamp is used to represent the original time information in the log corresponding to the event and serves as an auxiliary display field.

12. A server cross-domain event timing alignment device, characterized in that, Applied to a server, the device includes: The identification and timing maintenance module is used to generate a running cycle identifier corresponding to the current running cycle at the beginning of each running cycle, and to build and maintain a monotonic timer corresponding to the current running cycle, wherein the monotonic timer keeps monotonically increasing within the current running cycle; The BMC event log generation module is used to respond to the BMC detecting a target BMC event, write the target BMC event into the first log generated by the BMC, and append the running cycle identifier corresponding to the current running cycle and the clock count value of the monotonic timer to the first log. The system event log generation module is used to respond to the system side of the server detecting a target system event, write the target system event and the corresponding original clock timestamp into the second log generated by the system side; call the read-only query interface provided by BMC to obtain query results; if the query results include at least one of the running cycle identifier corresponding to the current running cycle and the clock count value of the monotonic timer, append the fields included in the query results to the second log. The log sending module is used to send the first log and the second log to the management terminal to generate an evidence chain corresponding to the server; wherein, the evidence chain includes at least the logs corresponding to the target BMC event and the target system event, which are used to reflect the temporal relationship between the target BMC event and the target system event.

13. A server cross-domain event timing alignment device, characterized in that, The device, used in the management terminal, includes: The log receiving module is used to receive a first log and a second log sent by the server; wherein, the first log is generated by the BMC of the server and includes a target BMC event, a running cycle identifier and a clock count value of a monotonic timer; the second log is generated by the system side of the server and includes at least one of a running cycle identifier and a clock count value of a monotonic timer, a target system event and an original clock timestamp. The segmentation and aggregation module is used to segment and aggregate the first log and the second log including the running cycle identifier based on the running cycle identifier in the log, so as to obtain the log timeline corresponding to each running cycle; wherein, the first log and the second log with the same running cycle identifier are divided into the same log timeline. The evidence chain sorting module is used to sort the event logs, including the clock count value, within each log timeline based on the clock count value of the monotonic timer to obtain an evidence chain; wherein, the evidence chain includes at least the logs corresponding to the target BMC event and the target system event, and the evidence chain is used to reflect the temporal relationship between the target BMC event and the target system event; The evidence chain output module is used to output the evidence chain.

14. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to perform the method according to any one of claims 1-11.

15. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, When the computer instructions are executed by the computer, the computer performs the method according to any one of claims 1-11.

Images