syslog-ng¶

Rôle¶

Point de collecte central des logs de toute la flotte Indio (53 VM) par UDP/TCP 514, avec rangement automatique par application. Assure l'archivage à froid (brut, non parsé, terminal) — voir Vue d'ensemble SOC pour la place de ce composant dans le pipeline complet et la distinction avec le traitement « à chaud » assuré par ELK/Logstash.

Architecture¶

VM unique Rocky 9.6 (tmpl-rocky96-hardened), INDSOC001 (10.100.20.130), segment seg-soc.

Schéma — collecte, rangement et archivage¶

flowchart TD
    Fleet["Flotte Indio<br/>53 VM (49 + 4 proxies DMZ)<br/>rsyslog omfwd TCP/514"]
    NSXFG["NSX Manager / FortiGate<br/>export syslog UDP/514<br/>hors baseline"]
    SNG["syslog-ng -- INDSOC001<br/>10.100.20.130<br/>source network(), flags(syslog-protocol)"]
    Disk[("Disque local dedie 2 To<br/>/dev/sdb, XFS<br/>/var/log/syslogng")]
    Retention["Script retention + timer systemd<br/>quotidien : compression J+7, purge J+365"]
    NFS[("vSAN File Service<br/>file-node01:/Log<br/>montage NFSv3 soft")]

    Fleet -->|"RFC5424, tout le trafic local"| SNG
    NSXFG -->|"RFC5424 attendu"| SNG
    SNG -->|"ecriture continue,<br/>EXCLUSIVEMENT locale"| Disk
    Disk --> Retention
    Retention -.->|"rsync -a --update<br/>*.log.gz UNIQUEMENT, timeout 300"| NFS

Rangement produit sur le disque local : /var/log/syslogng/${PROGRAM:-unknown}/${YEAR}/${MONTH}/${DAY}/messages.log — un dossier par application distincte, créé à la volée (create_dirs(yes)), aucune liste à maintenir. Le lien pointillé vers le NFS représente le seul chemin retenu vers ce stockage externe (rsync différé de fichiers déjà clos) — l'écriture continue directe a été testée et abandonnée, voir Points d'attention.

Historique du rangement¶

Le schéma de rangement a changé deux fois avant de se stabiliser :

