1Gateway product documentation


The purpose of 1Gateway is the exchange of messages between multiple disparate systems. It automatically keeps connected systems synchronized and propagates status information between them. Currently it is focused on messages that represent events, metrics and service desk tickets.
There are four differentiated parts in 1Gateway: core, mappers, plugins and configuration.
1Gateway is configured through the user interface. The configuration consists of all the plugin specifications (with their fields and conditions) and the plugin mappers.
The plugin configuration has two different parts. The main configuration, which is done through the production area; and the work area, where new plugins can be configured and put into production.
The production area directory name can be defined as a command-line argument in 1Gateway.



The plugins that are connected to 1Gateway are what define the integrations of the different monitoring products. There are two types of plugins: listeners and senders.
Listeners are the inbound plugins, passing messages into 1Gateway. Senders are outbound and pass messages from 1Gateway to other systems.

Image 1. Definition of plugin types

Message flow

Image 2. Message flow in 1Gateway

The listener plugin “listens” to messages from an outside source (endpoint). Incoming messages are normalized and routed to their final destination sender(s). Before a sender forwards a message to its endpoint, it can use a mapper to translate the normalized message into an endpoint-specific format.
A “normalized message” is a message that has a format that is not endpoint-specific and contains a minimum standard set of keys. See the messages for more detail.
Each sender has a message queue. The maximum size of sender queues, and the actions to take when they exceed the maximum size, are configurable. When a sender queue is full, the sender thread can be terminated, or in case of mission-critical senders, processing can be throttled until the queue clears, in which case listeners are not allowed to produce messages faster than senders can process them.
Queues are drained or saved to disk during graceful shutdown.


Mappers convert messages from one type to another. Mappers can perform calculations, unit conversions, time format conversions, apply regular expressions with capture groups, replace literal strings, etc.


Conditions are filters used to decide the routing of each message. They can be used by mappers, mappings, senders, anywhere a message filter is needed. Conditions apply to message fields. Basic Boolean logic like AND and OR is available.
An example of a condition:

Image 3. Condition example

In this example the condition filters on the message type “Normalized Metric” and the metric type “temperature”. If the conditions are met, the message will be propagated. Conditions in mappers provide additional filtering, for example to select a mapper based on metric type.