Server operation and maintenance system
By designing a lightweight server operation and maintenance system, including a monitoring unit to monitor the usage of CPU, memory and disk in real time, especially the disk IO delay, it solves the problem of the existing system's inability to effectively monitor the disk IO delay and achieves fast and accurate Fault diagnosis and the effect of reducing operation and maintenance costs.
Patent Information
- Application Number
- CN202411422275.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-12
- Publication Date
- 2025-01-17
AI Technical Summary
The existing server operation and maintenance system has complex functions and high cost, and cannot effectively monitor disk io delay, making it difficult to quickly and accurately determine whether the disk is faulty or has a large amount of io occupation.
A lightweight server operation and maintenance system is designed, including a monitoring unit to monitor the usage of CPU, memory and disk. In particular, the disk monitoring module is used to monitor the read and write speed and IO delay of the disk in real time. If the IO delay is frequently high value is judged to be a disk failure or a large amount of IO usage.
It realizes real-time monitoring of disk IO delays, can quickly and accurately determine whether the disk is faulty or has a large amount of IO occupied, reduces operation and maintenance costs, and is suitable for server operation and maintenance of small and medium-sized enterprises.
Smart Images
Figure CN119322718A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of server operation and maintenance, and in particular to a server operation and maintenance system. Background Art
[0002] Server operation and maintenance is the guarantee to ensure the normal operation of the server and provide services efficiently, involving multiple aspects such as monitoring server performance, managing server resources, regular updates and patches, implementing backup strategies, handling technical failures and security protection. Good server operation and maintenance can reduce system downtime and ensure business continuity. Existing server operation and maintenance systems are usually complex in functions, large in size, and not lightweight enough. They are costly and not applicable to some small and medium-sized enterprises. In addition, they usually monitor the CPU usage, memory usage, and disk usage, but do not have the function of monitoring the disk io latency, making it impossible to quickly and accurately determine whether the disk is faulty or whether there is a large amount of io occupancy. Summary of the invention
[0003] The present invention aims to provide a lightweight server operation and maintenance system, which can monitor the current IO latency of the disk, so as to quickly and accurately determine whether the disk is faulty or whether a large amount of IO is occupied.
[0004] A server operation and maintenance system includes a monitoring unit, wherein the monitoring unit includes a CPU monitoring module, a memory monitoring module, and a disk monitoring module. The CPU monitoring module is used to monitor the CPU usage percentage, the memory monitoring module is used to monitor the memory usage, and the disk monitoring module is used to monitor the usage of each disk. The disk monitoring module is also used to monitor the current read and write speed of each disk, as well as the current IO delay of each disk. If the current IO delay of the disk frequently appears at a high value, it is determined that there is a disk failure or there are a large number of applications occupying IO.
[0005] A preferred implementation of the present invention is that the disk usage includes the percentage usage of each mounted disk and the inode used. When the value is used up, it indicates that the disk capacity is not full, but files cannot be stored.
[0006] A preferred implementation of the present invention is that it also includes an image building unit, which includes an image builder and an image backup module. The image builder is used to package the application into an image, and the image backup module is used to modify the tag of the previous image with the same name to the time of the current build by default when the image builder is repeatedly executed.
[0007] A preferred implementation manner of the present invention is that the image building unit also includes an image builder reconstruction module, an image builder startup module, an image builder stop module, an image builder deletion module and an operation log viewing module, and the image builder reconstruction module can be used to modify corresponding parameters or modify the builder name to rebuild the builder.
[0008] A preferred embodiment of the present invention is that it also includes a container management unit, the container management unit includes an image startup setting module, the image startup setting module is used to fill in the image name, environment variables, startup command, and set the restart strategy, network mode and mount point, the restart strategy includes: no: no is the default restart policy. If the Docker container fails to start or stops unexpectedly, the Docker Daemon will not attempt to restart it. Unless the container is started manually, it will always be in the stopped state. Always: always means always restart. Its prerequisite is that if the container is stopped by the docker stop command, Docker will not start the container automatically. However, if the Docker Daemon is restarted after the docker stop command is executed, the container will trigger the always restart policy and start the container. on-failure: The container will be restarted only when it fails; unless-stopped: unless-stopped will detect the status of the container in the Docker container list when the Docker Daemon is started. If the container was stopped in the stop state when it was stopped last time, the container will not be started, otherwise the container will be started.
[0009] A preferred implementation of the present invention is that the container management unit further includes an image reconstruction module, an image startup module, an image stop module, an image deletion module and a log viewing module, and the image reconstruction module is used to modify image startup setting parameters or rebuild an image.
[0010] A preferred implementation manner of the present invention is that the container management unit further includes an image pulling module, and the image pulling module is used to pull the image when the filled-in image does not exist, and create a container after the pulling is successful.
[0011] A preferred implementation of the present invention is that it also includes an image management unit, which includes an image update module and a pull log creation module. The image update module is used for users to download images from a public network or a private image repository, and to update the original images. The pull log creation module is used to create a cache image when the user pulls the image, and the pull log can be viewed. When the image is pulled successfully, the cache image automatically disappears.
[0012] A preferred implementation manner of the present invention is that it also includes a load balancing unit, which uses nginx to create a load balancing function, which creates an nginx container and mounts an nginx configuration file into the container.
[0013] A preferred implementation of the present invention is that it also includes an online IDE unit, which is used to create a web version of an IDE environment on a server using Docker, so that programmers can edit and debug codes through web pages.
[0014] The server operation and maintenance system of the present invention adopts a lightweight design, has basic server operation and maintenance functions, has low operation and maintenance costs, is particularly suitable for server operation and maintenance of small and medium-sized enterprises, and has a disk IO delay monitoring function, which can facilitate operation and maintenance personnel to check disk problems. When the disk IO delay is often at a high value, it means that the IO capacity of the disk is not enough to meet the needs of the current application. At this time, it is necessary to check and determine whether it is a hard disk failure or a large number of applications occupying IO. At the same time, the system also has an image backup function. When the builder is repeatedly executed, the tag of the previous image with the same name (the image name format is name:tag) will be modified to the time of the current build by default, such as the format is: 2006-01-02.15.04.05, so that the garbage image file cannot be cleaned up; the system also has an image pulling function. When creating a container, if the filled-in image does not exist, the platform will first try to pull the image, and the container will be created only after the pull is successful. If the image filled in by the user does not exist, it may be that the user fills in an error. The system will match and compare the image name filled in by the user in the image database, thereby pulling the image desired by the user and improving the user experience. BRIEF DESCRIPTION OF THE DRAWINGS
[0015] Figure 1 A schematic block diagram of an embodiment of a server operation and maintenance system of the present invention. DETAILED DESCRIPTION
[0016] The preferred embodiments of the present invention are described below in conjunction with the accompanying drawings. It should be understood that the preferred embodiments described below are only used to explain the present invention and will not limit the protection scope of the present invention.
[0017] The terms "first", "second" and the like in the specification, claims and embodiments of the present application are used to distinguish similar objects rather than to describe a specific order or sequential sequence.
[0018] The present invention is further described in detail below through preferred specific embodiments: As attached Figure 1 As shown: the server operation and maintenance system disclosed in this embodiment includes a monitoring unit, and the monitoring unit includes a CPU monitoring module, a memory monitoring module, and a disk monitoring module.
[0019] The CPU monitoring module is used to monitor the CPU usage percentage. In this embodiment, different block colors are used for display on the monitoring page. When there are more green blocks (idle), it means that the CPU is working normally. On the contrary, when there are fewer green blocks, it means that the CPU is busy.
[0020] The memory monitoring module is used to monitor memory usage. Similarly, different block colors are used for display on the monitoring page. When there are more green blocks (free), the memory usage is normal; fault: on the contrary, when there are fewer green areas (free), it means that the memory is almost exhausted; alarm: when there are more yellow areas (cache), it means that there are applications that use a lot of memory at the current moment or in the past. Although it does not affect the server operation at this time, it still needs attention.
[0021] The disk monitoring module is used to monitor the usage of each disk. In this embodiment, a polygonal graphic is used for the disk monitoring page, and each corner is the percentage usage of a mounted disk. If the usage exceeds 80%, the text turns red. The disk monitoring is divided into: Percentage used: the actual usage of the disk. When this value is used up, files cannot be stored; Inode used: all usage of disk files. When this value is used up, it means that the disk capacity is not full, but files cannot be stored, which means that the format allocation of the disk is unreasonable and needs to be reallocated.
[0022] The disk monitoring module is also used to monitor the current read and write speed of each disk and the current io delay of each disk. If the current io delay of the disk frequently appears at a high value, it is determined that there is a disk failure or there are applications that occupy a large amount of io.
[0023] In this embodiment, a load monitoring module is also included. The load value (comprehensive calculation value of CPU, memory, and disk IO) reflects the busyness of the machine. When the load value exceeds the number of CPU cores (threads), it means that the machine is already quite busy. If it continues to increase, the machine will become more and more stuck, and may even crash. The load monitoring display is preferably in the form of a line graph.
[0024] In this embodiment, the server operation and maintenance system also includes an operation and maintenance prompt unit and a file storage area monitoring unit for which type of files are suitable for storing on each disk. The operation and maintenance prompt unit prompts information including the file type suitable for storage on disk C, the file type suitable for storage on disk D, the file type suitable for storage on disk E, and the file type suitable for storage on disk F; the file storage area monitoring unit is used to automatically monitor the size of a file when storing it on a disk. If the file size exceeds a set value, the file is judged to be a large file or a large installation software, and then monitors whether the file type matches the file type suitable for storage on the disk. If they match, a prompt is given that the file can be stored; if they do not match, a prompt is given that a storage area error occurs; the file storage area monitoring unit is also used to issue a prompt suggesting changing the storage area when the storage capacity of a disk reaches a preset value and the storage capacity of other disks that can store files of the same type does not reach the preset value. If the user stores the file on a disk that exceeds the preset value at this time, the file storage area monitoring unit issues a prompt suggesting changing the storage area, so that the user can store files as reasonably as possible, thereby avoiding the problem that a disk stores too large files while other disks store less files, resulting in uneven disk storage distribution and affecting the server operation performance.
[0025] The server operation and maintenance system of this embodiment further includes an image construction unit, which includes an image builder, an image backup module, and an image builder reconstruction module.
[0026] The image builder is used to package the application into an image; the image backup module is used to modify the tag of the previous image with the same name to the time of the current build by default when the image builder is repeatedly executed, because docker will overwrite the original image name by default when building or pulling the image, causing the original old image to become a garbage file. In this embodiment, since the image backup function is set, the builder will back up the name by default, and the above problem does not exist.
[0027] The image builder reconstruction module can be used to modify corresponding parameters or modify the builder name to rebuild the builder. In this embodiment, the corresponding parameters refer to the builder name, build type, code repository address, branch, repository user name, repository password and image name selected when packaging the image.
[0028] The image building unit also includes an image builder startup module for starting the image builder; an image builder stop module for stopping the image builder; an image builder deletion module for deleting the image builder; and an operation log viewing module for generating an operation log of the image building, which can be browsed and viewed.
[0029] The server operation and maintenance system further includes a container management unit, which includes an image startup setting module, which is used to fill in the image name, environment variables, startup commands, and set the restart strategy, network mode and mount point. The restart strategy includes: no: no is the default restart policy. If the Docker container fails to start or stops unexpectedly, the Docker Daemon will not attempt to restart it. Unless the container is started manually, it will always be in the stopped state. Always: always means always restart. Its prerequisite is that if the container is stopped by the docker stop command, Docker will not start the container automatically. However, if the Docker Daemon is restarted after the docker stop command is executed, the container will trigger the always restart policy and start the container. on-failure: The container will be restarted only when it fails; unless-stopped: unless-stopped will detect the status of the container in the Docker container list when the Docker Daemon is started. If the container was stopped in the stop state when it was stopped last time, the container will not be started, otherwise the container will be started.
[0030] The network modes include: Host network: The container uses the same network as the host. The application in the container can access any port on the host. This is the simplest mode. Bridging: The container uses its own network and is not connected to external machines by default. It needs to be mapped through ports to communicate with the host network. The default port format is: host port: container port; No network: This mode is convenient for advanced users. The network is not used when the container is created, and the user can configure the container network by himself afterwards.
[0031] The mount point is used to mount files on the host to the container for the convenience of applications in the container. For example, the backend configuration file can be mounted in this way. You can also mount the entire folder in. The format to fill in is: host file (folder) path: container file (folder) path.
[0032] The container management unit also includes an image reconstruction module, an image startup module, an image stop module, an image deletion module and a log viewing module. The image reconstruction module is used to modify image startup setting parameters or rebuild an image.
[0033] The container management unit further includes an image pulling module, and the image pulling module is used to pull the image when the filled image does not exist, and create a container after the pulling is successful.
[0034] The server operation and maintenance system also includes an image management unit, which includes an image update module and a pull log creation module. The image update module is used for users to download images from the public network or private image warehouse, and to update the original images. The pull log creation module is used to create a cache image when the user pulls the image, and can view the pull log. When the image is pulled successfully, the cache image disappears automatically. The information displayed by the cache image includes the image ID, image name, creation time, creation type, image size and operation. When the user pulls the image, other images similar to the pulled image will be displayed in the cache image at the same time, that is, the image management unit will automatically filter similar images according to the image to be pulled by the user and display them in the cache, but these similar images are not pulled, but only their related information is displayed in the cache for user reference. If the user needs to pull similar images at the same time, he can further choose batch pull, select other images to be pulled, and finally pull them together with the image to be pulled input by the user before. After the pull is successful, all cache images disappear.
[0035] The server operation and maintenance system also includes a load balancing unit, which uses nginx to create a load balancing function, which creates an nginx container and mounts an nginx configuration file into the container.
[0036] The load balancing unit also includes a module for modifying the nginx configuration, which is used to modify the configuration file in the nginx configuration file and restart the load balancing (container) to complete the modification. Another modification method is also provided. In the file management of the basic function, the corresponding configuration file (the default file name is: the name of the load balancing-nginx.conf) is modified and the load balancing (container) is restarted.
[0037] The server operation and maintenance system of this embodiment also includes an online IDE unit, which is used to create a web version of the IDE environment on the server using Docker, so that programmers can edit and debug the code through the web page. The details are as follows: Create a new workspace and perform basic configuration on the environment: The workspace name is the project name, which is actually the name of the code storage directory and is generally the same as the project repository name; Code repository address: project code address, supports git or svn; Branch: Optional. Leaving it blank will pull the default branch. Warehouse username / warehouse password: authentication information when pulling code; Template type: select the type of code and the type of IDE you are used to using; Configuration path: The default is OK.
[0038] operate: After creating a new workspace, you can start the web IDE by clicking the button. By default, it searches for an available port on a server to start the web IDE. Subsequent operations are the same as those of a local IDE, and you can perform coding and debugging.
[0039] The preferred implementation modes of the present application are described in detail above in conjunction with the accompanying drawings. Typical known structures and common knowledge technologies in the preferred implementation modes are not described in detail here. Ordinary technicians in the relevant field can improve and implement the technical solutions of the present invention based on their own abilities under the inspiration given by the present implementation modes. Some typical known structures, known methods or common knowledge technologies should not become obstacles for ordinary technicians in the relevant field to implement the present application.
[0040] The scope of protection required by this application shall be based on the contents of its claims, and the contents recorded in the invention content, specific implementation methods and drawings of the specification shall be used to interpret the claims.
[0041] Within the technical concept of the present application, several modifications may be made to the specific implementation methods of the present application, and these modified specific implementation methods should also be regarded as within the protection scope of the present application.
Claims
1. A server operation and maintenance system, comprising a monitoring unit, wherein the monitoring unit comprises a CPU monitoring module, a memory monitoring module, and a disk monitoring module, wherein the CPU monitoring module is used to monitor the CPU usage percentage, the memory monitoring module is used to monitor the memory usage, and the disk monitoring module is used to monitor the usage of each disk, and wherein: The disk monitoring module is also used to monitor the current read and write speed of each disk and the current io delay of each disk. If the current io delay of the disk frequently appears at a high value, it is determined that there is a disk failure or there are applications that occupy a large amount of io.
2. The server operation and maintenance system according to claim 1, characterized in that: The disk usage includes the percentage usage of each mounted disk and the inode used. When the value is used up, it indicates that the disk capacity is not full, but files cannot be stored.
3. The server operation and maintenance system according to claim 1, characterized in that: It also includes an image building unit, which includes an image builder and an image backup module. The image builder is used to package the application into an image, and the image backup module is used to modify the tag of the previous image with the same name to the time of the current build by default when the image builder is repeatedly executed.
4. The server operation and maintenance system according to claim 3, characterized in that: The image building unit also includes an image builder reconstruction module, an image builder startup module, an image builder stop module, an image builder deletion module and an operation log viewing module. The image builder reconstruction module can be used to modify corresponding parameters or modify the builder name to rebuild the builder.
5. The server operation and maintenance system according to claim 1, characterized in that: It also includes a container management unit, which includes an image startup setting module. The image startup setting module is used to fill in the image name, environment variables, startup commands, and set the restart strategy, network mode and mount point. The restart strategy includes: no: no is the default restart policy. If the Docker container fails to start or stops unexpectedly, the Docker Daemon will not attempt to restart it. Unless the container is started manually, it will always be in the stopped state. Always: always means always restart. Its prerequisite is that if the container is stopped by the docker stop command, Docker will not start the container automatically. However, if the Docker Daemon is restarted after the docker stop command is executed, the container will trigger the always restart policy and start the container. on-failure: The container will be restarted only when it fails; unless-stopped: unless-stopped will detect the status of the container in the Docker container list when the Docker Daemon is started. If the container was stopped in the stop state when it was stopped last time, the container will not be started, otherwise the container will be started.
6. The server operation and maintenance system according to claim 5, characterized in that: The container management unit also includes an image reconstruction module, an image startup module, an image stop module, an image deletion module and a log viewing module. The image reconstruction module is used to modify image startup setting parameters or rebuild an image.
7. The server operation and maintenance system according to claim 5, characterized in that: The container management unit further includes an image pulling module, and the image pulling module is used to pull the image when the filled image does not exist, and create a container after the pulling is successful.
8. The server operation and maintenance system according to claim 1, characterized in that: It also includes an image management unit, which includes an image update module and a pull log creation module. The image update module is used for users to download images from a public network or private image repository, and to update the original images. The pull log creation module is used to create a cache image when a user pulls an image, and can view the pull log. When the image is pulled successfully, the cache image automatically disappears.
9. The server operation and maintenance system according to claim 1, characterized in that: The system also includes a load balancing unit, which uses nginx to create a load balancing function, which creates an nginx container and mounts an nginx configuration file into the container.
10. The server operation and maintenance system according to claim 1, characterized in that: It also includes an online IDE unit, which is used to create a web version of an IDE environment on a server using Docker, so that programmers can edit and debug codes through web pages.