Unified management method, system and equipment for multiple JBOSS instances

Abstract

The invention discloses a unified management method, device and equipment for multiple JBOSS instances, and the method comprises the steps: when an instance starting request is received, analyzing configuration information associated with a target JBOSS instance, creating an independent management thread, starting a JBOSS process in the management thread, and creating an anonymous pipeline; the method comprises the following steps of: periodically monitoring a running state of a JBOSS process and capturing log data through an anonymous pipeline on the basis of starting a guard cycle in a management thread; creating a temporary log file corresponding to the log data, and matching with the log data in the temporary log file based on an alarm rule in a preset rule base to obtain a matching result; and generating structured alarm information from the log event indicating successful matching in the matching result according to a preset alarm template, storing the structured alarm information in a log alarm list, and providing the running state of the corresponding target JBOSS instance and the log alarm list through an HTTP service interface. The centralized management and real-time monitoring of a plurality of JBOSS instances can be realized, and the operation and maintenance efficiency and the system availability are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of JBOSS instance management, and particularly relates to a unified management method, device and equipment for multiple JBOSS instances. BACKGROUND

[0002] Under the background of the increasing popularity of distributed architecture, key business systems are often split into multiple business subsystems (such as microservices or functional modules) for independent deployment. In order to improve resource utilization and deployment flexibility, multiple JBOSS middleware-based subsystem instances are often deployed on the same Windows server node. This deployment mode causes each JBOSS instance to run as an independent process and appear as a separate command line console window at the operating system level. Although this to some extent optimizes resource allocation, it has some operation and maintenance problems: a large number of parallel JBOSS process windows are crowded and overlapped on the desktop or taskbar, making it difficult for administrators to quickly identify and locate target instances, resulting in process management chaos and low efficiency; the logs of each JBOSS instance are independently output to their respective working directories by default, and the scattered logs in multiple locations make diagnosis difficult. SUMMARY

[0003] In view of this, the purpose of the present application is to provide a unified management method, device and equipment for multiple JBOSS instances, aiming to solve the problem of how to realize unified management of multiple JBOSS instances and real-time log aggregation analysis, thereby improving operation and maintenance efficiency, system availability and reliability.

[0004] To achieve the above purpose, the present application provides a unified management method for multiple JBOSS instances, which comprises:

[0005] When an instance start request is received, the configuration information associated with the target JBOSS instance is parsed and an independent management thread is created, the JBOSS process is started in the management thread, and an anonymous pipe is created;

[0006] Based on the daemon cycle started in the management thread, the running state of the JBOSS process is periodically monitored and log data is captured through the anonymous pipe;

[0007] A temporary log file corresponding to the log data is created, and the log data in the temporary log file is matched with the alarm rules in the preset rule library based on a preset rule library, to obtain a matching result;

[0008] The log events indicating a successful match in the matching result are used to generate structured alarm information according to a preset alarm template and store the alarm information in a log alarm list, and the running state of the target JBOSS instance and the log alarm list are provided through an HTTP service interface.

[0009] Preferably, the parsing of the configuration information associated with the target JBOSS instance and the creation of the independent management thread comprises:

[0010] Obtaining the configuration information including the startup script path, the identification information, the listening port, the self-starting configuration flag and the running state of the target JBOSS instance from the instance list of the integrated graphical management interface;

[0011] Determining whether the target JBOSS instance is running according to the running state, and if yes, rejecting the startup request, otherwise, creating the management thread, wherein the management thread is used to execute tasks including process startup, running state monitoring and log capturing, and is decoupled from the main thread of the graphical management interface.

[0012] Preferably, the starting of the JBOSS process in the management thread and the creation of the anonymous pipe comprises:

[0013] Calling the API interface of the operating system and starting the JBOSS process based on the startup script path;

[0014] Creating the anonymous pipe and redirecting the output stream and the error stream of the JBOSS process to the write end of the anonymous pipe.

[0015] Preferably, the starting of the daemon cycle in the management thread comprises periodically monitoring the running state of the JBOSS process and capturing log data through the anonymous pipe, and comprises:

[0016] Using a preset function to listen to the handle of the JBOSS process, querying the running state of the JBOSS process, and determining whether the process is alive in real time according to the running state, and if the handle is detected to be triggered, it is determined that the JBOSS process has terminated and the current daemon cycle is exited;

[0017] Periodically checking whether there is log data to be read in the read end of the anonymous pipe, and if yes, reading the log data, associating the read log data with the identification information of the target JBOSS instance, and pushing the log data to the log display area of the graphical management interface in real time.

[0018] Preferably, the creation of the temporary log file corresponding to the log data and the matching of the alarm rule in the preset rule library with the log data in the temporary log file comprises:

[0019] automatically close the temporary log file and create a new temporary log file, and add the path of the temporary log file and the new temporary log file to a to-be-processed file queue; wherein the preset condition includes reading the log data to the end of a line and the size of the temporary log file exceeding a capacity threshold, or the modification time of the temporary log file exceeding a time threshold;

[0020] The background analysis thread continuously obtains the to-be-processed temporary log file from the to-be-processed file queue, reads the content in the temporary log file line by line, and matches the content with the alarm rule, wherein the alarm rule includes a keyword or a regular expression for matching log key information.

[0021] Preferably, the log event indicating a matching success in the matching result is used to generate structured alarm information according to a preset alarm template, and the alarm information is stored in a log alarm list, including:

[0022] The extracted log context, timestamp, alarm title, description, and solution are assembled into structured JSON format alarm information according to the alarm template;

