A method, device, medium, and product for visualizing server status.

Abstract

This application discloses a server status visualization method, device, medium, and product, relating to the field of page rendering. The method includes: a browser client using a data processing module pre-compiled into a binary instruction format to acquire and decode binary incremental data from each server node in a server cluster; then, writing the decoded data from each server node into a preset shared memory. Since the binary format can represent data more compactly and has less data redundancy, combined with transmitting only incremental data, the number of bytes occupied can be greatly reduced, lowering the required transmission bandwidth and memory usage. Subsequently, based on a preset address mapping relationship, the data in the preset shared memory is directly mapped to a preset target cache, enabling the browser client to directly access the target application programming interface of the graphics processor. This allows for timely page rendering using the data in the preset target cache, skipping other intermediate processing layers and improving the speed of browser page rendering.

Description

Technical Field

[0001] This application relates to the field of page rendering, and more particularly to a method, device, medium, and product for visualizing server status. Background Technology

[0002] With the development of the times, monitoring and visualization of large-scale server clusters has gradually become a core technology area for cloud computing and data center operation and maintenance. As digital transformation accelerates, the scale of server nodes in server clusters has also increased from thousands to millions, and correspondingly, the amount of monitoring data has also grown exponentially.

[0003] In related technologies, monitoring and visualization of server clusters typically employs full JSON (JavaScript Object Notation, a lightweight data exchange format) transmission and Canvas (used for drawing graphics on web pages) batch rendering. Specifically, the data transmission layer transmits monitoring data for the server cluster in full JSON format, while the front-end rendering layer parses the JSON using JavaScript (JS, a high-level, interpreted programming language) and creates a DOM (Document Object Model) object tree. Then, it calls the Canvas API (Application Programming Interface) to fully redraw the status of all server nodes.

[0004] However, due to the high redundancy of the JSON text protocol, tens of thousands of nodes consume a lot of bandwidth per second. Moreover, the full DOM construction requires the creation of tens of thousands of JS objects for tens of thousands of nodes, resulting in large memory consumption and long processing time, which can easily lead to high rendering latency. Summary of the Invention

[0005] This application provides a server status visualization method, device, medium, and product to at least solve the problems of high transmission bandwidth, large memory consumption, and high rendering latency in related technologies.

[0006] This application provides a server status visualization method, applied to a browser client, including:

[0007] The target incremental encoded data of each server node in the server cluster is obtained through the locally running data processing module. The data processing module is a data processing module pre-compiled into binary instruction format. The target incremental encoded data is the data obtained after encoding the target incremental data into binary format. The target incremental data includes the change in the state index of the server node between any two different states.

[0008] The data processing module decodes the target incremental encoded data and writes the decoded data from each server node into a preset shared memory.

[0009] Based on a preset address mapping relationship, the decoded data of each server node is mapped from a preset shared memory to a preset target cache; the preset target cache is a cache pre-configured for the target application programming interface of the browser client, and the target application programming interface is an interface used to provide users with direct access to the graphics processor.

[0010] The target application programming interface is used to render the page based on the decoded data of each server node in the preset target cache, so as to display the corresponding status of the server cluster on the visualization page.

[0011] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described server status visualization methods when executing the computer program.

[0012] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described server status visualization methods.

[0013] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described server status visualization methods.

[0014] This application encodes incremental data from each server node in a server cluster into binary format and transmits it. The browser client then uses a data processing module pre-compiled into binary instruction format to decode and store the binary incremental data. Since binary format represents data more compactly and has less redundancy than JSON format, it significantly reduces the number of bytes required. Combined with the fact that this application only transmits incremental data from server nodes, it greatly reduces the required transmission bandwidth and memory usage. Furthermore, based on the address mapping relationship between preset shared memory and preset target cache, this application can directly map data in preset shared memory to preset target cache, skipping other intermediate processing layers. This allows data in preset shared memory to directly reach preset target cache, enabling the browser client to directly access the target application programming interface of the graphics processor and promptly utilize the data in preset target cache for page rendering. Therefore, using address mapping to directly map data to preset target cache requires fewer resources and avoids the latency issues of other intermediate processing layers in related technologies, thus improving the speed of browser page rendering. Attached Figure Description

[0015] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart of a server status visualization method provided in this application embodiment;

[0017] Figure 2 A flowchart illustrating the decoding process of incrementally encoded data provided in this application embodiment;

[0018] Figure 3 A schematic diagram of a preset binary incremental stream protocol provided in an embodiment of this application;

[0019] Figure 4 This is a flowchart illustrating a server status indicator prediction and display process provided in an embodiment of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0021] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0022] In related technologies, server cluster monitoring and visualization typically employs full JSON transmission and batch rendering using Canvas. However, due to the high redundancy of the JSON text protocol, tens of thousands of nodes consume a significant amount of bandwidth per second. Furthermore, full DOM construction requires the creation of tens of thousands of JS objects for tens of thousands of nodes, resulting in high memory consumption and long processing times, easily leading to high rendering latency. Therefore, this application provides a server status visualization method that can at least solve the problems of high transmission bandwidth, high memory consumption, and high rendering latency in related technologies.

