demand

We use the Blue Whale standard operation to get through zabbix and JumpServer, although we implement the virtual machine from creation, jumpServer asset entry to permission allocation, CMDB asset entry this complete set of process. However, the assets and group relationships among CMDB, JumpServer, and Zabbix are not unified, and the team needs to spend some effort to maintain and synchronize the information among the teams. In this case, CMDB does not play the role of unifying the data source and providing data support, because Zabbix and JumpServer are all out of the Blue Whale system.

Think about jumpServer and Zabbix, which provide various services such as jump-off machines and alarm monitoring for basic operation and maintenance, application operation and maintenance, DBA, business operation and big data operation and maintenance, etc. The automated process of bringing the virtual machine (server) to the shelf only satisfies the entry of assets during the new server launch phase, but does not satisfy the consistent synchronization of group adjustments among CMDB, JumpServer, and Zabbix, which can cause the following problems:

• CMDB asset cluster and module assets are missing, and there will be omissions in application operation platform and fault self-healing.
• If the jumpServer group asset is missing, the user’s asset will be missing.
• When Zabbix generates alarms by service group, an asset alarm is missed. In addition, alarm information is associated with services by group, which helps us locate faults. However, fault rectification takes longer.

To sum up, we summarize the requirements into the following two points:

• The Blue Whale CMDB is isolated from systems such as Zabbix and JumpServer, and the asset groups cannot be consistent. It takes a lot of effort to maintain.
• Zabbix alarms are associated with services. The CMDB service topology provides zabbix groups. Alarm information is displayed in groups to help O&M quickly locate faults.
• The asset allocation of JumpServer is associated with businesses. The business topology of the CMDB provides a grouping basis for JumpServer to ensure the integrity of the use of assets by users.

The solution

There is no doubt that CMDB, as a unified data source for infrastructure, can provide data support for upper-layer applications such as Zabbix and JumpServer. Therefore, all asset allocation should be consistent and synchronized with CMDB as far as possible. In this case, event push of blue Whale CMDB is needed to push information changes in real time.

The event push function can realize the real-time notification to the associated system when the configuration information changes. Currently, the HTTP push mode is supported. Before you can use this feature, you need to develop an interface for the target system that can receive HTTP requests.

From the above information on the official website:

• Event push, invoking the callback interface through a series of actions of the business, module, and asset. We can obtain information related to CMDB changes, such as: asset IP, business, module, and so on.
• Event push depends on a target system and interface for receiving HTTP requests. We locate this interface as the event push gateway, which needs to be developed by ourselves. Through the event push gateway, and then accept the CMDB push information of assets, services, and modules in Zabbix, JumpServer to create related groups, and the asset IP is assigned to the associated groups, in order to ensure the consistency with the CMDB service topology.

So what we need to do next is:

• Configure CMDB event push, and define triggering actions and callback interfaces.
• Develop event push gateway to receive CMDB push information and associate zabbix and JumpServer API for operation.

To explore the implementation

As it is currently in the exploratory stage, we are still thinking about many details, but it is clear that we should first push CMDB events and initially develop the event push gateway to accept the change information.

CMDB event push

1. Create an event push

Open “Model Management-Event Push” through the side navigation and click the “New” button.

In the new push dialog box, focus on improving three parts:

1. Push name: Used to distinguish different pushes. The name must be unique with the service.
2. URL: The URL that the target system receives the push request. The deployment environment of the Blue Whale configuration platform is required to have smooth access to this URL.
3. Event subscription: Optionally select events based on the needs of the target system. After filling in the URL, you can use the “Test Push” function to view the detailed push information and perform push tests (debugging whether the configuration platform can access the API of the target system).

2. Query the event push status

After you create an event push, you can see the number of notifications received and the failure of the current push in the push list.

Event Push Gateway

The event Push Gateway is our self-named system, developed through PYTHon3.9 + Django3.2, and is used for CMDB callback. For the time being, we only get the CMDB change information.

Note: 10.10.2.11 belongs to module TEST1 and module test2. Delete it from module Test2 and only retain module Test1. After testing, CMDB operations are divided into the following three steps:

• Delete 10.10.2.11 from test1;
• Delete 10.10.2.11 from test2;
• Add 10.10.2.11 to test1;

Therefore, the action trigger of blue Whale 5.1 event push will generate multiple requests for the same requestid. At this time, we use Redis to deduplicate the request, and we only accept the final group information.

# 1.Python conda create -n gateway Python =3.9
source activate gateway
pip install django redis 

# 2.Create the project Django-admin startProject gateway CD gateway Python manage.py startapp gw_cmdbCopy the code

The specific implementation of the event push gateway will be further discussed in the following articles, but will not be released here for the time being. Please keep paying attention to the following content.