A unified management method, system, and device for multiple JBoss instances.

Abstract

This invention discloses a unified management method, apparatus, and device for multiple JBOSS instances, comprising: upon receiving an instance startup request, parsing the configuration information associated with the target JBOSS instance and creating an independent management thread; starting the JBOSS process and creating an anonymous pipe in the management thread; starting a daemon loop in the management thread, periodically monitoring the running status 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 base to obtain a matching result; generating structured alarm information from the log events indicating successful matching in the matching result according to a preset alarm template and storing it in a log alarm list; and providing the running status of the corresponding target JBOSS instance and the log alarm list through an HTTP service interface. This enables centralized management and real-time monitoring of multiple JBOSS instances, improving operational efficiency and system availability.

Description

Technical Field

[0001] This invention relates to the field of JBOSS instance management technology, and in particular to a unified management method, apparatus, and device for multiple JBOSS instances. Background Technology

[0002] With the increasing prevalence of distributed architectures, critical business systems are often broken down into multiple business subsystems (such as microservices or functional modules) and deployed independently. To improve resource utilization and deployment flexibility, multiple subsystem instances based on JBoss middleware are often centrally deployed on the same Windows server node. This deployment model results in each JBoss instance running as an independent process, appearing as a separate command-line console window at the operating system level. While this optimizes resource allocation to some extent, it also presents several operational challenges: numerous concurrent JBoss process windows crowd and overlap on the desktop or taskbar, making it difficult for administrators to quickly identify and locate target instances, leading to chaotic process management and low efficiency; and each JBoss instance's logs are output independently to its own working directory by default, resulting in logs scattered across multiple locations and making diagnosis difficult. Summary of the Invention

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

[0004] To achieve the above objectives, the present invention provides a unified management method for multiple JBoss instances, the method comprising:

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

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

[0007] Create a temporary log file corresponding to the log data, and match the log data in the temporary log file with the alarm rules in the preset rule base to obtain the matching result;

[0008] The log events indicating successful matching in the matching results are used to generate structured alarm information based on a preset alarm template and stored in the log alarm list. The running status of the target JBOSS instance and the log alarm list are provided through an HTTP service interface.

[0009] Preferably, the step of parsing the configuration information associated with the target JBoss instance and creating an independent management thread includes:

[0010] Based on the integrated graphical management interface, retrieve configuration information from the instance list, including the startup script path, identification information, listening port, auto-start configuration flag, and running status of the target JBOSS instance.

[0011] The system determines whether the target JBOSS instance is already running based on its running status. If so, the startup request is rejected; otherwise, the management thread is created. The management thread is used to perform tasks including process startup, running status monitoring, and log capture, and is decoupled from the main thread of the graphical management interface.

[0012] Preferably, starting the JBOSS process and creating an anonymous pipe in the management thread includes:

[0013] Call the operating system's API interface and start the JBOSS process based on the startup script path;

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

[0015] Preferably, the step of starting a daemon loop in the management thread to periodically monitor the running status of the JBOSS process and capture log data through the anonymous pipe includes:

[0016] The JBOSS process handle is monitored using a preset function to query the running status of the JBOSS process and to determine whether the process is alive in real time based on the running status. If the handle is detected to be triggered, the JBOSS process is determined to have terminated and the current guardian loop is exited.

[0017] 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.

[0018] Preferably, the step of creating a temporary log file corresponding to the log data, based on matching the alarm rules in a preset rule base with the log data in the temporary log file, includes:

[0019] When the temporary log file meets the preset conditions, the temporary log file is automatically closed and a new temporary log file is created. The path of the temporary log file and the path of the new temporary log file are added to the file queue to be processed. The preset conditions include reading the log data to the end of the line and the size of the temporary log file exceeds the capacity threshold, or the modification time of the temporary log file exceeds the time threshold.

[0020] The background analysis thread continuously retrieves the temporary log files to be processed from the queue of files to be processed, reads the contents of the temporary log files line by line and matches them with the alarm rules, wherein the alarm rules include keywords or regular expressions used to match key information in the logs.

[0021] Preferably, the step of generating structured alarm information from the log events indicating successful matching in the matching results according to a preset alarm template and storing it in the log alarm list includes:

[0022] The extracted alarm information, including log context, timestamp, alarm title, description, and solution, is assembled into a structured JSON format based on the alarm template.

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

[0024] Preferably, the method further includes:

