Integrating with Icinga

Icinga is designed to monitor the availability of network resources and proactively generate alerts about the outages and performances of hosts and services. As a tenant administrator, it's important that you can monitor the connected systems and quickly identify and resolve any issues. The BMC Helix Intelligent Integrations Icinga connector collects events and metrics from Icinga.

BMC Helix application	Type of data collected or viewed	Benefits
BMC Helix Operations Management	Events	Use a centralized event view to monitor and manage events, perform event operations, and filter events. Identify actionable events from a large volume of event data by processing events. For more information, see Monitoring events and reducing event noise.
BMC Helix Operations Management	Metrics	Detect anomalies and eliminate false positives. Use alarm and variate policies to detect anomalies through static and dynamic thresholds. For more information, see Detecting anomalies by using static and dynamic thresholds.
BMC Helix AIOps	Situations (created from events)	Improve the mean time to resolve (MTTR) based on the situation-driven workflow. Lower the mean time to detect or discover (MTTD) and the time required for investigating tickets. For more information, see Monitoring situations.

Supported versions

BMC Helix Intelligent Integrations supports version 2.x of Icinga for data collection.

Task 1: To plan for the connection

Review the following prerequisites to help you plan and configure a connection with Icinga.

Icinga prerequisites

Make sure that the user account that you plan to use while configuring a connection with Icinga has the following permissions:

