preface

It has been more than two months since the launch of Event Push Gateway: Let CMDB Bid farewell to “Vase”. During this period, we have fully explored the CMDB event push from scratch, constantly stepping on the pit and filling the pit, and now we have basically realized the following functions:

  • CMDB and Zabbix are synchronized, and creation, update, and deletion are synchronized according to the grouping rules of Service _ Cluster _ Module. Host creation, template binding, deletion, instead of zabbix’s passive automatic discovery or automatic registration, with a certain amount of initiative;
  • The CMDB synchronizes with JumpServer. According to the node rules of “/ service/cluster/module”, the CMDB ADAPTS the jumpServer tree structure and synchronizes the creation, update, and deletion of nodes. Update or delete asset groups.

Based on CMDB, we have a basis for infrastructure management, and the event push gateway ensures the orderly flow of the infrastructure, so that we can spare more time to focus on the demand construction of the upper layer.

demand

  1. The CMDB is isolated from systems such as Zabbix and JumpServer, and the asset groups cannot be consistent, which takes a lot of effort to maintain.
  2. Zabbix alarms cannot be associated with services. The SERVICE topology of the CMDB provides a grouping basis for Zabbix, and the alarm information is associated with the service topology to display, helping O&M quickly locate the system.
  3. Jumpserver asset allocation cannot be associated with services. The CMDB service topology provides a grouping basis for Zabbix. The Jumpserer web side is only responsible for permission allocation.

System isolation has always been a difficult problem for operation and maintenance management. It is not practical to use a unified ESB bus to accommodate all systems, so we hope to indirectly break through through the event push gateway.

The solution

1. Push CMDB events

The CMDB supports adding, editing, and deleting host services (resource pool and host), service topology (cluster and topology), and organization structure (service), and triggers the callback of the self-developed event push gateway.

2. Event Push Gateway

The Gateway receives the POST request pushed by the Blue Whale CMDB event. After merging the request, it calls the API of the Zabbix and JumpServer systems to realize the operations such as asset grouping, creation, and host transfer.

3. CMDB trigger rules

CMDB trigger rules are divided into the following categories:

  • Create, update, and delete services
# Parameter under the service triggering rule
{'action': 'create'.'obj_type': 'biz'}
{'action': 'update'.'obj_type': 'biz'}
{'action': 'delete'.'obj_type': 'biz'}
Copy the code
  • Cluster creation, update, and deletion
# Parameter under the cluster triggering rule
{'action': 'create'.'obj_type': 'set'}
{'action': 'update'.'obj_type': 'set'}
{'action': 'delete'.'obj_type': 'set'}
Copy the code
  • Module creation, update, delete
# Parameter under the module trigger rule
{'action': 'create'.'obj_type': 'module'}
{'action': 'update'.'obj_type': 'module'}
{'action': 'delete'.'obj_type': 'module'}
Copy the code
  • Host migration triggers host ID update
# Host transfer triggers host ID update rule under parameters
{'action': 'update'.'obj_type': 'hostidentifier'}
Copy the code

Note: Service, cluster, module update operation, will automatically trigger host identity update, why?

Because the host identity update is the smallest atomic operation, once the service, cluster, and module are updated, the group information of all hosts needs to be changed consistently. Therefore, the final action triggered is as follows:

# Business update
{'action': 'create'.'obj_type': 'biz'}
{'action': 'update'.'obj_type': 'hostidentifier'}

# Cluster update
{'action': 'create'.'obj_type': 'biz'}
{'action': 'update'.'obj_type': 'hostidentifier'}

# Update module
{'action': 'create'.'obj_type': 'biz'}
{'action': 'update'.'obj_type': 'hostidentifier'}
Copy the code

Considering the diversity of the parameter formats of THE CMDB event push POST, which brings some complexity to the gateway parsing parameters, we hereby specify the following CMDB trigger rules:

  • Operations on new services, clusters, and modules are not synchronized. Services, clusters, and modules are created at the same time only when the host is transferred to a related module to reduce repetitive operations.
  • Delete services, clusters, modules, and hosts for synchronization.
  • Update services, clusters, and modules for synchronization.

4. Zabbix synchronization logic

5. Jumpserver synchronization logic

Unlike Zabbix, There is no host creation operation in Jumpserver, as the host is automatically created in Jumpserver by default in the subsequent article [Blue Whale Implementing vsphere VIRTUAL Machine Delivery for Multiple Environments]. Through this process, we default that all the hosts already exist in JumpServer.

conclusion

Before the CMDB, our infrastructure management was disordered, but this does not mean that having the CMDB will make it orderly. Therefore, I think the main core idea is to build on the CMDB and make the infrastructure flow across the platforms effectively, rather than making it a real “vase”.