[0025] Regularly check the running status of all registered JBoss instances, and perform in-depth checks on process liveness and service health based on the running status; among them,

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

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

[0028] To achieve the above objectives, the present invention also provides a unified management device for multiple JBoss instances, the device comprising:

[0029] The instance startup unit is used to parse the configuration information associated with the target JBOSS instance and create an independent management thread when it receives an instance startup request. In the management thread, the JBOSS process is started and an anonymous pipe is created.

[0030] The guardian loop unit is used to start a guardian loop based on the management thread, and periodically monitor the running status of the JBOSS process and capture log data through the anonymous pipe.

[0031] The rule matching unit is used to create a temporary log file corresponding to the log data, and match the log data in the temporary log file with the alarm rules in the preset rule base to obtain the matching result;

[0032] The alarm generation unit is used to generate structured alarm information from the log events indicating successful matching in the matching results according to a preset alarm template and store them in the log alarm list. It also provides the running status of the target JBOSS instance and the log alarm list through an HTTP service interface.

[0033] Preferably, the device further includes:

[0034] The health check unit is used to periodically check the running status of all registered JBoss instances, and to perform in-depth checks on process liveness and service health based on the running status; among them,

[0035] Process liveness detection includes automatically triggering the startup process of the current JBOSS instance when the auto-start configuration flag in the configuration information of the current JBOSS instance is detected to be set to auto-start and the process PID of the current JBOSS instance does not exist. The startup process includes creating a management thread, creating an anonymous pipe, and starting a daemon loop.

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

[0037] To achieve the above objectives, the present invention also proposes a unified management device for multiple JBOSS instances, including a processor, a memory, and a computer program stored in the memory, wherein the computer program is executed by the processor to implement the steps of a unified management method for multiple JBOSS instances as described in the above embodiments.

[0038] To achieve the above objectives, the present invention also proposes a computer-readable storage medium storing a computer program that is executed by a processor to implement the steps of a unified management method for multiple JBOSS instances as described in the above embodiments.

[0039] To achieve the above objectives, the present invention also proposes a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of a unified management method for multiple JBOSS instances as described in the above embodiments.

[0040] Beneficial effects:

[0041] The above solution creates a management thread, anonymous pipes, and a startup daemon loop based on the startup request, enabling centralized management and real-time monitoring of multiple JBOSS instances. This improves operational efficiency and avoids the problems of window clutter and misoperation in traditional operations. By using anonymous pipes to capture log data and create temporary log files, it achieves centralized log aggregation and intelligent alarms, facilitating rapid problem location. The solution provides running status and log alarm lists through an HTTP service interface, facilitating integration with external monitoring systems and improving system scalability.

[0042] The graphical management interface allows administrators to view instance status intuitively through an instance list, making operations more convenient. The system checks if an instance is already running before creating a management thread, avoiding duplicate startups. The management thread is decoupled from the main thread, ensuring that the management of each instance does not interfere with each other, thus improving system stability. Starting the JBoss process by calling the operating system's API ensures standardization and controllability of the startup process. Redirecting output and error streams to anonymous pipes eliminates the need for administrators to search for target instance logs in stacked command-line windows, improving log management efficiency.

[0043] By using functions to monitor process handles and periodically checking log data in anonymous pipes, the system's reliability and real-time performance are enhanced. The presence of a daemon loop allows the system to proactively detect process exits or log anomalies, providing timely feedback to administrators and significantly improving operational response speed. Log files are segmented based on conditions, making them easier to manage and retrieve, avoiding performance bottlenecks caused by excessively large files. Background threads are used to match alarm rules, enhancing the intelligence of alarms and helping operations personnel quickly locate anomalies. Matched alarm information is assembled into JSON format and stored in a web service directory for easy integration with external systems (such as monitoring platforms or analysis tools). The JSON format makes data more standardized and easier to parse, reducing the burden of manual processing.

[0044] By introducing a deep detection mechanism for process survival and service health, it can not only deal with process crashes, but also detect and recover from "fake" states; through network layer and application layer detection, it more comprehensively covers all possible abnormal scenarios, ensuring the stability and reliability of the system. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a flowchart illustrating a unified management method for multiple JBOSS instances provided in an embodiment of the present invention.

[0047] Figure 2 This is a schematic diagram of an integrated process for centralized management and process protection provided in an embodiment of the present invention.