[0023] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0024] Embodiments of this application provide a server status visualization method, applied to a browser client, combined with... Figure 1 The execution flow shown provides a detailed description of the method of this application.

[0025] Step S11: Obtain the target incremental encoded data of each server node in the server cluster through the locally running data processing module; the data processing module is a data processing module pre-compiled into binary instruction format; the target incremental encoded data is the data obtained after encoding the target incremental data into binary format; the target incremental data includes the change in the state index of the server node between any two different states.

[0026] In this embodiment, the monitoring data source monitors each server node in the server cluster to obtain the target incremental data of each server node. Then, using a preset binary incremental stream protocol, the target incremental data of each server node is encoded into binary format to obtain the target incremental encoded data of each server node. The target incremental encoded data of each server node is then transmitted to the data processing module in the browser client. Correspondingly, the browser client obtains the target incremental encoded data of each server node sent by the monitoring data source through the locally running data processing module.

[0027] It should be noted that the target incremental data of the server node includes, but is not limited to, the change in the status indicators of the server node between any two different states; wherein, any two different states include the current state and the previous state, and the status indicators include, but are not limited to, CPU (Central Processing Unit) utilization and memory usage. Accordingly, the change in the status indicator can be zero, indicating that the status indicator of the current state and the previous state has not changed, or it can be non-zero, indicating that the status indicator of the current state and the previous state has changed, such as +1%, -5%, etc.

[0028] Among them, the core idea of ​​the pre-defined Binary Incremental Streaming Protocol (BISP) is to encode incremental data, thereby converting incremental data into a more compact binary format, avoiding the high overhead problems of JSON text protocol and XML (Extensible Markup Language) text protocol.

[0029] Furthermore, the data processing module in the browser client is a pre-compiled data processing module in binary instruction format. Specifically, this application embodiment uses WebAssembly (a web-oriented binary format) to provide an efficient compilation target for low-level source languages ​​such as C and C++. That is, this application embodiment uses WebAssembly to compile data processing modules written in languages ​​such as C or C++, so that the compiled data processing modules can run better on the web platform while ensuring security and near-native application running speed.

[0030] Step S12: The target incremental encoded data is decoded by the data processing module, and the decoded data of each server node is written into the preset shared memory.

[0031] In this embodiment, the browser client decodes the target incremental encoded data of each server node using a locally running data processing module to obtain the decoded data of each server node, and then writes the decoded data of each server node into a preset shared memory. The preset shared memory is memory pre-configured for the data processing module.

[0032] To ensure the correctness of the changes in state indicators in the target incremental data, this application embodiment further adds a data check code for the changes in state indicators to the target incremental data. That is, the target incremental data of the server node also includes a data check code corresponding to the changes in state indicators of the server node between any two different states.

[0033] It should be noted that data check codes include, but are not limited to, Cyclic Redundancy Check (CRC), parity check codes, Hamming codes, etc., and the specific code can be selected and used according to the user's actual needs.

[0034] When the target incremental data of the server node also includes a data checksum corresponding to the change in the state index of the server node between any two different states, the data processing module decodes the target incremental encoded data. Specifically, this includes: decoding the target incremental encoded data to obtain the change in the state index of the server node between any two different states and the corresponding data checksum; verifying the data checksum to determine whether to discard the target incremental encoded data of the server node based on the verification result; if the target incremental encoded data of the server node is not discarded, determining the actual state index of the server node in the current state based on the change in the state index of the server node between any two different states; wherein, any two different states include the current state and the previous state; and determining the decoded data of the server node based on the actual state index of the server node in the current state.

[0035] In one specific example, when determining the actual state index of a server node based on the change in its state index between any two different states, the actual state index can be determined based on the change in the server node's state index between any two different states and the server node's previous actual state index. Here, the actual state index of the server node in its initial state is a preset baseline state index, and this preset baseline state index is located within the server node's target incremental data.

[0036] Furthermore, in order to ensure the continuity of the timestamps corresponding to the server node in multiple consecutive states, this embodiment of the application also adds the time change between the first timestamp and the second timestamp to the target incremental data, wherein the first timestamp is the timestamp corresponding to the server node in the current state, and the second timestamp is the timestamp corresponding to the server node in the previous state.

[0037] Correspondingly, when the target incremental data of the server node also includes the time change between the first and second timestamps, the data processing module verifies the data checksum to determine whether to discard the target incremental encoded data of the server node based on the verification result. If the target incremental encoded data of the server node is not discarded, the first timestamp is determined based on the second timestamp and the time change decoded from the target incremental encoded data. At this time, the first timestamp is an absolute time. Finally, based on the actual status index of the server node and the first timestamp, the decoded data of the server node is determined.

