Currently, deploying an Icinga 2 Agent on a Linux system can be intricate, given the substantial variations in the process across different releases or OS families.
For instance:
The repository definition differs for each OS version and family
User and group specifications vary between Debian and RedHat
The environmental path for the Icinga installation also could differ
Fortunately, there’s no need to develop and maintain a custom script to manage these diverse scenarios. We can leverage the readily available Ansible Plugins for this purpose.
Given that our objectives are clearly defined, I developed a role that encompasses all the necessary steps. This allows you to effortlessly integrate it into your playbooks.
You can consult these links to better understand the topic:
Essentially, the role is structured around the following stages:
Gathering NetEye Information: Retrieving essential data from NetEye, including node role, NetEye version, and Icinga2 zone
Collecting Target Information: Gathering details about the target system, such as Linux version and hostname
Verifying Icinga Certificates: Checking for the existence of Icinga certificates on target systems
Token Generation: Creating a token either through the command-line interface (CLI) or by utilizing the API
Installing Icinga Repository and Agent: Setting up the Icinga repository and installing the agent on the designated target
Establishing Icinga Connection: Linking the Icinga agent to the master or satellite
Icinga 2 Restart: Initiating a restart of the Icinga 2 service
NB: When executing this role on a NetEye master or satellite node, there’s no requirement to input specific variables. All necessary data will be automatically collected and utilized.
The playbook will look something like this:
- hosts: all
remote_user: root
roles:
- icinga2-wp
As anticipated, the role can be executed from an external system, such as an Ansible server. In such cases, the following information needs to be provided:
For more information you can request the access to the bitbucket role
Conclusion
Deploying Icinga using Ansible greatly improves on manual deployment due to the efficiency, accuracy, and consistency of automation. Ansible eliminates human error, ensures uniformity across deployments, and adapts to various systems, reducing complexity. Centralized management and scalability enhances efficiency. In sum, Ansible accelerates deployment, minimizes mistakes, and boosts system reliability.
These Solutions are Engineered by Humans
Did you find this article interesting? Are you an “under the hood” kind of person? We’re really big on automation and we’re always looking for people in a similar vein to fill roles like this one as well as other roles here at Würth Phoenix.
Running Ollama locally or on dedicated hardware is straightforward until you need to know whether a model is actually loaded in RAM, how fast it generates tokens under load, or when memory consumption reaches a threshold that affects other workloads. Read More
Hi everyone! Today I'd like to share with you an investigation we undertook related to ingesting Open Telemetry data in Elasticsearch, while maintaining tenant segregation from start to end. The Scenario Let's imagine we have multiple customers, where in this Read More
SNMP monitoring is the standard method for obtaining information and metrics from network devices. Typically, we focus on extracting data from a single interface to monitor its status, traffic, or errors. But in many cases, we’re only interested in getting Read More
In the ITOA module we fixed a bug that prevented the Performance Graphs to be shown in the Monitoring host and service page. List of updated packages grafana, grafana-autosetup, grafana-configurator and grafana-neteye-config to version 12.4.1_neteye3.29.2-1
Creating a GitHub organization is easy. Creating a public one that is actually well-structured, secure, and maintainable over time… not so much. At the beginning, it feels like a simple task: create the org, push some repositories, maybe define a Read More