Docker : can’t create socket (must run as root?) : Permission denied

Dans le cadre de la dockerisation de proxy Zabbix, je suis tombé sur un problème étrange.

Je fais les commandes suivantes :

docker run -it zabbix/zabbix-proxy-sqlite3:ubuntu-3.4-latest /bin/bash
[...]
root@220fab01aae4:/var/lib/zabbix# fping palc.fr
palc.fr is alive
root@220fab01aae4:/var/lib/zabbix# su - zabbix -s /bin/bash
zabbix@220fab01aae4:~$ fping palc.fr
(null): can't create socket (must run as root?) : Permission denied

Note : l’option -it /bin/bash me permets d’avoir directement un bash pour faire mes tests. Lors d’un lancement de Docker en prod, il faudrait utiliser les options -d -t à la place.

Note 2 : vous pouvez également avoir une erreur du type socket: Operation not permitted.

Dans le container Docker, la commande fping fonctionne en root mais pas avec l’utilisateur Zabbix. Pourtant sur le système host, qui utilise le même OS, ça fonctionne bien.

Pour corriger le problème il faut simplement ajouter l’option --sysctl net.ipv4.ping_group_range="0 65535" à la commande lançant le container docker. Ça permets à n’importe quel utilisateur d’accéder directement au réseau de l’hôte, ce qui est indispensable pour effectuer des requêtes ICMP, comme le ping. Dans le cas contraire, seul l’utilisateur root serait autorisé à le faire.

Zabbix : invalid field name « items.jmx_endpoint »

Si vous rencontrez l’erreur suivante dans les logs d’un proxy Zabbix :

failed to update local proxy configuration copy: invalid field name "items.jmx_endpoint"

Ca veut dire que le master est en version 3.4 et que le proxy est en version 3.0. Ces deux versions ne peuvent pas travailler ensemble. Il faut donc mettre à jour le proxy en version 3.4.

Mais cette erreur à une conséquence inattendue. En apparence le proxy fonctionne normalement. Il continue à collecter des données et à les envoyer au master. Par contre il ne peut plus mettre à jour sa configuration (ajout ou modification de métriques). Celle-ci reste figée. Mais si vous relancez le service zabbix_proxy, c’est la cata et même la collecte ne fonctionne plus.

SELinux : détecter et corriger les problèmes de droits

Le problème

Dans le cadre de la supervision MySQL, l’agent Zabbix est censé exécuter cette commande en local pour s’assurer que le serveur accepte bien les connexion :

mysqladmin -h 127.0.0.1 ping

Si je lance la commande en local :

zabbix@1.2.3.4:~$ mysqladmin -h 127.0.0.1 ping
mysqld is alive

Mais quand c’est l’agent Zabbix lui-même qui lance la commande :

mysqladmin: connect to server at '127.0.0.1' failed
error: 'Can't connect to MySQL server on '127.0.0.1' (110)'
Check that mysqld is running on 127.0.0.1 and that the port is 3306.
You can check this by doing 'telnet 127.0.0.1 3306'

Pourtant les deux tests-ci-dessus ont un fonctionnement identique. C’est la même commande qui est utilisée dans les deux cas, avec les même droits. Après une heure à faire des tests et à s’arracher les cheveux pour comprendre d’où peut venir le problème, j’ai pensé à SELinux. Pour voir si SELinux est activé :

root@1.2.3.4:~# getenforce
Enforcing

Là c’est activé, sinon ça m’afficherait Permissive ou Disabled.

Je désactive temporairement SELinux pour faire des tests avec setenforce 0. Comme la supervision Zabbix se mets à fonctionner, je sais que le problème vient de là. Je réactive SELinux avec setenforce 1.

La solution

Pour désactiver définitivement SELinux il faut faire echo "0" > /selinux/enforce. Mais comme je suis sur une plateforme demandant un niveau de sécurité élevé, je ne peux pas le désactive. Il va donc falloir autoriser l’agent Zabbix à utiliser MySQL.

