CN112052133B - Method and device for monitoring service system based on Kubernetes - Google Patents
Method and device for monitoring service system based on Kubernetes Download PDFInfo
- Publication number
- CN112052133B CN112052133B CN201910492965.XA CN201910492965A CN112052133B CN 112052133 B CN112052133 B CN 112052133B CN 201910492965 A CN201910492965 A CN 201910492965A CN 112052133 B CN112052133 B CN 112052133B
- Authority
- CN
- China
- Prior art keywords
- task
- kubernetes
- data
- monitoring
- executed
- 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.)
- Active
Links
- 238000012544 monitoring process Methods 0.000 title claims abstract description 146
- 238000000034 method Methods 0.000 title claims abstract description 52
- 238000013515 script Methods 0.000 claims abstract description 66
- 238000012806 monitoring device Methods 0.000 claims description 36
- 238000004590 computer program Methods 0.000 claims description 13
- 238000011156 evaluation Methods 0.000 claims description 6
- 238000010586 diagram Methods 0.000 description 21
- 230000006870 function Effects 0.000 description 11
- 238000007726 management method Methods 0.000 description 11
- 238000004891 communication Methods 0.000 description 7
- 230000008569 process Effects 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 238000013468 resource allocation Methods 0.000 description 5
- 230000003287 optical effect Effects 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 238000012935 Averaging Methods 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
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 the following steps: collecting log data generated after the Kubernetes system executes task scripts submitted by a service system, and operating data of the Kubernetes system; the service system is deployed in a Kubernetes system; determining task data of the service system during operation 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 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 the Kubernetes system runs and running data of the Kubernetes system are acquired, and the data are matched with a preset monitoring rule to trigger monitoring early warning, so that unified monitoring of the Kubernetes system and the service system is realized.
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 a burg system based on google interior, and provides an application-oriented container cluster deployment and management system. The service system is built based on the Kubernetes system, and efficient and stable technical service can be provided for the service system. How to uniformly monitor the resource use condition of the Kubernetes system and the task execution condition of the business system is a basic guarantee of the stable operation of the system.
In the process of implementing the present invention, the inventor finds that at least the following problems exist in the prior art:
the unified monitoring of the Kubernetes system and the business system cannot be realized in the prior art.
Disclosure of Invention
In view of the above, the embodiment of the invention provides a method and a device for monitoring a service system based on Kubernetes, which are used for realizing unified monitoring of the Kubernetes system and the service system by acquiring task data deployed in the operation of the service system of the Kubernetes system and operation data of the Kubernetes system, and matching the data with a preset monitoring rule to trigger monitoring and early warning.
To achieve the above object, according to an aspect of the embodiments of the present invention, a method for monitoring a service system based on Kubernetes is provided.
The method for monitoring the service system based on the Kubernetes comprises the following steps: collecting log data generated after a Kubernetes system executes task scripts submitted by a service system, and operating data of the Kubernetes system; the service system is deployed in the Kubernetes system; determining task data of the service system during operation 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 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: invoking a label management interface of the Kubernetes system to label idle resources of the Kubernetes system with the service system; and taking part or all of the idle resources as new resources, and distributing the new resources to the tasks to be executed of the service system through the Kubernetes system.
Optionally, the service system is deployed to the Kubernetes system, the Kubernetes system executes task scripts submitted by the service system, and log data is generated, including: the service system issues a mirror image of an application program to a mirror image library, submits a task script to a 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, pulling the mirror image from the mirror image library, and then downloading 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 service system as the size of the target resource and the newly added resource of the task application to be executed; if the new resources are smaller than the target resources and the new resources meet the tasks to be executed with high priority, distributing the new resources to the tasks to be executed with high priority; if the new added resource is smaller than the target resource and the new added resource does not meet the task to be executed with high priority, terminating the designated task to be executed according to the execution evaluation result of the task in operation, and distributing the new added resource to the task to be executed which is not terminated.
Optionally, the method further comprises: and if the priorities of the plurality of tasks to be executed are the same, dynamically adjusting the execution sequence of the tasks to be executed according to the historical operation time length of the tasks to be executed and the resource use data so as to preferentially execute the tasks to be executed with short historical operation time length or low resource use.
To achieve the above object, according to another aspect of the embodiments of the present invention, a service system monitoring device based on Kubernetes is provided.
The invention provides a service system monitoring device based on Kubernetes, which comprises: the acquisition module is used for acquiring log data generated after the Kubernetes system executes task scripts submitted by the service system and operating data of the Kubernetes system; the service system is deployed in the Kubernetes system; the matching module is used for determining task data when the service system runs according to the log data, matching the task data with a preset first monitoring rule and matching the running 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 Kubernetes system to label idle resources of the Kubernetes system with labels of the service system; and taking part or all of the idle resources as new resources, and distributing the new 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 a mirror image library, submit a task script to a script library and send a task request to the Kubernetes system; after the Kubernetes system determines that the mirror image of the application program does not exist locally, pulling the mirror image from the mirror image library, and then downloading the task script from the script library; and the Kubernetes system executing the task script to generate log data.
Optionally, the apparatus further comprises: the resource allocation module is used for judging the size of the target resource and the newly added resource applied by the service system for the task to be executed; if the new resources are smaller than the target resources and the new resources meet the tasks to be executed with high priority, distributing the new resources to the tasks 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 high priority, terminating the designated task to be executed according to the execution evaluation result of the task in operation, 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 operation time length 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 operation time length or low resource use.
To achieve the above object, according to still another aspect of the embodiments of the present invention, there is provided an electronic device.
An electronic device according to an embodiment of the present invention includes: one or more processors; and 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 realize the business system monitoring method based on the Kubernetes.
To achieve the above object, according to still another aspect of the embodiments of the present invention, there is provided a computer-readable medium.
A computer readable medium of an embodiment of the present invention has stored thereon a computer program which, when executed by a processor, implements a Kubernetes-based business system monitoring method of an embodiment of the present invention.
One embodiment of the above invention has the following advantages or benefits: the task data when the service system deployed in the Kubernetes system operates and the operation data of the Kubernetes system are acquired, and the data are matched with a preset monitoring rule to trigger monitoring early warning, so that unified 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 a monitoring self-healing function to adjust resource allocation and ensure system stability; according to the target resources applied by the service system, the allocation of the newly added resources 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 resources and the Kubernetes is improved; and dynamically adjusting the execution sequence of the tasks to be executed, and preferentially executing the tasks to be executed with shorter historical operation time or lower resource use, so as to ensure that the number of the tasks to be executed in the queue is reduced.
Further effects of the above-described non-conventional alternatives are 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 business system monitoring method according to an embodiment of the present invention;
FIG. 2 is a system architecture diagram of a Kubernetes-based business system monitoring method according to an embodiment of the present invention;
FIG. 3 is a schematic diagram of the operating principle of a Kubernetes-based business system according to an embodiment of the present invention;
fig. 4 is a main flow diagram of a Kubernetes-based service system monitoring method according to an embodiment of the present invention;
fig. 5 is a schematic diagram of a graphical display result of a Kubernetes-based service system monitoring method according to an embodiment of the present invention;
FIG. 6 is a schematic diagram of the main modules of a Kubernetes-based business system monitoring device, 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 applied;
fig. 8 is a schematic structural diagram of a computer device suitable for use in an electronic apparatus to implement an embodiment of the present invention.
Detailed Description
Exemplary embodiments of the present invention will now be described with reference to the accompanying drawings, in which various details of the embodiments of the present invention are included to facilitate understanding, and are to be considered 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 related to the embodiments of the present invention are described below.
Kafka: a high throughput distributed publish-subscribe messaging system that can handle all action flow data in consumer scale websites.
SDK: a software development kit, known as Software Development Kit in english, is generally a collection of development tools for some software engineers to build application software for a particular software package, software framework, hardware platform, operating system, etc.
Storm: is a distributed, fault tolerant real-time computing system.
Kubelet: and operating on each node as an agent, receiving Pods tasks for distributing the node, managing the life cycle of the container, monitoring the resource use condition of the node, periodically acquiring the operation data of the container and Pod on the node, and feeding back the operation data to kube-apiserver. kube-apiserver are control inlets of the whole Kubernetes system.
Pod: is the basic operating unit of Kubernetes and is also the carrier for application execution. A Pod may consist of one or more containers, with the same Pod running only on the same host.
Etcd: for storing real-time operational data of Kubernetes clusters, such as state data of nodes.
Fig. 1 is a schematic diagram of main steps of a Kubernetes-based service system monitoring method according to an embodiment of the present invention. As shown in fig. 1, the method for monitoring a service system based on Kubernetes in the embodiment of the present invention mainly includes the following steps:
Step S101: collecting log data generated after a Kubernetes system executes task scripts submitted by a service system, and operating data of the Kubernetes system; the service system is deployed in the Kubernetes system. The service system is deployed to the Kubernetes system, and the Kubernetes system executes task scripts submitted by the service system to generate log data. The monitoring device collects the log data and the operation data of the Kubernetes system.
Step S102: and determining task data of the service system in operation 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. The monitoring device acquires dimensions according to the predetermined task data, and determines task data of the corresponding dimensions according to the log data. For example, the dimension of the task data to be acquired is the execution time of the task, the queuing time of the task and the number of the waiting tasks, and the task data of the dimension can be determined based on the log data. In addition, the monitoring device supports user-defined monitoring rules, and matches the task data and the operation data with the corresponding monitoring rules to judge whether the task data and the operation data meet the corresponding monitoring rules.
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. So far, the unified monitoring of the Kubernetes system and the business system is realized.
Fig. 2 is a system architecture diagram of a Kubernetes-based service system monitoring method according to an embodiment of the present invention. As shown in fig. 2, the system includes a monitoring device, a business system, a Kubernetes system, and a mirrored warehouse. When the service system needs to be deployed to the Kubernetes system, a container can be allocated to each task according to the task name, related attribute, task operation rule and the like of the service system. In an embodiment, a container may be allocated to a plurality of tasks, or a container may be allocated to a task. The task can be run in an isolated environment by assigning a container to a task. Meanwhile, the dynamic allocation of resources can be performed based on the task itself. For example, after a holiday promotion, the data volume may increase by a factor, and then for the task of extracting offline data, more resources may be provided for the corresponding container.
The monitoring device comprises a service system monitoring module, a Kubernetes 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. The Kubernetes system monitoring module is used for collecting operation data of the Kubernetes system. The monitoring 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 self-healing function of the system 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, the association between the business system, the Kubernetes system, and the mirror repository is described with respect to fig. 3.
Fig. 3 is a schematic diagram of the operation principle of a Kubernetes-based service system according to an embodiment of the present invention. As shown in fig. 3, the operating principle of the Kubernetes-based service system is as follows:
The user reports the message to Kafka through KafkaSDK, and Kafka consumes the message through Storm and presents the consumption result in the log area of the Web page. The execution flow of the business system is as follows:
(1) The Web client publishes the mirror image of the application program to the mirror image library. Wherein, the application program refers to computer program codes corresponding to each task of the service system. In an embodiment, the Web management layer publishes the mirror image of the application program to the mirror image library, and the mirror image of the application program is made through Dockerfile.
(2) And the Web client submits the task script to a script library. In an embodiment, a task script is submitted to a script library by a Web management layer.
(3) The Web client submits a task request to Kubelet. When the Web client submits a task request, the number of CPU cores, the memory size and the like required for executing the task need to be specified. In the embodiment, a central node formed by at least one computer submits a task request to Kubelet, a task of a service system is deployed on the central node, and the central node is managed by a Web management layer.
(4) The Kubernetes Node determines whether the mirror image of the application program exists locally, and if not, pulls the mirror image from the mirror image library. After pulling the mirror image, the Docker of the Kubernetes Node starts to run.
(5) The Docker instance of the Kubernetes Node downloads the latest task script from the script library, and verifies the validity of the task script. The executor of the Docker instance 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 valid.
(6) The executor of the Docker instance executes the task script and returns the log data and the running data of the Kubernetes system to the Web client. The log data is data related to the current task and is generated in the execution process of the task script; the operation data refer to CPU available and used quantity, memory available and used quantity, disk available and used quantity, pod starting time, operation state and other data of each node in the Kubernetes system. In an embodiment, log data and operational data are returned to the central node.
Fig. 4 is a main flow diagram of a Kubernetes-based service system monitoring method according to an embodiment of the present invention. As shown in fig. 4, the method for monitoring a service system based on Kubernetes in the embodiment of the present invention mainly includes the following steps:
Step S401: the service system issues a mirror image of the application program to a mirror image library, submits a task script to a script library, and sends a task request to the Kubernetes system. This step is used to deploy the business system to the Kubernetes system. The method is concretely realized as follows: the Web client of the business system issues a mirror image of the application program to a mirror image library and submits a task script to a script library; the central node of the business system sends a task request to Kubelet of the Kubernetes system. In an embodiment, 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 CPU and the memory quantity 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, and the downloaded task script is executed to generate log data and running data. The Kubernetes Node judges whether the 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 the task script does not exist, the latest task script is downloaded from the script library after the mirror image of the application program is pulled from the mirror image library. The Kubernetes Node executes the downloaded task script to generate log data and running data for the Node.
Step S403: the monitoring device collects log data from a database of the service system, determines task data when the service system operates according to the log data, and collects operation data of the Kubernetes system from etcd of the Kubernetes system. The database of the business system stores log data generated by executing task scripts, and the monitoring device obtains the task data such as task execution time length, task queuing time length, waiting task number and the like after obtaining the log data 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 waiting task number according to the task issuing time and the task starting execution time in the log data.
The etcd of the Kubernetes system stores real-time operation data of the system, and the monitoring device can directly obtain the operation data of the CPU availability and usage, the memory availability and usage, the disk availability and usage and the like of the system from the etcd by calling CRI (Container Runtime Interface, container operation interface), CNI (Container Network Interface ) and CSI (Container Storage Interface, container storage interface) interfaces 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 operation 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 user-defined monitoring rules, and can match task data and operation data with the monitoring rules to trigger monitoring early warning. In the embodiment, according to the characteristics of the task data and the operation data, the monitoring rules of corresponding dimensions can be set for the task data and the operation data respectively. For a business system, a first monitoring rule can be set for dimensions by taking task execution time length, task queuing time length and the number of tasks waiting for the business system; for the Kubernetes system, the second monitoring rule may be set by taking the CPU availability, the memory availability, and the current load number 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. Each monitoring rule is provided with a corresponding alarm triggering condition, and if the task data or the operation data meet the corresponding alarm triggering condition, the monitoring early warning is 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 warning information is set according to preset rules.
With the task queuing time length as one dimension, the first monitoring rule may include: and if more than 20 tasks are currently queued, and the queuing time exceeds 20 minutes, triggering monitoring and early warning. Taking the number of tasks in waiting as a dimension, the first monitoring rule may include: and if the number of the tasks in the current waiting process is continuously 3 times and is more than or equal to 30, triggering monitoring and early warning. The first monitoring rule includes an alarm triggering condition, and taking the number of tasks in waiting as an example, the alarm triggering condition, that is, the number of tasks in current waiting is continuously 3 times, which is greater than or equal to 30.
With CPU availability as one dimension, the second monitoring rule may include: and if the current CPU availability is less than 30%, triggering monitoring and early warning. With the memory available as a dimension, the second monitoring rule may include: and if the current available memory amount is less than 10% in 2 times, triggering monitoring and early warning.
In an embodiment, the monitoring device polls the database holding the task data and the operational data one time at a frequency (e.g., every 60 seconds). The first monitoring rule is illustrated in the following table 1:
table 1 shows the number of tasks in waiting obtained by the monitoring device in the example
| Number of waiting tasks | Acquisition time |
| 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 consecutive 3 times, so the monitoring and early warning will be triggered. In an embodiment, the alarm information may be, for example: the number of tasks currently waiting is continuously (3) times, which is larger than or equal to (30), the latest value of the number of tasks currently waiting is 38, and the time is as follows: 2019-04-20:20:49:23, sender: big data platform. In an embodiment, if the number of tasks in the wait for two consecutive checks exceeds 30, but the 3 rd check is less than 30, the count may be recounted.
Step S406: the monitoring device gathers the task data and the operation data and sends the task data and the operation data to related responsible persons. The monitoring device respectively carries out data processing operations such as aggregation, averaging and the like on task data and operation data for a period of time (such as the previous day), and sends processing results to related responsible persons.
Step S407: the monitoring device calls a label management interface of the Kubernetes system to label idle resources of the Kubernetes system with labels of the business 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: adding Kubernetes resources that can be used by the business system, dynamically adjusting task scheduling order, etc. The monitoring device calls a label management interface of the Kubernetes system, and labels idle storage resources and computing resources (called idle resources in the embodiment) in the Kubernetes system with a service system. The storage resource refers to disk resource of the Docker, and the computing resource refers to CPU and memory. The effect of tagging the idle resource with the business system is to allow the business system to use the resource.
Step S408: and the monitoring device takes part or all of the idle resources as new resources, and the Kubernetes system distributes the new resources to the tasks to be executed of the service system. The monitoring device acquires the resource use condition of each node at present through Kubelet API of the request Kubernetes system, then determines a new resource from idle resources, and distributes the new resource to each task to be executed of the service system by the Kubernetes system.
In a preferred embodiment, the monitoring device predicts a target resource required by a task to be executed of the service system, and executes a corresponding self-healing scheme according to the size of the target resource and the newly added resource. In an embodiment, the monitoring device checks the task execution condition in the waiting queue, sums up 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 specifically 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 then the task to be executed with high priority can be directly started in the newly added resource; if the newly added resource is smaller than the target resource and the newly added resource cannot meet the task to be executed with high priority, the execution condition of the task in operation is evaluated, part of the task to be executed is terminated according to the execution evaluation result of the task in operation, the newly added resource is distributed to the task to be executed which is not terminated, so that the task with high priority is started quickly, and the task to be executed which is terminated is placed at the head of the waiting queue.
In another preferred embodiment, if there are multiple tasks to be executed with the same priority, the execution sequence of the tasks to be executed may be dynamically adjusted according to the historical operation time length and the resource usage condition of the tasks to be executed, so that the tasks to be executed with shorter historical operation time length or lower resource usage are preferentially operated, and the number of tasks in the waiting queue is ensured to be reduced. After the self-healing function is triggered, a task responsible person can be notified through a short message, mail and the like, and when the number of tasks waiting for a 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 Kubernetes system in a chart form, so that an administrator can visually check the operation states of the service system and the Kubernetes system. Fig. 5 is a schematic diagram of a graphical display result of a Kubernetes-based service system monitoring method according to an embodiment of the present invention. As shown in fig. 5, the Kubernetes system shows the memory usage of approximately 7 days, the task top10 with low resource utilization, and the task top10 with overtime resource execution.
According to the method for monitoring the service system based on the Kubernetes, which is disclosed by the embodiment of the invention, the task data when the service system deployed in the Kubernetes system runs and the running data of the Kubernetes system are obtained, and the data are matched with the preset monitoring rules to trigger monitoring and early warning, so that the unified 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 a monitoring self-healing function to adjust resource allocation and ensure system stability; according to the target resources applied by the service system, the allocation of the newly added resources 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 resources and the Kubernetes is improved; and dynamically adjusting the execution sequence of the tasks to be executed, and preferentially executing the tasks to be executed with shorter historical operation time or lower resource use, so as to ensure 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 Kubernetes-based service system monitoring device according to an embodiment of the present invention. As shown in fig. 6, a Kubernetes-based service system monitoring device 600 according to an embodiment of the present invention mainly includes:
The acquisition module 601 is configured to acquire log data generated after a Kubernetes system executes a task script submitted by a service system, and operation data of the Kubernetes system; the service system is deployed in the Kubernetes system. The service system is deployed to the Kubernetes system, and the Kubernetes system executes task scripts submitted by the service system to generate log data. The monitoring device collects the log data and the operation data of the Kubernetes system.
And the matching module 602 is configured to determine task data when the service system runs according to the log data, match the task data with a preset first monitoring rule, and match the running data with a preset second monitoring rule. The monitoring device acquires dimensions according to the predetermined task data, and determines task data of the corresponding dimensions according to the log data. For example, the dimension of the task data to be acquired is the execution time of the task, the queuing time of the task and the number of the waiting tasks, and the task data of the dimension can be determined based on the log data. In addition, the monitoring device supports user-defined monitoring rules, and matches the task data and the operation data with the corresponding monitoring rules to judge whether the task data and the operation data meet the corresponding monitoring rules.
And the triggering module 603 is configured to trigger monitoring early warning when the task data meets an alarm triggering condition of the first monitoring rule and/or the operation data meets an 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. So far, the unified monitoring of the Kubernetes system and the business system is realized.
In addition, the Kubernetes-based service system monitoring device 600 of the embodiment of the present invention may further include: a resource adjustment module, a deployment run 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 Kubernetes system to label idle resources of the Kubernetes system with labels of the service system; and taking part or all of the idle resources as new resources, and distributing the new 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 a mirror image library, submit a task script to a script library and send a task request to the Kubernetes system; after the Kubernetes system determines that the mirror image of the application program does not exist locally, pulling the mirror image from the mirror image library, and then downloading the task script from the script library; and the Kubernetes system executing the task script to generate log data.
The resource allocation module is used for judging the size of the target resource and the newly added resource applied by the service system for the task to be executed; if the new resources are smaller than the target resources and the new resources meet the tasks to be executed with high priority, distributing the new resources to the tasks 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 high priority, terminating the designated task to be executed according to the execution evaluation result of the task in operation, 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 operation time length and the resource use data of the tasks to be executed under the condition that the priorities of a plurality of tasks to be executed are the same so as to preferentially execute the tasks to be executed with short historical operation time length or low resource use.
From the above description, it can be seen that by acquiring task data when the service system deployed in the Kubernetes system runs and running data of the Kubernetes system, matching the data with a preset monitoring rule to trigger monitoring and early warning, unified monitoring of the Kubernetes system and the service system is realized.
Fig. 7 illustrates an exemplary system architecture 700 to which Kubernetes-based business system monitoring methods or Kubernetes-based business system monitoring devices of embodiments of the present invention may be applied.
As shown in fig. 7, a system architecture 700 may include terminal devices 701, 702, 703, a network 704, and a server 705. The network 704 is the medium used to provide communication links between the terminal devices 701, 702, 703 and the server 705. The network 704 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.
A user may interact with the server 705 via the network 704 using the terminal devices 701, 702, 703 to receive or send messages or the like. Various communication client applications, such as shopping class applications, web browser applications, search class applications, instant messaging tools, mailbox clients, social platform software, etc., may be installed on the terminal devices 701, 702, 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 smartphones, tablets, laptop and 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 devices 701, 702, 703. The background management server can analyze the received log data and operation data, match alarm rules and the like, and feed back the processing result (such as alarm information) to the terminal equipment.
It should be noted that, the method for monitoring a service system based on Kubernetes provided by the embodiment of the present application is generally executed by the server 705, and accordingly, the device for monitoring a service system based on Kubernetes 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.
According to an embodiment of the invention, the invention further provides an electronic device and a computer readable medium.
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 realize the business system monitoring method based on the Kubernetes.
The computer readable medium of the present invention stores a computer program thereon, which when executed by a processor implements a Kubernetes-based business system monitoring method of an embodiment of the present invention.
Referring now to FIG. 8, there is illustrated a schematic diagram of a computer system 800 suitable for use in implementing an embodiment of the present invention. The electronic device shown in fig. 8 is only an example and should not be construed as limiting the functionality and scope of use of the embodiments of the 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 according to 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 required for the operation of the computer system 800 are also stored. The CPU 801, ROM 802, and RAM 803 are connected to each other by a bus 804. An input/output (I/O) interface 805 is also connected to the bus 804.
The following components are connected to the I/O interface 805: an input portion 806 including a keyboard, mouse, etc.; an output portion 807 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage section 808 including a hard disk or 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. The drive 810 is also connected to the I/O interface 805 as needed. 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 needed so that a computer program read out therefrom is mounted into the storage section 808 as needed.
In particular, the processes described above in the main step diagrams may be implemented as computer software programs according to the disclosed embodiments of the invention. 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 comprising program code for performing the method shown in the main step diagrams. In such an embodiment, the computer program may be downloaded and installed from a network via the communication section 809, and/or installed from the removable media 811. The above-described functions defined in the system of the present invention are performed when the computer program is executed by a Central Processing Unit (CPU) 801.
The computer readable medium shown in the present invention may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any 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 context of this document, 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, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. 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 flowcharts 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 involved in the embodiments of the present invention may be implemented in software or in hardware. The described modules may also be provided in a processor, for example, as: a processor includes an acquisition module, a matching module, and a triggering module. The names of these modules do not limit the module itself in some cases, for example, the collection module may also be described as "a module that collects log data generated after the Kubernetes system executes a task script submitted by the service system, and the operation data of the Kubernetes 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 present alone without being fitted into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to include: collecting log data generated after a Kubernetes system executes task scripts submitted by a service system, and operating data of the Kubernetes system; the service system is deployed in the Kubernetes system; determining task data of the service system during operation 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 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 when the service system deployed in the Kubernetes system runs and running data of the Kubernetes system, matching the data with a preset monitoring rule to trigger monitoring and early warning, unified monitoring of the Kubernetes system and the service system is realized.
The product can execute the method provided by the embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method. Technical details not described in detail in this embodiment may be found in the methods provided in the embodiments of the present invention.
The above embodiments do not limit the scope of the present invention. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives can occur depending upon design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of the present invention.
Claims (7)
1. The utility model provides a business system monitoring method based on Kubernetes, which is characterized in that the method comprises the following steps:
The service system issues a mirror image of the application program to a mirror image library, submits a task script to a script library, and sends a task request to the Kubernetes system so as to deploy the service system to the Kubernetes system; wherein, the application program refers to computer program codes corresponding to each task of the business system;
Collecting log data generated after a Kubernetes system executes task scripts submitted by a service system, and operating data of the Kubernetes system;
Determining task data of the service system during operation 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;
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;
Triggering a monitoring self-healing function to call a label management interface of the Kubernetes system to label idle resources of the Kubernetes system with labels of the service system;
Taking part or all of the idle resources as new resources, and distributing the new resources to the tasks to be executed of the service system through the Kubernetes system; the method comprises the steps of acquiring the resource use condition of each node at present through Kubelet API of a request Kubernetes system, and then determining a new resource from idle resources;
Tasks to be performed assigned to the business system by the Kubernetes system include: judging the service system as the size of the target resource and the newly added resource of the task application to be executed; the method comprises the steps of checking task execution conditions in a waiting queue, summarizing average resource usage of preset time, and taking the average resource usage as a target resource;
if the new resources are smaller than the target resources and the new resources meet the tasks to be executed with high priority, distributing the new resources to the tasks to be executed with high priority;
If the new added resource is smaller than the target resource and the new added resource does not meet the task to be executed with high priority, terminating the designated task to be executed according to the execution evaluation result of the task in operation, and distributing the new added resource to the task to be executed which is not terminated.
2. The method of claim 1, wherein collecting log data generated after the Kubernetes system executes task scripts submitted by the business system comprises:
After the Kubernetes system determines that the mirror image of the application program does not exist locally, pulling the mirror image from the mirror image library, and then downloading the task script from the script library;
the Kubernetes system executes the task script to generate log data.
3. The method according to claim 1, wherein the method further comprises:
and if the priorities of the plurality of tasks to be executed are the same, dynamically adjusting the execution sequence of the tasks to be executed according to the historical operation time length of the tasks to be executed and the resource use data so as to preferentially execute the tasks to be executed with short historical operation time length or low resource use.
4. A Kubernetes-based service system monitoring device, comprising:
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 so as to deploy the service system to the Kubernetes system; wherein, the application program refers to computer program codes corresponding to each task of the business system;
The acquisition module is used for acquiring log data generated after the Kubernetes system executes task scripts submitted by the service system and operating data of the Kubernetes system; the service system is deployed in the Kubernetes system;
The matching module is used for determining task data when the service system runs according to the log data, matching the task data with a preset first monitoring rule and matching the running data with a preset second monitoring rule;
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;
The resource adjusting module is used for triggering a monitoring self-healing function to call a label management interface of the Kubernetes system so as to label idle resources of the Kubernetes system with labels of the service system; and taking part or all of the idle resources as new resources, and distributing the new resources to the tasks to be executed of the service system through the Kubernetes system; the method comprises the steps of acquiring the resource use condition of each node at present through Kubelet API of a request Kubernetes system, and then determining a new resource from idle resources;
Tasks to be performed assigned to the business system by the Kubernetes system include: judging the service system as the size of the target resource and the newly added resource of the task application to be executed; the method comprises the steps of checking task execution conditions in a waiting queue, summarizing average resource usage of preset time, and taking the average resource usage as a target resource;
if the new resources are smaller than the target resources and the new resources meet the tasks to be executed with high priority, distributing the new resources to the tasks to be executed with high priority;
If the new added resource is smaller than the target resource and the new added resource does not meet the task to be executed with high priority, terminating the designated task to be executed according to the execution evaluation result of the task in operation, and distributing the new added resource to the task to be executed which is not terminated.
5. The apparatus of claim 4, wherein the apparatus further comprises: the deployment operation module is further used for:
After the Kubernetes system determines that the mirror image of the application program does not exist locally, pulling the mirror image from the mirror image library, and then downloading the task script from the script library; and
The Kubernetes system executes the task script to generate log data.
6. An electronic device, comprising:
One or more processors;
Storage means for storing one or more programs,
When executed by the one or more processors, causes the one or more processors to implement the method of any of claims 1-3.
7. A computer readable medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the method according to any of claims 1-3.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910492965.XA CN112052133B (en) | 2019-06-06 | 2019-06-06 | Method and device for monitoring service system based on Kubernetes |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910492965.XA CN112052133B (en) | 2019-06-06 | 2019-06-06 | Method and device for monitoring service system based on Kubernetes |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112052133A CN112052133A (en) | 2020-12-08 |
| CN112052133B true CN112052133B (en) | 2024-09-20 |
Family
ID=73609519
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910492965.XA Active CN112052133B (en) | 2019-06-06 | 2019-06-06 | Method and device for monitoring service system based on Kubernetes |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112052133B (en) |
Families Citing this family (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 |
| CN114326670B (en) * | 2021-12-24 | 2024-03-05 | 北京龙鼎源科技股份有限公司 | Detection method and device for executing tasks by controller, storage medium and electronic device |
| CN115756751A (en) * | 2022-11-23 | 2023-03-07 | 北京火山引擎科技有限公司 | Data processing method, device, equipment and medium for big data operation |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10719505B2 (en) * | 2017-05-17 | 2020-07-21 | International Business Machines Corporation | Database server system monitoring |
-
2019
- 2019-06-06 CN CN201910492965.XA patent/CN112052133B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112052133A (en) | 2020-12-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112052133B (en) | Method and device for monitoring service system based on Kubernetes | |
| CN110310034B (en) | Service arrangement and business flow processing method and device applied to SaaS | |
| CN108874640B (en) | Cluster performance evaluation method and device | |
| CN107729139B (en) | Method and device for concurrently acquiring resources | |
| US9721219B2 (en) | High-load business process scalability | |
| CN108733461B (en) | Distributed task scheduling method and device | |
| CN113934464A (en) | Method and device for starting android application in Linux system and electronic equipment | |
| CN109257320A (en) | Message storage method and device | |
| CN110928905B (en) | Data processing method and device | |
| CN113127225A (en) | Method, device and system for scheduling data processing tasks | |
| CN114090366A (en) | Method, device and system for monitoring data | |
| CN110912949B (en) | Method and device for submitting sites | |
| CN114489997A (en) | Timing task scheduling method, device, equipment and medium | |
| US9741040B2 (en) | High-load business process scalability | |
| CN111831503B (en) | Monitoring method based on monitoring agent and monitoring agent device | |
| CN111858040A (en) | Resource scheduling method and device | |
| CN115525411A (en) | Method, device, electronic equipment and computer readable medium for processing service request | |
| CN114968286A (en) | Micro-service issuing method, device, storage medium and electronic equipment | |
| CN112398669A (en) | Hadoop deployment method and device | |
| CN113760482B (en) | Task processing method, device and system | |
| CN113656239A (en) | Monitoring method and device for middleware and computer program product | |
| CN113672671A (en) | Method and device for realizing data processing | |
| CN113535371A (en) | Method and device for multithreading asynchronous loading of resources | |
| CN116010065A (en) | Distributed task scheduling method, device and equipment | |
| CN112688982B (en) | User request processing method and device |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |