Skip to content
Snippets Groups Projects
Select Git revision
  • 6a196a3ebb4c0edf4c7ec66f62b4672f6c31cbd6
  • master default protected
  • 1.32-release protected
  • 1.31-release protected
  • 1.30-release protected
  • 1.29-release protected
  • 1.28-release protected
  • 1.27-release protected
  • 1.26-release protected
  • 1.25-release protected
  • 1.24-release protected
  • 1.23-release protected
  • 1.22-release protected
  • 1.21-release protected
  • 1.20-release protected
  • 1.19-release protected
  • 1.18-release protected
  • 1.17-release protected
  • 1.16-release protected
  • 1.15-release protected
  • 1.13-release protected
  • 1.12-release protected
22 results

deploy-beats

Monitoring et logging de microservices kubernetes avec EK

Présentation

Ce dépôt est destiné à la configuration des agents de collecte de métriques et de log dans un cluster kubernetes respectivement avec metricbeat et filebeat. Chacun de ces deux agents fonctionnent avec des modules et sont executés dans des pods de DaemonSet sur tous les noeuds du cluster kubernetes.

Des volumes de types hostPath sont utilisés pour l'accès aux fichiers de log. Un fichier de manifest est mis à disposition pour le déploiement des objets liés aux DaemonSet.

Pré-requis:

Les instructions contenues dans ce dépôt font suite à la mise en place du projet elastic-kibana du même groupe de projets que celui-ci.

On suppose que le cluster d'orchestration est kubernetes et héberge déja l'application vapormap déployée lors du précédent projet fil rouge.

Les contraintes suivantes sont nécessaires:

Les taints du controlplane doivent correspondre aux tolérances suivantes:

       tolerations:
       - effect: "NoExecute"
         operator: "Exists"
       - effect: "NoSchedule"
         operator: "Exists"

Le volume des log des pods de l'application vapormap est un pv nommé volume-vapormap. Ajuster donc le déploiement de cette application avec le manifest log_volumes.yaml:

kubectl apply -f log_volumes.yaml

Note: Pour rappel, la définition correspondante dans le playbook de déploiement

...
            spec:
              containers:
              - image: "{{ vapormap_app_image }}"
                name: vapormapapp
                volumeMounts:
                - mountPath: /var/log/nginx/
                  name: vapormap-volume
...
              volumes:
              - name: vapormap-volume
                persistentVolumeClaim:
                  claimName: vapormap-volume
...

Le gestionnaire de paquetage helm doit être installé sur le noeud de controlplane.

Meticbeat

Les caractéristiques principales de cet agent sont:

  • effectue des mesures de statistiques telles que celles des systèmes d'hôte, de docker et de service/processus ainsi que celles des evenements kubernetes;
  • utilise des modules standards ou personalisés;
  • fournit des information relatives au cgroups à partir du système de fichier proc (ref. doc);
  • dépend de kubernetes-state-metrics;
  • utilise le sous-système autodiscover monitorer les services en cours d'exécution.

Déploiement

Les étapes indiquées à travers ce lien sont les références pour résoudre la dépendance de kubernetes-state-metrics. Une copie du dépot est disponible dans ce projet et les étapes à suivre sont les suivantes (Ajuster apiVersion selon la version de kubernetes):

Déployer les composants kubernetes dépendants:

git clone git@gitlab.imt-atlantique.fr:msicd-monitoring/node-agents.git
cd agent
# Lister les valeurs liees au déploiement
helm show values prometheus-community/kube-state-metrics

# Appliquer les valeurs standards
kubectl apply -f examples/standard

Pour vérifier avec un port-forward:

kubectl port-forward svc/kube-state-metrics -n kube-system 9000:8080 --address 0.0.0.0

Visiter le lien http://@IP_NODES:9000/metrics avec le navigateur ou faire :

curl http://@ClusterIP:8080/metrics -s | grep deployment_status_replicas_availab

Déployer à présent metribeat suivant les instructions de la documentation officielle.

Le fichier manifest final est celui qui répond au projet vapormap. Pour voir les différences faire:

diff metricbeat-kubernetes.yaml.orig metricbeat-kubernetes.yaml 

Les modifications concernent donc:

  • le dashboard et l'authentification;
  • le moteur de filtre et d'enrichissement processors;
  • l'activation de métriques système;
  • la désactivation d'args;
  • la défintion de nouvelles variables;
  • et l'application de taints pour autoriser le déploiement sur les noeuds de controlplane.

Pour appliquer faire:

kubectl create -f metricbeat-kubernetes.yaml

Filebeat

Tout comme metricbeat, il effectue la collecte à l'aide des modules et les inputs configurés suivants la localisation des fichiers de log. Il récupère ainsi tous les flux de logs, avec leur pod, leur conteneur, leur nœud, leur VM, leur hôte et leurs autres métadonnées pour une corrélation automatique. Les fonctionnalités Autodiscover des agents Beats détectent les nouveaux conteneurs et les surveillent de manière évolutive avec les modules Filebeat adaptés.

Déploiement

La documentation officielle fournit un fichier de manifest qui est modifié pour collecter les logs des pods de l'orchestrateur et de ceux de l'application vapormap.

# Afficher les modifications
diff filebeat-kubernetes.yaml.orig filebeat-kubernetes.yaml

Ces modifications concernent donc:

  • la découverte automatique avec autodiscovers;
  • le dashboard et l'authentification;
  • la défintion de modules nginx et traefik;
  • le path des logs pour vapormap dans le module nginx;
  • le path des logs pour traefik dans le module traefik;
  • la défintion de nouvelles variables;
  • et l'application de taints pour autoriser le déploiement sur les noeuds de controlplane.

Enfin appliquer les modifications:

kubectl  create -f filebeat-kubernetes.yaml