1. Rangement par IP source (avant le 07-16) : filtre netmask() sur FortiGate (10.15.91.14) / NSX Manager (10.15.100.15), fourre-tout network-other.
2. Rangement par catégorie Kafka fixe (2026-07-16) : filtre sur le champ syslog PROGRAM/APP-NAME, avec 5 catégories calquées sur les topics Kafka (cloud, firewall, identity, infra, windows) + unknown. Contrat imposé au futur pont Logstash : positionner PROGRAM à l'une de ces 5 valeurs.
3. Rangement par application réelle (2026-07-17, remplace le précédent — demande explicite de l'exploitant : « je veux qui range par appli stp avec année mois et jour », jugé plus simple) : une seule destination dynamique ${PROGRAM:-unknown}, sans énumération de filtres à maintenir. C'est la configuration actuelle (voir syslog-ng.conf.j2 ci-dessous). Le contrat pour le futur pont Logstash change en conséquence : préserver/positionner PROGRAM au nom réel de l'application d'origine, plus proche d'un passthrough que d'une transformation catégorielle.

Vérifié fonctionnel sur trafic réel (pas seulement logger de test) : après le déploiement fleet-wide du 2026-07-17, des dossiers applicatifs sont apparus automatiquement — chronyd, netbox/netbox-redis/netbox-worker, repmgrd, rsyslogd, sshd-session, sudo, systemd, systemd-logind, vault.

Provisioning Terraform¶

Fichiers : main.tf, variables.tf, versions.tf, terraform.tfvars.example.

• VM unique (vsphere_virtual_machine.syslogng), 1 vCPU / 2048 Mo RAM par défaut, réseau seg-soc, réservation IP via NetBox, disque OS unique issu du template.
• Le disque dédié de 2 To utilisé pour l'archivage n'apparaît pas dans ce main.tf : ajouté manuellement côté vSphere le 2026-07-17 (/dev/sdb, UUID b884941a-65dc-46a4-be07-10720aa1b0ad), hors Terraform — voir Procédure manuelle ci-dessous et Points d'attention (dette technique à régulariser si ce disque doit redevenir reproductible par IaC).

Configuration Ansible¶

Rôle unique syslog_ng :

• Installe syslog-ng + rsync + nfs-utils depuis le dépôt interne indio-epel (miroir Nexus de dl.fedoraproject.org — distinct de indio-extras, qui est le miroir du dépôt Rocky « Extras » natif malgré la ressemblance du nom). syslog-ng est un paquet EPEL en amont, pas fourni par indio-baseos/indio-appstream.
• Crée un compte système dédié (syslog-ng:syslog-ng), propriétaire des fichiers/dossiers archivés (permissions restrictives 0750/0640) ; le démon continue de tourner en root par défaut, nécessaire pour le bind direct sur le port privilégié 514 — c'est la propriété des fichiers créés qui est restreinte au compte dédié via owner()/group() dans syslog-ng.conf, pas l'UID du process lui-même.
• Monte le disque dédié (ansible.posix.mount, state: mounted), épingle le contexte SELinux var_log_t sur toute l'arborescence d'archivage (community.general.sefcontext + restorecon).
• Déclare le montage NFS externe en fstab sans forcer son état monté à chaque exécution (state: present, pas mounted) — voir Points d'attention pour la justification complète.
• Déploie syslog-ng.conf (template), valide sa syntaxe après déploiement, en tâche séparée (syslog-ng --syntax-only -f /etc/syslog-ng/syslog-ng.conf) — le validate: intégré du module template échoue sur le fichier temporaire (permissions restrictives, Permission denied même sous become), piège Ansible connu.
• Déploie le script + timer systemd de rétention/synchronisation.
• Ouvre 514/udp et 514/tcp dans firewalld (zone drop, template durci).

syslog-ng.conf — points clés réels¶

source s_network {
    network(transport("udp") port(514) so-rcvbuf(1048576) flags(syslog-protocol));
    network(transport("tcp") port(514) max-connections(200) flags(syslog-protocol));
};

destination d_by_app {
    file("/var/log/syslogng/${PROGRAM:-unknown}/${YEAR}/${MONTH}/${DAY}/messages.log"
        create_dirs(yes)
        dir_owner("syslog-ng") dir_group("syslog-ng") dir_perm(0750)
        owner("syslog-ng") group("syslog-ng") perm(0640)
        template(t_archive_line)
        frac_digits(3)
    );
};

options{} globales notables : keep-hostname(yes) (ne jamais écraser le HOSTNAME du message par une résolution DNS), use-dns(no)/dns-cache(no) (pas de dépendance DNS pour des IP inconnues), threaded(yes).

Procédure manuelle¶

Deux éléments réels de cette VM ne sont, à ce jour, décrits par aucun code versionné et devraient être reproduits manuellement en cas de rebuild :

1. Ajout du disque de données dédié (2 To, /dev/sdb) côté vSphere — hors Terraform (voir Provisioning ci-dessus) :

   govc vm.disk.create -vm INDSOC001 -name INDSOC001/syslogng-data -size 2T
   

   puis, côté VM, initialisation une seule fois si le disque est neuf :

   sudo mkfs.xfs /dev/sdb
   

   Le montage lui-même (/etc/fstab, point de montage /var/log/syslogng) est géré par le rôle Ansible (ansible.posix.mount, state: mounted) une fois le disque présent — seule la création du disque est manuelle.
2. Montage initial du NFS externe — le rôle Ansible déclare la ligne fstab (state: present, volontairement passif, voir Points d'attention) mais ne monte jamais activement le point de montage. Premier montage réel à faire une fois, à la main :

   sudo mkdir -p /mnt/syslog-nfs
   sudo mount /mnt/syslog-nfs
   sudo findmnt /mnt/syslog-nfs   # confirmer vers=3, soft, timeo=30, retrans=3
   

   Un reboot complet remonte aussi ce point via _netdev dans fstab, sans action manuelle supplémentaire.

L'export NFS file-node01.infra.indio:/Log lui-même (partage vSAN File Service) a été créé côté vCenter par l'exploitant — voir vSAN File Service pour ce composant (aucune automatisation possible côté serveur : pas de SSH, pas de module Ansible, pas d'endpoint REST vSphere fonctionnel pour ce type d'objet).

Procédure de déploiement¶

cd /root/syslogng/ansible
ansible-playbook --syntax-check site.yml
ansible-playbook site.yml -e @/root/.hap_secrets.yml

Contrôle de santé / Vérification¶

systemctl status syslog-ng --no-pager
logger -n 127.0.0.1 -P 514 -T "test message"          # test TCP local
echo "<134>1 - - test - - - test message UDP" | nc -u -w1 127.0.0.1 514

find /var/log/syslogng -maxdepth 1 -type d             # dossiers applicatifs existants
df -h /var/log/syslogng /mnt/syslog-nfs                # espace disque local vs NFS

# Rétention / synchronisation NFS :
systemctl list-timers syslogng-retention.timer
journalctl -t syslogng-retention -n 50 --no-pager

Espace observé au 2026-07-17 (mesure ponctuelle, à ne pas considérer comme une jauge en continu) : disque local à 1 % (~14 Go sur 2 To), NFS à 1 % (~10 Mo sur 14 To disponibles côté vSAN) — aucune pression de rétention à court terme.

Points d'attention¶

Design final retenu (validé bout en bout le 2026-07-17) : syslog-ng écrit exclusivement sur le disque local dédié. Un script de rétention (syslogng-retention.sh, timer quotidien) ajoute une étape de synchronisation entre la compression et la purge : rsync -a --update des fichiers déjà compressés (.log.gz) uniquement — jamais les .log actifs, ni en cours d'écriture ni en cours de compression — vers le NFS, avec :

• timeout 300 en dur : ce NFS s'est montré capable de bloquer des opérations bien plus simples qu'un rsync — mieux vaut un cycle partiel/manqué (retenté au suivant, --update ne re-transfère pas ce qui est déjà là) qu'un housekeeping qui ne rend jamais la main.
• Vérification défensive du point de montage (mountpoint -q) avant chaque cycle — un cycle est simplement sauté, proprement journalisé, si le NFS est transitoirement indisponible.
• set -uo pipefail (pas -e) dans le script : la purge (étape suivante) doit s'exécuter même si le rsync échoue ou expire — un NFS externe indisponible ne doit jamais empêcher le housekeeping local.

Des micro-coupures NFS récurrentes sont observées en usage normal sur ce vSAN File Service (dmesg : nfs: server file-node01.infra.indio not responding, timed out, plusieurs fois par heure) — gérées proprement par ce design (un cycle sauté plutôt qu'un blocage). Le NFS contenait déjà, avant même un premier test manuel, les dossiers de nombreuses applications réelles (vault, haproxy, netbox*, kafka-server-start.sh, etc.) — preuve que le rsync périodique fonctionne aussi tout seul en usage normal, pas seulement en déclenchement manuel.

• Pont Logstash Kafka → syslog-ng (prévu, non construit) : voir Vue d'ensemble SOC pour le schéma complet. Ce pont devrait consommer les 5 topics Kafka historiques (logs-cloud/firewall/identity/infra/windows) et réémettre en syslog standard vers INDSOC001:514, en préservant PROGRAM au nom réel de l'application d'origine (voir « Historique du rangement » ci-dessus). Une fois ce pont construit, le filtrage par IP source devenu obsolète dans la configuration actuelle n'a plus d'objet — mais un nouveau souci apparaîtra côté visibilité de la source : tous les paquets arriveront avec l'IP du pont Logstash, pas celle de l'équipement d'origine (FortiGate, NSX Manager, etc.). Pas encore résolu ; piste envisagée mais non validée : filtrer/enrichir sur le ${HOST} du message plutôt que sur l'IP paquet, si Logstash préserve bien le hostname d'origine dans le message réémis.
• Flux audit.log séparé : les événements auditd (relayés par audisp-syslog) empruntent aussi ce chemin générique — ils apparaissent donc normalement dans /var/log/syslogng/audisp-syslog/... comme n'importe quelle autre application. Un chemin distinct et déjà fonctionnel existe en parallèle, directement vers Kafka puis Elasticsearch (sans repasser par syslog-ng) — voir Kafka — topic logs-audit et ELK — pipeline audit.log.
• Le disque dédié de 2 To n'est pas géré par Terraform (ajouté manuellement côté vSphere) — voir Provisioning Terraform et Procédure manuelle ci-dessus.
• Export syslog NSX/FortiGate : configuré hors Terraform via l'API node NSX (pas de ressource dédiée dans le provider vmware/nsxt) — voir NSX. La conformité RFC5424 de cet export n'a pas été vérifiée spécifiquement ; en cas de non-conformité, ces messages tomberaient dans unknown comme tout message ne respectant pas syslog-protocol.