config/query
events/*
objects/query/*
status/query
types
variables

BMC Helix Intelligent Integrations prerequisites

In the following list, third-party product refers to Icinga.

Depending on the location of the third-party product (SaaS, on-premises), choose one or more BMC Helix Intelligent Integrations deployment modes and review the corresponding port requirements. For information about various deployment modes and port requirements, see Deployment-scenarios.
Based on the deployment mode, use the BMC Helix Intelligent Integrations SaaS deployment or the BMC Helix Intelligent Integrations on-premises gateway or both. For more information about the gateway, see Deploying-the-BMC-Helix-Intelligent-Integrations-on-premises-gateway.

The on-premises gateway must be able to reach the third-party product on the required port (default is 5665).

Task 2: To configure the connection with Icinga

Depending on the deployment mode, perform one of the following steps to access BMC Helix Intelligent Integrations:
- BMC Helix Intelligent Integrations SaaS – Log on to BMC Helix Portal, and click Launch on BMC Helix Intelligent Integrations.
- BMC Helix Intelligent Integrations on-premises gateway – Use the following URL to access BMC Helix Intelligent Integrations:
  https://<hostName>:<portNumber>/swpui
On the CONNECTORS tab, click in the SOURCES panel.
Click the Icinga tile.
Specify the source connection details:
1. Specify a unique instance name.
  Best practice
  We recommend that you specify the instance name in the following format:
  <sourceType>_<sourceControllerServerName>_<InstanceQualifier>
  The instance qualifier helps you distinguish the multiple instances configured from the same source server. For example, you can name your instances as ICINGA_PROD and ICINGA_TEST.
2. Specify the Icinga host name and port number (default value is 5665).
Click VALIDATE AND CREATE.
The specified connection details are validated and the corresponding source connection is created in the Source Connection list.
Verify that the source connection you created is selected.
Important
The destination host connection is created and configured automatically for each tenant when the source connection is created.
Verify that the options for the data types for which you want to collect data are selected.

Click a data type and specify the configuration parameters in the Collectors section as described in the following table:

Parameter name	Description	Data type
Parameter name	Description	Icinga Events	Icinga Metrics
Collection Schedule	Select one of the following options to specify the data collection frequency: Duration: When you select this option, data collection happens constantly. Specify the schedule in minutes, hours, or day. Default: 5 minutes Example: Collection Schedule is set to 5 mins. Current time is 00:30. If you run the collector just after 00:30, data is collected every 5 mins, first at 00:30 and next at 00:35, and so on. Cron schedule: When you select this option, data collection happens periodically. Specify the schedule by using a cron expression. A cron expression is a string consisting of five subexpressions (fields) that describe individual details of the schedule. These fields, separated by blank spaces, can contain any of the allowed values with various combinations of the allowed characters for that field. Default: /5 * * * (evaluates to 5 minutes) Format: Minutes *Hours (24-hour format)* Day of Month Month Day of Week** Example: If you specify 10 15 3 7 * , data is collected at 15:10 hours every third day in the month of July. For more information about how this parameter affects data collection, see Data collection schedule.	✅️	✅️
Subscription Time	Specify the duration a client (or subscriber) remains connected to Icinga and collects data. For example, if Collection Schedule and Subscription Time are set to 5 minutes, after every 5 minutes, the client (or subscriber) connects to Icinga and collects data for 5 minutes. Default: 5 minutes Important: The subscription time should not be longer than the collection schedule.	✅️	✅️
Service or Host Regex	Specify the regular expression for the service name. Events and metrics are collected for the services whose names match the regular expression. If no service name is received from Icinga, the regular expression is applied to the host name. Examples: To collect data for the services that contain the string ping in their names, specify the regex as *.ping.*. To collect data for the ping service, specify the regex as ping*. To collect the data for the services whose names start with the string ping, specify the regex as ^ping.. Separate multiple regular expressions by a pipe (\|). For example: ping\|.ping.\|^ping.* Important: If you are using multiple regular expressions, make sure that the regular expressions are not conflicting. For example, do not enter, ^Ping.* and ^(?!Ping$).*** together. The former expression collects metrics for the services whose name start with the string Ping, while the latter expression collects data for the services whose name do not start with the string Ping. The default expression for Services or Host Regex is .*. This regular expression collects data for all the services. Do not leave this field blank. Either use the default regular expression or enter a custom regular expression. To use the query for applying filters, see To filter the events and metrics by using a query.	✅️	✅️

Click CREATE COLLECTORS to create the required collector streams for the selected data types.

Click a data type and specify the configuration parameters in the Distributors section as described in the following table:

Parameter Name	Description	Icinga Events	Icinga Metrics
Max Batching Size	Specify the maximum number of data items to send in a single POST request to the destination API. The batch size depends on the destination’s ability to buffer the incoming data. Default: 250	✅️	✅️
Max Batching Delay	Specify the maximum time (in seconds) to wait before building and processing a batch. Default: 3 seconds	✅️	✅️
Base Retry Delay	Specify the initial time (in seconds) for which to wait before retrying to build and process a batch. The waiting time increases in the following sequence: n¹, n², n³, and so on, where n indicates the number of seconds. Default: 2 seconds Example: Base Retry Delay is set to 2 seconds.Retry is performed after 2, 4, 8, 16, ... seconds.	✅️	✅️
Max Intra-Retry Delay	Specify the maximum limit for the base retry delay. Default: 60 seconds Example: Max Intra-Retry Delay is set to 60 seconds. Base Retry Delay is set to 2 seconds.Retries are performed 2, 4, 8, 16, 32,... seconds later.	✅️	✅️
Max Retry Duration	Specify the total time for retrying a delivery. For REST destinations, a delivery is a batch of data items in one POST request. Default: 5 minutes Example: Max Retry Duration is set to 8 hours. Base Retry Delay is set to 2 seconds. Requests are sent for 2+4+8+16+32+64+132... until 8 hours in total duration is reached. After that, no subsequent attempts are made to retry the delivery. The assumption here is that if there is an outage or other issue with the destination tool, recovery should take less than the value of the Max Retry Duration parameter to be completed.	✅️	✅️
Device Filters and Metrics filtersDevice and Metrics filters help remove unwanted data and send only the required data to BMC Helix applications. The data is filtered by using the regular expression (regex) provided for device name, monitor name, monitor type, and metrics, and is sent to BMC Helix applications.
Device Name Regex	Specify the regex for the device name. Metrics for devices whose names match the regex are sent to BMC Helix applications. Examples: To send data for the devices that contain the string Linux in their names, specify the regex as *.Linux.**. To send data for the devices that contain the string Cisco* and Linux, specify the regex as *(?=.Cisco)(?=.Linux).*. To send the data for the devices whose names start with the string Linux, specify the regex as ^Linux.. Important: If you are using multiple regex, make sure that the regex do not conflict. For example, do not enter .Linux. and ^(?!.Linux).** together. The former regex sends metrics for the devices whose names contain the string Linux, while the latter regex sends metrics for the devices whose names do not contain the string Linux.	❌	✅️
Monitor Name Regex	Specify the regex for the monitor name. Metrics for the monitors whose names match the regex are sent to BMC Helix applications. Examples: To send data for the monitors that contain the string system in their names, specify the regex as *.system.**. To filter out the data for monitors that contain system* in their name, specify the regex as *^(?!.system).**. To send the data for monitors whose names start with the string system, specify the regex as ^system.. Important: If you are using multiple regex, make sure that the regex do not conflict. For example, do not enter .system. and ^(?!.system).** together. The former regex sends metrics for the monitors whose names contain the string system, while the latter regex sends metrics for the monitors whose names do not contain the string system.	❌	✅️
Monitor Type Regex	Specify the regex for the monitor type. Metrics are sent to BMC Helix applications for the monitor type that matches the regex. Examples: To send data for the monitor type that contains the string health, specify the regex as *.health.**. To send data for the monitor type that starts with the string health, specify the regex as ^health.*. To filter out the monitor type that contains the string health, specify the regex as ^(?!.health).*. Important: If you are using multiple regex, make sure that the regex do not conflict. For example, do not enter, ^health.* and ^(?!.health).** together. The former regex collects metrics for the monitor type whose names contain the string health, while the latter regex collects data for the monitor types whose names do not contain the string health.	❌	✅️
Metrics Regex	Specify the regex for the metrics. Metrics are sent to BMC Helix applications whose names match the regex. Examples: To send metrics that contain the string avg in their names, specify the regex as *.avg.**. To filter out the metrics that contain the string avg, specify the regex as ^(?!.avg).**. To send metrics whose names start with the string avg, specify the regex as ^avg.. Important: If you are using multiple regex, make sure that the regex do not conflict. For example, do not enter, .avg. and ^(?!.avg).** together. The former regex sends metrics whose name contains the string avg, while the latter regex sends metrics whose name does not contain the string avg.	❌	✅️
Events FiltersEvents filters help remove unwanted data and send only the required events to BMC Helix applications. The data is filtered by using the regular expression (regex) provided for host, message, and detailed message and is sent to BMC Helix applications.
Host Regex	Specify the regex for the host name. Events for the hosts whose names match the regex are sent to BMC Helix applications. Examples: To send data for the host name /inventory/pricing, specify the regex as ^/inventory/pricing$. To filter out data whose host name contains the string inventory, specify the regex as *^(?!.inventory).**. To send the data for the host whose names start with the string inventory, specify the regex as ^inventory.. Important: If you are using multiple regex, make sure that the regex do not conflict. For example, do not enter .(inventory). and ^(?!.inventory).** together. The former regex sends events for the hosts whose names contain the string inventory, while the latter regex sends events for the hosts whose names do not contain the string inventory.	✅️	❌
Message Regex	Specify the regex for the event message. Messages for the events that match the regex are sent to BMC Helix applications. Examples: To send events whose messages contain the string HRV alert, specify the regex as *.HRV alert**. To filter out the events whose message contains the string HRV alert, specify the regex as ^(?!.HRV alert).**. To send events whose message starts with the string HRV alert, specify the regex as ^(HRV alert).. Important: If you are using multiple regex, make sure that the regex do not conflict. For example, do not enter .HRV alert. and ^(?!.HRV alert).** together. The former regex sends events whose message contains the string HRV alert, while the latter regex sends events whose message do not contain the string HRV alert.	✅️	❌
Detailed Message Regex	Specify the regex for the detailed message. Detailed messages for the events that match the regex are sent to BMC Helix applications. Examples: To send events whose detailed message contains the string ci_display_name: easyTravel-k8s, specify the regex as *.ci_display_name: easyTravel-k8s.**. To filter out the events whose detailed message contains the string ci_display_name: easyTravel-k8s, specify the regex as ^(?!.ci_display_name: easyTravel-k8s).**. To send the events whose detailed message starts with the string ci_display_name: easyTravel-k8s, specify the regex as ^(ci_display_name: easyTravel-k8s).. Important: If you are using multiple regex, make sure that the regex do not conflict. For example, do not enter .ci_display_name: easyTravel-k8s. and ^(?!.ci_display_name: easyTravel-k8s).** together. The former regex sends events whose detailed message contains the string ci_display_name: easyTravel-k8s, while the latter regex sends events whose message do not contain the string ci_display_name: easyTravel-k8s.	✅️	❌

Click CREATE DISTRIBUTORS to create the required distributor streams for the selected data types.
Click one of the following buttons:
- SAVE STREAM: Click this button if you want to edit the integration details before creating the instance. After you save the stream, the connector that you just created is listed in the SOURCES panel. Move the slider to the right to start the data stream.
- SAVE AND START STREAM: Click this button if you want to save the integration details and start receiving data immediately.
Important
For a data stream, the Run Latency (max/avg), Items (Avg per Run), and Last Run Status columns on the Streams page might show the status as No Runs during the data collection process. After completion of the process, these columns are updated with an appropriate status.
For more information about data streams, see Starting-or-stopping-data-streams.

Task 3: To verify the connection

In BMC Helix Intelligent Integrations, on the SOURCES panel, confirm that the data streams for the integration you created are running. Data streaming is indicated by moving colored arrows.

A moving dark blue arrow ( ) indicates that the event stream is running. Event data will be pushed according to the configured Collection Schedule interval.
A moving red arrow ( ) indicates that the metric stream is running. Metric data will be pushed according to the configured Collection Schedule interval.

To view data in BMC Helix applications

View data collected from Icinga in multiple BMC Helix applications.

To view events in BMC Helix Operations Management

In BMC Helix Operations Management, select Monitoring > Events.
Filter the events by the IcingaEvent class.

Incoming events from Icinga are processed in BMC Helix Operations Management through a set of rules to determine whether the incoming event contains the results of the same test on the same node and then processed accordingly. For more information, see Event-deduplication-suppression-and-closure-for-reducing-event-noise.

For information about events, see Monitoring and managing events.

To view metrics in BMC Helix Operations Management

In BMC Helix Operations Management, select Monitoring > Devices.
Click the links for the required device.
On the Monitors tab, click the required monitor.
The Monitors tab shows the list of service names that are specified in Icinga for service monitoring. Additionally, you can also see Icinga's internal services to monitor host performance.
The Performance Overview tab shows the metrics graph.

For information about metrics, see Viewing collected data.

Filtering events and metrics data by using a query

In addition to using regex to filter events and metrics data, you can use a query to filter the events and metrics data from Icinga. Queries are helpful when the data being collected might change over a period of time. When you specify a query, data is collected according to the filter conditions specified in the query. For example, you can use the query to collect events for all those services whose state is OK.

Data collected for events changes as soon as the conditions specified in the query are not satisfied. For example, if the state of a service changes to INACTIVE after the data collection interval you have specified, events are not collected.

Use the entityType parameter to specify the entity for which you want to collect data and the filterQueryString parameter to specify the filter query.

Important

If filter conditions are provided through query and regex both, BMC Helix Intelligent Integrations uses the filter provided in the query to collect data from Icingaand ignores the regex.
If entry for entityType or filterQueryString is missing, BMC Helix Intelligent Integrations collects data from Icinga using the regex specified.
If entityType or filterQueryString has an invalid entry, BMC Helix Intelligent Integrations does not collect any data from Icinga.

To filter events and metrics data by using a query

Click Configure Mediator adjacent to Icinga.
Expand the ICINGA EVENTS section to specify the query for events or expand ICINGA METRICS for metrics.
Under the Collector Configuration tab, enable the Edit JSON option.
You can see the JSON format of collector configuration parameters.
Set the value of the entityType parameter to hosts to collect data for hosts.
The default value is services.

In the filterQueryString parameter, enter the query to collect data.
For example, the following query collects events for the services whose state is not ServiceOK, or whose low flapping threshold is greater than or equal to 20:
{
"filter":"service.state != \"ServiceOK\" || flapping_threshold_low >= 20"
}
Click SAVE.
Disable the Edit JSON option.
Click SAVE & CLOSE.