> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/fr/module-9-supervision-et-depannage/03-log-management.md).

# Gestion et transfert des journaux

## Le rôle des journaux dans les opérations VergeOS

Les journaux sont la trace d'audit et la colonne vertébrale du diagnostic de chaque environnement VergeOS. Ils consignent les actions initiées par les utilisateurs, les événements automatisés du système, les relevés des capteurs matériels et l'activité de réplication -- fournissant les preuves nécessaires pour résoudre les problèmes, satisfaire aux exigences de conformité et comprendre ce qui s'est passé et quand.

VergeOS organise les journaux en trois catégories distinctes, chacune ayant un objectif différent et étant stockée à un emplacement différent. Comprendre ces catégories est essentiel pour savoir où chercher lors du diagnostic d'un problème et comment assurer une conservation à long terme.

```mermaid
graph TB
    subgraph logTypes["Catégories de journaux VergeOS"]
        direction TB
        SYS["Journaux système<br/>Activité utilisateur et automatisée<br/>Événements vSAN, VM, réseau"]
        SYNC["Journaux de synchronisation<br/>Activité de réplication de synchronisation de site<br/>Démarrage/arrêt, données transférées"]
        SEL["Journal des événements système (SEL)<br/>Événements matériels IPMI<br/>Stocké sur le matériel BMC"]
    end

    subgraph retention["Conservation"]
        UI["Dans l'interface : 45 jours"]
        HW["Sur le matériel : capacité limitée"]
        EXT["Externe : transfert Syslog"]
    end

    SYS --> UI
    SYNC --> UI
    SEL --> HW
    SYS --> EXT
    SEL --> EXT

    style logTypes fill:#f0f4ff,stroke:#336
    style retention fill:#f0fff4,stroke:#363
```

## Détails des types de journaux

### Journaux système

Les journaux système sont la principale catégorie de journaux dans VergeOS. Ils capturent les activités liées aux **opérations vSAN, aux événements du cycle de vie des VM, aux changements réseau, aux connexions des utilisateurs, aux modifications de configuration** et aux autres opérations liées au système. Ces journaux sont essentiels pour comprendre le fonctionnement détaillé et les performances de l'ensemble de l'environnement.

Voici des exemples d'entrées de journal système :

| Type d'événement                      | Exemple d'entrée de journal                                                |
| ------------------------------------- | -------------------------------------------------------------------------- |
| **Authentification de l'utilisateur** | Adresse IP, nom d'utilisateur, horodatage de connexion                     |
| **Modifications de mot de passe**     | Quel utilisateur a modifié quel mot de passe, depuis quel environnement    |
| **Opérations VM**                     | VM démarrée, arrêtée, migrée, instantané créé                              |
| **Événements de stockage**            | Avertissements de disque, changements d'état du niveau vSAN, alertes SMART |
| **Événements réseau**                 | Réseau créé, règle de pare-feu modifiée, changement d'état de la NIC       |
| **Opérations système**                | Mise à jour téléchargée, nœud redémarré, mode maintenance activé           |

Les journaux système sont accessibles depuis le **Tableau de bord principal** (en bas de la page) ou en sélectionnant **Journaux** dans le menu supérieur. Chaque entrée de journal comprend un **niveau** (Critique, Erreur, Avertissement ou Message), un **horodatage**, un **source** (par exemple : node1, vSAN, admin) et un **message** décrivant l'événement.

### Journaux de synchronisation

Les journaux de synchronisation sont spécifiques aux opérations de **synchronisation de site (réplication)** . Ils sont disponibles sur les tableaux de bord de synchronisation entrante et sortante et fournissent des statistiques détaillées pour chaque tâche de synchronisation d'instantané :

* **Heures de début et de fin** pour chaque opération de synchronisation
* **Quantité de données vérifiées** -- volume total de données évalué pour les changements
* **Quantité de données analysées** -- données lues pendant la synchronisation
* **Quantité de données envoyées** -- données modifiées identifiées comme nécessitant un transfert (avant compression)
* **Données nettes envoyées** -- octets réels sur le réseau (après compression)
* **Nombre de répertoires et de fichiers** -- portée de l'opération de synchronisation

Les journaux de synchronisation sont indispensables pour surveiller l'état de la réplication, vérifier que les tâches de reprise après sinistre se terminent dans les délais et diagnostiquer les problèmes de bande passante ou de performance liés à la synchronisation de site à site.

### Journal des événements système (SEL)

Le Journal des événements système (SEL) contient des événements provenant de l' **interface matérielle IPMI** (Intelligent Platform Management Interface). Contrairement aux journaux système, le SEL est **stocké directement sur le matériel BMC du serveur**, ce qui signifie qu'il dispose d'une **capacité limitée et fixe**. Une fois le SEL plein, de nouveaux événements ne peuvent plus être enregistrés tant qu'il n'a pas été vidé.

Le tableau de bord du nœud affiche une **barre de pourcentage** indiquant combien de capacité du SEL est actuellement utilisée sur chaque nœud. Les entrées SEL courantes incluent :

* Dépassements de seuil de température
* Avertissements de vitesse des ventilateurs
* Événements d'alimentation électrique
* Erreurs ECC de mémoire
* Événements thermiques du processeur
* Événements d'initialisation matérielle

{% hint style="warning" %}
**La capacité du SEL est limitée**

Le SEL est stocké sur le Contrôleur de gestion de la carte mère (BMC) du serveur et dispose d'une capacité limitée et fixe. Si le SEL se remplit complètement, les nouveaux événements matériels sont ignorés sans avertissement. Surveillez le pourcentage de capacité du SEL sur le tableau de bord de chaque nœud et videz le SEL de manière proactive.
{% endhint %}

## Conservation des journaux dans l'interface

VergeOS conserve les journaux système dans l'interface utilisateur pendant un maximum de **45 jours**. Passé ce délai, les journaux sont automatiquement supprimés de l'interface. Cette durée de conservation suffit pour le dépannage quotidien et l'audit à court terme, mais les organisations soumises à des exigences de conformité (HIPAA, SOC 2, PCI-DSS, etc.) devront configurer le **transfert de journaux à distance** pour conserver les journaux plus longtemps.

### Journaux contextuels

L'une des fonctionnalités les plus pratiques de la journalisation VergeOS est le **filtrage des journaux spécifique au contexte**. Dans de nombreuses zones de la plateforme -- par exemple, le tableau de bord d'une VM individuelle, d'un réseau ou d'un tenant -- il existe un **Journaux** bouton qui affiche uniquement les journaux pertinents pour cet objet spécifique.

Cette portée élimine la nécessité de parcourir manuellement des milliers d'entrées de journal à l'échelle du système. Par exemple :

* **Tableau de bord VM → Journaux** n'affiche que les événements liés à cette VM spécifique (démarrage, arrêt, migration, instantané, erreur)
* **Tableau de bord Réseau → Journaux** n'affiche que les événements liés au réseau (modifications des règles, changements d'état, événements de connectivité)
* **Tableau de bord du tenant → Journaux** n'affiche que les événements dans le périmètre de ce tenant

Les journaux contextuels accélèrent considérablement le dépannage en réduisant le rapport signal/bruit à l'objet exact faisant l'objet de l'enquête.

## Transfert Syslog à distance

Pour les organisations qui ont besoin d'une conservation des journaux au-delà de 45 jours ou qui doivent intégrer les journaux VergeOS dans une plateforme centralisée de gestion des journaux (Graylog, Splunk, Elastic Stack, Datadog, etc.), VergeOS prend en charge **le transfert Syslog à distance** via les protocoles Syslog standard.

### Étapes de configuration

Le transfert Syslog à distance se configure via les **Paramètres avancés** dans l'interface VergeOS :

#### Étape 1 : configurer le serveur Syslog distant

1. Accédez à **Système → Paramètres → Paramètres avancés**
2. Dans le **Paramètre** colonne, saisissez `syslog` et appuyez sur **Appuyez sur Entrée** pour rechercher
3. Sélectionnez et modifiez **Serveur syslog distant (tcp: @@nom/ip:port, udp: @nom/ip:port)**
4. Saisissez la destination Syslog en utilisant la syntaxe appropriée :

| Protocole | Syntaxe         | Exemple             | Remarques                                        |
| --------- | --------------- | ------------------- | ------------------------------------------------ |
| **TCP**   | `@@<ip>:<port>` | `@@10.10.10.10:514` | Livraison fiable, recommandée                    |
| **UDP**   | `@<ip>:<port>`  | `@10.10.10.10:514`  | Moins de surcharge, aucune garantie de livraison |