[0048] Figure 3 This is a schematic diagram of a log aggregation and alarm analysis process provided in an embodiment of the present invention.

[0049] Figure 4 This is a schematic diagram of the structure of a unified management device for multiple JBOSS instances provided in an embodiment of the present invention.

[0050] The realization of the invention's objective, its functional characteristics, and advantages will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[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] Therefore, this application provides a unified centralized management console to enable convenient start-up, shutdown, status monitoring, and visualization of all JBOSS instances; supports real-time log aggregation, centralized display, and advanced retrieval, breaking down the barriers of scattered logs; and integrates a process protection engine to provide real-time health monitoring of JBOSS processes, automatically triggering alarms and executing preset recovery strategies (such as automatic restart) when a process exits abnormally, ensuring the continuous and stable operation of critical business processes and significantly improving the overall availability and resilience of the system.

[0061] The present invention will be described in detail below with reference to the embodiments.

[0062] Reference Figure 1 The diagram shown is a flowchart illustrating a unified management method for multiple JBOSS instances according to an embodiment of the present invention.

[0063] In this embodiment, the method includes:

[0064] S11, When an instance startup request is received, the configuration information associated with the target JBOSS instance is parsed and an independent management thread is created. In the management thread, the JBOSS process is started and an anonymous pipe is created.

[0065] Furthermore, in step S11, parsing the configuration information associated with the target JBOSS instance and creating an independent management thread includes:

[0066] S11-1, Based on the instance list of the integrated graphical management interface, obtain configuration information including the startup script path, identification information, listening port, auto-start configuration flag, and running status of the target JBOSS instance;

[0067] S11-2, determine whether the target JBOSS instance is already running based on the running status. If so, reject the startup request; otherwise, create the management thread. The management thread is used to perform tasks including process startup, running status monitoring, and log capture, and is decoupled from the main thread of the graphical management interface.

[0068] Furthermore, in step S11, starting the JBOSS process and creating an anonymous pipe in the management thread includes:

[0069] S11-3, Call the operating system's API interface and start the JBOSS process based on the startup script path;

[0070] S11-4, Create the anonymous pipe and redirect the output stream and error stream of the JBOSS process to the write end of the anonymous pipe.

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

[0072] When the instance startup command is received, the system performs the following steps:

[0073] (1) Parse the configuration information associated with the target JBOSS instance, obtain its startup script path, window title and other parameters, check whether the instance is already running, and if so, reject the repeated startup request.

[0074] (2) Create an independent management thread for this instance. This management thread is responsible for executing all background tasks such as subsequent process startup, monitoring and log capture, thereby decoupling the main thread (GUI) from the background tasks.

[0075] (3) In the management thread, the operating system API interface is called to start the JBOSS process based on the corresponding startup script path; when creating the child process, its standard output (stdout) stream and standard error (stderr) stream are configured to be redirected to the write end of an anonymous pipe. This allows the console output of the JBOSS instance to no longer be displayed in a separate window, but to be captured by the system background.

[0076] S12, based on the start of the guardian loop in the management thread, the running status of the JBOSS process is periodically monitored and log data is captured through the anonymous pipe.

[0077] Furthermore, in step S12, the step of starting a daemon loop in the management thread to periodically monitor the running status of the JBOSS process and capture log data through the anonymous pipe includes:

[0078] S12-1, Use a preset function to monitor the handle of the JBOSS process, query the running status of the JBOSS process, and determine whether the process is alive in real time based on the running status. If the handle is detected to be triggered, determine that the JBOSS process has terminated and exit the current guardian loop.

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

[0080] In this embodiment, a daemon object is created and initialized. This daemon object holds the handle of the child process and the read end of the pipe, and its core daemon loop is started, executing the following:

[0081] (1) Capture the JBOSS console output stream (stdout / stderr) through an anonymous pipe, periodically check if there is log data to be read in the anonymous pipe, and if so, read the log data content from the reading end of the anonymous pipe.

[0082] (2) Associate the read log data with the instance's identification information (e.g., add the prefix "[Instance Name]"), and push it to the log display area of ​​the graphical management interface in real time in a thread-safe manner to achieve centralized and orderly display of all instance logs;

[0083] (3) In the guardian loop, use the Windows API WaitForSingleObject to listen to the handle of the child process, query the running status of the child process in a non-blocking manner, and determine whether the child process is alive in real time. If the child process is detected to have terminated, exit the guardian loop immediately, marking the end of the guardian cycle.