[0023] The alarm information is written into a JSON alarm file under a preset Web service directory, and the JSON file is stored as an alarm record in the log alarm list, wherein the alarm record includes an alarm title, a link, an alarm level, and a last update time.

[0024] Preferably, the method further includes:

[0025] Periodically detecting the running state of all registered JBOSS instances, and detecting process survival and service health depth according to the running state; wherein,

[0026] The process survival detection includes automatically triggering a start process of the current JBOSS instance when a self-start configuration flag in configuration information of the current JBOSS instance is detected to be self-starting and the process PID of the current JBOSS instance does not exist, and the start process includes creating a management thread, creating an anonymous pipe, and starting a daemon loop;

[0027] The service health depth detection includes network layer detection and application layer detection; wherein the network layer detection includes establishing a TCP connection to a listening port through the listening port in the configuration information corresponding to the JBOSS instance to verify whether the TCP port is in a listening state; and the application layer detection includes sending a preset application layer detection packet to the TCP port and waiting for a response if the TCP connection is successful.

[0028] To achieve the above object, the application further provides a device for unified management of multiple JBOSS instances, which comprises:

[0029] An instance starting unit is configured to, when receiving an instance starting request, parse configuration information associated with a target JBOSS instance and create an independent management thread, start a JBOSS process in the management thread and create an anonymous pipe;

[0030] A daemon loop unit is configured to start a daemon loop based on the management thread, periodically monitor the running state of the JBOSS process and capture log data through the anonymous pipe;

[0031] A rule matching unit is configured to create a temporary log file corresponding to the log data, match the log data in the temporary log file with alarm rules in a preset rule library based on a preset rule library, and obtain a matching result;

[0032] An alarm generating unit is configured to generate structured alarm information from a log event indicating a successful match in the matching result according to a preset alarm template and store the alarm information in a log alarm list, and provide the running state of the target JBOSS instance and the log alarm list corresponding to the target JBOSS instance through an HTTP service interface.

[0033] Preferably, the device further comprises:

[0034] A health check unit is configured to periodically detect the running state of all registered JBOSS instances, and detect process survival and service health degree depth according to the running state; wherein,

[0035] Process survival detection comprises automatically triggering the starting process of the current JBOSS instance when detecting that the self-starting configuration flag in the configuration information of the current JBOSS instance is self-starting and the process PID of the current JBOSS instance does not exist, the starting process comprising creating a management thread, creating an anonymous pipe and starting a daemon loop;

[0036] Service health degree depth detection comprises network layer detection and application layer detection; wherein, the network layer detection comprises establishing a TCP connection through a listening port in the configuration information corresponding to the JBOSS instance to listen to the port to verify whether the TCP port is in a listening state; the application layer detection comprises sending a preset application layer detection packet to the TCP port and waiting for a response if the TCP connection is successful.

[0037] In order to achieve the above object, the application further provides a device for unified management of multiple JBOSS instances, comprising a processor, a memory and a computer program stored in the memory, the computer program being executed by the processor to implement the steps of the method for unified management of multiple JBOSS instances as described in the above embodiment.

[0038] In order to achieve the above object, the application further provides a computer readable storage medium, the computer readable storage medium storing a computer program, the computer program being executed by a processor to implement the steps of the method for unified management of multiple JBOSS instances as described in the above embodiment.

[0039] In order to achieve the above object, the application further provides a computer program product, comprising computer programs / instructions, the computer programs / instructions being executed by a processor to implement the steps of the method for unified management of multiple JBOSS instances as described in the above embodiment.

[0040] Advantages:

[0041] The above scheme creates a management thread, an anonymous pipe and a start daemon cycle according to a start request, realizes centralized management and real-time monitoring of multiple JBOSS instances, improves operation and maintenance efficiency, avoids the problems of window confusion and misoperation in traditional operation, utilizes the anonymous pipe to capture log data and create a temporary log file, realizes centralized aggregation and intelligent alarm of logs, and facilitates quick positioning of problems, provides a running state and a log alarm list through an HTTP service interface, facilitates integration with an external monitoring system, and improves the scalability of the system.

[0042] The configuration information is obtained through the instance list of the graphical management interface, so that the administrator can intuitively see the instance state and the operation is more convenient, the instance is judged whether it has been running before the management thread is created, the problem of repeated start is avoided, the management thread is decoupled from the main thread, the management of each instance is ensured not to interfere with each other, and the stability of the system is improved, the JBOSS process is started by calling the API of the operating system, the standardization and controllability of the start process are ensured, the output and error streams are redirected to the anonymous pipe, so that the administrator does not need to find the log of the target instance in the stacked command line window, and the efficiency of log management is improved.

[0043] The function monitors the process handle, periodically checks the log data in the anonymous pipe, enhances the reliability and real-time performance of the system, and the existence of the daemon cycle enables the system to actively discover process exit or log exception, and timely feedback to the administrator, which greatly improves the response speed of operation and maintenance; the log file is divided according to the condition, so that the log file is easier to manage and retrieve, and the performance bottleneck caused by large file is avoided, the background thread is matched with the alarm rule, the intelligent level of the alarm is enhanced, and the operation and maintenance personnel are helped to quickly locate the exception; the matched alarm information is assembled into JSON format and stored in the Web service directory, which is convenient for connecting with external systems (such as monitoring platform or analysis tool); the JSON format makes the data more standardized and easy to parse, and reduces the burden of manual processing.

[0044] By introducing the deep detection mechanism of process survival and service health degree, not only the process crash can be coped with, but also the "false death" state can be detected and recovered; through network layer and application layer detection, all possible abnormal scenes are more comprehensively covered, and the stability and reliability of the system are ensured. BRIEF DESCRIPTION OF DRAWINGS