[0038] Specifically, such as Figure 2As shown, the browser client decodes the target incremental encoded data of the server node through a locally running data processing module to obtain the time change between the first timestamp corresponding to the server node in the current state and the second timestamp corresponding to the previous state, the change in the state index of the server node between the current state and the previous state, and the corresponding data checksum. The data checksum is then verified to obtain the verification result. If the verification result indicates a failure, the target incremental encoded data of the server node is discarded. If the verification result indicates a successful verification, the target incremental encoded data of the server node is not discarded. The time change is added to the second timestamp corresponding to the server node in the previous state to determine the first timestamp corresponding to the server node in the current state. The change in the state index is added to the server node's previous actual state index to determine the server node's current actual state index. Finally, based on the first timestamp corresponding to the server node in the current state and the server node's current actual state index, the decoded data of the server node is determined.

[0039] Step S13: Based on the preset address mapping relationship, map the decoded data of each server node from the preset shared memory to the preset target cache; the preset target cache is a cache pre-configured for the target application programming interface of the browser client, and the target application programming interface is an interface used to provide users with direct access to the graphics processor.

[0040] In this embodiment, after the data processing module writes the decoded data of each server node into the preset shared memory, since an address mapping relationship is pre-established between the preset shared memory and the preset target cache, the decoded data of each server node can be directly mapped from the preset shared memory to the preset target cache based on the preset address mapping relationship. This skips the processing of other intermediate layers, such as the JS layer, avoids the problem of processing delays in other intermediate layers, improves the efficiency of data transmission, realizes zero-copy data transmission, and facilitates subsequent improvement of the browser page rendering speed.

[0041] It should be noted that the preset target cache is a cache pre-configured for the target application programming interface of the browser client, and the target application programming interface is an interface used to provide users with direct access to the functions of the graphics processing unit (GPU), such as WebGPU.

[0042] Specifically, the creation of preset shared memory can include: during the initialization of the data processing module, creating a preset shared memory with contiguous addresses for the data processing module based on the preset memory size, and enabling the sharing flag of the preset shared memory.

[0043] The creation of a preset target cache may specifically include: creating a preset target cache based on a preset cache size; and mapping the preset target cache to a preset shared memory according to the sharing flag of the preset shared memory, so that the data in the preset shared memory can be directly mapped to the preset target cache.

[0044] Specifically, a preset target cache is created for the target application programming interface based on a preset cache size, and the usage of the preset target cache is specified. For example, the preset target cache is used to store data and as a copy target to receive copied data. Then, according to the sharing flag of the preset shared memory, the preset target cache is mapped to the preset shared memory so that the data in the preset shared memory can be directly mapped to the preset target cache, realizing physical address pass-through between the preset shared memory and the preset target cache, which greatly improves the efficiency of data transmission.

[0045] Step S14: Utilize the target application programming interface and render the page based on the decoded data of each server node in the preset target cache to display the corresponding status of the server cluster on the visualization page.

[0046] In this embodiment, the browser client uses the target application programming interface to obtain the decoded data of each server node from the preset target cache, and calls the shader in the graphics processor to render the visualization page based on the decoded data of each server node, so as to display the corresponding status of the server cluster on the visualization page.

[0047] Furthermore, since the frame rate of the graphics processor affects the rendering accuracy and display effect of the image, this application embodiment designs an anti-jitter dynamic rendering mode switching algorithm to dynamically switch different precision rendering modes according to the frame rate of the graphics processor, so that the image displayed on the visualization page is suitable for the frame rate of the graphics processor. In this way, this application embodiment can not only avoid using a high precision rendering mode when the frame rate of the graphics processor is low, which would put a heavy burden on the graphics processor or even cause the graphics processor to crash, but also avoid using a low precision rendering mode when the frame rate of the graphics processor is high, which would waste the resources of the graphics processor.

[0048] Specifically, the browser client uses the target application programming interface to obtain the frame rate and frame rate change rate of the graphics processor; based on the frame rate and frame rate change rate of the graphics processor, it determines the target rendering mode; it then determines whether the target rendering mode is the same as the rendering mode of the visualization page; if the target rendering mode is different from the rendering mode of the visualization page, it uses the target rendering mode and, based on the decoded data of each server node in the preset target cache, re-renders the visualization page to display the corresponding status of the server cluster on the visualization page; if the target rendering mode is the same as the rendering mode of the visualization page, it uses the target rendering mode and, based on the decoded data of each server node in the preset target cache, determines the area to be redrawn from the visualization page, and uses the decoded data of each server node to re-render the area to be redrawn to display the corresponding status of the server cluster on the visualization page.

[0049] According to one specific example, determining the target rendering mode may include: determining whether the frame rate and frame rate change rate of the graphics processor meet a first preset condition and a second preset condition; if the frame rate and frame rate change rate of the graphics processor meet the first preset condition, then the first rendering mode is determined as the target rendering mode; if the frame rate and frame rate change rate of the graphics processor meet the second preset condition, then the second rendering mode is determined as the target rendering mode; if the frame rate and frame rate change rate of the graphics processor meet neither the first preset condition nor the second preset condition, then the third rendering mode is determined as the target rendering mode.