[0084] (4) Receive user intervention instructions. If a "stop" instruction is received from the user, the daemon mechanism will actively send a termination signal to the child process to force it to exit.

[0085] S13, create a temporary log file corresponding to the log data, and match the log data in the temporary log file with the alarm rules in the preset rule base to obtain the matching result.

[0086] Furthermore, in step S13, creating a temporary log file corresponding to the log data, and matching the log data in the temporary log file with the alarm rules in the preset rule base, includes:

[0087] S13-1, When the temporary log file meets the preset conditions, the temporary log file is automatically closed and a new temporary log file is created, and the path of the temporary log file and the new temporary log file are added to the file queue to be processed; wherein, the preset conditions include reading the log data to the end of the line and the size of the temporary log file exceeds the capacity threshold, or the modification time of the temporary log file exceeds the time threshold.

[0088] S13-2, the background analysis thread continuously retrieves the temporary log files to be processed from the queue of files to be processed, reads the contents of the temporary log files line by line and matches them with the alarm rules, wherein the alarm rules include keywords or regular expressions used to match key information in the logs.

[0089] This embodiment aims to achieve 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 ultimately present it in a user-friendly manner, solving the problems of scattered logs, difficult analysis, and untimely alarms in traditional systems. It receives the output streams of the raw consoles of each JBOSS instance captured through anonymous pipes and creates independent temporary log files for each JBOSS instance's real-time log stream. When a temporary log file meets specific conditions (such as the log reaching the end of a line and the temporary log file size exceeding a threshold, or the temporary log file modification time exceeding a threshold), the current temporary log file is automatically closed and a new file is generated, ensuring orderly log segmentation. The paths of the generated and closed temporary log files are added to a global pending file queue for subsequent analysis threads to consume.

[0090] The system maintains a pre-defined alarm rule library. Each alarm rule contains one or more keywords or regular expressions used to match key information in the logs. The background analysis thread continuously retrieves temporary log files from the queue of files to be processed. When a log line successfully matches a keyword of an alarm rule, the system not only captures that log line but also extracts several subsequent log lines as context information to fully present the stack trace or related operation sequence at the time of the error.

[0091] S14, the log events indicating successful matching in the matching results are used to generate structured alarm information according to a preset alarm template and stored in the log alarm list. The running status of the target JBOSS instance and the log alarm list are provided through the HTTP service interface.

[0092] Furthermore, in step S14, generating structured alarm information from the log events indicating successful matching in the matching results according to a preset alarm template and storing it in the log alarm list includes:

[0093] S14-1, Based on the alarm template, the extracted alarm information, including log context, timestamp, alarm title, description, and solution, is assembled into a structured JSON format.

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

[0095] In this embodiment, for successfully matched log events, the system, based on a preset alarm template, assembles the extracted information, including log context, timestamp, alarm title, description, and solution, into structured JSON format alarm information. The generated JSON alarm information is then written to a specific JSON alarm file in a preset web service directory for easy front-end display. The system maintains a log alarm list (e.g., exception_changetable.json). Whenever a new JSON alarm file is generated, the system dynamically appends an alarm record to the log alarm list. This record contains metadata such as the alarm title, URL, alarm level, and last update time. When the system date changes, the previous day's "log alarm list" file is automatically archived to the directory corresponding to that date, achieving periodic log organization.

[0096] It also exposes a JSON-RPC interface to the outside world through an embedded self-developed lightweight HTTP service, providing the running status, log and alarm list, and system health status of all current JBOSS instances. It also supports integration with external monitoring systems or operation and maintenance portals to achieve remote status acquisition and alarm linkage.

[0097] Furthermore, the method also includes:

[0098] Regularly check the running status of all registered JBoss instances, and perform in-depth checks on process liveness and service health based on the running status; among them,

[0099] Process liveness detection includes automatically triggering the startup process of the current JBOSS instance when the auto-start configuration flag in the configuration information of the current JBOSS instance is detected to be set to auto-start and the process PID of the current JBOSS instance does not exist. The startup process includes creating a management thread, creating an anonymous pipe, and starting a daemon loop.

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

[0101] In this embodiment, the system has a built-in periodic status check task that periodically scans the current running status of all registered JBoss instances and performs in-depth detection of process liveness and service health based on the running status. Specifically:

[0102] Process liveness detection: When the inspection task finds that the "auto-start" 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 (that is, re-execute the above startup process steps, such as the specific process of creating a management thread, creating an anonymous pipe and starting the daemon loop).