[0045] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0046] Figure 1 A flowchart of a unified management method of multiple JBOSS instances provided by an embodiment of the present application.

[0047] Figure 2 A centralized management and process daemon integrated flowchart provided by an embodiment of the present application.

[0048] Figure 3 A log aggregation and alarm analysis flowchart provided by an embodiment of the present application.

[0049] Figure 4 A structure diagram of a unified management device of multiple JBOSS instances provided by an embodiment of the present application.

[0050] The implementation of the present application, functional features and advantages will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0051] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention 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 the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to represent selected embodiments of the invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0052] Currently, multiple subsystem instances based on the JBoss middleware are deployed on the same Windows server node, which has caused some operational and maintenance issues, such as:

[0053] 1. Inefficient process visualization and management: A large number of parallel JBOSS process windows are crowded and overlapping on the desktop or taskbar, making it difficult for administrators to quickly identify and locate target instances and perform basic operation and maintenance operations such as instance startup, shutdown or restart. This is inefficient and prone to errors.

[0054] 2. By default, each JBoss instance outputs its logs independently to its own working directory, resulting in scattered logs that make diagnosis difficult and also causing the following problems:

[0055] 1) Real-time viewing of multi-instance combined logs or tracking of cross-instance call chains is cumbersome, lacks a unified log aggregation view, and is difficult to perform correlation analysis and global status monitoring;

[0056] 2) The physical distribution of log files hinders efficient access to a centralized log analysis platform and increases operational complexity.

[0057] 3. The process is highly vulnerable and lacks a protection mechanism:

[0058] 1) The current deployment model lacks effective process management methods. Once a process is unexpectedly terminated due to human error (such as accidentally closing a window), resource contention (such as memory overflow) or other abnormal reasons, the operation and maintenance personnel often find it difficult to detect in time. This not only leads to service interruption, but may also cause more serious business impact due to the delay in fault detection.

[0059] 2) The system lacks the ability to automatically monitor and protect the JBOSS process. When the process exits unexpectedly, it cannot automatically detect, alarm, or restart and recover, which seriously threatens the continuous availability and service reliability of the system and greatly increases the passive response burden of the operation and maintenance personnel.

[0060] Thus, the application realizes convenient start and stop, state monitoring and visual operation of all JBOSS instances by providing a unified centralized management console; supports real-time log aggregation, centralized display and advanced search, breaks the barrier of scattered logs; integrates a process daemon engine to provide real-time health monitoring of JBOSS processes, automatically triggers an alarm and executes a preset recovery strategy (such as automatic restart) when the process abnormally exits, guarantees continuous and stable operation of key business processes, and significantly improves the overall availability and resilience of the system.

[0061] The content of the application will be described in detail below in combination with embodiments.

[0062] Referring to Figure 1 Fig. 1 shows a flowchart of a unified management method for multiple JBOSS instances according to an embodiment of the application.

[0063] In the embodiment, the method comprises:

[0064] S11, when a start request of an instance is received, configuration information associated with a target JBOSS instance is parsed and an independent management thread is created, a JBOSS process is started in the management thread, and an anonymous pipe is created.

[0065] Further, in step S11, the configuration information associated with the target JBOSS instance is parsed and the independent management thread is created, comprising:

[0066] S11-1, the configuration information including the start script path, identification information, listening port, self-starting configuration flag and running state of the target JBOSS instance is obtained from the instance list of the integrated graphical management interface;

[0067] S11-2, whether the target JBOSS instance is running is determined according to the running state, if yes, the start request is rejected, otherwise, the management thread is created, wherein the management thread is used to execute tasks including process start, running state monitoring and log capture, and is decoupled from the main thread of the graphical management interface.

[0068] Further, in step S11, the JBOSS process is started in the management thread and the anonymous pipe is created, comprising:

[0069] S11-3, an API interface of an operating system is called and the JBOSS process is started based on the start script path;

[0070] S11-4, the anonymous pipe is created and the output stream and error stream of the JBOSS process are redirected to the write end of the anonymous pipe.

[0071] In the embodiment, the method is based on a centralized management control platform under a Windows system, realizes unified visual management of multiple JBOSS instances, and provides an integrated graphical management interface (GUI) containing a control of an instance list, which is used for centralized display of identification information (such as application name), configuration path, running state (such as running, stopped) and the like of all registered JBOSS instances. The system maintains a global state data structure, which is used for recording real-time running information of each JBOSS instance, including process state description, state code and associated process identifier (PID). By allocating independent management resources for each JBOSS instance, it is ensured that the management operations of the instances are isolated from each other and do not interfere with each other.

[0072] When receiving an instance start instruction, the system performs the following steps:

[0073] (1) Analyzing the configuration information associated with the target JBOSS instance, obtaining its start script path, window title and the like parameters, checking whether the instance is running, and if so, refusing the repeated start request;

[0074] (2) Creating an independent management thread for the instance, which is responsible for executing all subsequent background tasks such as process start, monitoring and log capture, and realizing decoupling of the main thread (GUI) and the background task;

[0075] (3) In the management thread, calling the operating system API interface, starting the JBOSS process based on the corresponding start script path; when creating the child process, configuring its standard output (stdout) stream and standard error (stderr) stream, so as to redirect them to the write end of an anonymous pipe. This can make the console output of the JBOSS instance no longer displayed in an independent window, but captured by the system background.

[0076] S12, based on the daemon cycle started in the management thread, periodically monitoring the running state of the JBOSS process and capturing log data through the anonymous pipe.