5. Cliquez sur **Soumettre** pour enregistrer

#### Étape 2 : configurer le modèle de format

1. Recherchez `syslog` à nouveau dans les paramètres avancés
2. Sélectionnez et modifiez **Modèle à définir pour le serveur syslog (voir rsyslog pour le format)**
3. Saisissez un format de modèle Syslog compatible avec votre serveur distant

Pour **Graylog** en utilisant le format RFC 5424 :

```
GRAYLOGRFC5424,"<%PRI%>%PROTOCOL-VERSION% %TIMESTAMP:::date-rfc3339% %HOSTNAME%.your-hostname-here %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n"
```

{% hint style="success" %}
**Personnalisation du modèle**

Remplacez `your-hostname-here` par votre véritable nom d'hôte afin de rendre les entrées de journal facilement identifiables dans votre plateforme de journalisation centralisée. Le modèle suit la syntaxe rsyslog -- consultez la [documentation rsyslog](https://www.rsyslog.com/doc/master/configuration/examples.html) pour des options de format supplémentaires.
{% endhint %}

4. Cliquez sur **Soumettre** pour enregistrer

#### Étape 3 : vérifier le transfert

Une fois la configuration terminée, les journaux commenceront à être transférés vers le serveur Syslog spécifié. Vérifiez les journaux entrants de votre serveur distant pour confirmer que les entrées VergeOS sont bien reçues. Étapes de vérification courantes :

