Export objects with Exportd

Knowledge Base
1

One of the main ideas of DATAGERRY is to export objects to external systems like monitoring systems, configuration management, ticket systems or any other systems and use DATAGERRY as a single source of truth. The export of objects is done with Exportd, an own daemon, which uses plugins to talk to various external systems.

concept
Exportd is organized in jobs. Each job consists of a source, a destination and export variables and can be configured in the WebUI.

A source is a set of objects of a specific type:

image
image1496Ă—663 39.8 KB

In the above screenshot, we choose all objects of type server, where the field management-monitoring is True. You can also choose multiple sources for one export job.

A destination is the definition of an external system, where objects should be exported:

image
image1650Ă—780 70.3 KB

Each destination consists of a class that is specific for an external system and a set of parameters. In the above screenshot, we choose the monitoring system OpenNMS as external system and define parameters that describe how DATAGERRY communicates with OpenNMS. Per export job, multiple destinations can be configured.

Export Variables define a mapping between the fields of an object in DATAGERRY and data that are required by an external system:

image
image1650Ă—685 44.9 KB

Each external system requires a set of variables, that needs to be set. You can click on the blue “Variable helpers” button to get an overview of the variables of an external system. Each variable has a name and a default value. If you export objects of multiple types (like routers and servers), you can define an own value for every type in the templates section.
The value of a variable uses Jinja2 syntax. You can access the public id of an object, the value object fields and even access fields of referenced objects. Have a look at the following examples:

# access the ID of the current object
{{id}}

# access the field "hostname" of the current object
{{fields["hostname"]}}

# dereference an object reference in field "location" (access the field "city" of the referenced object)
# max 3 levels were dereferenced
{{fields["location"]["fields"]["city"]}}

Export jobs are triggered event based, that means, if an object of a type that is defined within the source section is added, updated or deleted, the export job will be triggered. We have an intelligent algorithm there, which avoids triggering the export job multiple time on bulk changes.

functions in version 1.0.x
In version 1.0.x, we implemented a first external system, which exports objects to the OpenSource monitoring system OpenNMS.

functions in version 1.1.x
For the upcoming DATAGERRY version 1.1.0 (which by the way will be released at 6th March 2020 :slight_smile: ), we added support for the following external systems among other things:

  • Ansible: use DATAGERRY as an dynamic inventory for Ansible
  • CSV: export objects to a user defined CSV file

We also added support for “pull” jobs, which means, an external system can call a REST endpoint, to get required data from DATAGERRY. We needed that function for adding support for Ansible dynamic inventory.

functions in version 1.2.x and future releases
For version 1.2.x, we plan to introduce a plugin system for Exportd, which enables a user to simply write an own plugin for an external system. We also think about a scripting plugin, where DATAGERRY can trigger an external script or binary within Exportd.
With customer projects we want to add support for additional external systems.

your thoughts?
What are your thoughts about Exportd and our future plans? Which external systems would you like to get integrated?

1 Like