[0077] Further, in step S12, the daemon cycle started in the management thread is based on periodically monitoring the running state of the JBOSS process and capturing log data through the anonymous pipe, which includes:

[0078] S12-1, using a preset function to listen to the handle of the JBOSS process, querying the running state of the JBOSS process, and judging whether the process is alive in real time according to the running state, if the handle is detected to be triggered, it is determined that the JBOSS process has terminated and the current daemon cycle is exited;

[0079] S12-2, periodically checking whether there is log data to be read in the reading end of the anonymous pipe, if there is, reading the log data, associating the read log data with the identification information of the target JBOSS instance, and pushing the log data to the log display area of the graphical management interface in real time.

[0080] In the embodiment, a daemon object is created and initialized, the daemon object holds the handle of the child process and the reading end of the pipe, and starts its core daemon cycle to perform the following:

[0081] (1) capturing the JBOSS console output stream (stdout / stderr) through an anonymous pipe, periodically checking whether there is log data to be read in the anonymous pipe, if there is, reading the log data content from the reading end of the anonymous pipe;

[0082] (2) associating the read log data with the identification information of the instance (such as adding the prefix "[instance name]"), and pushing it to the log display area of the graphical management interface in real time in a thread-safe manner, realizing the centralized and orderly display of all instance logs;

[0083] (3) using Windows API WaitForSingleObject to listen to the handle of the child process in the daemon cycle, non-blockingly querying the running state of the child process, and judging in real time whether the child process is alive, if it is detected that the child process has terminated, the daemon cycle is immediately exited, marking the end of this daemon cycle;

[0084] (4) receiving user-initiated intervention instructions, if a "stop" instruction issued by the user is received, the daemon mechanism will actively send a termination signal to the child process to force it to exit.

[0085] S13, creating a temporary log file corresponding to the log data, matching the log data in the temporary log file with the alarm rules in the preset rule library to obtain a matching result.

[0086] Further, in step S13, the temporary log file corresponding to the log data is created, and the log data in the temporary log file is matched with the alarm rules in the preset rule library, including:

[0087] S13-1, automatically closing the temporary log file and creating a new temporary log file when the temporary log file meets a preset condition, and adding the path of the temporary log file and the new temporary log file to a to-be-processed file queue; wherein the preset condition includes reading the log data to the end of a line and the size of the temporary log file exceeding a capacity threshold, or the modification time of the temporary log file exceeding a time threshold;

[0088] S13-2, continuously acquiring the to-be-processed temporary log file from the to-be-processed file queue by a background analysis thread, reading the content in the temporary log file line by line and matching the content with the alarm rule, wherein the alarm rule includes a keyword or a regular expression for matching log key information.

[0089] In the embodiment, the purpose is to realize real-time aggregation and intelligent analysis of massive log data generated by multiple JBOSS middleware instances, automatically generate structured alarm information based on preset rules, and finally present the information in a user-friendly manner, so as to solve the problems of traditional log dispersion, difficult analysis, and untimely alarm. The output stream of the original console of each JBOSS instance captured through an anonymous pipe is received, and an independent temporary log file is created for the real-time log stream of each JBOSS instance. When the temporary log file meets a specific condition (such as reading the log to the end of a line and the size of the temporary log file exceeding a threshold or the modification time of the temporary log file exceeding a threshold), the current temporary log file is automatically closed and a new file is generated, ensuring the orderly segmentation of the log. The path of the generated and closed temporary log file is added to a global to-be-processed file queue for subsequent analysis thread consumption.

[0090] The system maintains an alarm rule library with preset alarm rules, and each alarm rule contains one or more keywords or regular expressions for matching log key information. The background analysis thread continuously acquires the to-be-processed temporary log file from the to-be-processed file queue, and when a log line successfully matches the keyword of a certain alarm rule, the system not only captures the log line, but also extracts the subsequent log lines as context information to completely present the stack or related operation sequence when the error occurs.

[0091] S14, generating structured alarm information from the matching result indicating a successful match according to a preset alarm template and storing the alarm information in a log alarm list, and providing the running state of the target JBOSS instance and the log alarm list through an HTTP service interface.

[0092] Further, in step S14, the generation of structured alarm information from the matching result indicating a successful match according to a preset alarm template and the storage of the alarm information in a log alarm list include:

[0093] S14-1, assembling the extracted log context, timestamp, alarm title, description, solution into structured JSON format alarm information according to the alarm template;

[0094] S14-2, writing the alarm information into a JSON alarm file under a preset Web service directory, and storing the JSON file as an alarm record in a log alarm list, wherein the alarm record includes the title, link, alarm level and last update time of the alarm.

[0095] In the embodiment, for a matched log event, the system assembles the extracted information including log context, timestamp, alarm title, description, solution, etc. into structured JSON format alarm information according to a preset alarm template, writes the generated JSON alarm information into a specific JSON alarm file under a preset Web service directory, and facilitates front-end display. The system maintains a log alarm list (such as exception_change table.json), and whenever a new JSON alarm file is generated, the system dynamically appends an alarm record to the log alarm list, which contains metadata such as the title, link (URL), alarm level, and last update time of the alarm. When the system date changes, the previous day's "log alarm list" file is automatically archived under the directory corresponding to the date, realizing periodic arrangement of logs.

[0096] Further, a lightweight HTTP service is embedded to expose a jsonrpc interface to the outside, providing the running state of all JBOSS instances, log alarm list, system health status, and supporting integration with external monitoring systems or operation and maintenance portals to realize remote state acquisition and alarm linkage.

[0097] Further, the method further comprises:

[0098] periodically detecting the running state of all registered JBOSS instances, and detecting process survival and service health degree according to the running state; wherein,

[0099] The process survival detection comprises automatically triggering a start process of the current JBOSS instance when it is detected that a self-starting configuration flag in configuration information of the current JBOSS instance is self-starting and a process PID of the current JBOSS instance does not exist, and the start process comprises creating a management thread, creating an anonymous pipe, and starting a daemon loop;

[0100] The service health degree deep detection includes network layer detection and application layer detection. The network layer detection includes establishing a TCP connection with a listening port in configuration information corresponding to the JBOSS instance to verify whether the TCP port is in a listening state. The application layer detection includes sending a preset application layer detection message to the TCP port and waiting for a response if the TCP connection is successful.

[0101] In the embodiment, the system is built with a periodic state checking task, which periodically scans current running states of all registered JBOSS instances, detects process survival and service health degree deep according to the running states, and specifically:

[0102] Process survival detection: when the checking task finds that the "self-starting" function is enabled in the configuration information of a JBOSS instance, but the process PID of the current JBOSS instance does not exist, the system will automatically trigger the restart process of the JBOSS instance (i.e., re-executes the startup process steps, such as the specific process of creating a management thread, creating an anonymous pipe, and starting a daemon loop).

[0103] Service health degree deep detection: for the JBOSS instance with a running state of "running", the system further performs service health degree deep detection, including two levels:

[0104] (1) Network layer detection: attempts to establish a TCP connection with a listening port in configuration information corresponding to the JBOSS instance to verify whether the network port is in a listening (LISTENING) state.

[0105] (2) Application layer detection: if the TCP connection is successful, a preset, lightweight application layer detection message (such as a simulated login request) is sent to the port, and a response is waited for.

[0106] False death judgment and forced recovery: if the service health degree deep detection fails (including TCP connection failure or no valid response at the application layer) for multiple times (for example, 3 times) in succession, it is determined that the JBOSS instance is in a "false death" state. The system will actively terminate the abnormal process and immediately trigger the automatic restart process. This mechanism forms a multi-level, closed-loop monitoring and recovery system from "process survival" to "service availability", which not only can cope with process crashes, but also can effectively handle complex faults such as process false death, greatly improving the availability and resilience of key business systems.

[0107] Further, all running state changes (such as "running", "stopped") are updated to the global state data structure and the instance list of the graphical management interface through a synchronization mechanism, ensuring the consistency and real-time of the information. Users can intuitively view the running state of each JBOSS instance through the interface, and perform start, stop and other operations, and all operation results are fed back in real time.

[0108] The following is described through a specific example:

[0109] Referring to Figure 2 The centralized management and process daemon integrated process shown in the figure includes:

[0110] 1) Initial configuration and interface loading:

[0111] Suppose a system administrator needs to manage two JBOSS instances: OrderService and PaymentService deployed on the same Windows server; the administrator first defines two JBOSS instances in the configuration file of the system:

[0112] JBOSS instance 1: the application name is "OrderService", the startup script path is C:\jboss\orderservice\bin\standalone.bat, the listening port is 8081, and self-start is enabled;

[0113] JBOSS instance 2: the application name is "PaymentService", the startup script path is C:\jboss\paymentservice\bin\standalone.bat, the listening port is 8082, and self-start is not enabled.

[0114] The administrator starts the graphical management application, which loads the configuration and clearly lists the two JBOSS instances in the instance list of the graphical management interface, and the "running state" of each instance is initially "unknown".

[0115] 2) Start the "OrderService" instance, including:

[0116] Verification and thread creation: the system first queries the global state to confirm that the instance is not running and passes the verification, and then the system creates a separate management thread for "OrderService";

[0117] Process startup and redirection: in this management thread, the system calls the operating system interface to start the JBOSS process with C:\jboss\orderservice\bin\standalone.bat as the command line, and the system creates an anonymous pipe and redirects the standard output stream and the standard error stream of the JBOSS process to the write end of the anonymous pipe; therefore, the administrator will not see any new command line window pop up;

[0118] Daemon loop startup: the system initializes a daemon object that holds the handle of the JBOSS process and the reference to the read end of the anonymous pipe, and immediately enters its daemon loop.

[0119] 3) Log capturing and status monitoring, including:

[0120] Daemon loop reads log data: the loop periodically checks the anonymous pipe, and when the JBOSS of the [order service] instance starts to output startup logs, the system reads log data from the anonymous pipe (the specific process is described in the log aggregation and alarm analysis process section later), automatically adds the [order service] prefix, and pushes the log data to the central log display area of the GUI in real time; the administrator can clearly see all the outputs in the GUI window of this service;

[0121] Running status monitoring: the loop simultaneously and non-blockingly monitors the process handle. Once the [order service] instance is started and the process enters a stable running state, the monitoring continues; the running status of the [order service] instance in the GUI interface is automatically updated to "running".

[0122] 4) Start and stop of the [payment service] instance:

[0123] The [payment service] instance does not enable the self-starting flag, and the administrator needs to select the [payment service] list item in the service list and click the start button, and the system performs the same process as the [order service] instance (thread creation, redirection startup, log capturing, etc.), and its running status is also updated to "running".

[0124] After a period of time, the administrator needs to maintain the [payment service] instance, and selects the [payment service] list item and clicks the "stop" button; the daemon loop mechanism receives the "stop" instruction and immediately sends a termination signal to the JBOSS process of the [payment service] instance, forcing it to exit. After the daemon loop detects that the process has terminated, it exits, the system updates the running status of the [payment service] instance to "stopped", and records in the log that the [payment service] has stopped.