[0103] Deep service health check: For JBoss instances with a running status of "Running", the system further performs a deep service health check, which includes two levels:

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

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

[0106] False Dead Detection and Forced Recovery: If multiple consecutive (e.g., 3) deep probing attempts for service health fail (including TCP connection failures or no effective response from the application layer), the JBoss instance is determined to be in a "false dead" state. The system will then proactively terminate the abnormal process and immediately trigger its automatic restart process. This mechanism forms a multi-layered, closed-loop monitoring and recovery system from "process survival" to "service availability," effectively handling not only process crashes but also complex faults such as process deadlocks, greatly improving the availability and resilience of critical business systems.

[0107] Furthermore, all changes to the running status (such as "Running" or "Stopped") are updated to the global status data structure and the instance list in the graphical management interface through a synchronization mechanism, ensuring information consistency and real-time performance. Users can intuitively view the running status of each JBoss instance through this interface and perform operations such as starting and stopping, with all operation results provided in real time.

[0108] The following is an example to illustrate this:

[0109] Reference Figure 2 The integrated centralized management and process protection process shown includes:

[0110] 1) Initial configuration and interface loading:

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

[0112] JBOSS Example 1: The application name is "Order Service", the startup script path is C:\jboss\orderservice\bin\standalone.bat, the listening port is 8081, and automatic startup is enabled;

[0113] JBOSS Example 2: The application name is "Payment Service", the startup script path is C:\jboss\paymentservice\bin\standalone.bat, the listening port is 8082, and auto-start is not enabled.

[0114] The administrator starts the graphical management application. After the application loads the configuration, the two JBOSS instances are clearly listed in the instance list of the graphical management interface, and their "running status" is initially "unknown".

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

[0116] Verification and thread creation: The system first queries the global status to confirm that the instance is not running and the verification passes. Then the system creates a separate management thread for "Order Service".

[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. The system creates an anonymous pipe and redirects the standard output stream and standard error stream of the JBOSS process to the write end of this anonymous pipe; therefore, the administrator will not see any new command line windows pop up.

[0118] The daemon loop starts: The system initializes a daemon object that holds a handle to the JBOSS process and a reference to the anonymous pipe reader, and immediately enters its daemon loop.

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

[0120] The system continuously reads log data in a loop: It periodically checks the anonymous pipe. When the JBoss instance of the "Order Service" starts outputting startup logs, the system reads log data from the anonymous pipe (see the log aggregation and alarm analysis process section below for details), 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 output in the GUI window of this service.

[0121] Running status monitoring: The process handle is monitored in a loop without blocking. Once the "Order Service" instance has started and entered a stable running state, monitoring continues; the running status of the "Order Service" instance in the GUI interface is automatically updated to "Running".

[0122] 4) Starting and stopping the "Payment Service" instance:

[0123] The "Payment Service" instance does not have the auto-start flag enabled. Administrators need to select the "Payment Service" list item in the service list and click the start button. The system will perform the exact same process as the "Order Service" instance (create thread, redirect startup, log capture, etc.), and its running status will also be updated to "Running".

[0124] After a period of time, the administrator needs to maintain the "Payment Service" instance. They select the "Payment Service" list item and click the "Stop" button. Upon receiving the "Stop" command, the daemon loop mechanism immediately sends a termination signal to the JBoss process of the "Payment Service" instance, forcing it to exit. After detecting the process termination, the daemon loop exits, the system updates the running status of the "Payment Service" instance to "Stopped," and records in the log that "Payment Service" has stopped.

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

[0126] 5.1) Unexpected Process Crash: Suppose that for some unknown reason, the JBOSS process of the "Order Service" instance unexpectedly crashes and exits; the system's built-in periodic status check task (e.g., running every 15 seconds) finds that the process PID of "Order Service" does not exist during the next scan, but its "auto-start" flag is enabled in its configuration. The system then automatically triggers the restart process of "Order Service," including creating a management thread, redirecting the startup child process, and initializing the daemon loop. Before the administrator notices, the "Order Service" instance has been automatically restarted and is running again; the system logs the restart event, reminding the administrator to investigate the cause of the crash.