[0050] The first preset condition includes a graphics processor (GPU) frame rate not less than a first preset frame rate and a GPU frame rate change rate greater than a first preset change rate. The second preset condition includes a GPU frame rate less than a second preset frame rate, or a GPU frame rate less than a third preset frame rate and a GPU frame rate change rate less than a second preset change rate. Furthermore, the first preset frame rate is greater than the third preset frame rate, the third preset frame rate is greater than the second preset frame rate, and the first preset change rate is greater than the second preset change rate.

[0051] Taking a first preset frame rate of 60, a second preset frame rate of 30, a third preset frame rate of 45, a first preset change rate of -2.0, and a second preset change rate of -5.0 as an example: If the graphics processor's frame rate is not less than 60 and the frame rate change rate is greater than -2.0, it indicates that the graphics processor's frame rate is high and not dropping rapidly. In this case, a high-precision first rendering mode can be activated, i.e., the first rendering mode is set as the target rendering mode. If the graphics processor's frame rate is less than 30, or if the graphics processor's frame rate is less than 45 and the frame rate change rate is less than -5.0, it indicates that the graphics processor's frame rate is very low, or the graphics processor's frame rate is low and dropping too quickly. In this case, to ensure rendering performance and avoid further stuttering, a low-precision second rendering mode can be activated, i.e., the second rendering mode is set as the target rendering mode. If neither of the above two situations applies, it indicates that the graphics processor's frame rate is moderate and the frame rate drop rate is also moderate. In this case, a medium-precision third rendering mode can be activated, i.e., the third rendering mode is set as the target rendering mode. In this way, the embodiments of this application provide an appropriate range of fluctuations by setting the frame rate threshold and the frame rate change rate threshold, thereby ensuring graphics rendering performance while preventing screen jitter caused by frequent switching of rendering modes.

[0052] The specific content displayed on the visualization page for different rendering precision modes takes into account the actual physical distribution of the server cluster. In this physical distribution, each server node in the cluster is located in at least one rack, and that rack is located in at least one data center.

[0053] Based on this, if the target rendering mode differs from the rendering mode of the visualization page and the target rendering mode is the first rendering mode, then the visualization page is re-rendered based on the decoded data of each server node in the preset target cache to display the corresponding status of each server node on the visualization page; if the target rendering mode differs from the rendering mode of the visualization page and the target rendering mode is the second rendering mode, then the visualization page is re-rendered based on the decoded data of server nodes located in the same data center to display the corresponding status of each data center on the visualization page; if the target rendering mode differs from the rendering mode of the visualization page and the target rendering mode is the third rendering mode, then the visualization page is re-rendered based on the decoded data of server nodes located in the same rack to display the corresponding status of each rack on the visualization page.

[0054] In other words, if the target rendering mode is different from the rendering mode of the visualization page, and the target rendering mode is the first rendering mode, then the visualization page needs to be re-rendered because the rendering mode has been switched to the high-precision first rendering mode. Specifically, the decoded data of each server node is first obtained from the preset target cache. The decoded data of the server node includes the first timestamp corresponding to the server node in the current state and the actual state index of the server node in the current state. Then, based on the decoded data of each server node, the visualization page is re-rendered to display the corresponding state of each server node on the visualization page, such as displaying the timestamp corresponding to the server node in the current state and the actual state index in the current state.

[0055] If the target rendering mode differs from the visualization page's rendering mode, and the target rendering mode is the second rendering mode, then the visualization page also needs to be re-rendered due to the switching of the rendering mode to the lower-precision second rendering mode. Specifically, the decoded data of each server node is first obtained from the preset target cache. The decoded data of the server node includes the actual status indicators of the server node at this time. Then, the overall status indicators of each data center are determined based on the decoded data of the server nodes located in the same data center. For example, the overall status indicators of each data center are obtained by averaging the actual status indicators of the server nodes located in the same data center. Then, the visualization page is re-rendered using the overall status indicators of each data center to display the corresponding status of each data center on the visualization page, such as displaying the overall status indicators of each data center.

[0056] If the target rendering mode differs from the visualization page's rendering mode, and the target rendering mode is the third rendering mode, then the visualization page needs to be re-rendered because the rendering mode has switched to the medium-precision third rendering mode. Specifically, the decoded data of each server node is first retrieved from the preset target cache. This decoded data includes the actual status indicators of the server nodes at this time. Then, the overall status indicators of each rack are determined based on the decoded data of the server nodes located in the same rack. For example, the overall status indicators of each rack are obtained by averaging the actual status indicators of the server nodes located in the same rack. Finally, the visualization page is re-rendered using the overall status indicators of each rack to display the corresponding status of each rack on the visualization page, such as displaying the overall status indicators of each rack.

[0057] It should be noted that the high-precision first rendering mode displays status at the server node level, the low-precision second rendering mode displays status at the data center level, and the medium-precision third rendering mode displays status at the rack level.