On installe d’abord un utilitaire qui va bien nous aider :

apt-get install policycoreutils

Ensuite on surveille le fichier audit.log :

tail -f -n 0 /var/log/audit/audit.log | audit2allow

À chaque fois que l’agent Zabbix tente de se connecter au MySQL, ca affiche quelque chose qui ressemble à ça :

#============= zabbix_agent_t ==============
allow zabbix_agent_t mysqld_etc_t:file { open read };
#!!!! The file '/var/lib/mysql/mysql.sock' is mislabeled on your system.
#!!!! Fix with $ restorecon -R -v /var/lib/mysql/mysql.sock
#!!!! This avc can be allowed using the boolean 'daemons_enable_cluster_mode'
allow zabbix_agent_t mysqld_t:unix_stream_socket connectto;

On peut voir la cause du problème. L’agent Zabbix ne peut pas accéder à /var/lib/mysql/mysql.sock. Ça nous donne même l’option à activer : daemons_enable_cluster_mode.

Je lance donc les commandes suivantes :

setsebool -P daemons_enable_cluster_mode 1setsebool daemons_enable_cluster_mode 1

Il ne reste plus qu’à redémarrer l’agent Zabbix (systemctl restart zabbix-agent.service), et le problème est résolu.

Zabbix : superviser les tablespaces Oracle

Dans l’article précédent, nous avons vu comment exécuter des requêtes Oracle depuis Linux. Maintenant nous allons nous en servir pour superviser des tablespaces avec Zabbix.

La supervision va se faire en deux parties : une découverte automatique des tablespaces, et la supervision de l’espace libre.

Un export de mon template et des fichiers nécessaires peut être téléchargé à cette adresse : https://palc.fr/wp-content/uploads/template_oracle_tablespace.zip

La découverte automatique

La découverte des tablespace a été abordée dans l’article précédent, mais je vais revenir dessus.

Je vais utiliser un externalscript. Chez moi ils se trouvent dans le dossier /usr/lib/zabbix/externalscripts. Je vais donc dedans et je créé le fichier oracle_tablespace_discovery.ext :

SET heading OFF;
SET feedback OFF;

SELECT
a.tablespace_name
FROM
dba_data_files a
GROUP BY
a.tablespace_name;

EXIT;

On notera la désactivation des en-tête et autres infos inutiles. Cette commande retourne uniquement les tablespaces, et rien d’autre.

Ensuite je créé un script oracle_tablespace_discovery.sh dans le même répertoire :

#!/bin/bash

LD_LIBRARY_PATH=/usr/lib/oracle/12.1/client64/lib

echo '{
  "data":['

for tablespace in `/usr/lib/oracle/12.1/client64/bin/sqlplus -s "$3/$4@ (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = $1)(PORT = $2))) (CONNECT_DATA = (SERVICE_NAME = $5)))" @/usr/lib/zabbix/externalscripts/oracle_tablespace_discovery.ext`
do
  echo -n '    {"{#ORACLE_TABLESPACE_NAME}":"'
  echo -n $tablespace
  echo '"},'
done

echo '    {}'
echo '  ]
}'

Ce script lance la requête Oracle vue dans l’article précédent, et mets le résultat sous un format JSON pour que Zabbix puisse l’interpréter.

À noter le echo ' {}' à la fin. C’est pas très propre, mais c’est une méthode efficace et rapide pour éviter les erreurs JSON sur le dernier résultat retourné.

Maintenant on lance la commande à la main, pour tester :

root@SV-TCA-ZPXSCP01+~# /usr/lib/zabbix/externalscripts/oracle_tablespace_discovery.sh IP 1521 user password NOM_DU_SERVICE
{
  "data":[
    {"{#ORACLE_TABLESPACE_NAME}":"ZABBIX_TS"},
    {"{#ORACLE_TABLESPACE_NAME}":"UNDOTBS1"},
    {"{#ORACLE_TABLESPACE_NAME}":"SYSAUX"},
    {"{#ORACLE_TABLESPACE_NAME}":"USERS"},
    {"{#ORACLE_TABLESPACE_NAME}":"SYSTEM"},
    {"{#ORACLE_TABLESPACE_NAME}":"WF_TABLE"},
    {}
  ]
}

