Options supplémentaires¶

Le rôle Ansible reemo-infra responsable de l’installation possède des options supplémentaires. Par souci de facilité de lecture, ces options sont détaillées dans ce document.

Ecriture des logs Syslog¶

Par défaut les logs de chaque service sont envoyés dans le Syslog local de chacun des noeuds avec facility=daemon par défaut.

Syslog Facility¶

Vous pouvez modifier la valeur de facility en utilisant la liste d’options suivante:

SYSLOG_FACILITY: "daemon"
SYSLOG_FACILITY_API: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_APICRON: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_DB: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_EXIM4: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_MYSQL: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_PORTAL: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_PORTALADMIN: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_SIGNAL: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_PROAPI: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_STUN: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_PRORELAYAPI: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_PROCLOUDAPI: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_APICRONLOG: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_APICRONLDAP: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_APICRONCLOUD: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_HAPROXY: "{{SYSLOG_FACILITY}}"
SYSLOG_FACILITY_TRAEFIK: "{{SYSLOG_FACILITY}}"

Tip

Tous les logs sont écrits dans le Syslog avec comme préfixe reemo_

Commandes utiles de recherche dans les logs Reemo¶

Pour rechercher des erreurs dans les logs avec l’aide d’Ansible:

Infra Manager

ansible infra_manager -i inventory.yml -m shell -a "grep _traefik /var/log/syslog | grep '\" 5[0-9][0-9] [0-9]'"
ansible infra_manager -i inventory.yml -m shell -a "grep ' 500 [0-9]' /var/log/syslog"

API Manager

ansible api_manager -i inventory.yml -m shell -a "grep _traefik /var/log/syslog | grep '\" 5[0-9][0-9] [0-9]'"
ansible api_manager -i inventory.yml -m shell -a "grep ' 500 [0-9]' /var/log/syslog"

Portal Manager

ansible portal_manager -i inventory.yml -m shell -a "grep _traefik /var/log/syslog | grep '\" 5[0-9][0-9] [0-9]'"
ansible portal_manager -i inventory.yml -m shell -a "grep ' 500 [0-9]' /var/log/syslog"

Logs de sécurité¶

La plateforme permet la gestion et la centralisation des événements de sécurité via le service logapi. Les options de configuration suivantes sont disponibles :

LOGAPI_ENABLED : true (par défaut). Permet d’activer ou de désactiver globalement le service logapi.
LOGAPI_SYSLOG_ACTIVE : false. Définit si les logs de sécurité doivent être envoyés vers le service Syslog local de l’hôte.
API_LOGAPI_ANONYMIZE : false. Permet d’activer l’anonymisation des données sensibles au sein des logs de sécurité.

Santé de la plateforme¶

Pour monitorer la santé de la plateforme depuis un service externe, vous avez la possibilité d’activer une route de healthcheck sur un ou plusieurs Portail. Cette route vous permet d’afficher un état global de la plateforme. Elle est accessible via l’URL:

https://url-de-votre-portail/api/healthcheck

Exemple de la réponse JSON:

{
    "status": "OK",
    "version": "2.14.4",
    "services": {
        "api": 
        {
            "status": "OK",
            "version": "2.15.2",
            "services": 
            {
                "db": 
                {
                    "status": "OK"
                },
                "provision-api": 
                {
                    "status": "OK",
                    "version": "2.7.0"
                },
                "provision-relay-api": 
                {
                    "status": "OK",
                    "version": "1.3.0"
                },
                "container-providers": [
                    {
                        "status": "OK",
                        "name": "Reemo SWARM",
                        "type": "SWARM"
                    }
                ],
                "ws-relays": [
                    {
                        "status": "OK",
                        "name": "Global - WS_SWARM",
                        "type": "WS_SWARM"
                    }
                ]
            }
        },
        "signal": {
            "status": "OK",
            "version": "2.6.1"
        }
    }
}

Activation de la route¶

Pour activer cette route sur le Portail, vous pouvez utiliser les options:

HEALTHCHECK_ENABLE: “true”
HEALTHCHECK_RESTRICT_IP: “192.168.1.1,192.168.10.0/24”

Et pour activer cette route sur le Portail Admin:

HEALTHCHECK_PORTALADMIN_ENABLE: “true”
HEALTHCHECK_PORTALADMIN_RESTRICT_IP: “192.168.1.1,192.168.10.0/24”

Format Prometheus¶

Si vous souhaitez obtenir ces informations au format Prometheus, elles sont accessibles sur la route https://url-de-votre-portail/api/healthcheck/prometheus

# HELP app_service_status Services status (1 = up, 0 = down)
# TYPE app_service_status gauge
# HELP app_service_items Services items numbers
# TYPE app_service_items gauge

app_service_status{service="db"} 1
app_service_status{service="provision-api"} 0
app_service_status{service="provision-relay-api"} 0
app_service_status{service="Mon provider - SWARM", parent="container-providers", type="SWARM"} 0
app_service_status{service="Mon websocket relay 1 - WS_SWARM", parent="ws-relays", type="WS_SWARM"} 0
app_service_status{service="Mon websocket relay 1 - Traefik status", parent="ws-relays", type="WS_SWARM"} 0

