Aller au contenu

Stack de supervision

Métriques, journaux, tableaux de bord et alertes.
URL Dashboards https://metrics.akko.local (Perses)
URL Couche Métriques (Prometheus) https://prometheus.akko.local
Authentification Identité (Keycloak) SSO (Dashboards)
Sous-charts Helm vmstack (victoria-metrics-k8s-stack), vlogs (victoria-logs-single), akko-observability (Perses + Fluent Bit)

Aperçu

AKKO inclut une stack d'observabilité complète qui fournit la collecte de métriques, l'agrégation de journaux, la visualisation et l'alerte. Les services de supervision démarrent avec le profil principal, aucun drapeau supplémentaire n'est nécessaire.

Les backends de journaux et de tableaux de bord vivent dans la couche Lego akko-observability, qui livre des défauts permissifs Apache 2.0 / CNCF (VictoriaLogs, Perses, Fluent Bit) à la place du bundle AGPL Loki + Grafana + Promtail.

                    metrics.akko.local
                          |
                     Traefik (TLS)
                          |
                      Perses (:8080)
                   /       |       \
          Prometheus  VictoriaLogs  Alertmanager
           (:9090)    (:9428)    (:9093)
              |          |
         cibles de    Fluent Bit
         collecte     (DaemonSet)
              |          |
      +-------+---+   stdout des pods
      |       |   |   + journaux du nœud
    object storage  JHub  ...

Métriques vs Logs — Prometheus vs VictoriaLogs

Les deux piliers de la couche d'observabilité répondent à des questions différentes. Ils sont complémentaires, pas concurrents : Prometheus dit combien / à quelle vitesse, VictoriaLogs dit ce qui s'est passé.

Prometheus VictoriaLogs
Type de donnée Métriques, séries temporelles numériques (CPU %, RAM, latence, req/s, nb de pods) Logs, lignes de texte horodatées (messages d'applis, erreurs, audit)
Exemple http_requests_total{pod="x"} 4213 à l'instant T 2026-06-14 01:12 ERROR trino: query failed for user carol_analyst
Question « le système va-t-il bien ? quelles tendances ? » « pourquoi ça a planté ? que faisait l'utilisateur X ? »
Ingestion Pull, scrape périodique des endpoints /metrics Push, les logs lui sont expédiés (par Fluent Bit)
Langage de requête PromQL (taux, agrégations, percentiles) LogsQL (recherche plein-texte, filtres, motifs)
Profil de volume petit et régulier (un nombre toutes les 15 s) gros et irrégulier (rafales de texte)
Remplace (standard de fait) Loki (AGPL). VictoriaLogs est sous Apache 2.0

Comment ils s'articulent dans AKKO

  • Prometheus collecte les métriques, visualisées dans Perses (Platform Dashboards, metrics.<domaine>), puis Alertmanager déclenche quand une métrique franchit un seuil.
  • VictoriaLogs stocke les logs (alimenté par Fluent Bit, qui les ramasse sur chaque pod), explorés dans la page Logs du cockpit (logs.<domaine>).

Flux de diagnostic typique : une métrique Prometheus vous alerte qu'il y a un problème (latence qui explose), puis vous plongez dans les logs VictoriaLogs pour comprendre pourquoi.

Analogie

Prometheus = le tableau de bord de la voiture (vitesse, température, essence, des chiffres en continu). VictoriaLogs = la boîte noire / le journal de bord (le récit détaillé, ligne par ligne, de ce qui s'est passé). Les deux vivent dans la couche Lego akko-observability, aux côtés de Perses (dashboards), Alertmanager (routage d'alertes) et Fluent Bit (collecte des logs).

Exposition des services (layer-first)

Aucun moteur brut n'est exposé à l'edge. L'UI des métriques = Perses sur metrics.<domaine> (« Platform Dashboards ») ; les logs se lisent dans la page Logs du cockpit. prometheus.<domaine> et victorialogs.<domaine> ne sont volontairement pas publiés, ce sont des composants backend, visibles uniquement dans la page Architecture du cockpit et les health checks.

Composants

Couche Métriques (Prometheus)

Moteur de collecte de métriques. Collecte les cibles toutes les 15 secondes et évalue les règles d'alerte toutes les 15 secondes. Déployé via le chart victoria-metrics-k8s-stack (clé Helm vmstack).

Paramètre Valeur
URL https://prometheus.akko.local
Port interne 9090
Configuration valeurs monitoring dans helm/akko/values.yaml
Intervalle de collecte 15s

Cibles de collecte actives :

Job Cible Chemin des métriques
prometheus localhost:9090 /metrics
alertmanager akko-alertmanager:9093 /metrics
storage akko-storage:9000 /storage/v2/metrics/cluster
jupyterhub akko-jupyterhub:8000 /hub/metrics

Métriques Moteur de requête (Trino) et Moteur d'orchestration (Airflow)

Les cibles de collecte Moteur de requête et Moteur d'orchestration sont actuellement désactivées car leurs points d'accès de santé renvoient du JSON, pas du format Couche Métriques. Pour les activer :

  • Moteur de requête : Déployez JMX Exporter comme agent Java dans l'image Moteur de requête (port 9483)
  • Moteur d'orchestration : Déployez un sidecar statsd_exporter ou installez apache-airflow-providers-statsd

Dashboards (Perses)

Plateforme de visualisation et de tableaux de bord (Perses, Apache 2.0, CNCF Sandbox). Déployée dans la couche akko-observability. Pré-configurée avec les sources de données Prometheus et VictoriaLogs.

Paramètre Valeur
URL https://metrics.akko.local
Service interne akko-perses
Port interne 8080
Image persesdev/perses:v0.50.0
Authentification Identité SSO
Tableaux de bord helm/akko/charts/akko-observability/dashboards/*

Sources de données pré-configurées :

Source de données Type URL Par défaut
Prometheus prometheus http://akko-prometheus-server:9090 Oui
VictoriaLogs loki (compatible API Loki) http://akko-victorialogs:9428 Non
Alertmanager alertmanager http://akko-alertmanager:9093 Non

Couche Logs (VictoriaLogs)

Moteur d'agrégation de journaux (VictoriaLogs, Apache 2.0). Reçoit les journaux de Fluent Bit et les rend interrogeables via Perses et la page Logs du cockpit en utilisant LogsQL. Il expose aussi une API de requête compatible Loki sur le même port, ce qui permet aux clients LogQL de continuer à fonctionner pendant la migration. Déployé via le chart victoria-logs-single (clé Helm vlogs).

Paramètre Valeur
Service interne akko-victorialogs
Port interne 9428 (push + requête LogsQL, compat Loki)
Image victoriametrics/victoria-logs:v1.6.0-victorialogs
Rétention 14d (défaut)

Collecteur de logs (Fluent Bit)

Agent de collecte de journaux (Fluent Bit, CNCF Graduated). Tourne comme un DaemonSet cluster, collecte le stdout des pods et les journaux du nœud, et les transmet à VictoriaLogs avec des labels pour le nom du service, le conteneur et d'autres métadonnées.

Paramètre Valeur
DaemonSet akko-fluent-bit
ConfigMap akko-fluent-bit-config
Image cr.fluentbit.io/fluent/fluent-bit:3.1.10
Source stdout des pods + journaux du système de fichiers du nœud

Alertmanager

Moteur de routage et de notification d'alertes. Reçoit les alertes de Couche Métriques et les route en fonction de la sévérité.

Paramètre Valeur
Port interne 9093
Récepteur par défaut Journalisation uniquement (stdout)

Règles d'alerte

AKKO est livré avec des règles d'alerte pré-configurées (rendues par le chart dans une PrometheusRule) :

Alerte Sévérité Condition Durée
ServiceDown Critique up == 0 2 min
HighLatency Avertissement Temps de réponse > 2s 5 min
HighMemoryUsage Avertissement Mémoire conteneur > 90% de la limite 2 min
HighCPUUsage Avertissement CPU conteneur > 80% 5 min
DiskSpaceRunningLow Avertissement Système de fichiers > 85% utilisé 5 min
PostgresConnectionsHigh Avertissement Connexions > 80% du max 5 min
StorageBucketEmpty Info Le bucket contient 0 objet 10 min

Le routage des alertes est configuré avec un groupement basé sur la sévérité :

  • Alertes critiques : délai de groupement de 5 secondes, intervalle de répétition de 15 minutes
  • Toutes les autres alertes : délai de groupement de 10 secondes, intervalle de répétition d'1 heure
  • Inhibition : une alerte critique supprime les avertissements pour le même service

Accéder aux tableaux de bord

  1. Ouvrez https://metrics.akko.local
  2. Connectez-vous avec Identité SSO (par ex. alice avec le rôle administrateur)
  3. Parcourez les tableaux de bord Perses pré-construits
  4. Interrogez directement les métriques Prometheus ou les journaux VictoriaLogs

Interroger les journaux

Pour consulter les journaux d'un service AKKO spécifique, utilisez une requête LogsQL sur VictoriaLogs (via la page Logs du cockpit ou la source de données logs de Perses) :

{container_name="akko-trino"}

Filtrer par niveau de log :

{container_name="akko-airflow"} |= "ERROR"

Interroger les métriques

Interrogez Prometheus avec PromQL :

# Disponibilité des services (1 = en ligne, 0 = hors ligne)
up

# Utilisateurs actifs JupyterHub
jupyterhub_running_servers

# Requêtes par seconde object storage
rate(storage_http_requests_total[5m])

Ajouter des alertes personnalisées

Ajoutez des règles à la PrometheusRule du chart via les valeurs monitoring, par exemple :

groups:
  - name: my-custom-alerts
    rules:
      - alert: SlowTrinoQueries
        expr: trino_query_execution_time_seconds > 30
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Slow Trino queries detected"
          description: "Queries taking longer than 30 seconds for 5+ minutes."

Prometheus charge automatiquement les règles provisionnées par le chart.

Ajouter des tableaux de bord personnalisés

Les tableaux de bord Perses sont gérés comme du code. Placez les définitions de tableaux de bord sous helm/akko/charts/akko-observability/dashboards/ et elles sont provisionnées au déploiement par le Job perses-dashboards-init.

Configurer les notifications

La configuration par défaut d'Alertmanager utilise un récepteur de journalisation uniquement (les alertes apparaissent dans stdout). Pour activer de vraies notifications, éditez la configuration Alertmanager (monitoring) dans votre overlay de valeurs :

receivers:
  - name: default
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
        channel: '#akko-alerts'
        send_resolved: true

receivers:
  - name: default
    webhook_configs:
      - url: 'http://your-webhook-endpoint:5001/'
        send_resolved: true

global:
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: 'akko-alerts@example.com'
  smtp_auth_username: 'user'
  smtp_auth_password: 'pass'

receivers:
  - name: default
    email_configs:
      - to: 'team@example.com'
        send_resolved: true

Après modification, redémarrez Alertmanager :

kubectl rollout restart deploy/akko-alertmanager -n akko

Référence de configuration

Emplacement Fonction
helm/akko/values.yaml (monitoring) Cibles de collecte Prometheus, règles d'alerte, routage Alertmanager
helm/akko/values.yaml (vlogs) Configuration du stockage et de la rétention VictoriaLogs
helm/akko/charts/akko-observability/values.yaml Backends des slots logs / dashboards / collecteur
helm/akko/charts/akko-observability/dashboards/* Définitions des tableaux de bord Perses
helm/akko/charts/akko-observability/templates/fluentbit-config.yaml Configuration de la collecte de journaux Fluent Bit