CN112052133A - Service system monitoring method and device based on Kubernetes - Google Patents
Service system monitoring method and device based on Kubernetes Download PDFInfo
- Publication number
- CN112052133A CN112052133A CN201910492965.XA CN201910492965A CN112052133A CN 112052133 A CN112052133 A CN 112052133A CN 201910492965 A CN201910492965 A CN 201910492965A CN 112052133 A CN112052133 A CN 112052133A
- Authority
- CN
- China
- Prior art keywords
- task
- kubernetes
- data
- monitoring
- service system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3017—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is implementing multitasking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45587—Isolation or security of virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/48—Indexing scheme relating to G06F9/48
- G06F2209/484—Precedence
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5021—Priority
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Quality & Reliability (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses a service system monitoring method and device based on Kubernetes, and relates to the technical field of computers. One embodiment of the method comprises: collecting log data generated after a Kubernetes system executes a task script submitted by a service system and running data of the Kubernetes system; the service system is deployed in a Kubernetes system; determining task data when the business system operates according to the log data, matching the task data with a preset first monitoring rule, and matching the operating data with a preset second monitoring rule; and triggering monitoring early warning when the task data meets the alarm triggering condition of the first monitoring rule and/or the operation data meets the alarm triggering condition of the second monitoring rule. According to the method, task data when a service system deployed in a Kubernetes system runs and running data of the Kubernetes system are obtained, the data are matched with a preset monitoring rule to trigger monitoring early warning, and unified monitoring of the Kubernetes system and the service system is achieved.
Description
Technical Field
The invention relates to the field of computers, in particular to a service system monitoring method and device based on Kubernetes.
Background
The Kubernetes system is based on the Borg system inside google, and provides an application-oriented container cluster deployment and management system. The service system is constructed based on the Kubernetes system, and efficient and stable technical service can be provided for the service system. How to monitor the resource use condition of the Kubernetes system and the task execution condition of the service system in a unified manner is a basic guarantee for stable operation of the system.
In the process of implementing the invention, the inventor finds that at least the following problems exist in the prior art:
in the prior art, the unified monitoring of a Kubernetes system and a service system cannot be realized.
Disclosure of Invention
In view of this, embodiments of the present invention provide a service system monitoring method and apparatus based on Kubernetes, where task data when a service system deployed in the Kubernetes system operates and operation data of the Kubernetes system are obtained, and the data are matched with a preset monitoring rule to trigger monitoring and early warning, so that unified monitoring of the Kubernetes system and the service system is achieved.
In order to achieve the above object, according to an aspect of the embodiments of the present invention, a service system monitoring method based on Kubernetes is provided.
The business system monitoring method based on Kubernetes in the embodiment of the invention comprises the following steps: collecting log data generated after a Kubernetes system executes a task script submitted by a service system and running data of the Kubernetes system; wherein the service system is deployed in the Kubernetes system; determining task data when the business system operates according to the log data, matching the task data with a preset first monitoring rule, and matching the operating data with a preset second monitoring rule; and triggering monitoring early warning when the task data meets the alarm triggering condition of the first monitoring rule and/or the operation data meets the alarm triggering condition of the second monitoring rule.
Optionally, the method further comprises: calling a label management interface of the Kubernetes system to mark idle resources of the Kubernetes system with a label of the service system; and distributing part or all of the idle resources as newly added resources to the tasks to be executed of the service system through the Kubernetes system.
Optionally, deploying the service system to the kubernets system, executing a task script submitted by the service system by the kubernets system, and generating log data, where the task script is generated by the kubernets system, and the method includes: the service system issues a mirror image of an application program to a mirror image library, submits a task script to the script library and sends a task request to a Kubernetes system; after the Kubernetes system determines that the mirror image of the application program does not exist locally, the Kubernetes system pulls the mirror image from the mirror image library and downloads the task script from the script library; the Kubernetes system executes the task script to generate log data.
Optionally, the method further comprises: judging the size of the target resource and the newly added resource which are applied by the service system for the task to be executed; if the newly added resource is smaller than the target resource and the newly added resource meets the task to be executed with high priority, distributing the newly added resource to the task to be executed with high priority; if the newly added resource is smaller than the target resource and the newly added resource does not meet the task to be executed with the high priority, terminating the specified task to be executed according to the execution evaluation result of the running task, and distributing the newly added resource to the task to be executed which is not terminated.
Optionally, the method further comprises: if the priorities of the tasks to be executed are the same, dynamically adjusting the execution sequence of the tasks to be executed according to the historical running time length and the resource use data of the tasks to be executed so as to preferentially execute the tasks to be executed with short historical running time length or low resource use.
In order to achieve the above object, according to another aspect of the embodiments of the present invention, a service system monitoring apparatus based on Kubernetes is provided.
The invention provides a service system monitoring device based on Kubernetes, which comprises: the system comprises an acquisition module and a processing module, wherein the acquisition module is used for acquiring log data generated after a Kubernets system executes a task script submitted by a service system and running data of the Kubernets system; wherein the service system is deployed in the Kubernetes system; the matching module is used for determining task data when the business system operates according to the log data, matching the task data with a preset first monitoring rule and matching the operating data with a preset second monitoring rule; and the triggering module is used for triggering monitoring early warning when the task data meets the alarm triggering condition of the first monitoring rule and/or the operation data meets the alarm triggering condition of the second monitoring rule.
Optionally, the apparatus further comprises: the resource adjusting module is used for calling a label management interface of the Kubernets system so as to print the idle resources of the Kubernets system with the label of the service system; and distributing part or all of the idle resources as newly added resources to the tasks to be executed of the service system through the Kubernetes system.
Optionally, the apparatus further comprises: the deployment operation module is used for the service system to issue the mirror image of the application program to the mirror image library, submit the task script to the script library and send the task request to the Kubernetes system; after the Kubernetes system determines that the mirror image of the application program does not exist locally, the Kubernetes system pulls the mirror image from the mirror image library and downloads the task script from the script library; and the Kubernetes system executes the task script to generate log data.
Optionally, the apparatus further comprises: the resource allocation module is used for judging the sizes of the target resource and the newly added resource which are applied by the service system for the task to be executed; if the newly added resource is smaller than the target resource and the newly added resource meets the task to be executed with high priority, distributing the newly added resource to the task to be executed with high priority; and if the newly added resource is smaller than the target resource and the newly added resource does not meet the task to be executed with the high priority, terminating the specified task to be executed according to the execution evaluation result of the running task, and distributing the newly added resource to the task to be executed which is not terminated.
Optionally, the apparatus further comprises: and the task scheduling module is used for dynamically adjusting the execution sequence of the tasks to be executed according to the historical running time and the resource use data of the tasks to be executed if the priorities of the tasks to be executed are the same so as to preferentially execute the tasks to be executed with short historical running time or low resource use.
To achieve the above object, according to still another aspect of embodiments of the present invention, there is provided an electronic apparatus.
An electronic device of an embodiment of the present invention includes: one or more processors; the storage system is used for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors implement the service system monitoring method based on the kubernets according to the embodiment of the invention.
To achieve the above object, according to still another aspect of embodiments of the present invention, there is provided a computer-readable medium.
A computer-readable medium of the embodiments of the present invention stores thereon a computer program, and when the computer program is executed by a processor, the service system monitoring method based on kubernets according to the embodiments of the present invention is implemented.
One embodiment of the above invention has the following advantages or benefits: the method comprises the steps that task data when a service system deployed in a Kubernetes system runs and running data of the Kubernetes system are obtained, the data are matched with a preset monitoring rule to trigger monitoring early warning, and unified monitoring of the Kubernetes system and the service system is achieved; when the task execution condition or the resource use condition of the Kubernetes system is abnormal, triggering the monitoring self-healing function to adjust resource allocation and ensure the stability of the system; according to the target resource applied by the service system, the allocation of the newly added resource is adjusted, the influence on the execution of the high-priority task is reduced, the linkage between the Kubernetes system and the service system is realized, and the unified scheduling efficiency of the task resource and the Kubernetes is improved; and dynamically adjusting the execution sequence of the tasks to be executed, preferentially executing the tasks to be executed with shorter historical running time or lower resource usage, and ensuring that the number of the tasks to be executed in the queue is reduced.
Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.
Drawings
The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:
fig. 1 is a schematic diagram of the main steps of a Kubernetes-based service system monitoring method according to an embodiment of the present invention;
fig. 2 is a system architecture diagram of a Kubernetes-based service system monitoring method according to an embodiment of the present invention;
fig. 3 is a schematic diagram illustrating an operation principle of a Kubernetes-based service system according to an embodiment of the present invention;
fig. 4 is a schematic main flow chart of a service system monitoring method based on Kubernetes according to an embodiment of the present invention;
fig. 5 is a schematic diagram of a graphical display result of a service system monitoring method based on Kubernetes according to an embodiment of the present invention;
FIG. 6 is a schematic diagram of the main modules of a Kubernetes-based traffic system monitoring apparatus according to an embodiment of the present invention;
FIG. 7 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;
FIG. 8 is a schematic diagram of a computer apparatus suitable for use in an electronic device to implement an embodiment of the invention.
Detailed Description
Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
Technical terms involved in the embodiments of the present invention are explained below.
Kafka: a high throughput distributed publish-subscribe messaging system that can handle all the action flow data in a consumer-scale website.
And (3) SDK: a Software Development Kit, which is called Software Development Kit, is a set of Development tools used by some Software engineers to build application Software for a specific Software package, Software framework, hardware platform, operating system, and the like.
Storm: is a distributed, fault-tolerant real-time computing system.
Kubelet: the operation data is fed back to the kube-apiserver after the operation data of the containers and the Pod on the nodes is periodically obtained. kube-apiserver is the control portal for the entire Kubernetes system.
Pod: is a basic operation unit of Kubernetes and is also a carrier for application and operation. A Pod may consist of one or more containers, and the same Pod can only operate on the same host.
etcd: the system is used for storing real-time operation data of the Kubernetes cluster, such as state data of the nodes.
Fig. 1 is a schematic diagram of main steps of a service system monitoring method based on kubernets according to an embodiment of the present invention. As shown in fig. 1, the service system monitoring method based on Kubernetes according to the embodiment of the present invention mainly includes the following steps:
step S101: collecting log data generated after a Kubernetes system executes a task script submitted by a service system and running data of the Kubernetes system; wherein the service system is deployed in the Kubernetes system. And deploying the service system to a Kubernetes system, and executing a task script submitted by the service system by the Kubernetes system to generate log data. The monitoring device collects the log data and the running data of the Kubernetes system.
Step S102: and determining task data when the business system operates according to the log data, matching the task data with a preset first monitoring rule, and matching the operation data with a preset second monitoring rule. And the monitoring device acquires the dimensionality according to the predetermined task data and determines the task data of the corresponding dimensionality according to the log data. For example, the dimensionality of the task data to be acquired is the task execution time, the task queuing time and the number of waiting tasks, and the task data of the dimensionality can be determined based on the log data. In addition, the monitoring device supports a user to define the monitoring rule, and matches the task data and the operation data with the corresponding monitoring rule to judge whether the task data and the operation data meet the corresponding monitoring rule.
Step S103: and triggering monitoring early warning when the task data meets the alarm triggering condition of the first monitoring rule and/or the operation data meets the alarm triggering condition of the second monitoring rule. And if the monitoring device judges that any one or both of the task data and the operation data meet the corresponding monitoring rule, triggering monitoring early warning. Therefore, the unified monitoring of the Kubernetes system and the service system is realized.
Fig. 2 is a system architecture diagram of a service system monitoring method based on Kubernetes according to an embodiment of the present invention. As shown in fig. 2, the system includes a monitoring device, a service system, a kubernets system, and a mirror repository. When the service system needs to be deployed to the kubernets system, a container can be allocated to each task according to the task name, the relevant attributes, the task operation rules and the like of the service system. In an embodiment, one container may be allocated to a plurality of tasks, or one container may be allocated to one task. The mode of allocating a container to a task can realize that the task runs in an isolated environment. Meanwhile, the dynamic allocation of resources can be carried out based on the tasks. For example, after festival promotion, the data volume may be multiplied, and at this time, for the task of extracting the offline data, more resources may be provided for the container corresponding to the task.
The monitoring device comprises a service system monitoring module, a Kubernets system monitoring module, a monitoring early warning module, a monitoring self-healing module and a monitoring view module. The service system monitoring module is used for collecting log data of the service system. And the Kubernetes system monitoring module is used for collecting the operation data of the Kubernetes system. The monitoring and early warning module is used for obtaining task data based on the log data, matching the task data with a preset first monitoring rule and matching the operation data with a preset second monitoring rule; and triggering monitoring early warning when the task data meets the alarm triggering condition of the first monitoring rule and/or the operation data meets the alarm triggering condition of the second monitoring rule. And the monitoring self-healing module is used for automatically triggering the system self-healing function after triggering the monitoring early warning. And the monitoring view module is used for graphically displaying the task data and the operation data.
In addition, see the description about fig. 3 for the association between the service system, the Kubernetes system, and the mirror repository.
Fig. 3 is a schematic diagram illustrating an operation principle of a Kubernetes-based service system according to an embodiment of the present invention. As shown in fig. 3, the operation principle of the service system based on Kubernetes is as follows:
and the user reports the message to the Kafka through the Kafka SDK, the Kafka consumes the message through the Storm, and the consumption result is presented in a log area of the Web page. The execution flow of the service system is as follows:
(1) and the Web client issues the mirror image of the application program to the mirror image library. The application program refers to a computer program code corresponding to each task of the business system. In the embodiment, the Web management layer issues the mirror image of the application program to the mirror image library, and the mirror image of the application program is manufactured through Dockerfile.
(2) And the Web client submits the task script to a script library. In an embodiment, the Web management layer submits the task script to a script library.
(3) The Web client submits a task request to the Kubelet. When a Web client submits a task request, the number of CPU cores, the size of memory, and the like required for executing the task need to be specified. In the embodiment, a central node composed of at least one computer submits a task request to a Kubelet, the central node is provided with a task of a service system, and a Web management layer manages the central node.
(4) The Kubernetes Node judges whether the mirror image of the application program exists locally or not, and if the mirror image does not exist, the mirror image is pulled from the mirror image library. After the mirror image is pulled, Docker of Kubernetes Node starts to run.
(5) The Docker instance of Kubernetes Node downloads the latest task script from the script library and verifies the validity of the task script. And the executor of the Docker example checks the version of the task script, downloads the latest task script from the script library, and executes the task script after verifying that the latest task script is effective.
(6) And the executor of the Docker instance executes the task script and returns log data and running data of the Kubernetes system to the Web client. The log data is data which is generated in the task script execution process and is related to the current task; the operation data refers to data such as available amount and usage amount of a CPU, available amount and usage amount of a memory, available amount and usage amount of a disk, start time of Pod, operation state, and the like of each node in the Kubernetes system. In an embodiment, the log data and the run data are returned to the central node.
Fig. 4 is a schematic main flow chart of a service system monitoring method based on Kubernetes according to an embodiment of the present invention. As shown in fig. 4, the service system monitoring method based on Kubernetes according to the embodiment of the present invention mainly includes the following steps:
step S401: the service system issues the mirror image of the application program to the mirror image library, submits the task script to the script library, and sends the task request to the Kubernetes system. This step is used to deploy the business system to the Kubernetes system. The concrete implementation is as follows: a Web client of the service system issues a mirror image of an application program to a mirror image library and submits a task script to a script library; and the central node of the service system sends a task request to a Kubelet of the Kubernetes system. In embodiments, the business system may be a dispatch system, an inventory system, a settlement system, and the like. The scheduling system can be used for managing timing tasks and supporting the establishment of dependency relationships among the tasks. The task request comprises the amount of CPU and memory applied by the service system for the task.
Step S402: after the Kubernetes system acquires the mirror image of the application program, the latest task script is downloaded from the script library, the downloaded task script is executed, and log data and running data are generated. The Kubernetes Node judges whether a mirror image of the application program exists locally or not, and if so, the latest task script is directly downloaded from a script library; if not, the mirror image of the application program is pulled from the mirror image library, and then the latest task script is downloaded from the script library. The Kubernetes Node executes the downloaded task script to generate log data and running data of the Node.
Step S403: the monitoring device collects log data from a database of the service system, determines task data of the service system in operation according to the log data, and collects operation data of the Kubernetes system from the etcd of the Kubernetes system. The database of the service system stores log data generated by executing the task script, and after the monitoring device obtains the log data, task data such as task execution time, task queuing time, the number of waiting tasks and the like can be obtained through certain calculation. For example, the task execution duration is obtained from the task start execution time and the task end execution time in the log data; and obtaining the task queuing time and the number of the waiting tasks according to the task issuing time and the task starting execution time in the log data.
The real-time operation data of the system is stored in the etcd of the Kubernetes system, and the monitoring device can directly acquire the CPU available amount and usage amount, the memory available amount and usage amount, the disk available amount and usage amount and other operation data of the system from the etcd by calling the CRI (Container Runtime Interface), the CNI (Container Network Interface) and the CSI (Container Storage Interface) Interface of the Kubernetes system. The CRI interface is called to obtain the computing resource information, the CNI interface is called to obtain the network resource information, and the CSI interface is called to obtain the storage resource information. In an embodiment, the task data and the operational data are saved to a database, such as HBase.
Step S404: the monitoring device matches the task data with a preset first monitoring rule, and matches the operation data with a preset second monitoring rule. The monitoring device supports a user to define a monitoring rule, and can match task data and running data with the monitoring rule to trigger monitoring early warning. In the embodiment, monitoring rules of corresponding dimensions can be set for the task data and the operation data respectively according to the characteristics of the task data and the operation data. For a service system, setting a first monitoring rule by taking task execution time, task queuing time and the number of waiting tasks as dimensions; for the Kubernetes system, a second monitoring rule can be set by taking the available amount of the CPU, the available amount of the memory and the current load amount as dimensions.
Step S405: and triggering monitoring early warning when the task data meets the alarm triggering condition of the first monitoring rule and/or the operation data meets the alarm triggering condition of the second monitoring rule. And each monitoring rule is provided with a corresponding alarm triggering condition, and if the task data or the operation data meets the corresponding alarm triggering condition, monitoring and early warning are triggered. The mode of triggering the monitoring and early warning can be mail, internal communication software, short message, telephone and the like, and is used for warning the user, and the specific content of the warning information is set according to the preset rule.
With the task queuing time as a dimension, the first monitoring rule may include: and if more than 20 tasks are queued currently and the queuing time exceeds 20 minutes, triggering monitoring and early warning. With the number of waiting tasks as a dimension, the first monitoring rule may include: and if the number of the tasks currently waiting for 3 times is more than or equal to 30, triggering monitoring and early warning. The first monitoring rule includes an alarm triggering condition, for example, the number of waiting tasks is taken as an example, and the alarm triggering condition, that is, the number of currently waiting tasks, is continuous for 3 times and is greater than or equal to 30.
With CPU availability as a dimension, the second monitoring rule may include: and if the available quantity of the CPU is less than 30%, triggering monitoring early warning. With memory availability as a dimension, the second monitoring rule may include: and if the current memory available amount is less than 10% for 2 times, triggering monitoring and early warning.
In an embodiment, the monitoring device polls the database holding the task data and operational data at a frequency (e.g., every 60 seconds). The first monitoring rule is illustrated below in connection with table 1:
table 1 shows the number of waiting tasks obtained by the monitoring device in the example
| Number of tasks waiting | Time of acquisition |
| 21 | 2019-04-20-20:44:23 |
| 20 | 2019-04-20-20:45:23 |
| 22 | 2019-04-20-20:46:23 |
| 31 | 2019-04-20-20:47:23 |
| 32 | 2019-04-20-20:48:23 |
| 38 | 2019-04-20-20:49:23 |
| … | … |
As shown in table 1, the number of waiting tasks exceeds 30 in 3 consecutive times, and therefore, a monitoring and early warning is triggered. In an embodiment, the alarm information may be, for example: the number of tasks currently waiting continues for (3) times, which is equal to or greater than (30), and the latest value of the number of tasks waiting is 38, time: 2019-04-2020: 49:23, sender: a big data platform. In an embodiment, if the number of tasks in two consecutive inspection waits exceeds 30, but is less than 30 at the 3 rd inspection, the count may be re-counted.
Step S406: and the monitoring device summarizes the task data and the operation data and sends the summary data and the operation data to relevant responsible persons. The monitoring device respectively carries out data processing operations such as aggregation, averaging and the like on task data and running data in a period of time (such as the previous day), and sends processing results to relevant responsible persons.
Step S407: the monitoring device calls a label management interface of the Kubernetes system to label the idle resources of the Kubernetes system with the label of the service system. After the monitoring device triggers the monitoring early warning, the monitoring self-healing function can be automatically triggered. Monitoring self-healing functions such as: increasing Kubernetes resources which can be used by a service system, dynamically adjusting task scheduling sequence and the like. The monitoring device calls a label management interface of the Kubernetes system, and tags the service system with idle storage resources and computing resources (in the embodiment, idle resources) in the Kubernetes system. The storage resource refers to a disk resource of Docker, and the computing resource refers to a CPU and a memory. The role of tagging the idle resource to the business system is to allow the business system to use the resource.
Step S408: the monitoring device takes part or all of the idle resources as newly added resources, and the Kubernetes system distributes the newly added resources to the tasks to be executed of the service system. The monitoring device acquires the resource use condition of each current node by requesting a Kubelet API of the Kubernetes system, then determines a newly added resource from idle resources, and the Kubernetes system allocates the newly added resource to each task to be executed of the service system.
In a preferred embodiment, the monitoring device estimates a target resource required by a task to be executed of the service system, and executes a corresponding self-healing scheme according to the target resource and the size of the newly added resource. In an embodiment, the monitoring device checks the task execution status in the waiting queue, aggregates the average resource usage for a period of time (for example, the past 7 days), and takes the average resource usage as the target resource. The self-healing scheme is as follows:
if the newly added resource is smaller than the target resource and the newly added resource meets the task to be executed with high priority, the newly added resource is distributed to the task to be executed with high priority, and the task to be executed with high priority can be directly started in the newly added resource subsequently; and if the newly added resource is smaller than the target resource and the newly added resource cannot meet the high-priority task to be executed, evaluating the execution condition of the running task, terminating part of the tasks to be executed according to the execution evaluation result of the running task, and distributing the newly added resource to the unterminated tasks to be executed so that the high-priority task is quickly started and the terminated tasks to be executed are placed at the head of the waiting queue.
In another preferred embodiment, if the priorities of a plurality of tasks to be executed are the same, the execution sequence of the tasks to be executed can be dynamically adjusted according to the historical running time length and the resource use condition of the tasks to be executed, the tasks to be executed with shorter historical running time length or lower resource use of the tasks to be executed are preferentially run, and the number of the tasks in the waiting queue is ensured to be reduced. After the self-healing function is triggered, the task responsible person can be notified in the modes of short messages, mails and the like, and when the number of the tasks in the waiting queue is recovered to be normal, the self-healing scheme is immediately invalid.
Step S409: the monitoring device graphically displays task data of the service system and operation data of the Kubernetes system. The monitoring device uses an open source visual plug-in to display task data of the service system and operation data of the Kubernets system in a chart form, so that an administrator can visually check the operation states of the service system and the Kubernets system. Fig. 5 is a schematic diagram of a graphical display result of a service system monitoring method based on Kubernetes according to an embodiment of the present invention. As shown in fig. 5, the memory usage, the task top10 with low resource utilization rate, and the task top10 with overtime resource execution of the kubernets system in the last 7 days are shown.
According to the service system monitoring method based on Kubernetes, disclosed by the embodiment of the invention, by acquiring the task data when the service system deployed in the Kubernetes system runs and the running data of the Kubernetes system, the data is matched with the preset monitoring rule to trigger monitoring early warning, so that the uniform monitoring of the Kubernetes system and the service system is realized; when the task execution condition or the resource use condition of the Kubernetes system is abnormal, triggering the monitoring self-healing function to adjust resource allocation and ensure the stability of the system; according to the target resource applied by the service system, the allocation of the newly added resource is adjusted, the influence on the execution of the high-priority task is reduced, the linkage between the Kubernetes system and the service system is realized, and the unified scheduling efficiency of the task resource and the Kubernetes is improved; and dynamically adjusting the execution sequence of the tasks to be executed, preferentially executing the tasks to be executed with shorter historical running time or lower resource usage, and ensuring that the number of the tasks to be executed in the queue is reduced.
Fig. 6 is a schematic diagram of main modules of a kubernets-based traffic system monitoring apparatus according to an embodiment of the present invention. As shown in fig. 6, a service system monitoring apparatus 600 based on kubernets according to an embodiment of the present invention mainly includes:
the acquisition module 601 is used for acquiring log data generated after a Kubernets system executes a task script submitted by a service system, and running data of the Kubernets system; wherein the service system is deployed in the Kubernetes system. And deploying the service system to a Kubernetes system, and executing a task script submitted by the service system by the Kubernetes system to generate log data. The monitoring device collects the log data and the running data of the Kubernetes system.
A matching module 602, configured to determine task data when the service system operates according to the log data, match the task data with a preset first monitoring rule, and match the operating data with a preset second monitoring rule. And the monitoring device acquires the dimensionality according to the predetermined task data and determines the task data of the corresponding dimensionality according to the log data. For example, the dimensionality of the task data to be acquired is the task execution time, the task queuing time and the number of waiting tasks, and the task data of the dimensionality can be determined based on the log data. In addition, the monitoring device supports a user to define the monitoring rule, and matches the task data and the operation data with the corresponding monitoring rule to judge whether the task data and the operation data meet the corresponding monitoring rule.
The triggering module 603 is configured to trigger a monitoring early warning when the task data meets the alarm triggering condition of the first monitoring rule, and/or the operation data meets the alarm triggering condition of the second monitoring rule. And if the monitoring device judges that any one or both of the task data and the operation data meet the corresponding monitoring rule, triggering monitoring early warning. Therefore, the unified monitoring of the Kubernetes system and the service system is realized.
In addition, the service system monitoring apparatus 600 based on kubernets according to the embodiment of the present invention may further include: a resource adjustment module, a deployment execution module, a resource allocation module, and a task scheduling module (not shown in fig. 6). The resource adjusting module is used for calling a label management interface of the Kubernets system so as to print the idle resources of the Kubernets system with the label of the service system; and distributing part or all of the idle resources as newly added resources to the tasks to be executed of the service system through the Kubernetes system.
The deployment operation module is used for the service system to issue the mirror image of the application program to the mirror image library, submit the task script to the script library and send the task request to the Kubernetes system; after the Kubernetes system determines that the mirror image of the application program does not exist locally, the Kubernetes system pulls the mirror image from the mirror image library and downloads the task script from the script library; and the Kubernetes system executes the task script to generate log data.
The resource allocation module is used for judging the sizes of the target resource and the newly added resource which are applied by the service system for the task to be executed; if the newly added resource is smaller than the target resource and the newly added resource meets the task to be executed with high priority, distributing the newly added resource to the task to be executed with high priority; and if the newly added resource is smaller than the target resource and the newly added resource does not meet the task to be executed with the high priority, terminating the specified task to be executed according to the execution evaluation result of the running task, and distributing the newly added resource to the task to be executed which is not terminated.
And the task scheduling module is used for dynamically adjusting the execution sequence of the tasks to be executed according to the historical running time and the resource use data of the tasks to be executed under the condition that the priorities of the tasks to be executed are the same so as to preferentially execute the tasks to be executed with short historical running time or low resource use.
From the above description, it can be seen that by acquiring task data of a service system deployed in the kubernets system during operation and operation data of the kubernets system, and matching the data with a preset monitoring rule to trigger monitoring and early warning, unified monitoring of the kubernets system and the service system is achieved.
Fig. 7 shows an exemplary system architecture 700 of a Kubernetes-based traffic system monitoring method or a Kubernetes-based traffic system monitoring apparatus to which an embodiment of the present invention may be applied.
As shown in fig. 7, the system architecture 700 may include terminal devices 701, 702, 703, a network 704, and a server 705. The network 704 serves to provide a medium for communication links between the terminal devices 701, 702, 703 and the server 705. Network 704 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.
A user may use the terminal devices 701, 702, 703 to interact with a server 705 over a network 704, to receive or send messages or the like. Various communication client applications, such as shopping applications, web browser applications, search applications, instant messaging tools, mailbox clients, social platform software, and the like, may be installed on the terminal devices 701, 702, and 703.
The terminal devices 701, 702, 703 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.
The server 705 may be a server that provides various services, such as a background management server that processes log data provided by an administrator using the terminal apparatuses 701, 702, and 703. The background management server can analyze the received log data and the received running data, match the alarm rules and the like, and feed back a processing result (such as alarm information) to the terminal equipment.
It should be noted that the service system monitoring method based on kubernets provided in the embodiment of the present application is generally executed by the server 705, and accordingly, the service system monitoring apparatus based on kubernets is generally disposed in the server 705.
It should be understood that the number of terminal devices, networks, and servers in fig. 7 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
The invention also provides an electronic device and a computer readable medium according to the embodiment of the invention.
The electronic device of the present invention includes: one or more processors; and the storage device is used for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors implement the service system monitoring method based on the kubernets according to the embodiment of the invention.
The computer readable medium of the present invention stores thereon a computer program, which when executed by a processor implements a service system monitoring method based on Kubernetes according to an embodiment of the present invention.
Referring now to FIG. 8, shown is a block diagram of a computer system 800 suitable for use in implementing an electronic device of an embodiment of the present invention. The electronic device shown in fig. 8 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present invention.
As shown in fig. 8, the computer system 800 includes a Central Processing Unit (CPU)801 that can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)802 or a program loaded from a storage section 808 into a Random Access Memory (RAM) 803. In the RAM 803, various programs and data necessary for the operation of the computer system 800 are also stored. The CPU 801, ROM 802, and RAM 803 are connected to each other via a bus 804. An input/output (I/O) interface 805 is also connected to bus 804.
The following components are connected to the I/O interface 805: an input portion 806 including a keyboard, a mouse, and the like; an output section 807 including a signal such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 808 including a hard disk and the like; and a communication section 809 including a network interface card such as a LAN card, a modem, or the like. The communication section 809 performs communication processing via a network such as the internet. A drive 810 is also connected to the I/O interface 805 as necessary. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 810 as necessary, so that a computer program read out therefrom is mounted on the storage section 808 as necessary.
In particular, the processes described above with respect to the main step diagrams may be implemented as computer software programs, according to embodiments of the present disclosure. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program containing program code for performing the method illustrated in the main step diagram. In such an embodiment, the computer program can be downloaded and installed from a network through the communication section 809 and/or installed from the removable medium 811. The computer program executes the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 801.
It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor includes an acquisition module, a matching module, and a triggering module. The names of the modules do not limit the modules themselves in some cases, for example, the collection module may also be described as a module that collects log data generated after the kubernets system executes a task script submitted by a business system and operation data of the kubernets system.
As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise: collecting log data generated after a Kubernetes system executes a task script submitted by a service system and running data of the Kubernetes system; wherein the service system is deployed in the Kubernetes system; determining task data when the business system operates according to the log data, matching the task data with a preset first monitoring rule, and matching the operating data with a preset second monitoring rule; and triggering monitoring early warning when the task data meets the alarm triggering condition of the first monitoring rule and/or the operation data meets the alarm triggering condition of the second monitoring rule.
From the above description, it can be seen that by acquiring task data of a service system deployed in the kubernets system during operation and operation data of the kubernets system, and matching the data with a preset monitoring rule to trigger monitoring and early warning, unified monitoring of the kubernets system and the service system is achieved.
The product can execute the method provided by the embodiment of the invention, and has corresponding functional modules and beneficial effects of the execution method. For technical details that are not described in detail in this embodiment, reference may be made to the method provided by the embodiment of the present invention.
The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (10)
1. A service system monitoring method based on Kubernetes is characterized by comprising the following steps:
collecting log data generated after a Kubernetes system executes a task script submitted by a service system and running data of the Kubernetes system; wherein the service system is deployed in the Kubernetes system;
determining task data when the business system operates according to the log data, matching the task data with a preset first monitoring rule, and matching the operating data with a preset second monitoring rule;
and triggering monitoring early warning when the task data meets the alarm triggering condition of the first monitoring rule and/or the operation data meets the alarm triggering condition of the second monitoring rule.
2. The method of claim 1, further comprising:
calling a label management interface of the Kubernetes system to mark idle resources of the Kubernetes system with a label of the service system;
and distributing part or all of the idle resources as newly added resources to the tasks to be executed of the service system through the Kubernetes system.
3. The method of claim 1, wherein deploying the business system to the kubernets system, executing a task script submitted by the business system by the kubernets system, and generating log data comprises:
the service system issues a mirror image of an application program to a mirror image library, submits a task script to the script library and sends a task request to a Kubernetes system;
after the Kubernetes system determines that the mirror image of the application program does not exist locally, the Kubernetes system pulls the mirror image from the mirror image library and downloads the task script from the script library;
the Kubernetes system executes the task script to generate log data.
4. The method of claim 2, further comprising:
judging the size of the target resource and the newly added resource which are applied by the service system for the task to be executed;
if the newly added resource is smaller than the target resource and the newly added resource meets the task to be executed with high priority, distributing the newly added resource to the task to be executed with high priority;
if the newly added resource is smaller than the target resource and the newly added resource does not meet the task to be executed with the high priority, terminating the specified task to be executed according to the execution evaluation result of the running task, and distributing the newly added resource to the task to be executed which is not terminated.
5. The method of claim 4, further comprising:
if the priorities of the tasks to be executed are the same, dynamically adjusting the execution sequence of the tasks to be executed according to the historical running time length and the resource use data of the tasks to be executed so as to preferentially execute the tasks to be executed with short historical running time length or low resource use.
6. A service system monitoring device based on Kubernetes is characterized by comprising:
the system comprises an acquisition module and a processing module, wherein the acquisition module is used for acquiring log data generated after a Kubernets system executes a task script submitted by a service system and running data of the Kubernets system; wherein the service system is deployed in the Kubernetes system;
the matching module is used for determining task data when the business system operates according to the log data, matching the task data with a preset first monitoring rule and matching the operating data with a preset second monitoring rule;
and the triggering module is used for triggering monitoring early warning when the task data meets the alarm triggering condition of the first monitoring rule and/or the operation data meets the alarm triggering condition of the second monitoring rule.
7. The apparatus of claim 6, further comprising: resource adjustment module for
Calling a label management interface of the Kubernetes system to mark idle resources of the Kubernetes system with a label of the service system; and
and distributing part or all of the idle resources as newly added resources to the tasks to be executed of the service system through the Kubernetes system.
8. The apparatus of claim 6, further comprising: deployment run module for
The service system issues a mirror image of an application program to a mirror image library, submits a task script to the script library and sends a task request to a Kubernetes system;
after the Kubernetes system determines that the mirror image of the application program does not exist locally, the Kubernetes system pulls the mirror image from the mirror image library and downloads the task script from the script library; and
the Kubernetes system executes the task script to generate log data.
9. An electronic device, comprising:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-5.
10. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910492965.XA CN112052133A (en) | 2019-06-06 | 2019-06-06 | Service system monitoring method and device based on Kubernetes |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910492965.XA CN112052133A (en) | 2019-06-06 | 2019-06-06 | Service system monitoring method and device based on Kubernetes |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112052133A true CN112052133A (en) | 2020-12-08 |
Family
ID=73609519
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910492965.XA Pending CN112052133A (en) | 2019-06-06 | 2019-06-06 | Service system monitoring method and device based on Kubernetes |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112052133A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113052296A (en) * | 2021-03-02 | 2021-06-29 | 贵州电网有限责任公司 | Power grid power transmission defect intelligent management system based on deep learning convolutional neural network technology |
| CN113722198A (en) * | 2021-09-02 | 2021-11-30 | 中国建设银行股份有限公司 | Script job submission control method and device, storage medium and electronic equipment |
| CN113778636A (en) * | 2021-01-07 | 2021-12-10 | 北京沃东天骏信息技术有限公司 | Task scheduling management method and device |
| CN114326670A (en) * | 2021-12-24 | 2022-04-12 | 北京龙鼎源科技股份有限公司 | Method and device for detecting task executed by controller, storage medium and electronic device |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180336227A1 (en) * | 2017-05-17 | 2018-11-22 | International Business Machines Corporation | Database server system monitoring |
| CN109245931A (en) * | 2018-09-19 | 2019-01-18 | 四川长虹电器股份有限公司 | The log management of container cloud platform based on kubernetes and the implementation method of monitoring alarm |
| CN109343947A (en) * | 2018-09-26 | 2019-02-15 | 郑州云海信息技术有限公司 | A kind of resource regulating method and device |
-
2019
- 2019-06-06 CN CN201910492965.XA patent/CN112052133A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180336227A1 (en) * | 2017-05-17 | 2018-11-22 | International Business Machines Corporation | Database server system monitoring |
| CN109245931A (en) * | 2018-09-19 | 2019-01-18 | 四川长虹电器股份有限公司 | The log management of container cloud platform based on kubernetes and the implementation method of monitoring alarm |
| CN109343947A (en) * | 2018-09-26 | 2019-02-15 | 郑州云海信息技术有限公司 | A kind of resource regulating method and device |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113778636A (en) * | 2021-01-07 | 2021-12-10 | 北京沃东天骏信息技术有限公司 | Task scheduling management method and device |
| CN113052296A (en) * | 2021-03-02 | 2021-06-29 | 贵州电网有限责任公司 | Power grid power transmission defect intelligent management system based on deep learning convolutional neural network technology |
| CN113722198A (en) * | 2021-09-02 | 2021-11-30 | 中国建设银行股份有限公司 | Script job submission control method and device, storage medium and electronic equipment |
| CN114326670A (en) * | 2021-12-24 | 2022-04-12 | 北京龙鼎源科技股份有限公司 | Method and device for detecting task executed by controller, storage medium and electronic device |
| CN114326670B (en) * | 2021-12-24 | 2024-03-05 | 北京龙鼎源科技股份有限公司 | Detection method and device for executing tasks by controller, storage medium and electronic device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112052133A (en) | Service system monitoring method and device based on Kubernetes | |
| CN108733461B (en) | Distributed task scheduling method and device | |
| CN107729139B (en) | Method and device for concurrently acquiring resources | |
| CN109783151B (en) | Method and device for rule change | |
| CN111597033A (en) | Task scheduling method and device | |
| CN109428926B (en) | Method and device for scheduling task nodes | |
| CN111858040A (en) | Resource scheduling method and device | |
| CN113672357A (en) | Task scheduling method, device and system | |
| CN112398669A (en) | Hadoop deployment method and device | |
| CN112099937A (en) | Resource management method and device | |
| CN113422808A (en) | Internet of things platform HTTP information pushing method, system, device and medium | |
| CN111831503B (en) | Monitoring method based on monitoring agent and monitoring agent device | |
| US10893015B2 (en) | Priority topic messaging | |
| CN107045452B (en) | Virtual machine scheduling method and device | |
| CN106657195B (en) | Task processing method and relay device | |
| CN110912949B (en) | Method and device for submitting sites | |
| CN112448977A (en) | System, method, apparatus and computer readable medium for assigning tasks | |
| CN116185578A (en) | Scheduling method of computing task and executing method of computing task | |
| CN115952050A (en) | Reporting method and device for organization service buried point data | |
| CN115525411A (en) | Method, device, electronic equipment and computer readable medium for processing service request | |
| CN112688982B (en) | User request processing method and device | |
| CN113282455A (en) | Monitoring processing method and device | |
| CN115129438A (en) | Method and device for task distributed scheduling | |
| CN112988417A (en) | Message processing method and device, electronic equipment and computer readable medium | |
| CN113656239A (en) | Monitoring method and device for middleware and computer program product |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |