Icinga

Siehe auch

Module

Module für Icingaweb2 liegen in /usr/share/icingaweb2/modules/.

Update eines Moduls (beispielhaft für das Icubator-Modul):

MODULE_NAME=incubator
MODULE_VERSION=v0.17.0
MODULES_PATH="/usr/share/icingaweb2/modules"
MODULE_PATH="${MODULES_PATH}/${MODULE_NAME}"
RELEASES="https://github.com/Icinga/icingaweb2-module-${MODULE_NAME}/archive"

mkdir -p "$MODULE_PATH" \
&& wget -q $RELEASES/${MODULE_VERSION}.tar.gz --output-document - \
   | tar xfz - -C "$MODULE_PATH" --strip-components 1

icingacli module enable "${MODULE_NAME}"

API

Liste aller Hosts zurückgeben:

API_USERNAME=alice
API_PASSWORD=linuxfabrik
curl \
    --insecure \
    --connect-timeout 5 \
    --header 'Accept: application/json' \
    --user "$API_USERNAME:$API_PASSWORD" \
    'https://monitor.example.com:5665/v1/objects/hosts'

Liste aller Services zurückgeben:

API_USERNAME=alice
API_PASSWORD=linuxfabrik
curl \
    --insecure \
    --connect-timeout 5 \
    --header 'Accept: application/json' \
    --user "$API_USERNAME:$API_PASSWORD" \
    'https://monitor.example.com:5665/v1/objects/services'

Downtime auf dem Icinga2 Master per API für alle Hosts und Services setzen:

API_USERNAME='downtime-user'
API_PASSWORD=$(icinga2 object list --type ApiUser --name $API_USERNAME | sed -n 's/.* password = "\(.*\)"/\1/p')
START_TIME=$(date +%s)
END_TIME=$(( START_TIME + 7200 )) # 2h
cat > /tmp/icinga2-api.json << EOF
{
    "type": "Host",
    "all_services": true,
    "start_time": "$START_TIME",
    "end_time": "$END_TIME",
    "author": "$USER",
    "comment": "Updating the Icinga Director config."
}
EOF
curl \
    --insecure \
    --data @/tmp/icinga2-api.json \
    --header 'Accept: application/json' \
    --request POST \
    --user $API_USERNAME:$API_PASSWORD \
    "https://localhost:5665/v1/actions/schedule-downtime" | python3 -m json.tool

Bemerkung

Meldung „Unauthorized. Please check your user credentials.“?

Lösung: icinga2 daemon -C --dump-objects und erneut laufen lassen.

Alle Downtimes auf dem Icinga2 Master per API entfernen:

API_USERNAME='downtime-user'
API_PASSWORD=$(icinga2 object list --type ApiUser --name $API_USERNAME | sed -n 's/.* password = "\(.*\)"/\1/p')
cat > /tmp/icinga2-api.json << EOF
{
    "type": "Host",
    "all_services": true
}
EOF
curl \
    --insecure \
    --data @/tmp/icinga2-api.json \
    --header 'Accept: application/json' \
    --request POST \
    --user $API_USERNAME:$API_PASSWORD \
    "https://localhost:5665/v1/actions/remove-downtime" | python3 -m json.tool

Passiven Check befüttern:

username='icinga-director-api'
password='linuxfabrik'

host_name='test-host'
service_name='passive service'

plugin_output='multiline test
line 2
line 3

line 4 (after empty line)
line 5
line 6
'
# convert for icinga
plugin_output=${plugin_output//$'\n'/\\n}

curl \
    --insecure \
    --silent \
    --user "$username":"$password" \
    --header 'Accept: application/json' \
    --request POST 'https://master.example.com:5665/v1/actions/process-check-result' \
    --data @- << EOF
{
    "type": "Service",
    "filter": "host.name==\"$host_name\" && service.name==\"$service_name\"",
    "exit_status": 2,
    "plugin_output": "$plugin_output",
    "performance_data": [
    "rta=5000.000000ms;3000.000000;5000.000000;0.000000",
    "pl=100%;80;100;0"
    ],
    "check_source": "example.localdomain"
}
EOF

Icinga PowerShell Framework

Bemerkung

WinRM ist die von Microsoft und Windows genutzte Plattform, um Systeme remote zu verwalten. WMI kann als eine Möglichkeit WinRM verwenden. Wer WMI auf seinem lokalen Rechner verwendet, nutzt demnach kein WinRM.

Siehe auch https://icinga.com/docs/icinga-for-windows.

Beispiele für Abfragen gegen einen MS-SQL-Server:

PS C:\Windows\system32> icinga { Invoke-IcingaCheckMSSQLResource -SqlUsername 'user' -SqlPassword (ConvertTo-IcingaSecureString 'password') -SqlHost sqlsrv -Verbosity 1 }
[OK] MSSQL Performance (MSSQLSERVER)
| 'average_latch_wait_time_ms'=0.001238s;; 'buffer_cache_hit_ratio'=100%;;;0;100 'page_life_expectancy'=2027081;;
0

PS C:\Windows\system32> icinga { Invoke-IcingaCheckMSSQLBackupStatus -SqlUsername 'user' -SqlPassword (ConvertTo-IcingaSecureString 'password') -SqlHost sqlsrv -Verbosity 1 }
[OK] MSSQL Backup (MSSQLSERVER)
| 'average_size'=1658538B;; 'log_age'=0s;; 'size'=1670148000B;; 'status'=0;6;5 'execution_time'=0s;; 'age'=0s;; 'average_size'=24806280B;; 'log_age'=0s;; 'size'=5854283000B;; 'status'=0;6;5 'execution_time'=0s;; 'age'=54000s;; 'average_size'=1658919B;; 'log_age'=0s;; 'size'=1670531000B;; 'status'=0;6;5 'execution_time'=0s;; 'age'=0s;; 'average_size'=13233520B;; 'log_age'=0s;; 'size'=16409560000B;; 'status'=0;6;5 'execution_time'=0s;; 'age'=0s;; 'average_size'=4590350B;; 'log_age'=0s;; 'size'=5710395000B;; 'status'=0;6;5 'execution_time'=0s;; 'age'=0s;; 'average_size'=5829484B;; 'log_age'=0s;; 'size'=1375758000B;; 'status'=0;6;5 'execution_time'=0s;; 'age'=54000s;; 'average_size'=3417790B;; 'log_age'=0s;; 'size'=4255149000B;; 'status'=0;6;5 'execution_time'=0s;; 'age'=0s;; 'average_size'=981317.3B;; 'log_age'=0s;; 'size'=1224684000B;; 'status'=0;6;5 'execution_time'=0s;; 'age'=0s;; 'average_size'=56638400B;; 'log_age'=0s;; 'size'=70231610000B;; 'status'=0;6;5 'execution_time'=0s;; 'age'=0s;;
0

PS C:\Windows\system32> icinga { Invoke-IcingaCheckMSSQLHealth -SqlUsername 'user' -SqlPassword (ConvertTo-IcingaSecureString 'password') -SqlHost sqlsrv -Verbosity 1 }
[OK] MSSQL Health (MSSQLSERVER)
| 'service_sql_server_mssqlserver_mssqlserver'=4;;4 'connection_time'=0.069s;;
0

PS C:\Windows\system32> icinga { Invoke-IcingaCheckMSSQLPerfCounter -SqlUsername 'user' -SqlPassword (ConvertTo-IcingaSecureString 'password') -SqlHost sqlsrv -Verbosity 1 -Performanc
eCounter '\SQLServer:Buffer Manager\Buffer cache hit ratio', '\SQLServer:Latches\Average Latch Wait Time (ms)'}
[OK] MSSQL Performance Counter (MSSQLSERVER)
| 'sqlserverlatches'=56371;; 'sqlserverbuffer_manager'=24;;
0

Migration

Für den Umzug einer Icinga2-Master-Installation von server-alt nach server-neu muss zunächst Icinga2 auf dem neuen Server gleich wie auf dem alten installiert und als Master konfiguriert werden. Danach müssen auf beiden Servern die Services gestoppen werden:

icinga2 feature disable notification
systemctl disable --now icinga2
systemctl disable --now httpd
systemctl disable --now php-fpm

Falls man IcingaDB verwendet, sollte man /var/lib/icinga2/icingadb.env vom alten Server kopieren (siehe https://icinga.com/docs/icinga-db/latest/doc/05-Distributed-Setups/#environment-id).

Nun müssen die Datenbanken migriert werden, normalerweise ist dies MySQL/MariaDB/PostgreSQL und eine InfluxDB. Siehe MariaDB Migration und InfluxDB Backup und Restore.

Ist dies abgeschlossen, muss der Director auf den neuen Hostnamen vom Master aufmerksam gemacht werden. Der erste Aufruf wird einen Fehler liefern (ERROR: RuntimeException in /usr/share/icingaweb2/modules/director/library/Director/KickstartHelper.php:448 with message: Failed to remove External Zone 'my-old-master.example.com', it's eventually still in use), beim zweiten Mal sollte es dann ohne Fehlermeldungen durchlaufen.

systemctl start icinga2
systemctl start httpd
systemctl start php-fpm

icingacli director kickstart run
icingacli director kickstart run
systemctl restart icinga-director.service
# deploy the changes in the director

Nun ist der Master soweit bereit. Falls sich der Hostname geändert hat, müssen alle Agents neu ausgerollt werden, damit die PKI stimmt.

Sobald alles getestet wurde und wie erwartet funktioniert, sollten die Notification wieder aktiviert werden:

icinga2 feature enable notification
systemctl restart icinga2

systemctl enable icinga2
systemctl enable httpd
systemctl enable php-fpm

Troubleshooting

icinga2 wird durch wegen out-of-memory gekillt

In so einem Fall sollte man sich die Grössen der Queues des Icinga2 Cores anschauen. Diese werden immer wieder in das Icinga2 Logfile schrieben. Alternativ werden diese auch als Performance Daten von bultin-in icinga-Check ausgegeben.

Module path "/usr/share/icingaweb2/modules" does not exist. ERROR: Cannot read enabled modules. Config directory "/etc/icingaweb2" is not readable beim Aufruf von icingacli durch Icinga2

Das kann entweder an falschen File-Permissions oder an SELinux liegen. Zu SELinux gibt es ein ungelöstes GitHub-Issue. Als Workaround kann man ein eigenes SEModule bauen und laden:

cat > icingacli.te << 'EOF'
module icingacli 1.0;

require {
    type icingaweb2_rw_content_t;
    type icingaweb2_config_t;
    type icingaweb2_content_t;
    type icinga2_t;
    class dir { getattr open read search };
    class file { getattr open read };
    class lnk_file { getattr open read };
}

#============= icinga2_t ==============

allow icinga2_t icingaweb2_config_t:dir { getattr open read search };
allow icinga2_t icingaweb2_config_t:file { getattr open read };
allow icinga2_t icingaweb2_config_t:lnk_file { getattr read };
allow icinga2_t icingaweb2_content_t:dir { getattr open read search };
allow icinga2_t icingaweb2_content_t:file { getattr open read };
allow icinga2_t icingaweb2_rw_content_t:dir getattr;
EOF

yum -y install make selinux-policy-devel
make --file /usr/share/selinux/devel/Makefile icingacli.pp
semodule --install icingacli.pp
systemctl restart icinga2
unexpected database schema version: v4 (expected v5), please make sure you have applied all database migrations after upgrading Icinga DB
mysql --user mariadb-admin --password icingadb < /usr/share/icingadb/schema/mysql/upgrades/1.2.0.sql
mysql --user mariadb-admin --password icingadb < /usr/share/icingadb/schema/mysql/upgrades/optional/1.2.0-history.sql

systemctl restart icingadb
Im Icinga Director funktionieren custom variables im notes und notes_url-Feld nicht.

Siehe https://github.com/Icinga/icingaweb2-module-director/issues/1021

high-availability: Lost heartbeat-Meldungen im IcingaDB Journal nach Deployments im Icinga Director

Wenn der Restart des Icinga2-Prozesses nach dem Deployment etwas länger dauert (was in grösseren Umgebungen durchaus vorkommen kann), werden möglicherweise keine Heartbeats in Redis geschrieben. Sobald der Restart jedoch abgeschlossen ist, sollte alles wieder normal laufen.

Built on 2025-05-09