# Monitoring et logging de microservices kubernetes avec EK
>_Date:_ Lundi 21 mars 2023.
>
> **Mastère Spécialisé - Infrastructure Cloud et DevOps 2022-23**
>
> GROUPE 3
>
# Monitoring et logging du microservice meteo-icd
## 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`.
Des volumes de types `configMap` 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:
## Pré-requis:
Les instructions contenues dans ce dépôt font suite à la mise en place du projet [elastic-kibana](https://gitlab.imt-atlantique.fr/msicd-monitoring/elastic-kibana.git) du même groupe de projets que celui-ci.
Les instructions contenues dans ce dépôt font suite au projet de déploiement de l'application meteo-icd 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.
On suppose que le cluster d'orchestration est kubernetes et héberge déja l'application meteo-icd.
Les contraintes suivantes sont nécessaires:
...
...
@@ -23,32 +32,8 @@ Les `taints` du controlplane doivent correspondre aux tolérances suivantes:
- 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`:
```sh
kubectl apply -f log_volumes.yaml
```
>Note:
> Pour rappel, la définition correspondante dans le playbook de déploiement
```sh
...
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.
Le gestionnaire de paquetage `helm` doit être installé sur le noeud de controlplane. Cette nécessité est satisfaite par le playbook `environment.yml`.
## Meticbeat
Les caractéristiques principales de cet agent sont:
...
...
@@ -58,75 +43,39 @@ Les caractéristiques principales de cet agent sont:
-[x] dépend de [kubernetes-state-metrics](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html);
-[x] utilise le sous-système [autodiscover](https://www.elastic.co/guide/en/beats/metricbeat/current/configuration-autodiscover.html) monitorer les services en cours d'exécution.
### Déploiement
Les étapes indiquées à travers ce [lien](http://elatov.github.io/2020/01/monitoring-kubernetes-with-metricbeat/#deploying-kube-state-metrics) sont les références pour résoudre la dépendance de `kubernetes-state-metrics`. Une copie du [dépot](https://github.com/kubernetes/kube-state-metrics.git) est disponible dans ce projet et les étapes à suivre sont les suivantes (Ajuster `apiVersion` selon la version de kubernetes):
Déployer à présent metribeat suivant les instructions de la [documentation officielle](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html).
Le fichier manifest final est celui qui répond au projet vapormap. Pour voir les différences faire:
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.
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.
## Déploiement
Les étapes indiquées à travers ce [lien](http://elatov.github.io/2020/01/monitoring-kubernetes-with-metricbeat/#deploying-kube-state-metrics) sont les références pour résoudre la dépendance de `kubernetes-state-metrics`. Une copie du [dépot](https://github.com/kubernetes/kube-state-metrics.git) est disponible dans ce projet et les étapes à suivre sont les suivantes (Ajuster `apiVersion` selon la version de kubernetes):
Pour appliquer faire:
La chaine de deploiement de ce depot resoud les dependances evoqees et deploie automatiquement les agents dans le cluster kubernetes.
```sh
kubectl create -f metricbeat-kubernetes.yaml
```
Les variables de `pipeline` importantes pour le deploiement sont contenues dans le fichier de variable `METEO_PROD_VARS` notamment `METEO_VOLUME_PATH`, `NGINX_ACCESS_LOG_PATHS` et `NGINX_ERROR_LOG_PATHS`.
Egalement les varibles de groupe de projet
-`NODE_PUBLIC_IP` qui correspond l'adresse IP de `Elasticsearch`;
-`ELASTICSEARCH_PORT` pour port de `Elasticsearch`;
-`KIBANA_PORT` pour le port de `Kibana`;
## Filebeat
Le declenchement de la chaine est assure par des contraintes de branches protegees `master` et `*-release` lors des commit ou manuellement en selectionnant un `tag` correspondant a un numero de release puis l'execution avec le bouton `Run pipeline` (menu CI/CD > Pipelines).
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
>_NB:_
>
> A chaque numero de release correspond un deploiement specifique suivants les changements desires par l'iteration.
>
La [documentation officielle](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html) fournit un fichier de manifest qui est modifié pour collecter les logs des pods de l'orchestrateur et de ceux de l'application vapormap.
Pour vérifier que la dependance `kube-state-metrics` est operationnelle, il suffit de le faire avec un port-forward:
