> ## Documentation Index
> Fetch the complete documentation index at: https://infra-docs.kaeyros.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Stack de supervision Kaeyros : vue d'ensemble

> Découvrez la stack de supervision Kaeyros basée sur VictoriaMetrics, VictoriaLogs, vmalert, Alertmanager et Grafana. Architecture frugale, libre, à sens unique.

La stack de supervision Kaeyros est conçue pour répondre à trois questions essentielles, dans un ordre précis: est-ce que tout va bien, où se situe le problème, et que se passe-t-il exactement sur cette machine ou dans ce namespace. Cette page présente l'architecture globale, les composants qui la constituent, et les principes qui guident ses choix techniques.

## Les trois questions

> **Est-ce que ça va?**
>
> Un écran, 10 secondes, sans faire défiler. Le dashboard d'accueil donne l'état de santé global de l'ensemble des services en un coup d'oeil.

> **Où est le problème?**
>
> Un dashboard par domaine permet d'identifier rapidement la zone concernée: réseau, stockage, calcul, ou applicatif.

> **Que se passe-t-il ici?**
>
> Le forage: un namespace ou un nœud spécifique, avec tous les détails nécessaires pour comprendre le comportement observé.

## Une stack frugale et libre

La stack repose sur cinq composants open source, tous hébergés sur un seul serveur. Pas de SaaS externe, pas de licence propriétaire.

| Composant | Rôle |
| - | - |
| VictoriaMetrics | Stockage et requêtage des métriques en série temporelle |
| VictoriaLogs | Stockage et requêtage des journaux |
| vmalert | Évaluation des règles d'alerte et des recording rules |
| Alertmanager | Routage des alertes vers les canaux de notification |
| Grafana | Affichage des dashboards et exploration des données |

Cette simplicité réduit la surface d'attaque, les coûts d'infrastructure, et la complexité opérationnelle.

## Vos applications ne sont PAS instrumentées

> [!WARNING]
>
> Les applications du cluster n'exposent aucune métrique personnalisée. La stack ne sait rien du trafic HTTP autrement que via Traefik, et ne détecte les erreurs applicatives qu'en lisant le TEXTE des journaux. Ce choix architectural explique beaucoup de décisions prises dans les dashboards et les règles d'alerte.

Par conséquent, les indicateurs de performance applicative (latence, taux d'erreur, débit) sont tous dérivés des métriques de Traefik et des patterns observés dans les logs. Il n'y a pas de métriques métier personnalisées, pas de traces distribuées, et pas de profiling continu.

## L'architecture en 10 lignes

```mermaid theme={null}
flowchart TB
    subgraph Cluster["Cluster (POUSSE)"]
        vmagent["vmagent"]
        node_exporter["node-exporter"]
        kube_state_metrics["kube-state-metrics"]
        cadvisor["cAdvisor"]
        fluent_bit["fluent-bit"]
        traefik["Traefik"]
    end

    subgraph Supervision["Serveur de supervision"]
        vmauth["vmauth"]
        vm["VictoriaMetrics"]
        vl["VictoriaLogs"]
        vmalert["vmalert<br/>261 règles métriques<br/>26 règles logs"]
        alertmanager["Alertmanager"]
        grafana["Grafana"]
    end

    subgraph Notifications["Notifications"]
        email["Courriel"]
        whatsapp["WhatsApp (WAHA)"]
    end

    vmagent -->|métriques| vmauth
    node_exporter -->|métriques| vmauth
    kube_state_metrics -->|métriques| vmauth
    cadvisor -->|métriques| vmauth
    fluent_bit -->|journaux| vmauth
    traefik -->|métriques| vmauth

    vmauth --> vm
    vmauth --> vl
    vm --> vmalert
    vl --> vmalert
    vmalert --> alertmanager
    alertmanager --> email
    alertmanager --> whatsapp
    grafana --> vm
    grafana --> vl
```

Le cluster pousse les métriques et les journaux. Le serveur de supervision les reçoit, les stocke, évalue les règles, et affiche les résultats.

## Direction unique

> [!NOTE]
>
> Le cluster ne stocke aucune donnée de supervision: il pousse tout vers le serveur de supervision. Le serveur de supervision ne va rien chercher: il reçoit passivement. Cette direction unique évite d'ouvrir le cluster vers l'extérieur, et permet à plusieurs clusters d'écrire vers la même stack sans conflit de sécurité.

Ce modèle de flux unidirectionnel simplifie les règles de pare-feu et réduit les risques d'exposition. Chaque cluster possède ses propres identifiants vmauth, ce qui permet une isolation logique des données même lorsqu'elles convergent vers le même serveur.

## Dashboards versionnés

> [!WARNING]
>
> Grafana ne stocke aucune donnée métier. Ses dashboards sont des FICHIERS versionnés, provisionnés au démarrage du conteneur. Ne modifiez JAMAIS un dashboard dans l'interface de Grafana: la prochaine régénération écrasera votre travail sans possibilité de récupération. Pour apporter des modifications, consultez la page [Modifier un dashboard](https://infra-docs.kaeyros.org/supervision/taches-courantes.md).

La stack compte 13 dashboards, 226 panneaux, répartis sur 3 niveaux: Accueil, Diagnostic, et Détail. Tous les dashboards sont définis dans des fichiers JSON versionnés et déployés automatiquement.

## Contact

Pour toute question sur la stack de supervision, contactez l'équipe DevOps: [devops@kaeyros-analytics.com](mailto:devops@kaeyros-analytics.com)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.