[0058] Furthermore, considering that in the second and third rendering modes with low to medium precision, it is also necessary to refine the display of the focus area with a relatively high server fault density, this embodiment of the application also adds a fault status bit of the server node to the target incremental data of the server node. When the fault status bit is 0, it indicates that the server node is in a normal state; when the fault status bit is 1, it indicates that the server node is in a warning / alarm state; and when the fault status bit is 2, it indicates that the server node is in a fault state. Correspondingly, the decoded data of the server node also includes the fault status bit of the server node.

[0059] Based on this, during the process of re-rendering the visualization page based on the decoded data of server nodes located in the same data center, the server nodes in a faulty state can be determined according to the fault status bits of the server nodes in the same data center. Based on the proportion of server nodes in a faulty state to all server nodes in the data center, the server fault density of the data center can be determined. Then, based on the server fault density of each data center, the data centers to be displayed in detail can be determined from each data center. So that when the corresponding status of each data center is displayed on the visualization page, the corresponding status of the server nodes in the data centers to be displayed in detail is displayed at the same time.

[0060] This process involves determining which data centers to be displayed in more detail based on the server failure density of each data center. This can include identifying data centers with server failure densities greater than a preset density, or identifying a preset number of data centers with the highest server failure densities. The preset number can be set according to user needs, the graphics processor's frame rate, and the frame rate variation rate.

[0061] Correspondingly, during the process of re-rendering the visualization page based on the decoded data of server nodes located in the same rack, the server nodes in a faulty state can be determined according to the fault status bits of the server nodes in the same rack. Based on the proportion of server nodes in a faulty state to all server nodes in the rack, the server fault density of the rack can be determined. Then, based on the server fault density of each rack, the racks to be displayed in detail can be determined from each rack. So that when the corresponding status of each rack is displayed on the visualization page, the corresponding status of the server nodes in the racks to be displayed in detail is displayed at the same time.

[0062] Specifically, based on the server fault density of each rack, the racks to be displayed in detail are determined from each rack. This may include: determining racks to be displayed in detail whose server fault density is greater than a preset density from each rack, and may also include: determining a preset number of racks to be displayed in detail whose server fault density is the highest from each rack.

[0063] Another approach is to determine the faulty server nodes in the server cluster based on the fault status bits of each server node in the low-to-medium precision second and third rendering modes. Then, based on the proportion of faulty server nodes to all server nodes in the server cluster, the server fault density is determined. If the server fault density is greater than the preset density, the corresponding status of each data center or rack will be displayed on the visualization page, along with the corresponding status of the faulty server nodes.

[0064] In this way, by introducing server fault density, the visibility of server faults can be guaranteed even when the frame rate of the graphics processor is low. A relative balance is achieved between display performance and server fault visibility, ensuring that critical server fault information can be displayed and monitored in a timely manner as much as possible.

[0065] Furthermore, in this embodiment of the application, when displaying the corresponding status of server nodes through a visualization page, in order to display different effects for different types of status indicators of server nodes, status indicator types can be added to the target incremental data of the server nodes. Correspondingly, the decoded data of the server nodes also includes status indicator types. In this way, when rendering the page based on the decoded data of each server node in the preset target cache, the display effect corresponding to the actual status indicator of the server node at this time can be determined according to the correspondence between the status indicator type and the display effect (e.g., color display, animation display, size display, etc.), thereby displaying the actual status indicator of the server node at this time with the corresponding display effect on the visualization page. Moreover, in order to improve the processing efficiency of each server node, this embodiment of the invention can pre-configure multiple threads to perform parallel processing on each server node, thereby improving processing efficiency.

[0066] It should be noted that the target incremental data for a server node may include the server node's node identifier, the change in the server node's status indicators between any two different states, and the corresponding data checksum, status indicator type, time change, fault status bit, and preset baseline status indicator. The preset binary incremental stream protocol (BISP) data structure is as follows: Figure 3As shown, uint16_t represents an unsigned 16-bit integer type, uint8_t represents an unsigned 8-bit integer type, int32_t represents a 32-bit signed integer type, float represents a single-precision floating-point number; node_id represents the node identifier and occupies only two bytes; metric represents the status indicator type and occupies only one byte. When metric is 0x01, it represents the status indicator type as CPU utilization; when metric is 0x02, it represents the status indicator type as MEM memory usage; time_delta represents the time change and occupies only four bytes; delta_val `ue` represents the change in status indicators and occupies only four bytes. `state` represents the fault status bit and occupies only one byte. When `state` is 0, it indicates that the server node is in a normal state. When `state` is 1, it indicates that the server node is in a warning state. When `state` is 2, it indicates that the server node is in a fault state. `base` represents the preset baseline status indicator and occupies only four bytes. `crc` represents the data checksum and occupies only two bytes. The data structure of the preset binary incremental stream protocol occupies a total of 18 bytes, which is significantly less than the 72 bytes or more of the JSON format. This can significantly reduce the number of bytes required and reduce memory usage and transmission bandwidth consumption.