C’est exactement ce que l’ont veut. Il ne reste plus qu’à créer la règle de découverte correspondante. Elle doit juste avoir pour clé oracle_tablespace_discovery.sh[{HOST.IP},{$ORACLE_PORT},{$ORACLE_USER},{$ORACLE_PASSWORD},{$ORACLE_SERVICENAME}] :

On notera l’utilisation des macros, cette règle de découverte étant destinée à finir dans un template.

La supervision de l’espace libre

Là encore je vais utiliser un externalscript. D’abord la requête SQL, dans le fichier oracle_tablespace_stat.ext :

SET heading OFF;
SET feedback OFF;
SET LINE 250;

SELECT
    a.tablespace_name,
    TO_CHAR(SUM(a.bytes)) "Curb",
    TO_CHAR(SUM(decode(b.maxextend, NULL, A.BYTES, b.maxextend*8192))) "Maxb",
    TO_CHAR((SUM(a.bytes) - ROUND(c."Free"))) "TotalUsed",
    TO_CHAR(SUM(decode(b.maxextend, NULL, A.BYTES, b.maxextend*8192)) - (SUM(a.bytes) - ROUND(c."Free"))) "TotalFree",
    100*(SUM(a.bytes) - ROUND(c."Free"))/(SUM(DECODE(b.maxextend, NULL, A.BYTES, b.maxextend*8192))) "UPercent"
FROM
    dba_data_files a,
    sys.filext$ b,
    (SELECT d.tablespace_name , SUM(nvl(c.bytes,0)) "Free"
    FROM dba_tablespaces d, DBA_FREE_SPACE c
    WHERE d.tablespace_name = c.tablespace_name(+) GROUP BY d.tablespace_name
    ) c
WHERE a.file_id = b.file#(+)
    AND a.tablespace_name = c.tablespace_name
GROUP BY
    a.tablespace_name, c."Free"
ORDER BY
    ROUND(100*(SUM(a.bytes) - ROUND(c."Free"))/(SUM(decode(b.maxextend, NULL, A.BYTES, b.maxextend*8192)))) DESC;

EXIT;

Cette requête retourne le nom du tablespace, deux colonnes dont je ne comprends pas trop l’utilité, puis la taille totale et l’espace libre en octets, et enfin le pourcentage d’utilisation. Comme la requête doit obligatoirement être stockée dans un fichier, je suis obligé de tout retourner à chaque fois, sinon ça impliquerait de créer un fichier à la volée et ça créerait de la complexité.

LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2 /opt/oracle/instantclient_12_2/sqlplus -s "user/password@ (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 1.2.3.4)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = NOM_DU_SERVICE)))" @/usr/lib/zabbix/externalscripts/oracle_tablespace_stat.ext

TABLESPACE_NAME Curb Maxb TotalUsed TotalFree UPercent
------------------------------ ---------------------------------------- ---------------------------------------- ---------------------------------------- ---------------------------------------- ----------
WF_TABLE 89120571392 93415538688 83884572672 9530966016 89.797237
SYSAUX 933232640 34359721984 879296512 33480425472 2.55909088
SYSTEM 807403520 34359721984 801243136 33558478848 2.33192555
ZABBIX_TS 104857600 104857600 1048576 103809024 1
USERS 5242880 34359721984 1376256 34358345728 .004005434
UNDOTBS1 728760320 34359721984 14548992 34345172992 .04234316

(ici j’ai réactivé l’affichage de l’en-tête des colonnes, pour que le résultat soit plus facile à comprendre)

Maintenant il reste à exploiter le résultat, via le script oracle_tablespace_stat.sh :

