Logs et debug

Visualiser les logs dans les pods

Gestion Kubernetes améliorée avec k9s

Pour une manière plus interactive et conviviale de naviguer dans les pods Kubernetes et visualiser les logs, envisagez d'utiliser k9s. Cet outil fournit une manière efficace et visuelle de gérer les applications Kubernetes directement depuis la ligne de commande, améliorant l'expérience de visualisation des logs et de gestion des ressources.

Pour visualiser les logs dans un pod, utilisez la commande kubectl logs. Remplacez [POD_NAME] par le nom spécifique de votre pod :

kubectl logs [POD_NAME] -n [NAMESPACE]

Si vous n'êtes pas sûr du nom du pod, listez d'abord tous les pods avec :

kubectl get pods -n [NAMESPACE]

Pod de debug

info

Notez que pour pouvoir exécuter la commande de debug, votre version de kubectl doit être >= 1.27.

Pour démarrer une session de debug pour un pod existant, exécutez la commande kubectl debug comme ci-dessous, en utilisant le pod internal-api comme exemple (remplacez [NAMESPACE] par le bon et trouvez les noms des autres pods sur la page Topologie de l'application) :

kubectl debug \
  --namespace=[NAMESPACE] \
  --profile=restricted \
  --share-processes \
  --container=app \
  --copy-to=webapp-debug \
  --image=$(kubectl --namespace=[NAMESPACE] get pods -l app.kubernetes.io/component=internal-api -o jsonpath='{.items[0].spec.containers[0].image}')-debug \
  $(kubectl --namespace=[NAMESPACE] get pods -l app.kubernetes.io/component=internal-api -o jsonpath='{.items[0].metadata.name}')

Où :

• --profile=restricted : monte tous les volumes, config maps et secrets du pod d'origine avec des capacités limitées.
• --container : spécifie le conteneur de debug.
• --copy-to : nomme le nouveau pod de debug.
• --image : définit l'image de debug, modifiant le tag de l'image originale avec un suffixe --debug.

À l'exécution, un pod de debug nommé webapp-debug sera créé dans votre namespace désigné, contenant un seul conteneur app exécutant l'image de debug :

Pour interagir avec le conteneur de debug, utilisez kubectl exec :

kubectl exec -it webapp-debug -- bash

Pour les diagnostics, vous pouvez exécuter :

kubectl exec -it webapp-debug -- python manage.py diagnose_instance

Après avoir terminé vos tâches de debug, supprimez le pod de debug avec cette commande :

kubectl delete pod webapp-debug

Log collector

Les déploiements GitGuardian Self-Hosted disposent désormais d'un log collector intégré, conçu pour faciliter le dépannage et le support. Ce système exploite Loki, MinIO et Fluent Bit pour collecter, stocker et centraliser automatiquement les logs de votre application GitGuardian. La collecte des logs est activée par défaut pour tous les types d'installation (Helm ou KOTS), garantissant que tous les logs pertinents soient facilement disponibles pour les diagnostics sans nécessiter de configuration manuelle. Par défaut, nous conservons 3 jours de logs.

Installation via Helm

Dans le fichier values.yaml, définissez le paramètre logCollector.enabled à false pour désactiver le log collector.

Par défaut, lors de la génération du Support Bundle, nous récupérons 3 jours de logs applicatifs. Cette durée est configurable via le paramètre Helm : logCollector.supportBundle.since en utilisant ce format : <0-9>+<h|d>, et ne doit pas dépasser 7 jours.

Configuration Loki

Vous devrez peut-être configurer les limites de ressources et les pod labels Loki pour vous conformer aux politiques de votre organisation :

Limites de ressources :

loki:
  singlyBinary:
    resources:
      limits:
        # Specify CPU limits for Loki
        cpu: 1000m
        # Specify Memory limits for Loki  
        memory: 1024Mi
      requests:
        cpu: 500m
        memory: 512Mi

Pod Labels :

loki:
  podLabels:
    env: production
    team: infrastructure

Pipelines additionnels

Le LogCollector peut être étendu avec des pipelines personnalisés pour transférer les logs applicatifs vers des systèmes externes d'agrégation de logs. Cela vous permet d'intégrer les logs GitGuardian à votre infrastructure d'observabilité existante.

Outputs supportés :

Le LogCollector exploite l'écosystème étendu de plugins de sortie de Fluent Bit, permettant l'intégration avec des plateformes populaires de gestion des logs incluant :

• Splunk - Gestion et analyse de logs en entreprise
• Loki - Système d'agrégation de logs de Grafana
• Elasticsearch - Moteur de recherche et d'analytics
• Kafka - Plateforme de streaming distribuée
• Datadog - Services de monitoring cloud

Pour la liste complète des sorties disponibles et leurs options de configuration, consultez la documentation des outputs Fluent Bit.

Configuration :

Les pipelines additionnels sont configurés via la section logCollector.pipelines dans votre fichier de values. Chaque pipeline peut inclure :

• Filters - Transforment, enrichissent ou modifient les enregistrements de logs avant la sortie
• Outputs - Définissent les systèmes de destination et les paramètres de connexion

Exemple : intégration Splunk

La configuration suivante montre comment envoyer des logs vers un endpoint Splunk HTTP Event Collector (HEC) :

logCollector:
  envFrom:
    - secretRef:
        # Secret containing token (SPLUNK_TOKEN)
        name: splunk
  pipelines:
    splunk:
      filters:
        - |
          name modify
          add  index my-splunk-index

      outputs:
        - |
          name splunk
          host <HOST>
          port 8088
          splunk_token ${SPLUNK_TOKEN}
          tls on
          tls.verify off

Installation via KOTS

Dans la console d'administration KOTS, désactivez le log collector.

Cluster embedded

Sur un cluster Embedded, vous avez besoin d'une étape supplémentaire pour pouvoir exécuter des commandes kubectl.

sudo ./gitguardian shell

Vous pouvez maintenant opérer le cluster.

Tâches des workers

Pour surveiller l'activité des tâches, le nombre de workers et l'utilisation, visitez la page tâches dans l'admin area.