[0067] In the process of determining the area to be redrawn from the visualization page by utilizing the target rendering mode and the decoded data of each server node in the preset target cache, the visualization page is first divided into several grids using the grid division method corresponding to the target rendering mode. Then, based on the decoded data of each server node in the preset target cache, the first target server node with a non-zero change in status indicators is determined from each server node. Based on the first target server node, the target grid is determined from the several grids, and the area to be redrawn is determined based on the target grid.

[0068] According to one specific example, when the target rendering mode is the first rendering mode, the first grid division method corresponding to the first rendering mode can be used, and the visualization page can be divided into several first grids based on the preset grid size. Then, based on the decoded data of each server node in the preset target cache, the first target server node with a non-zero change in status index is determined from each server node. According to the display position of the corresponding status of the first target server node on the visualization page, the first target grid is determined from several first grids, and the area to be redrawn is determined based on the first target grid.

[0069] It should be noted that the preset grid size can be determined based on the preset base grid size and the frame rate of the graphics processor. The specific calculation formula is as follows: Where G represents the length / width of the preset grid size, in pixels. This indicates a preset maximum pixel constraint, such as 160 pixels. Set a minimum pixel constraint, for example, 20 pixels. This represents the length / width of the preset base grid size in pixels. For example, the length / width of the preset base grid size is 40 pixels. F represents the frame rate of the graphics processor. It can be observed that, according to the above formula, the higher the frame rate of the graphics processor, the smaller the length and width of the preset grid size in pixels, and the more grid divisions there are. Conversely, the lower the frame rate of the graphics processor, the larger the length and width of the preset grid size in pixels, and the fewer grid divisions there are, so that the grid division is adapted to the frame rate of the graphics processor.

[0070] According to another specific example, when the target rendering mode is the second rendering mode, the second grid division method corresponding to the second rendering mode can be used, and the visualization page can be divided into several second grids based on the display position of the corresponding status of each data center on the visualization page. The second grid includes the display status of one or more complete data centers. Then, based on the decoded data of each server node in the preset target cache, the first target server node with a non-zero change in status index is determined from each server node, the target data center containing the first target server node is determined from each data center, and the second target grid is determined from several second grids based on the display position of the corresponding status of the target data center on the visualization page, and the area to be redrawn is determined based on the second target grid.

[0071] According to another specific example, when the target rendering mode is the third rendering mode, the third grid division method corresponding to the third rendering mode can be used, and the visualization page can be divided into several third grids based on the display position of the corresponding status of each rack on the visualization page. The third grid includes the display status of one or more complete racks. Then, based on the decoded data of each server node in the preset target cache, the first target server node with a non-zero change in status index is determined from each server node, the target rack containing the first target server node is determined from each rack, and the third target grid is determined from several third grids based on the display position of the corresponding status of the target rack on the visualization page, and the area to be redrawn is determined based on the third target grid.

[0072] It should be noted that when determining the area to be redrawn based on the target grid, adjacent target grids in the visualization page can be merged to obtain a merged grid. Both the merged grid and the unmerged target grids are then identified as the area to be redrawn. Adjacent target grids include those adjacent to the top, bottom, left, and right.

[0073] Furthermore, this application embodiment can also create a one-dimensional array to record the dirty grid identifiers of several grids. The dirty grid identifier is used to identify whether the grid is the target grid. By default, the dirty grid identifiers of several grids recorded in the one-dimensional array are all first preset identifiers, such as 0. After the target grid is determined from several grids, the one-dimensional array is updated to update the dirty grid identifier of the target grid in the one-dimensional array to a second preset identifier, such as 1, thereby obtaining the updated one-dimensional array.

[0074] When the target rendering mode is the first rendering mode, the first target grid can be determined as follows: First, number the first grids (for example, divide the visualization page into m×n first grids based on a preset grid size (width×length)) sequentially from left to right and from top to bottom. The numbers of the first grids are consecutive natural numbers starting from zero, i.e., 0, 1, 2, ..., m×n-1. Then, determine the display position (node.x, node.y) of the corresponding state of the first target server node on the visualization page, determine the ratio between the horizontal position node.x and the width of the preset grid size, and then... The ratio is rounded down to obtain the first value, i.e., the first value = Math.floor(node.x / width), where Math.floor represents the rounding down operation. At the same time, the ratio between the vertical position node.y in the display position and the length of the preset grid size is determined, and this ratio is rounded down to obtain the second value, i.e., the second value = Math.floor(node.y / length). The target number is determined by multiplying the second value by m and adding the first value, i.e., the target number = the second value × m + the first value. At this point, the first grid corresponding to the target number is determined as the first target grid.

[0075] In this embodiment, after determining the area to be redrawn from the visualization page, a second target server node required for rendering the area to be redrawn is first determined from each server node in the server cluster. Then, the decoded data of the second target server node is obtained from a preset target cache, and the area to be redrawn is re-rendered based on the decoded data of the second target server node to display the corresponding status of the server cluster on the visualization page. In this way, when the target rendering mode and the visualization page rendering mode are the same and have not switched, this application reduces the resources required for page rendering by redrawing only a portion of the visualization page, solving the resource waste problem of a full redraw for every page rendering and improving the page rendering speed.