[0125] 5) Triggering of the automatic recovery mechanism:

[0126] 5.1) Process unexpected crash: Assume that the JBOSS process of the "Order Service" instance crashes unexpectedly and exits due to some unknown reason; the system's built-in periodic state check task (e.g., runs every 15 seconds) discovers that the process PID of the "Order Service" does not exist at the next scan, but the "self-start" flag in its configuration is enabled, so the system automatically triggers the restart process of the "Order Service", including creating a management thread, redirecting the startup sub-process, initializing the daemon loop, etc. Without the administrator's awareness, the "Order Service" instance has been automatically restarted and resumed running; the system records the restart event in the log to remind the administrator to check the crash reason later.

[0127] 5.2) Process hanging: Assume that the "Order Service" instance has entered a "hanging" state due to resource exhaustion (such as thread pool full, database connection leakage) after a long time of high load running, although the JBOSS process is still running (the PID exists at the operating system level), it cannot respond to any external requests. The system's built-in periodic health check task starts to probe the "Order Service":

[0128] Network layer probing: The system attempts to connect to the listening port (8081) of the "Order Service"; the connection is successful, indicating that the TCP port is still listening;

[0129] Application layer probing: The system sends a preset, lightweight probing packet (such as a simulated login request) to the port and waits for a response.

[0130] Probing failure: Since the service has hung up and cannot handle requests, the system does not receive a valid response within the timeout time, and this probing is determined to be a failure.

[0131] Hanging determination: The health check task records this failure; the situation is still the same in the next two probes (30 seconds apart). When three consecutive probes fail, the system determines that the "Order Service" instance is in an unrecoverable "hanging" state.

[0132] Force recovery: The system actively sends a termination instruction to the JBOSS process of the "Order Service" to force it to exit; after the process exits, its running state is marked as "stopped" in the global state.

[0133] Automatic restart: In the next periodic scan, the system discovers that the running state of the "Order Service" is "stopped" and the "self-start" configuration is enabled, so it automatically triggers the restart process to restart the instance.

[0134] Result: After a short service jitter that external users might perceive, the "order service" has resumed normal operation. The system explicitly records in the log the event "detected instance zombie, forced termination and restart", providing key clues for the administrator to analyze the zombie reason (such as memory leak, deadlock) later.

[0135] Referring to Figure 3 The log aggregation and alarm analysis process shown in the figure describes the process of capturing logs, identifying exceptions, and generating alarms for the "order service" and "payment service" two JBOSS instances during operation; including:

[0136] 1) Real-time log capture and temporary file generation:

[0137] When the "order service" and "payment service" instances are successfully started, their console output is captured through an anonymous pipe.

[0138] Order service log stream: Assuming that the "order service" outputs a series of error logs due to database connection timeout, these log streams are received through the CreateLog logic;

[0139] Temporary file creation: The system creates a temporary log file named after the time (such as 20250821_100000.log) for the "order service";

[0140] Conditional trigger segmentation: When the size of the temporary log file exceeds 80KB, or the system detects a log ending with a line feed, and the last modified time of the temporary log file has exceeded 1 minute, the system will immediately close this temporary log file, and the corresponding file path will be added to the global pending file queue JbossLogFileList.

[0141] 2) Alarm rule matching and context extraction:

[0142] A separate background analysis thread (JbossLogProcess) continuously monitors the JbossLogFileList queue.

[0143] File consumption: The background analysis thread takes out the 20250821_100000.log temporary log file of the "order service" from the JbossLogFileList queue;

[0144] Rule matching: The background analysis thread reads the content of the temporary log file line by line, and when it reads a line containing the keywords ERROR and SQLException, the system matches it with the "database exception" alarm rule in the alarm rule library, and the matching is successful;

[0145] Context capture: The system not only records this line of error, but also continues to read the subsequent 5 lines of logs, which contain complete Java stack trace information, thus completely restoring the error scene.

[0146] 3) Alert information structuring and filing (showing detailed alert information):

[0147] JSON assembly: The system creates a JSON object according to the alert template preset by the "database exception" alert rule, which contains:

[0148] title: "Database connection exception"

[0149] date: "2025-08-21 10:05:30"

[0150] viewcontent: (captured error line and subsequent 5 lines of stack information)

[0151] desc: "JBOSS application cannot connect to the database."

[0152] resolve: "Check the status of the database service."

[0153] solution: "1. Check if the database server is running. 2. Verify the database connection configuration."

[0154] File writing: The system generates a file name (such as DBException_10_3.json) according to the current time and rules, and writes the above JSON data to the 2025_08_21 / subdirectory under the Web directory.

[0155] 4) Alert aggregation and dynamic update (showing alert summary information):

[0156] Change list addition: After successfully generating the DBException_10_3.json file, the system immediately appends a new record to the exception_changetable.json file in the root directory, which contains:

[0157] title: "Database connection exception"

[0158] url: "2025_08_21 / DBException_10_3.json"

[0159] warning: "1"

[0160] level: "0"

[0161] lastUpdate: "20250821100530000".

[0162] The application is based on Windows desktop application development, and does not need to modify JBOSS configuration or deploy additional services, and is easy to implement. By integrating the process daemon engine, abnormal automatic detection, alarm and restart are realized, and continuous operation of key business is ensured. By monitoring process crashes (such as abnormal exit, termination, access violation, etc.), the operating system will clean up the resources of the parent process, but will not automatically terminate the JBOSS child process created by it. And by non-intrusive collection of console log data, real-time aggregation display and abnormal template matching are supported, and the fault positioning speed is improved. The built-in HTTP service is convenient for docking with the existing monitoring system, and improves the platform scalability.