[0127] 5.2) Process Hanging: Suppose that after running under high load for a long time, the "Order Service" instance, due to resource exhaustion (such as a full thread pool or database connection leak), causes its JBOSS process to still be running (the PID exists at the operating system level), but it is unable to respond to any external requests, i.e., it enters a "hanging" state. The system's built-in periodic health check task begins 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 probe message (such as a simulated login request) to this port and waits for a response.

[0130] Probe failed: The service is inactive and unable to process the request. The system did not receive a valid response within the timeout period, so this probe is considered a failure.

[0131] False Death Detection: The health check task records this failure; the situation remains the same in the next two probes (30-second interval). When three consecutive probes fail, the system determines that the "Order Service" instance is in an unrecoverable "false death" state.

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

[0133] Automatic restart: During the next periodic scan, if the system finds that the "Order Service" is in the "Stopped" running status and is configured to "Auto Start", it will automatically trigger the restart process to restart the instance.

[0134] Result: After a brief period of service fluctuation that external users might only perceive, the "Order Service" returned to normal operation. The system clearly recorded the event "Instance deadlock detected, forcibly terminated and restarted" in the logs, providing crucial clues for administrators to analyze the cause of the deadlock (such as memory leaks or deadlocks).

[0135] Reference Figure 3 The log aggregation and alarm analysis process shown describes how two JBoss instances, "Order Service" and "Payment Service," capture logs, identify anomalies, and generate alarms during operation; including:

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

[0137] Once the "Order Service" and "Payment Service" instances are successfully started, their console output is captured via an anonymous pipe.

[0138] Order Service Log Stream: Suppose that the "Order Service" outputs a series of error logs due to a database connection timeout, and these log streams are received through the CreateLog logic;

[0139] Temporary file creation: The system creates a temporary log file named after the time for "Order Service" (e.g., 20250821_100000.log);

[0140] Condition-triggered splitting: When the size of the temporary log file exceeds 80KB, or the system detects a log file ending with a newline character and the last modification time of the temporary log file has exceeded 1 minute, the system will immediately close the temporary log file and add the corresponding file path to the global pending file queue JbossLogFileList.

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

[0142] The JbossLogFileList queue is continuously monitored through a separate background analysis thread (JbossLogProcess).

[0143] File consumption: The background analysis thread retrieves the temporary log file 20250821_100000.log for "Order Service" from the JbossLogFileList queue;

[0144] Rule matching: The background analysis thread reads the contents of the temporary log file line by line. 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 base. If the match is successful, the system will match the line.

[0145] Context capture: The system not only logged this line of error, but also continued to read the next 5 lines of logs, which contained complete Java stack trace information, thus fully reconstructing the error situation.

[0146] 3) Structured and documented alarm information (displaying detailed alarm information):

[0147] JSON Assembly: The system creates a JSON object based on the preset alarm template of the "database anomaly" alarm rules. This object contains:

[0148] title: "Database connection error"

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

[0150] viewcontent: (The captured error line and the following 5 lines of stack trace information)

[0151] The message "JBoss application cannot connect to the database" is displayed under the command "desc".

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

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

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

[0155] 4) Alarm aggregation and dynamic updates (displaying alarm summary information):

[0156] Change list append: 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. This record contains:

[0157] title: "Database connection error"

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

[0159] warning:"1"

[0160] level:"0"

[0161] lastUpdate: "20250821100530000".

[0162] This project is based on Windows desktop application development, requiring no modification to JBOSS configuration or deployment of additional services, making it easy to implement. By integrating a process daemon engine, it achieves automatic anomaly detection, alerting, and restarting, ensuring the continuous operation of critical business processes. By monitoring process crashes (such as abnormal exits, termination, or access violations), the operating system cleans up the parent process's resources but does not automatically terminate any JBOSS child processes it created. Furthermore, by non-intrusively collecting console log data, it supports real-time aggregation and display, as well as anomaly template matching, improving the speed of fault location. Built-in HTTP service facilitates integration with existing monitoring systems, enhancing platform scalability.

[0163] Reference Figure 4 The diagram shown is a structural schematic of a unified management device for multiple JBOSS instances provided in an embodiment of the present invention.

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

[0165] The instance startup unit 21 is used to parse the configuration information associated with the target JBOSS instance and create an independent management thread when it receives an instance startup request, and to start the JBOSS process and create an anonymous pipe in the management thread.

[0166] The guardian loop unit 22 is used to start a guardian loop based on the management thread, and periodically monitor the running status of the JBOSS process and capture log data through the anonymous pipe.