app_service_status: Indique l’état de chaque service surveillé. La valeur 1 signifie que le service est opérationnel. La valeur 0 signifie qu’il est indisponible.

Exemple de supervision¶

Voici un exemple de mise en place d’une supervision de la santé de la plateforme en utilisant Nagios

Prérequis¶

Sur le serveur Nagios: avoir les commandes curl et jq disponibles

Command¶

define command {
    command_name    reemo_healthcheck
    command_line    /usr/lib/nagios/plugins/reemo_healthcheck $ARG1$
}

Script¶

#!/bin/bash

# Check if an argument (URL) is provided
if [ -z "$1" ]; then
    echo "CRITICAL: No URL provided. Usage: $0 <URL>"
    exit 2
fi

HEALTHCHECK_URL="$1"

# Fetch JSON response
response=$(curl -s "$HEALTHCHECK_URL/api/healthcheck")

# Check if the request was successful
if [ $? -ne 0 ] || [ -z "$response" ]; then
    echo "CRITICAL: Unable to access the health check page ($HEALTHCHECK_URL)"
    exit 2
fi

# Extract service statuses using jq
status=$(echo "$response" | jq -r '.status')
errors=$(echo "$response" | jq -r '.. | objects | select(.status? and .status != "OK")')

# Check if the global status is OK
if [ "$status" != "OK" ]; then
    echo "CRITICAL: Global health check status is $status"
    exit 2
fi

# Check if any sub-services have issues
if [ -n "$errors" ]; then
    echo "WARNING: Some services are not OK:"
    echo "$errors"
    exit 1
fi

# Everything is OK
echo "OK: All services are operational"
exit 0

Service¶

define service{
    host_name                       < HOSTNAME >
    use                             generic-service         ; Name of service template to use
    service_description             Reemo Healthcheck
    check_command                   reemo_healthcheck!https://< URL >
}

Monitoring Prometheus¶

Il est possible d’activer Prometheus sur les points d’entrées Traefik, plusieurs options sont disponibles:

Activer Prometheus¶

Pour activer Prometheus, vous pouvez rajouter l’option TRAEFIK_PROMETHEUS_ENABLE: true dans le fichier inventaire.

Port¶

Par défaut la page Prometheus sera accessible sur le même port que le Portail, utilisez l’option TRAEFIK_PROMETHEUS_PORT: “<numero du port>” pour le modifier.

URL¶

Par défaut la page Prometheus sera accessible sur l’url du Portail avec le lien /metrics. Il est possible de spécifier une ou plusieurs url dédiées:

TRAEFIK_PROMETHEUS_URLS:
    - "metrics1.domain.tld"
    - "metrics2.domain.tld"

Note

Dans le cas d’un cluster avec 3 noeuds, il est conseillé de mettre 3 urls pour que Prometheus puisse récupérer les metrics de tous les noeuds.

Filtrage IP¶

Pour restreindre l’accès à des adresses IP, vous pouvez utiliser l’option TRAEFIK_PROMETHEUS_RESTRICT_IP.

Exemple:

TRAEFIK_PROMETHEUS_RESTRICT_IP: "1.1.1.1,2.2.2.2"

Envoi de mails¶

Si vous souhaitez que la plateforme Reemo soit capable d’envoyer des emails aux utilisateurs, vous pouvez activer le service de messagerie inclus dans le rôle Ansible reemo-infra:

API_MAIL_ACTIVE: "true"
API_MAIL_BASEURL: "https://< URL du portal de connexion pour les utilisateurs >"
EXIM_SMARTHOST: "< URL du serveur SMTP >::587"
EXIM_PASSWORD: "< URL du serveur SMTP >:< Utilisateur SMTP >:< Mot de passe de connexion SMTP>"

Mode maintenance¶

Lors d’une opération de maintenance, vous avez la possibilité de remplacer le Portail par une page de maintenance.

Activation¶

ansible-playbook -i inventory.yml playbooks/reemo-infra.yml --tags maintenance --extra-vars "MAINTENANCE_ENABLE=true"

Désactivation¶

ansible-playbook -i inventory.yml playbooks/reemo-infra.yml --tags portal

CRON¶

Plusieurs taches CRON sont déclarées dans une plateforme Reemo. Il est impératif qu’elles soient unique. Dans le cas de l’utilisation de plusieurs serveurs/clusters infra ou api, il faut choisir le serveur/cluster devant prendre en charge ces services et les désactiver dans les autres par l’option CRON_ENABLE: “false”

Gestion générale des tâches

Option disponible:

API_cronGhostContainersMinutes: Temps d’expiration des conteneurs qui continuent à être UP dans l’environnement Provision mais qui n’ont plus d’existance connue par l’interface

LDAP alternatif¶

Dans le cas d’une architecture à plusieurs API il est possible d’utiliser 2 FQDN pour un meme serveur LDAP.

Pour cela, vous pouvez rajouter l’option suivante dans la configuration du serveur API qui doit utiliser l’url alternative pour contacter le serveur LDAP:

API_useAlternateLDAPHost: "true"

Provisioning¶

Pour précharger les images Docker, utilisez la variable PROVISION_IMAGE_WARMUP.