[0076] Furthermore, to avoid directly stopping the display of the server cluster status when the browser client experiences network anomalies, this embodiment introduces a preset server status indicator prediction model built based on Long Short-Term Memory (LSTM). This model predicts the status indicators of each server node over a future period based on decoded data from recent times when the browser client experiences network anomalies. Then, using the target application programming interface (API), the visualization page is rendered based on these future status indicators to continue displaying the corresponding server cluster status over the future period. It should be noted that the future period should not be set too long, for example, 30 minutes. This avoids directly stopping the display of the server cluster status when the browser client experiences network anomalies, thus solving the problem of browser client unavailability during short-term network anomalies.

[0077] Specifically, when the browser client network is normal, the decoded data of each server node is stored in a preset database; when the browser client network is abnormal, the decoded data of each server node within a preset time period is retrieved from the preset database; the decoded data of each server node within the preset time period is input into a preset server status indicator prediction model to determine the predicted status indicator of each server node; using the target application programming interface and based on the predicted status indicator of each server node, the page is rendered to continue displaying the corresponding status of the server cluster on the visualization page.

[0078] More specifically, such as Figure 4 As shown, the system determines whether the browser client's network is normal. If the browser client's network is normal, a separate thread in the browser client's background, such as a service worker (a separate thread running in the browser's background used to intercept network requests, cache resources, and enable offline access), stores the decoded data of each server node in a preset database. If the browser client's network is abnormal, the system retrieves the decoded data of each server node within a preset time period from the preset database. This decoded data is then input into a preset server status indicator prediction model to determine the predicted status indicator of each server node. Using the target application programming interface (API), and based on the predicted status indicators of each server node and their corresponding display effects, the system renders the visualization page to continue displaying the corresponding status of the server cluster for a future period.

[0079] It should be noted that the display effects of the predicted status indicators include, but are not limited to, semi-transparent display and adding prediction labels, so that users can distinguish between the actual status indicators and the predicted status indicators of server nodes.

[0080] Therefore, this application encodes the incremental data of each server node in the server cluster into binary format and transmits it. The browser client then uses a data processing module pre-compiled into binary instruction format to decode and store the binary incremental data. Since binary format represents data more compactly and has less data redundancy than JSON format, it significantly reduces the number of bytes required. Combined with the fact that this application only transmits incremental data from server nodes, it can substantially reduce the required transmission bandwidth and memory usage. Furthermore, based on the address mapping relationship between preset shared memory and preset target cache, this application can directly map data in preset shared memory to preset target cache, skipping the processing of other intermediate layers. This allows data in preset shared memory to directly reach preset target cache, enabling the browser client to directly access the target application programming interface of the graphics processor and promptly utilize the data in preset target cache for page rendering. Thus, using address mapping to directly map data to preset target cache requires fewer resources and avoids the processing delays of other intermediate layers in related technologies, thereby improving the speed of browser page rendering.

[0081] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0082] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described server status visualization method embodiments.

[0083] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described server status visualization method embodiments at runtime.

[0084] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0085] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described server status visualization method embodiments.

[0086] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described server status visualization method embodiments.

[0087] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0088] The above provides a detailed description of a server status visualization method provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for visualizing server status, characterized in that, Applied to browser clients, including: The target incremental encoded data of each server node in the server cluster is obtained through a locally running data processing module; the data processing module is a data processing module pre-compiled into a binary instruction format; the target incremental encoded data is the data obtained by encoding the target incremental data into binary format; the target incremental data includes the change in the state index of the server node between any two different states. The data processing module decodes the target incremental encoded data and writes the decoded data of each server node into a preset shared memory. Based on a preset address mapping relationship, the decoded data of each server node is mapped from the preset shared memory to a preset target cache; the preset target cache is a cache pre-configured for the target application programming interface of the browser client, and the target application programming interface is an interface for providing users with direct access to the graphics processor. Using the target application programming interface and based on the decoded data of each server node in the preset target cache, page rendering is performed to display the corresponding status of the server cluster on a visualization page; The target incremental data also includes a data check code corresponding to the change in the state index of the server node between any two different states. The step of decoding the target incremental encoded data through the data processing module includes: The data processing module decodes the target incremental encoded data to obtain the change in the state index of the server node between any two different states and the corresponding data check code. The data checksum is verified to determine whether to discard the target incremental encoded data of the server node based on the verification result; If the target incremental encoded data of the server node is not discarded, the actual state index of the server node in this current state is determined based on the change in the state index of the server node between any two different states; the two different states include the current state and the previous state. Based on the actual status indicators of the server node at this time, the decoded data of the server node is determined; The step of determining the actual state index of the server node in the current state based on the change in state index between any two different states includes: Based on the change in the state index of the server node between any two different states and the actual state index of the server node in the previous state, the actual state index of the server node in the current state is determined; the actual state index of the server node in the initial state is a preset baseline state index, and the preset baseline state index is located in the target incremental data of the server node.