[0167] Rule matching unit 23 is used to create a temporary log file corresponding to the log data, and match the log data in the temporary log file with the alarm rules in the preset rule base to obtain a matching result;

[0168] The alarm generation unit 24 is used to generate structured alarm information from the log events indicating successful matching in the matching results according to a preset alarm template and store them in the log alarm list, and provide the running status of the target JBOSS instance and the log alarm list through the HTTP service interface.

[0169] Furthermore, the device 20 also includes:

[0170] The health check unit is used to periodically check the running status of all registered JBoss instances, and to perform in-depth checks on process liveness and service health based on the running status; among them,

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

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

[0173] Each unit module of the device 20 can execute the corresponding steps in the above method embodiment, so the details of each unit module will not be elaborated here. Please refer to the description of the corresponding steps above for details.

[0174] This invention also provides a unified management device for multiple JBoss instances. The device includes the unified management apparatus for multiple JBoss instances described above, wherein the unified management apparatus for multiple JBoss instances can employ... Figure 4 The structure of the embodiment, correspondingly, can be executed Figure 1 The technical solutions of the method embodiments shown are similar in implementation principle and technical effect. For details, please refer to the relevant records in the above embodiments, which will not be repeated here.

[0175] The device includes: a mobile phone, digital camera, or tablet computer, or other device with a camera function; or a device with an image processing function; or a device with an image display function. The device may include components such as a memory, processor, input unit, display unit, and power supply.

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

[0177] The input unit can be used to receive input numerical, character, or image information, and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control. Specifically, in addition to a camera, the input unit of this embodiment may also include a touch-sensitive surface (e.g., a touch screen) and other input devices.

[0178] The display unit can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. The display unit may include a display panel, optionally configured as an LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode), or other similar display panel. Furthermore, a touch-sensitive surface may cover the display panel. When the touch-sensitive surface detects a touch operation on or near it, it transmits the information to the processor to determine the type of touch event. Subsequently, the processor provides corresponding visual output on the display panel based on the type of touch event.

[0179] This invention also provides a computer-readable storage medium, which may be a computer-readable storage medium included in the memory described in the above embodiments; or it may be a standalone computer-readable storage medium not assembled into a device. The computer-readable storage medium stores at least one instruction, which is loaded and executed by a processor to implement... Figure 1 This illustrates a unified management method for multiple JBoss instances. The computer-readable storage medium can be a read-only memory, a hard disk, or an optical disk, etc.

[0180] This invention also provides a computer program product, including a computer program / instructions, which are loaded and executed by a processor to achieve [the desired result]. Figure 1 This illustrates a unified management method for multiple JBoss instances.

[0181] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, device embodiments, and storage medium embodiments, since they are basically similar to the method embodiments, the descriptions are relatively simple, and relevant parts can be referred to the descriptions in the method embodiments.

[0182] Furthermore, in this document, 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. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0183] The foregoing description illustrates and describes preferred embodiments of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the inventive concept by means of the foregoing teachings or techniques or knowledge in related fields. Any modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A unified management method for multiple JBoss instances, characterized in that, The method includes: Upon receiving an instance startup request, the configuration information associated with the target JBoss instance is parsed and an independent management thread is created. Within this management thread, the JBoss process is started and an anonymous pipe is created. The step of starting the JBoss process and creating the anonymous pipe within the management thread includes: The operating system's API interface is invoked, and the JBOSS process is started based on the startup script path; Create the anonymous pipe and redirect the output stream and error stream of the JBOSS process to the write end of the anonymous pipe; Based on the daemon loop started in the management thread, the running status of the JBOSS process is periodically monitored and log data is captured through the anonymous pipe; including: The JBOSS process handle is monitored using a preset function to query the running status of the JBOSS process and to determine whether the process is alive in real time based on the running status. If the handle is detected to be triggered, the JBOSS process is determined to have terminated and the current guardian loop 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. Create a temporary log file corresponding to the log data, and match the log data in the temporary log file with the alarm rules in the preset rule base to obtain the matching result; The log events indicating successful matching in the matching results are used to generate structured alarm information based on a preset alarm template and stored in the log alarm list. The running status of the target JBOSS instance and the log alarm list are provided through the HTTP service interface. Regularly check the running status of all registered JBoss instances, and perform in-depth checks on process liveness and service health based on the running status; among them, Process liveness detection includes automatically triggering the startup process of the current JBOSS instance when the auto-start configuration flag in the configuration information of the current JBOSS instance is detected to be set to auto-start and the process PID of the current JBOSS instance does not exist. The startup process includes creating a management thread, creating an anonymous pipe, and starting a daemon loop. Service health deep detection includes network layer detection and application layer detection; wherein, the network layer detection includes establishing a TCP connection to the 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; the application layer detection includes sending a preset application layer probe message to the TCP port and waiting for a response if the TCP connection is successful; If the service health deep probe fails multiple times in a row, the JBOSS instance is determined to be in a dead state, the corresponding JBOSS process is actively terminated, and the automatic restart process of the JBOSS instance is immediately triggered.