* Confirmez la connectivité réseau entre VergeOS et le serveur Syslog (port 514 ou port personnalisé)
* Vérifiez que les règles de pare-feu autorisent le trafic Syslog dans les deux sens
* Consultez le tableau de bord d'ingestion des journaux du serveur distant pour les entrées entrantes
* Générez un événement de test (par exemple, connectez-vous/déconnectez-vous de l'interface VergeOS) et confirmez qu'il apparaît sur le serveur distant

### Prérequis pour le transfert Syslog

Avant de configurer le transfert de journaux à distance, assurez-vous des éléments suivants :

* **Connectivité réseau** entre le système VergeOS et le serveur Syslog distant
* **Règles de pare-feu** autorisant le trafic Syslog (généralement le port TCP ou UDP 514, ou votre port personnalisé)
* **Accès aux paramètres système VergeOS** avec des privilèges administratifs
* Le serveur Syslog distant est configuré pour **accepter les connexions entrantes** depuis la plage d'adresses IP VergeOS

## Gestion du SEL

Comme le SEL dispose d'une capacité matérielle limitée, il nécessite une maintenance périodique pour garantir que de nouveaux événements puissent toujours être enregistrés.

### Surveillance de la capacité du SEL

Le **tableau de bord du nœud** affiche une barre de pourcentage montrant l'utilisation actuelle du SEL pour chaque nœud. Surveillez régulièrement cet indicateur -- en particulier sur le matériel plus ancien, qui peut générer davantage d'événements IPMI.

### Vidage du SEL

Lorsque le SEL approche de sa capacité maximale, videz-le en suivant la procédure ci-dessous :

1. Accédez à **Infrastructure → Nœuds**
2. Double-cliquez sur le nœud souhaité pour accéder au **Tableau de bord du nœud**
3. Cliquez sur **Vider le SEL** dans le menu de gauche
4. Cliquez sur **Oui** pour confirmer

{% hint style="success" %}
**Gestion proactive du SEL**

Envisagez de mettre en place un calendrier régulier pour vider le SEL -- par exemple, mensuellement ou trimestriellement -- afin d'éviter qu'il n'atteigne sa capacité maximale. Avant de le vider, exportez les entrées SEL vers votre serveur Syslog distant ou documentez les événements importants pour vos archives.
{% endhint %}

### Filtrage des entrées SEL faussement positives

Certains matériels serveur génèrent des événements IPMI répétitifs ou bénins qui encombrent le SEL et les journaux système. Les faux positifs courants incluent :

* Des relevés de capteurs qui dépassent brièvement les seuils pendant les séquences de démarrage
* Des événements d'alimentation pendant des fenêtres de maintenance planifiées
* Des pics de température lors de charges de travail brèves et intenses qui se résolvent immédiatement

Pour les entrées faussement positives persistantes, VergeOS prend en charge le filtrage via un filtre regex Syslog encodé en hexadécimal, configuré par l'API. Après avoir appliqué le filtre, redémarrez le `openipmi` service pour activer le changement. Travaillez avec le support VergeOS pour obtenir des conseils sur la mise en œuvre de filtres SEL spécifiques à votre plateforme matérielle.

## Rapports d'activité SMTP

En plus des journaux système et du transfert Syslog, VergeOS fournit des **rapports de livraison SMTP** via le tableau de bord SMTP (traité dans la page [Abonnements et alertes](/learn-the-platform/fr/module-9-supervision-et-depannage/02-alerts.md) ). Ces rapports offrent une visibilité sur l'activité de livraison des e-mails :

* **File d'attente des e-mails** -- Afficher les messages en attente, l'état des nouvelles tentatives et les échecs de livraison
* **Journal des e-mails** -- Trace d'audit de tous les e-mails d'abonnement envoyés avec horodatages et état de livraison
* **Résumés quotidiens de livraison** -- Suivre l'activité SMTP d'hier et d'aujourd'hui pour confirmer que les alertes sont bien livrées

Les rapports d'activité SMTP complètent la gestion des journaux en fournissant un canal de vérification secondaire -- si vous vous attendez à recevoir une alerte mais ne la recevez pas, le journal SMTP peut révéler si le message a été mis en file d'attente, livré ou rejeté.

## Bonnes pratiques de gestion des journaux

### Transférer les journaux à l'extérieur

Configurez le transfert Syslog distant dès le départ. La conservation dans l'interface pendant 45 jours est insuffisante pour la plupart des cadres de conformité et limite l'analyse des tendances à long terme.

### Surveiller la capacité du SEL

Vérifiez régulièrement la barre de pourcentage du SEL sur le tableau de bord de chaque nœud. Videz le SEL avant qu'il n'atteigne sa capacité maximale afin d'éviter la perte de nouveaux événements matériels.

### Utiliser des journaux spécifiques au contexte

Lorsque vous dépannez une VM, un réseau ou un tenant spécifique, utilisez le bouton Journaux spécifique au contexte sur le tableau de bord de cet objet pour filtrer le bruit non pertinent.

### Établir des politiques de conservation

Définissez tôt les exigences de conservation de votre organisation. Utilisez le transfert Syslog vers une plateforme centralisée pour le stockage à long terme, la recherche et l'audit de conformité.

{% hint style="info" %}
**Pont VMware**

Vous venez de VMware ? Dans VergeOS, les événements opérationnels et d'audit cohabitent dans une vue unique et filtrable Journaux système (Critique/Erreur/Avertissement/Message), conservée dans l'interface pendant 45 jours. Le transfert Syslog distant se configure une seule fois au niveau du système via deux champs des Paramètres avancés -- serveur Syslog et modèle -- plutôt que par hôte.
{% endhint %}

{% hint style="info" %}
**Pont Nutanix**

Vous venez de Nutanix ? Dans VergeOS, les opérations système et les événements d'audit cohabitent dans une seule vue Journaux système (conservation dans l'interface pendant 45 jours) ; le transfert Syslog distant se configure une seule fois au niveau du système. Les événements matériels restent dans le SEL avec les mêmes consignes de vidage proactif.
{% endhint %}

## Points clés

### Trois types de journaux

**Journaux système** pour les événements opérationnels, **Journaux de synchronisation** pour l'activité de réplication, et **SEL** pour les événements matériels IPMI. Chacun répond à un objectif de dépannage distinct.

### Conservation dans l'interface pendant 45 jours

VergeOS conserve les journaux système pendant 45 jours dans l'interface. Configurez le transfert Syslog distant pour une conservation plus longue et pour répondre aux exigences de conformité.

### Configuration Syslog simple

Deux champs des Paramètres avancés -- adresse du serveur Syslog et format du modèle -- configurent le transfert des journaux pour l'ensemble de l'environnement. TCP (`@@`) pour la fiabilité, UDP (`@`) pour les performances.

### Le SEL nécessite une maintenance

Le SEL matériel a une capacité fixe. Surveillez la barre de pourcentage sur le tableau de bord de chaque nœud et videz le SEL de manière proactive pour éviter la perte d'événements.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.verge.io/learn-the-platform/fr/module-9-supervision-et-depannage/03-log-management.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