2. The server status visualization method according to claim 1, characterized in that, The target incremental data also includes the time change between the first timestamp and the second timestamp, where the first timestamp is the timestamp corresponding to the server node in the current state, and the second timestamp is the timestamp corresponding to the server node in the previous state. After determining whether to discard the target incremental encoded data of the server node based on the verification result, the method further includes: If the target incremental encoded data of the server node is not discarded, the first timestamp is determined based on the second timestamp and the time change amount decoded from the target incremental encoded data, so as to determine the decoded data of the server node based on the actual status index of the server node at this time and the first timestamp.

3. The server status visualization method according to claim 1, characterized in that, The process of creating the preset shared memory includes: Create a pre-defined shared memory with contiguous addresses for the data processing module, and enable the sharing flag of the pre-defined shared memory.

4. The server status visualization method according to claim 3, characterized in that, The creation process of the preset target cache includes: The preset target cache is created based on the preset cache size; Based on the shared flag of the preset shared memory, the preset target cache is mapped to the preset shared memory so that the data in the preset shared memory can be directly mapped to the preset target cache.

5. The server status visualization method according to claim 1, characterized in that, The step of rendering the page using the target application programming interface and based on the decoded data of each of the server nodes in the preset target cache includes: Using the target application programming interface, the frame rate and frame rate change rate of the graphics processor are obtained; The target rendering mode is determined based on the frame rate and the frame rate change rate. Determine whether the target rendering mode is the same as the rendering mode of the visualization page; If they are different, the target rendering mode is used, and the visualized page is re-rendered based on the decoded data of each server node in the preset target cache. If they are the same, the target rendering mode is used, and based on the decoded data of each server node in the preset target cache, the area to be redrawn is determined from the visualization page, and the page is re-rendered for the area to be redrawn using the decoded data of each server node.

6. The server status visualization method according to claim 5, characterized in that, The determination of the target rendering mode based on the frame rate and the frame rate change rate includes: Determine whether the frame rate and the frame rate change rate satisfy the first preset condition and the second preset condition; If the first preset condition is met, then the first rendering mode is determined as the target rendering mode; If the second preset condition is met, then the second rendering mode is determined as the target rendering mode; If the first preset condition and the second preset condition are not met, then the third rendering mode will be determined as the target rendering mode. The first preset condition includes that the frame rate is not less than a first preset frame rate and the frame rate change rate is greater than a first preset change rate; the second preset condition includes that the frame rate is less than a second preset frame rate, or that the frame rate is less than a third preset frame rate and the frame rate change rate is less than a second preset change rate. The first preset frame rate is greater than the third preset frame rate, and the third preset frame rate is greater than the second preset frame rate; the first preset change rate is greater than the second preset change rate.

7. The server status visualization method according to claim 6, characterized in that, Each of the server nodes in the server cluster is located in at least one rack, and the at least one rack is located in at least one data center; The step of re-rendering the visualization page using the target rendering mode and based on the decoded data of each server node in the preset target cache includes: If the target rendering mode is the first rendering mode, then based on the decoded data of each server node in the preset target cache, the visualization page is re-rendered to display the corresponding status of each server node on the visualization page. If the target rendering mode is the second rendering mode, then based on the decoded data of the server nodes located in the same data center, the visualization page is re-rendered to display the corresponding status of each data center on the visualization page; If the target rendering mode is the third rendering mode, the visualization page is re-rendered based on the decoded data of the server nodes located in the same rack, so as to display the corresponding status of each rack on the visualization page.

8. The server status visualization method according to claim 7, characterized in that, The step of determining the area to be redrawn from the visualization page using the target rendering mode and based on the decoded data of each server node in the preset target cache includes: The visualization page is divided into several grids using the grid division method corresponding to the target rendering mode; Based on the decoded data of each server node in the preset target cache, a first target server node with a non-zero change in status indicators is determined from each server node. Based on the first target server node, a target grid is determined from the plurality of grids, and the area to be redrawn is determined based on the target grid.

9. The server status visualization method according to claim 8, characterized in that, The step of re-rendering the area to be redrawn using the decoded data from each of the server nodes includes: Determine the second target server node required to render the area to be redrawn from each of the server nodes; Based on the decoded data from the second target server node, the area to be redrawn is re-rendered.

10. The server status visualization method according to any one of claims 1 to 9, characterized in that, Also includes: When the browser client network is normal, the decoded data of each of the server nodes is stored in a preset database; When the browser client experiences a network error, the decoded data of each of the server nodes within a preset time period is retrieved from the preset database. The decoded data of each server node within the preset time period is input into a preset server status indicator prediction model to determine the predicted status indicator of each server node. Using the target application programming interface and based on the predicted status indicators of each server node, page rendering is performed to continue displaying the corresponding status of the server cluster on the visualization page.

11. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the server status visualization method as described in any one of claims 1 to 10 when executing the computer program.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the server status visualization method as described in any one of claims 1 to 10.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the server status visualization method as described in any one of claims 1 to 10.

Images