2. The unified management method for multiple JBoss instances according to claim 1, characterized in that, The process of parsing the configuration information associated with the target JBoss instance and creating an independent management thread includes: Based on the integrated graphical management interface, retrieve configuration information from the instance list, including the startup script path, identification information, listening port, auto-start configuration flag, and running status of the target JBOSS instance. The system determines whether the target JBOSS instance is already running based on its running status. If so, the startup request is rejected; otherwise, the management thread is created. The management thread is used to perform tasks including process startup, running status monitoring, and log capture, and is decoupled from the main thread of the graphical management interface.

3. The unified management method for multiple JBoss instances according to claim 1, characterized in that, The step of creating a temporary log file corresponding to the log data, and matching the log data in the temporary log file with the alarm rules in the preset rule base, includes: When the temporary log file meets the preset conditions, the temporary log file is automatically closed and a new temporary log file is created. The path of the temporary log file and the path of the new temporary log file are added to the file queue to be processed. The preset conditions include reading the log data to the end of the line and the size of the temporary log file exceeds the capacity threshold, or the modification time of the temporary log file exceeds the time threshold. The background analysis thread continuously retrieves the temporary log files to be processed from the queue of files to be processed, reads the contents of the temporary log files line by line and matches them with the alarm rules, wherein the alarm rules include keywords or regular expressions used to match key information in the logs.

4. The unified management method for multiple JBoss instances according to claim 1, characterized in that, The step of generating structured alarm information from the log events indicating successful matches in the matching results according to a preset alarm template and storing them in the log alarm list includes: The extracted alarm information, including log context, timestamp, alarm title, description, and solution, is assembled into a structured JSON format based on the alarm template. The alarm information is written to a JSON alarm file in a preset Web service directory, and the JSON file is stored as an alarm record in the log alarm list. The alarm record includes the alarm title, link, alarm level, and last update time.

5. A unified management device for multiple JBoss instances, characterized in that, The apparatus for using the unified management method for multiple JBoss instances according to any one of claims 1-4 includes: The instance startup unit is used to parse the configuration information associated with the target JBOSS instance and create an independent management thread when it receives an instance startup request. In the management thread, the JBOSS process is started and an anonymous pipe is created. The guardian loop unit is used to start a guardian loop based on the management thread, and periodically monitor the running status of the JBOSS process and capture log data through the anonymous pipe. The rule matching unit is used to create a temporary log file corresponding to the log data, and match the log data in the temporary log file with the alarm rules in the preset rule base to obtain the matching result; The alarm generation unit is used to generate structured alarm information from the log events indicating successful matching in the matching results according to a preset alarm template and store them in the log alarm list. It also provides the running status of the target JBOSS instance and the log alarm list through an HTTP service interface.

6. A unified management device for multiple JBoss instances according to claim 5, characterized in that, The device further includes: The health check unit is used to periodically check the running status of all registered JBoss instances, and to perform in-depth checks on process liveness and service health based on the running status; among them, Process liveness detection includes automatically triggering the startup process of the current JBOSS instance when the auto-start configuration flag in the configuration information of the current JBOSS instance is detected to be set to auto-start and the process PID of the current JBOSS instance does not exist. The startup process includes creating a management thread, creating an anonymous pipe, and starting a daemon loop. The deep service health check includes network layer probing and application layer probing. The network layer probing includes establishing a TCP connection to the listening port in the configuration information corresponding to the JBOSS instance to verify whether the TCP port is in a listening state. The application layer probing includes sending a preset application layer probing message to the TCP port and waiting for a response if the TCP connection is successful.

7. A unified management device for multiple JBoss instances, characterized in that, The method includes 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 a unified management method for multiple JBOSS instances as described in any one of claims 1 to 4.

Images