#!/bin/bash

LD_LIBRARY_PATH=/usr/lib/oracle/12.1/client64/lib

/usr/lib/oracle/12.1/client64/bin/sqlplus -s "$3/$4@ (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = $1)(PORT = $2))) (CONNECT_DATA = (SERVICE_NAME = $5)))" @/usr/lib/zabbix/externalscripts/oracle_tablespace_stat.ext | grep -E "^$6\W" | awk "{print \$$7}"

Ce script est assez simple. Il prends les mêmes paramètres que le script de découverte mais en rajouter deux autres : le nom du tablespace, et le numéro de la colonne dont on veut retrouver la donnée. J’ai choisis de faire le filtrage sur le numéro de colonne plutôt que sur son nom pour simplifier la commande. La clé Zabbix est moins clair, mais le script est beaucoup plus simple. C’est un compromis.

Testons le script à la main. Je vais demander le pourcentage d’espace utilisé sur le tablespace WF_TABLE :

root@SV-TCA-ZPXSCP01+~# /usr/lib/zabbix/externalscripts/stat.sh IP 1521 user password NOM_DU_SERVICE WF_TABLE 6
89.797237

Ce tablespace est bien utilisé à 89%. Le script est donc fonctionnel. Il ne reste plus qu’à créer les items.

Un exemple de clé : oracle_tablespace_stat.sh[{HOST.IP},{$ORACLE_PORT},{$ORACLE_USER},{$ORACLE_PASSWORD},{$ORACLE_SERVICENAME},{#ORACLE_TABLESPACE_NAME},2]

La configuration d’un des items :

Tous les items :

Il ne reste plus qu’à créer le trigger, avec l’expression : {Template Oracle:oracle_tablespace_stat.sh[{HOST.IP},{$ORACLE_PORT},{$ORACLE_USER},{$ORACLE_PASSWORD},{$ORACLE_SERVICENAME},{#ORACLE_TABLESPACE_NAME},6].min(#3)}>90

Zabbix : surveiller l’évolution du statut de triggers

Dans le cadre de mon travail il m’est arrivé de devoir surveiller l’évolution des triggers de plusieurs hôtes de façon arbitraire. Il est possible de s’en sortir via les Host groups et la page Monitoring > Triggers, mais ça peut vite être lourd à gérer quand on doit surveiller simultanément plusieurs groupes d’équipements qui n’ont rien en commun.

Comme à l’époque je débutais en Python, j’ai décidé de développer mon propre script pour me faire la main.

#!/usr/bin/env python3
#  Copyright 2018 palc.fr
#
#  Licensed under the WTFPL, Version 2
#            DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE 
# TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 
# 0. You just DO WHAT THE FUCK YOU WANT TO.

"""
  A trigger status viewer

  This script displays the status of triggers on some devices

  Usage :
      ./triggerstatus.py zabbix_server [list of triggers id]
"""

import os       # To manage cursor and window size
import signal   # To manage Ctrl+C and widnow resizing
import sys      # To manage script arguments and terminal buffer
import time     # To get date and for temporisation

import getpass  # For password input without displaying it
import math     # For calculating graph datas
from pyzabbix import ZabbixAPI

def signal_sigint(sig, frame):
    """
        When receiving SIGINT (Ctrl+c), the script exit proprely
    """
    os.system('setterm -cursor on')
    print()
    exit (0)

def signal_sigwinch(sig, frame):
    """
        When the window is resized, redraw the screen
    """
    draw(ok, notclassified, information, warning, average, high, disaster, disable, date)

def draw(ok, notclassified, information, warning, average, high, disaster, disable, date):
    """
        Clear the screen and redraw all the datas
    """

    os.system('clear')

    # Get screen width and height (in characters)
    rows, columns = os.popen('stty size', 'r').read().split()
    rows=int(rows)
    columns=int(columns)

    # General informations
    sum_triggers=len(disable)+len(ok)+len(notclassified)+len(information)+len(warning)+len(average)+len(high)+len(disaster)
    print(date, end='')
    print(" | " + str(sum_triggers) + " (", end='')
    print("\033[32m" + str(len(ok)) + "\033[0m/", end='')
    print("\033[31m" + str(len(notclassified)+len(information)+len(warning)+len(average)+len(high)+len(disaster)) + "\033[0m/", end='')
    print("\033[90m" + str(len(disable)) + "\033[0m)")

    # Calculate graph width
    coef_graph=1
    if(sum_triggers>(columns-6)):
        coef_graph=(columns-6)/sum_triggers

    # Draw the graph
    print('[', end='')
    for i in (range(0, math.ceil(len(disaster)*coef_graph))):
        print("\033[91m", end='')
        print('|', end='')
    for i in (range(0, math.ceil(len(high)*coef_graph))):
        print("\033[31m", end='')
        print('|', end='')
    for i in (range(0, math.ceil(len(average)*coef_graph))):
        print("\033[93m", end='')
        print('|', end='')
    for i in (range(0, math.ceil(len(warning)*coef_graph))):
        print("\033[33m", end='')
        print('|', end='')
    for i in (range(0, math.ceil(len(information)*coef_graph))):
        print("\033[34m", end='')
        print('|', end='')
    for i in (range(0, math.ceil(len(notclassified)*coef_graph))):
        print("\033[37m", end='')
        print('|', end='')
    for i in (range(0, math.ceil(len(disable)*coef_graph))):
        print("\033[90m", end='')
        print('|', end='')
    for i in (range(0, math.ceil(len(ok)*coef_graph))):
        print("\033[32m", end='')
        print('|', end='')
    print("\033[0m]", end='')

    length=3

    # Display items in PROBLEM state
    for i in disaster:
        print("\033[91m", end='')
        if(length<rows):
            print("\n" + i[:columns], end='')
            length+=1
    for i in high:
        print("\033[31m", end='')
        if(length<rows):
            print("\n" + i[:columns], end='')
            length+=1
    for i in average:
        print("\033[93m", end='')
        if(length<rows):
            print("\n" + i[:columns], end='')
            length+=1
    for i in warning:
        print("\033[33m", end='')
        if(length<rows):
            print("\n" + i[:columns], end='')
            length+=1
    for i in information:
        print("\033[34m", end='')
        if(length<rows):
            print("\n" + i[:columns], end='')
            length+=1
    for i in notclassified:
        print("\033[37m", end='')
        if(length<rows):
            print("\n" + i[:columns], end='')
            length+=1

    # Display disabled items
    print("\033[90m", end='')
    for i in disable:
        if(length<rows):
            print("\n" + i[:columns], end='')
            length+=1

    # Display items in OK state
    print("\033[32m", end='')
    for i in ok:
        if(length<rows):
            print("\n" + i[:columns], end='')
            length+=1

    print("\033[0m", end='')

    sys.stdout.flush()

# When receiving SIGINT (Ctrl+c)
signal.signal(signal.SIGINT, signal_sigint)
# When the window is resized
signal.signal(signal.SIGWINCH, signal_sigwinch)

# Connection to Zabbix server
user = input("Username: ")
password = getpass.getpass("Password for " + user + ": ")
try:
    zapi = ZabbixAPI('https://' + sys.argv[1])
    zapi.login(user, password)
except:
    print("Cannot conect to Zabbix server ☹")
    exit(1)

# Disable cursor
os.system('setterm -cursor off')

# main loop
while 1:
    # Tables for each trigger status
    ok=[]
    notclassified=[]
    information=[]
    warning=[]
    average=[]
    high=[]
    disaster=[]
    disable=[]

    for hostid in sys.argv[2:]:
        # Get triggers status
        try:
            triggers=zapi.trigger.get(hostids=hostid)
        except:
            print("Problem with Zabbix server ☹")
            exit(1)

        for trigger in triggers:
            # Item is in OK state
            if(trigger['status'] == '0' and trigger['value'] == '0'):
                ok.append(hostid + ' ' + trigger['description'])

            # Item is in PROBLEM state
            if(trigger['status'] == '0' and trigger['value'] == '1'):
                if(trigger['priority'] == '0'):
                    notclassified.append(hostid + ' ' + trigger['description'] + ' (not classified)')
                if(trigger['priority'] == '1'):
                    information.append(hostid + ' ' + trigger['description'] + ' (information)')
                if(trigger['priority'] == '2'):
                    warning.append(hostid + ' ' + trigger['description'] + ' (warning)')
                if(trigger['priority'] == '3'):
                    average.append(hostid + ' ' + trigger['description'] + ' (average)')
                if(trigger['priority'] == '4'):
                    high.append(hostid + ' ' + trigger['description'] + ' (high)')
                if(trigger['priority'] == '5'):
                    disaster.append(hostid + ' ' + trigger['description'] + ' (disaster)')

            # Item is disabled
            if(trigger['status'] == '1'):
                disable.append(hostid + ' ' + trigger['description'])

    date=time.strftime("%d/%m/%Y %H:%M:%S")

    draw(ok, notclassified, information, warning, average, high, disaster, disable, date)

    time.sleep(10)

exit(0)
triggerstatus.py

Ce script plusieurs plusieurs paramètres :

  • L’URL du serveur Zabbix (en HTTPS uniquement)
  • la liste des ID des équipements à surveiller, séparés par des espaces

Par exemple, pour superviser les équipements 13111 13112 13123 sur le serveur zabbix.palc.fr :

./triggerstatus.py zabbix.palc.fr 13111 13112 13123

Je me suis clairement inspiré de htop pour faire ce script. Il affiche, dans l’ordre :

  • La date (pour vérifier que le script n‘est pas planté), le nombre total de triggers, et le détail par statut (OK, KO et DISABLED)
  • Une barre affichant
  • Tous les triggers classés, d’abord ceux en KO (classé par ordre de sévérité), puis les DISABLED et enfin les OK

C’est mon tout premier « vrai » script fait en Pyhton (hors Hello word! ou équivalent), donc soyez indulgents.

Zabbix : planifier le lancement d’un item

Zabbix 4 offre quelques possibilités pour planifier le lancement d’un item à un moment précis. Mais avec les versions précédentes, il faut ruser.

Il faut créer l’item avec Update interval (in sec) à 0, pour que l’item ne soit jamais exécuté. Ensuite il faut configurer un Flexible intervals avec un Interval à 60 et une Period de une minute. De cette manière, l’item sera exécuté exactement une seul fois dans l’intervalle de une minute.

Par exemple, pour lancer un item à 10h du lundi au samedi :

Zabbix : faire un export de tous les équipements supervisés et de leur statut

Cette technique est super crade. Je l’ai utilisé pour faire un export en urgence des serveurs supervisés. Elle tient en une seule requête SQL :

SELECT
  hosts.hostid AS ID,
  hosts.host AS Serveur,
  CASE
    WHEN hosts.status=0 THEN 'Activé'
    WHEN hosts.status=1 THEN 'Désactivé'
  END AS Statut,
  CASE
    WHEN hosts.maintenance_status=0 THEN 'Pas en maintenance'
    WHEN hosts.maintenance_status=1 THEN 'En maintenance'
  END AS Maintenance,
  interface.ip AS IP
  FROM hosts, interface
  WHERE hosts.status<>3
  AND hosts.hostid=interface.hostid;

Cette requête fait un export des serveurs contenant :

  • L’ID de l’équipement dans Zabbix
  • Le nom de l’équipement
  • Son status (Activé ou Désactivé)
  • L’état de sa maintenance (En maintenance ou Pas en maintenance)
  • Son adresse IP

La requête est assez simple mais comporte quelques subtilités :

  • Les conditions en utilisant CASE / WHEN / THEN / END, qui permettent de convertir le numéro du status en son texte
  • Les AS qui permettent d’affiche un en-tête de colonne plus clair
  • La condition WHERE hosts.status<>3 qui permets de masquer les templates

Zabbix : acknowledge impossible

Sur un Zabbix 3.4, il n’était pas possible d’acknowledger les alertes. L’erreur était :

Fatal error, please report to the Zabbix team

- Controller: acknowledge.edit
- action: acknowledge.edit
- backurl: zabbix.php%3Faction%3Ddashboard.view
- eventids: Array

Le problème est tout con, et ne provient pas de Zabbix. Dans la configuration Apache j’ai retrouvé les lignes suivantes :

RewriteEngine on
RewriteRule ^/zabbix / [R,L]

Je suppose qu’a une époque l’interface web se trouvait derrière le répertoire /zabbix mais qu’à un moment quelqu’un a voulu simplifier et tout mettre à la racine. Ensuite il a rajouté la redirection pour ne pas casser tous les webservices existants (plusieurs services externes utilisent l’API de ce Zabbix). Le problème c’est que ce faisant il a redirigé tout ce qui commençait par /zabbix, y compris les appels à /zabbix.php. Et, vous l’aurez compris, l’acknowledge fait justement un appel à /zabbix.php.

En regardant les logs Apache j’ai vu que aucun webservice n’appelait /zabbix. J’ai donc tout simplement supprimé la redirection.

Si vous devez conserver la redirection, il devrait être possible de s’en sortir avec une règle du type (attention, je n’ai pas testé) :

RewriteEngine on
RewriteRule ^/zabbix(?:/.*)?$ /$1 [R,L]

Zabbix : un trigger actif seulement à certains moments de la journée

Dans Zabbix (jusqu’à la version 3.4), les maintenances ne peuvent s’appliquer qu’à des équipements entiers. Si on veut que certains trigger, mais pas tous, soient en maintenance à certains moments de la journée, il faut ruser. Il y a deux techniques principales.

Pour un seul trigger

Les fonctions date et dayofweek sont faites pour vous. dayofmonth existe aussi mais est moins utile.

{Template Windows:agent.ping.nodata(5m)}=1 and {Template Windows:agent.ping.time(0)}>090000 and {Template Windows:agent.ping.time(0)}<180000 and {Template Windows:agent.ping.dayofweek(0)}<6

Le trigger ci-dessus contient un test d’agent ping standard. J’ai rajouté deux conditions sur l’heure (.time(0)}>090000 et .time(0)}<180000, pour alerter seulement entre 9h et 18h). J’ai également ajouté une condition sur le jour de la semaine (.dayofweek(0)}<6),pour n’alerte que du lundi au vendredi.

Nous pouvons remarquer que les triggers de type date doivent obligatoirement s’appliquer sur un item, mais que sa valeur ne sert à rien dans l’évaluation de la condition.

Pour un gros groupes de triggers

La technique ci-dessus est assez contraignante si on a beaucoup de triggers. Dans ce cas il est possible de faire plus simple. On créé d’abord un trigger :

{Template Windows:agent.ping.time(0)}<090000 or {Template Windows:agent.ping.time(0)}>180000 or {Template Windows:agent.ping.dayofweek(0)}>4

Sur le même principe que la première technique, ce trigger sera systématiquement en alerte entre 18h et 9h, le samedi et le dimanche. Il faut le mettre en sévérité Information pour qu’il ne remonte pas en MCO et ne dérange pas l’astreinte. Ensuite il n’y a plus qu’à faire une dépendance entre ce trigger et ceux qui devront être en maintenance :

De cette manière, le vrai trigger ne sonnera pas quand le trigger « maintenance » sera en alerte, c’est à dire la nuit et le week-end.

Cette technique est plus efficace pour gérer un grand nombre de triggers sur la même plage de maintenance.