Agent concepts, scenarios, and implementations in the automated O & M system

1 concept

In my understanding, the core of O & M is to always maintain the target machine (servers, network devices, system software, etc.) to adapt to business needs. Automated O & M is to automate a series of O & M steps. During all the steps, the maintenance target machine is generally implemented through the agent mounted on the machine. It is a mouth and a pipe on the target machine, integrate the target machine into the entire O & M ecosystem.

Since we use the agent to maintain the target machine, what are the main tasks of the agent? You can think of the following:

• Accept resource delivery: such as sending scripts, configuration files, applications, and libraries.
• Execute local tasks: execute tasks from time to time, such as collecting hardware and software information of machines, starting and stopping services, and log analysis.
• Network services: such as scanning network devices connected to the target machine, pushing data, and providing similar HTTP Services for pull data, a management tool.
• Other custom services.

If an agent is used to adapt to different O & M environments, which is called unique agent, it must provide basic functions other than the preceding agent functions to facilitate automated O & M:

1. Cross-platform: supports mainstream operating systems such as Windows, various Linux and UNIX.
2. Core Service + extension support: uniagent is a container with built-in common services, such as executing scripts (Perl, Python, Shell, BAT), polling SNMP network devices, and analyzing logs. The service exists as a module. Because of the unpredictable environment, uniagent must provide sdks to facilitate developers in specific environments to develop corresponding modules and then load them into uniagent.
3. Control center: the agent must be managed by an agent manager, which is used to collect the agent status and reflect it to a web application named Manager Console. It is convenient for O & M personnel to issue various commands on and off the console, such as installation, uninstallation of services (modules), start and stop, installation of software, and configuration change.

Here I particularly emphasize uniagent, because in a bigger company, there are many departments, products, projects, and O & M and monitoring personnel, which are not uniform yet, installing many agents on the same target machine has many drawbacks. A very important goal of uniagent is to have only one agent on the target machine to be operated and maintained.

2 scenarios

The following describes the life cycle of uniagent in a monitoring scenario. This scenario defines the memory usage monitored by a target machine from scratch.

The entire process is described as follows:

1. Apply for a target machine, install an application, and monitor the application. When the target machine is handed over to the developer for application deployment, it is a "ready to use" machine, that is, the system, IP address, configuration, and so on are OK and the uniagent is pre-installed, at the same time, the basic hardware information of this machine, system + version, has been found in the machine Information Query System (hereinafter referred toMqs.
2. When the target machine starts, uniagent queries the registration machine (Agent manager) from the masterAMHere, the master is a unique server (or server list, after VIP/LVS) with a domain name ). The master reports the information based on the uniagent, mainly the IP address information, and then assigns it an agent manager IP address based on certain policies (such as IDC room policies. Uniagent is successfully registered with AM. As for how the master knows which agent managers and policies are available, there should be another system for maintenance.
3. Uniagent sends heartbeat and other information to AM. Am regularly refreshes this information to the database (DB.
4. O & M personnel use the Manager Console (hereinafter referred toMCYou can view the list of uniagents maintained under an AM, the status of each target machine, system information, and the list of Agent modules. Because the O & M personnel need to monitor the memory usage and assume that the script service is executed (normally it is built in, so that the context is simple and complete. This service or module is called exescript for the time being) if the exescript module is not installed, run the following command to install the exescript module.
5. Am in the target machine system information sent based on uniagent, combined with the mqs system, findAppropriate versionTo issue the exescript module to the uniagent. For example, if the target machine is Windows, it may be exescript. dll; if it is Linux, It is exescript. So.
6. Uniagent returns the updated module information to AM. Note that the subprocess of exescript has been started and can provide services. The O & M personnel will see that the module is successfully delivered, and there is a Perl script meminfo. pl stored in the Resource Center (hereinafter referred toRCAnd can be seen through MC. He decided to deliver the meminfo. pl file to all its target machines through AM.
7. Uniagent receives a request from the resource meminfo. pl and delivers the request to an exescript file directory that is stored in the exescript module. Each resource has a unique relative address, such as/sys/MEM/x86/meminfo. pl. The directory stored in conjunction with the exescript script is an absolute path that can be located.
8. The am monitoring system spy sends a monitoring task, that is, the scheduled scan script meminfo. pl. This task is delivered to the uniagent. When a scheduled execution script is enabled, the result is sent to monitor. How do I know which monitor to send? See step 2.
9. The uniagent queries the monitor on the master node (the monitoring-related data consumer is monitor. For example, the Collector may be related to the portal, and the master node determines which data consumers are based on the module information ), the uniagent connects monitor a and monitor B and continuously sends data to the specified location. This data transfer protocol is uniform and may use HTTP POST.

Of course, only the installation and collection behaviors are described above. For a complete system, there are also stop tasks, unmount modules, and delete resources. Among all the elements, only the monitoring system spy and monitor belong to the application, and others must be developed or provided (for example, RC and mqs must be provided) to run the uniagent automatic process.

3. Implementation

Although uniagent cannot be too large in size, it provides container functions and requires a language with better abstraction capabilities. I suggest using C ++ for implementation, because:

1. Language Features: C ++ is standard and cross-platform. It supports advanced data structures, modular programming, and error exception handling.
2. Many libraries: such as STL, boost, and protobuf. For the daily System Tasks of uniagent, the operating system SDK provides a wide range of libraries to simplify the implementation.
3. Cross-language: All component libraries that can implement multi-language interfaces are implemented based on C ++, such as COM, XPCOM, and CORBA. This provides basic support for uniagent to implement cross-language programming in the future.

Many build systems support C ++, such as automake, scons, cmake, nmake (MS build, that is, Visual Studio), among which cmake has good "native" features, that is, the build system that adapts to the system itself, for example, generating the Visual Studio solution file on Windows. In addition, cmake has also passed the practices of large-scale projects such as kde4. In Linux, kdevelop, cmake and C ++, are also available.

The dynamic module mechanism of uniagent is based on the operating system's DL (dynamic loading), that is, dynamic library loading. It is implemented in UNIX and windows. Because the binary formats of the two operating systems are different, the implementation mechanisms are different, but the functions required by uniagent are sufficient.

Because the SDK is provided, the uniagent Container development must also be in the database + shell mode. Similar to the relationship between APACHE and APR, the two must be separated at the beginning, in this way, the Library can be included in the SDK for other module developers.

Reference implementation:

Https://github.com/lifesting/uniagent