[0163] Referring to Figure 4 Fig. 1 shows a structural schematic diagram of a unified management device for multiple JBOSS instances according to an embodiment of the application.

[0164] In this embodiment, the device 20 comprises:

[0165] An instance starting unit 21 is configured to, when receiving an instance starting request, parse configuration information associated with a target JBOSS instance and create an independent management thread, start a JBOSS process in the management thread and create an anonymous pipe.

[0166] A daemon cycle unit 22 is configured to start a daemon cycle based on the management thread, periodically monitor the running state of the JBOSS process and capture log data through the anonymous pipe.

[0167] A rule matching unit 23 is configured to create a temporary log file corresponding to the log data, match the log data in the temporary log file with an alarm rule in a preset rule library based on the preset rule library, and obtain a matching result.

[0168] An alarm generating unit 24 is configured to generate structured alarm information according to a preset alarm template for a log event indicating a matching success in the matching result and store the alarm information in a log alarm list, and provide the running state of the target JBOSS instance and the log alarm list through an HTTP service interface.

[0169] Further, the device 20 further comprises:

[0170] A health check unit is configured to periodically detect the running state of all registered JBOSS instances, and detect the process survival and service health degree depth according to the running state; wherein,

[0171] The process survival detection comprises automatically triggering a starting process of the current JBOSS instance when a self-starting configuration flag in configuration information of the current JBOSS instance is detected to be self-starting and a process PID of the current JBOSS instance does not exist, and the starting process comprises creating a management thread, creating an anonymous pipe and starting a daemon loop.

[0172] The service health degree deep detection comprises network layer detection and application layer detection; the network layer detection comprises establishing a TCP connection through a listening port in configuration information corresponding to the JBOSS instance to verify whether the TCP port is in a listening state; the application layer detection comprises sending a preset application layer detection packet to the TCP port and waiting for a response if the TCP connection is successful.

[0173] The various unit modules of the device 20 can respectively execute the corresponding steps in the above method embodiments, so the unit modules will not be described here, and please refer to the above description of the corresponding steps for details.

[0174] The embodiment of the application further provides a unified management device of multiple JBOSS instances, which comprises the unified management device of multiple JBOSS instances as described above, wherein the unified management device of multiple JBOSS instances can adopt Figure 4 The structure of the embodiment, which can correspondingly execute Figure 1 The technical solutions of the method embodiments shown in the drawings have similar implementation principles and technical effects, and details can be referred to the above description of the embodiments, which will not be described here.

[0175] The device comprises a mobile phone, a digital camera, a tablet computer or the like having a photographing function, or a device having an image processing function, or a device having an image display function. The device can comprise a memory, a processor, an input unit, a display unit, a power supply and the like.

[0176] The memory can be used to store software programs and modules, and the processor can execute various function applications and data processing by running the software programs and modules stored in the memory. The memory can mainly comprise a program storage area and a data storage area, wherein the program storage area can store an operating system, application programs (such as an image playing function and the like) required by at least one function and the like; the data storage area can store data created according to the use of the device and the like. In addition, the memory can comprise a high-speed random access memory, and can also comprise a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device or other volatile solid-state storage device. Correspondingly, the memory can also comprise a memory controller to provide access of the processor and the input unit to the memory.

[0177] The input unit can be used to receive inputted digital or character or image information, and to generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function controls. Specifically, the input unit of the present embodiment can include a camera, in addition to a touch-sensitive surface (such as a touch display) and other input devices.

[0178] The display unit can be used to display information inputted by a user or provided to the user, and various graphical user interfaces of the device, which can be composed of graphics, text, icons, video and any combination thereof. The display unit can include a display panel, which can be configured in the form of an LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode), etc. Further, the touch-sensitive surface can cover the display panel, and when the touch-sensitive surface detects a touch operation thereon or nearby, it transmits to the processor to determine the type of touch event, and then the processor provides corresponding visual output on the display panel according to the type of touch event.

[0179] The present embodiment also provides a computer readable storage medium, which can be the computer readable storage medium contained in the memory in the above-mentioned embodiments; or can exist separately and not be assembled into the device. The computer readable storage medium stores at least one instruction, which is loaded and executed by the processor to implement Figure 1 the unified management method of multiple JBOSS instances shown. The computer readable storage medium can be a read-only memory, a disk or an optical disk, etc.

[0180] The present embodiment also provides a computer program product, which includes computer programs / instructions, which are loaded and executed by the processor to implement Figure 1 the unified management method of multiple JBOSS instances shown.

[0181] It should be noted that each embodiment in the present specification is described in a progressive manner, and each embodiment focuses on the difference from other embodiments, and the same and similar parts of each embodiment can be referred to. For the system embodiment, the device embodiment and the storage medium embodiment, since they are basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the part of the method embodiment.

[0182] Also, as used herein, the terms "comprise", "comprising", or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0183] The foregoing description shows and describes preferred embodiments of the application, but it is to be understood that the application is not limited to the particular examples, arrangements, or methodologies described, and that various other embodiments, modifications, and changes can be made thereto without departing from the spirit and scope of the application as set forth in the following claims.

Claims

1. A method for unified management of a plurality of JBOSS instances, characterized in that, The method comprises: Upon receiving an instance start request, parsing configuration information associated with a target JBOSS instance and creating an independent management thread, starting a JBOSS process in the management thread and creating an anonymous pipe; Based on starting a daemon cycle in the management thread, periodically monitoring the running state of the JBOSS process and capturing log data through the anonymous pipe; Creating a temporary log file corresponding to the log data, matching the log data in the temporary log file with alarm rules in a preset rule library based on a preset rule library, and obtaining a matching result; The log events indicating a successful match in the matching result are used to generate structured alarm information according to a preset alarm template and store them in a log alarm list, and the running state of the target JBOSS instance and the log alarm list are provided through an HTTP service interface.

2. The method of claim 1, wherein the method further comprises: The parsing of the configuration information associated with the target JBOSS instance and the creation of the independent management thread comprise: Based on the instance list of the integrated graphical management interface, the configuration information including the start script path, identification information, listening port, self-starting configuration flag and running state of the target JBOSS instance is obtained; According to the running state, it is judged whether the target JBOSS instance is running, if yes, the start request is rejected, otherwise, the management thread is created, wherein the management thread is used to execute tasks including process start, running state monitoring and log capture, and is decoupled from the main thread of the graphical management interface.

3. The method of claim 1, wherein the method further comprises: The starting of the JBOSS process in the management thread and the creation of the anonymous pipe comprise: Calling the API interface of the operating system and starting the JBOSS process based on the start script path; The anonymous pipe is created and the output stream and error stream of the JBOSS process are redirected to the write end of the anonymous pipe.

4. The method of claim 1, wherein the method further comprises: The starting of the daemon cycle in the management thread, periodically monitoring the running state of the JBOSS process and capturing log data through the anonymous pipe comprise: Using a preset function to listen to the handle of the JBOSS process, querying the running state of the JBOSS process, and judging whether the process is alive in real time according to the running state, if the handle is detected to be triggered, it is determined that the JBOSS process has terminated and the current daemon cycle is exited; By periodically checking whether there is log data to be read in the reading end of the anonymous pipe, if there is, the log data is read, the read log data is associated with the identification information of the target JBOSS instance, and the log data is pushed to the log display area of the graphical management interface in real time.

5. The method of claim 1, wherein the method further comprises: The creation of the temporary log file corresponding to the log data, the matching of the log data in the temporary log file with the alarm rules in the preset rule library comprise: automatically close the temporary log file and create a new temporary log file when the temporary log file meets preset conditions, and add paths of the temporary log file and the new temporary log file to a to-be-processed file queue; the preset conditions include that reading the log data to an end of a line and a size of the temporary log file exceeds a capacity threshold, or a modification time of the temporary log file exceeds a time threshold; a background analysis thread continuously acquires the to-be-processed temporary log file from the to-be-processed file queue, reads content in the temporary log file line by line, and matches the content with the alarm rule, where the alarm rule includes a keyword or a regular expression used for matching log key information.

6. The method of claim 1, wherein the method further comprises: The method further includes: Assembling the extracted log context, timestamp, alarm title, description, and solution into the structured JSON format alarm information according to the alarm template; writing the alarm information into a JSON alarm file under a preset Web service directory, and storing the JSON file as an alarm record in a log alarm list, where the alarm record includes an alarm title, a link, an alarm level, and a last update time.

7. The method of claim 1, wherein the method further comprises: The method further includes: periodically detecting running states of all registered JBOSS instances, and detecting process survival and service health depth according to the running states; where the process survival detection includes automatically triggering a start process of a current JBOSS instance when a self-starting configuration flag in configuration information of the current JBOSS instance is detected to be self-starting and a process PID of the current JBOSS instance does not exist, and the start process includes creating a management thread, creating an anonymous pipe, and starting a daemon loop; the service health depth detection includes network layer detection and application layer detection; where the network layer detection includes establishing a TCP connection to a listening port through the listening port in configuration information corresponding to the JBOSS instance to verify whether the TCP port is in a listening state; and the application layer detection includes sending a preset application layer detection packet to the TCP port and waiting for a response if the TCP connection is successful.

8. A unified management device for multiple JBoss instances, characterized in that, The apparatus includes: an instance start unit configured to, when an instance start request is received, parse configuration information associated with a target JBOSS instance, create an independent management thread, start a JBOSS process in the management thread, and create an anonymous pipe; a daemon loop unit configured to start a daemon loop based on the management thread, periodically monitor a running state of the JBOSS process, and capture log data through the anonymous pipe; a rule matching unit configured to create a temporary log file corresponding to the log data, match the log data in the temporary log file with alarm rules in a preset rule library, and obtain a matching result. An alarm generating unit is configured to generate structured alarm information according to a preset alarm template based on the log event indicating a successful match in the matching result and store the alarm information in a log alarm list, and provide the running state of the target JBOSS instance and the log alarm list through an HTTP service interface.

9. The apparatus for unified management of multiple JBOSS instances of claim 8, wherein, The device further comprises: A health check unit is configured to periodically detect the running state of all registered JBOSS instances, and detect the process survival and service health depth according to the running state; wherein, The process survival detection comprises automatically triggering the starting process of the current JBOSS instance when it is detected that the self-starting configuration flag in the configuration information of the current JBOSS instance is self-starting and the process PID of the current JBOSS instance does not exist, and the starting process comprises creating a management thread, creating an anonymous pipe and starting a daemon loop; The service health depth detection comprises network layer detection and application layer detection; wherein, the network layer detection comprises establishing a TCP connection with the listening port in the configuration information corresponding to the JBOSS instance to verify whether the TCP port is in a listening state; and the application layer detection comprises sending a preset application layer detection packet to the TCP port and waiting for a response if the TCP connection is successful.

10. A device for unified management of a plurality of JBOSS instances, characterized in that, A computer program stored in the memory is executed by the processor to implement the steps of the method for unified management of multiple JBOSS instances according to any one of claims 1 to 7.

Images