Le produit décrit dans cette documentation, Anthos Clusters on AWS (génération précédente), est désormais en mode de maintenance. Toutes les nouvelles installations doivent utiliser le produit de génération actuelle, Anthos Clusters on AWS.

Journalisation et surveillance des clusters Anthos sur AWS

Cet article explique comment exporter les journaux et les métriques d'un cluster d'utilisateur de type "clusters Anthos sur AWS" vers Cloud Logging et Cloud Monitoring.

Présentation

Il existe plusieurs options pour la journalisation et la surveillance des clusters Anthos sur AWS. Anthos peut être intégré à Cloud Logging et Cloud Monitoring. Comme Anthos est basé sur le modèle Kubernetes Open Source, de nombreux outils Open Source et tiers sont compatibles.

Options de journalisation et de surveillance

Vous disposez de plusieurs options de journalisation et de surveillance pour votre cluster Anthos :

Vous pouvez déployer les agents Cloud Logging et Cloud Monitoring pour surveiller et afficher les journaux de vos charges de travail dans Google Cloud Console. Cet article présente cette solution.
Vous pouvez utiliser des outils Open Source tels que Prometheus, Grafana et Elasticsearch. L'article ne traite pas de cette solution.
Vous pouvez utiliser des solutions tierces, telles que Datadog. L'article ne traite pas de cette solution.

Cloud Logging et Cloud Monitoring

Avec Anthos, Cloud Logging et Cloud Monitoring, vous pouvez créer des tableaux de bord, envoyer des alertes, surveiller votre cluster et examiner les journaux des charges de travail exécutées sur celui-ci. Vous devez configurer les agents Cloud Logging et Cloud Monitoring pour qu'ils collectent des journaux et des métriques dans votre projet Google Cloud. Si vous ne configurez pas ces agents, les clusters Anthos sur AWS ne collectent pas de données de journalisation et de surveillance.

Quelles sont les données recueillies ?

Une fois configurés, les agents collectent les journaux et les métriques du cluster et des charges de travail s'exécutant sur celui-ci. Ces données sont stockées dans votre projet Google Cloud. Vous devez configurer l'ID de projet dans le champ project_id d'un fichier de configuration lorsque vous installez le service de transfert de journaux.

Les données collectées incluent les éléments suivants :

Journaux des services système sur chacun des nœuds de calcul
Journaux d'application pour toutes les charges de travail s'exécutant sur le cluster
Métriques pour le cluster et les services système. Pour plus d'informations sur les métriques spécifiques, consultez la page Métriques Anthos.
Métriques d'applications pour les pods si vos applications sont configurées avec des cibles de scrape Prometheus et annotées avec une configuration incluant prometheus.io/scrape, prometheus.io/path et prometheus.io/port.

Vous pouvez désactiver les agents à tout moment. Consultez la page Effectuer un nettoyage pour en savoir plus. Les données collectées par les agents peuvent être gérées et supprimées comme toute autre donnée de métrique ou de journal, comme décrit dans les documentations de Cloud Monitoring et Cloud Logging.

Les données de journalisation sont stockées selon les règles de conservation configurées. La conservation des données de métriques varie selon le type de métrique.

Composants de journalisation et de surveillance

Pour exporter des données de télémétrie au niveau du cluster depuis des clusters Anthos sur AWS vers Google Cloud, vous devez déployer les composants suivants dans votre cluster :

Service de transfert de journaux Stackdriver (stackdriver-log-forwarder-*) Un DaemonSet Fluentbit qui transfère les journaux de chaque nœud Kubernetes vers Cloud Logging.
Agent de métriques GKE (gke-metrics-agent-*). Un DaemonSet basé sur OpenTelemetry Collector, qui collecte les données de métriques et les transmet à Cloud Monitoring.

Les fichiers manifestes de ces composants se trouvent dans le dépôt anthos-samples sur GitHub.

Prerequisites

Un projet Google Cloud avec facturation activée. Pour en savoir plus sur les coûts, consultez la page Tarifs de la suite Google Cloud Operations.

Les API Cloud Logging et Cloud Monitoring doivent également être activées sur le projet. Pour activer ces API, exécutez les commandes suivantes :
```
gcloud services enable logging.googleapis.com
gcloud services enable monitoring.googleapis.com
```
Un environnement de type "cluster Anthos sur AWS" comprenant un cluster d'utilisateur enregistré auprès de Connect. Exécutez la commande suivante pour vérifier que votre cluster est enregistré.
```
gcloud container fleet memberships list
```
Si votre cluster est enregistré, Google Cloud CLI affiche son nom et son ID.
```
NAME       EXTERNAL_ID
cluster-0  1abcdef-1234-4266-90ab-123456abcdef
```
Si votre cluster n'est pas répertorié, consultez la section Se connecter à un cluster avec Connect.
L'outil de ligne de commande git doit être installé sur votre machine.

Configurer des autorisations pour la suite Google Cloud Operations

Les agents de journalisation et de surveillance utilisent Fleet Workload Identity pour communiquer avec Cloud Logging et Cloud Monitoring. Cette identité a besoin d'autorisations pour écrire des journaux et des métriques dans votre projet. Pour ajouter les autorisations, exécutez les commandes suivantes :

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:PROJECT_ID.svc.id.goog[kube-system/stackdriver]" \
  --role=roles/logging.logWriter
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:PROJECT_ID.svc.id.goog[kube-system/stackdriver]" \
  --role=roles/monitoring.metricWriter

Remplacez PROJECT_ID par votre projet Google Cloud.

Se connecter à l'hôte bastion

Pour vous connecter à vos ressources Anthos clusters on AWS, procédez comme suit : Indiquez si vous disposez d'un VPC AWS (ou d'une connexion directe à votre VPC) ou si vous avez créé un VPC dédié lors de la création de votre service de gestion.

VPC existant

Si vous disposez d'une connexion directe ou VPN à un VPC existant, omettez la ligne env HTTP_PROXY=http://localhost:8118 des commandes de cette rubrique.

VPC dédié

Lorsque vous créez un service de gestion dans un VPC dédié, Anthos clusters on AWS inclut un hôte bastion placé dans un sous-réseau public.

Pour vous connecter à votre service de gestion, procédez comme suit :

Accédez au répertoire contenant votre configuration Anthos clusters on AWS. Vous avez créé ce répertoire lors de l'installation du service de gestion.
```
cd anthos-aws
```
Pour ouvrir le tunnel, exécutez le script bastion-tunnel.sh. Le tunnel est transféré vers localhost:8118.

Pour ouvrir un tunnel vers l'hôte bastion, exécutez la commande suivante :
```
./bastion-tunnel.sh -N
```
Les messages en provenance du tunnel SSH s'affichent dans cette fenêtre. Lorsque vous êtes prêt à fermer la connexion, arrêtez le processus à l'aide du raccourci Ctrl+C ou en fermant la fenêtre.
Ouvrez un nouveau terminal et accédez au répertoire anthos-aws.
```
cd anthos-aws
```
Vérifiez que vous êtes en mesure de vous connecter au cluster à l'aide de kubectl.
```
env HTTPS_PROXY=http://localhost:8118 \
kubectl cluster-info
```
La sortie inclut l'URL du serveur d'API du service de gestion.

Cloud Logging et Cloud Monitoring sur les nœuds de plan de contrôle

À l'aide d'Anthos clusters on AWS 1.8.0 et des versions ultérieures, Cloud Logging et Cloud Monitoring pour les nœuds du plan de contrôle peuvent être automatiquement configurés lors de la création de clusters d'utilisateur. Pour activer Cloud Logging ou Cloud Monitoring, complétez la section controlPlane.cloudOperations de votre configuration AWSCluster.

cloudOperations:
  projectID: PROJECT_ID
  location: GC_REGION
  enableLogging: ENABLE_LOGGING
  enableMonitoring: ENABLE_MONITORING

Remplacez les éléments suivants :

PROJECT_ID : ID de votre projet.
GC_REGION : région Google Cloud dans laquelle vous souhaitez stocker les journaux. Choisissez une région proche de la région AWS. Pour plus d'informations, consultez la section Emplacements mondiaux – Régions et zones. Vous pouvez, par exemple, opter pour la région us-central1.
ENABLE_LOGGING : true ou false, pour indiquer si Cloud Logging doit être activé ou non sur les nœuds du plan de contrôle.
ENABLE_MONITORING : true ou false, pour indiquer si Cloud Monitoring doit être activé ou non sur les nœuds du plan de contrôle.

Ensuite, suivez la procédure décrite sur la page Créer un cluster d'utilisateur personnalisé.

Cloud Logging et Cloud Monitoring sur les nœuds de calcul

Supprimer la version précédente

Si vous avez configuré une version antérieure des agents de journalisation et de surveillance qui inclut stackdriver-log-aggregator (Fluentd) et stackdriver-prometheus-k8s (Prometheus), vous devrez peut-être les désinstaller avant de continuer.

Cliquez pour afficher les commandes permettant de désinstaller une version antérieure.

    kubectl delete -n kube-system statefulset stackdriver-log-aggregator
    kubectl delete -n kube-system configmap stackdriver-log-aggregator-input-config
    kubectl delete -n kube-system configmap stackdriver-log-aggregator-output-config
    kubectl delete -n kube-system networkpolicy stackdriver-log-aggregator-in-forward
    kubectl delete -n kube-system networkpolicy stackdriver-log-aggregator-prometheus-scrape
    kubectl delete -n kube-system serviceaccount stackdriver-log-aggregator
    kubectl delete -n kube-system service stackdriver-log-aggregator-in-forward
    kubectl delete -n kube-system statefulset stackdriver-prometheus-k8s
    kubectl delete -n kube-system service stackdriver-prometheus-k8s
    kubectl delete -n kube-system secret stackdriver-prometheus-scrape
    kubectl delete -n kube-system clusterrolebinding stackdriver-prometheus-scrape
    kubectl delete -n kube-system clusterrole stackdriver-prometheus-scrape
    kubectl delete -n kube-system serviceaccount stackdriver-prometheus-scrape
    kubectl delete -n kube-system clusterrolebinding stackdriver-user:prometheus
    kubectl delete -n kube-system clusterrole stackdriver-user:prometheus
    kubectl delete -n kube-system serviceaccount stackdriver-prometheus
    kubectl delete -n kube-system configmap stackdriver-prometheus-k8s
    kubectl delete -n kube-system configmap stackdriver-prometheus-sidecar-config
    kubectl delete -n kube-system pvc/stackdriver-log-aggregator-persistent-volume-claim-stackdriver-log-aggregator-0
    kubectl delete -n kube-system pvc/stackdriver-log-aggregator-persistent-volume-claim-stackdriver-log-aggregator-1
    kubectl delete -n kube-system pvc/stackdriver-prometheus-data-stackdriver-prometheus-k8s-0
    kubectl delete secret google-cloud-credentials -n kube-system

Installer le service de transfert de journaux

Dans cette section, vous allez installer le service de transfert de journaux Stackdriver sur votre cluster.

Passez du répertoire anthos-samples/aws-logging-monitoring/ au répertoire logging/.
```
cd logging/
```
Modifiez le fichier forwarder.yaml pour qu'il corresponde à la configuration de votre projet :
```
sed -i "s/PROJECT_ID/PROJECT_ID/g" forwarder.yaml
sed -i "s/CLUSTER_NAME/CLUSTER_NAME/g" forwarder.yaml
sed -i "s/CLUSTER_LOCATION/GC_REGION/g" forwarder.yaml
```
Remplacez les éléments suivants :
- PROJECT_ID : ID de votre projet.
- CLUSTER_NAME : nom de votre cluster, par exemple, cluster-0.
- GC_REGION : région Google Cloud dans laquelle vous souhaitez stocker les journaux. Choisissez une région proche de la région AWS. Pour plus d'informations, consultez la section Emplacements mondiaux – Régions et zones. Vous pouvez, par exemple, opter pour la région us-central1.
(Facultatif) En fonction de vos charges de travail, du nombre de nœuds dans votre cluster et du nombre de pods par nœud, vous devrez peut-être définir des demandes de ressources de mémoire et de processeur. Pour plus d'informations, consultez la section Allocations de processeurs et de mémoire recommandées.
À partir de votre répertoire anthos-aws, utilisez anthos-gke pour basculer vers le contexte de votre cluster d'utilisateur.
```
cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
Remplacez CLUSTER_NAME par le nom de votre cluster d'utilisateur.

Créez le compte de service stackdriver s'il n'existe pas et déployez le service de transfert de journaux sur le cluster.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl create serviceaccount stackdriver -n kube-system
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f forwarder.yaml

Utilisez kubectl pour vérifier que les pods ont démarré.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl get pods -n kube-system | grep stackdriver-log

Vous devriez voir un pod de service de transfert par nœud dans un pool de nœuds. Par exemple, dans un cluster de six nœuds, vous devriez voir six pods de service de transfert.

stackdriver-log-forwarder-2vlxb              2/2     Running   0          21s
stackdriver-log-forwarder-dwgb7              2/2     Running   0          21s
stackdriver-log-forwarder-rfrdk              2/2     Running   0          21s
stackdriver-log-forwarder-sqz7b              2/2     Running   0          21s
stackdriver-log-forwarder-w4dhn              2/2     Running   0          21s
stackdriver-log-forwarder-wrfg4              2/2     Running   0          21s

Tester le transfert de journaux

Dans cette section, vous allez déployer une charge de travail contenant un serveur Web HTTP de base avec générateur de charge sur votre cluster. Vous allez ensuite vérifier que les journaux sont présents dans Cloud Logging.

Avant d'installer cette charge de travail, vous pouvez vérifier les fichiers manifestes du serveur Web et du générateur de charge.

Déployez le serveur Web et le générateur de charge sur votre cluster.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f  https://raw.githubusercontent.com/GoogleCloudPlatform/istio-samples/master/sample-apps/helloserver/server/server.yaml
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/istio-samples/master/sample-apps/helloserver/loadgen/loadgen.yaml

Pour vérifier que vous pouvez afficher les journaux de votre cluster dans le tableau de bord Cloud Logging, accédez à l'explorateur de journaux dans la console Google Cloud:

Accéder à l'explorateur de journaux
Copiez l'exemple de requête ci-dessous dans le champ Générateur de requête.
```
resource.type="k8s_container" resource.labels.cluster_name="CLUSTER_NAME"
```
Remplacez CLUSTER_NAME par le nom de votre cluster.
Cliquez sur Exécuter la requête. Vous devriez voir les journaux de cluster récents apparaître sous Résultats de la requête.

Après avoir vérifié que les journaux apparaissent bien dans les résultats de la requête, supprimez le générateur de charge et le serveur Web.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/istio-samples/master/sample-apps/helloserver/loadgen/loadgen.yaml

env HTTPS_PROXY=http://localhost:8118 \
  kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/istio-samples/master/sample-apps/helloserver/server/server.yaml

Installer le collecteur de métriques

Dans cette section, vous allez installer un agent chargé d'envoyer des données à Cloud Monitoring.

Passez du répertoire anthos-samples/aws-logging-monitoring/logging/ au répertoire anthos-samples/aws-logging-monitoring/monitoring/.
```
cd ../monitoring
```
Modifiez le fichier gke-metrics-agent.yaml pour qu'il corresponde à la configuration de votre projet :
```
sed -i "s/PROJECT_ID/PROJECT_ID/g" gke-metrics-agent.yaml
sed -i "s/CLUSTER_NAME/CLUSTER_NAME/g" gke-metrics-agent.yaml
sed -i "s/CLUSTER_LOCATION/GC_REGION/g" gke-metrics-agent.yaml
```
Remplacez les éléments suivants :
- PROJECT_ID : ID de votre projet.
- CLUSTER_NAME : nom de votre cluster, par exemple, cluster-0.
- GC_REGION : région Google Cloud dans laquelle vous souhaitez stocker les journaux. Choisissez une région proche de la région AWS. Pour plus d'informations, consultez la section Emplacements mondiaux – Régions et zones. Vous pouvez, par exemple, opter pour la région us-central1.
(Facultatif) En fonction de vos charges de travail, du nombre de nœuds dans votre cluster et du nombre de pods par nœud, vous devrez peut-être définir des demandes de ressources de mémoire et de processeur. Pour plus d'informations, consultez la section Allocations de processeurs et de mémoire recommandées.

Créez le compte de service stackdriver s'il n'existe pas et déployez l'agent de métriques sur votre cluster.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl create serviceaccount stackdriver -n kube-system
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f gke-metrics-agent.yaml

Utilisez l'outil kubectl pour vérifier que le pod gke-metrics-agent est en cours d'exécution.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl get pods -n kube-system | grep gke-metrics-agent

Vous devriez voir un pod d'agent par nœud dans un pool de nœuds. Par exemple, dans un cluster à trois nœuds, vous devez voir trois pods d'agent.

gke-metrics-agent-gjxdj                    2/2     Running   0          102s
gke-metrics-agent-lrnzl                    2/2     Running   0          102s
gke-metrics-agent-s6p47                    2/2     Running   0          102s

Pour vérifier que les métriques du cluster sont exportées vers Cloud Monitoring, accédez à l'explorateur de métriques dans la console Google Cloud:

Accéder à l'explorateur de métriques
Dans l'explorateur de métriques, cliquez sur Éditeur de requête, puis copiez la commande suivante dans la zone de texte de l'éditeur :
```
fetch k8s_container
| metric 'kubernetes.io/anthos/otelcol_exporter_sent_metric_points'
| filter
    resource.project_id == 'PROJECT_ID'
    && (resource.cluster_name =='CLUSTER_NAME')
| align rate(1m)
| every 1m
```
Remplacez les éléments suivants :
- PROJECT_ID : ID de votre projet.
- CLUSTER_NAME : nom de cluster que vous avez utilisé lors de la création du cluster d'utilisateur, par exemple cluster-0.
Cliquez sur Run query. Le taux de points de métriques envoyés à Cloud Monitoring depuis chaque pod gke-metrics-agent de votre cluster s'affiche.

Remarque : Il peut s'écouler plusieurs minutes avant que les métriques ne soient visibles dans l'explorateur de métriques.

Les autres métriques utiles incluent, mais sans s'y limiter :
- kubernetes.io/anthos/container_memory_working_set_bytes : l'utilisation de la mémoire du conteneur ;
- kubernetes.io/anthos/container_cpu_usage_seconds_total : l'utilisation du processeur du conteneur ;
- kubernetes.io/anthos/apiserver_aggregated_request_total : le nombre de requêtes kube-apiserver, disponible uniquement si Cloud Monitoring est activé sur le plan de contrôle.
Pour obtenir la liste complète des métriques disponibles, consultez la page Métriques Anthos. Pour en savoir plus sur l'utilisation de l'interface utilisateur, consultez la page Explorateur de métriques.

Créer un tableau de bord dans Cloud Monitoring

Dans cette section, vous allez créer un tableau de bord Cloud Monitoring qui surveille l'état des conteneurs de votre cluster.

Passez du répertoire anthos-samples/aws-logging-monitoring/monitoring/ au répertoire anthos-samples/aws-logging-monitoring/monitoring/dashboards.
```
cd dashboards
```
Remplacez les instances de la chaîne CLUSTER_NAME dans pod-status.json par le nom de votre cluster.
```
sed -i "s/CLUSTER_NAME/CLUSTER_NAME/g" pod-status.json
```
Remplacez CLUSTER_NAME par le nom de votre cluster.
Créez un tableau de bord personnalisé avec le fichier de configuration en exécutant la commande suivante :
```
gcloud monitoring dashboards create --config-from-file=pod-status.json
```
Pour vérifier que votre tableau de bord a bien été créé, accédez à "Tableaux de bord Cloud Monitoring" dans la console Google Cloud.

Accéder aux tableaux de bord

Ouvrez le tableau de bord nouvellement créé avec un nom au format CLUSTER_NAME (Anthos cluster on AWS) pod status.

Nettoyer

Dans cette section, vous allez supprimer les composants de journalisation et de surveillance de votre cluster.

Supprimez le tableau de bord de surveillance dans la liste des tableaux de bord de la console Google Cloud en cliquant sur le bouton de suppression associé au nom du tableau de bord.
Accédez au répertoire anthos-samples/aws-logging-monitoring/.
```
cd anthos-samples/aws-logging-monitoring
```

Pour supprimer toutes les ressources créées dans ce guide, exécutez les commandes suivantes :

env HTTPS_PROXY=http://localhost:8118 \
  kubectl delete -f logging/
env HTTPS_PROXY=http://localhost:8118 \
  kubectl delete -f monitoring/

Allocations de processeurs et de mémoire recommandées

Cette section inclut les ressources de processeur recommandées et les allocations pour les composants individuels utilisés dans le cadre de la journalisation et de la surveillance. Chacun des tableaux ci-après répertorie les demandes de ressources de mémoire et de processeur pour un cluster comportant un nombre de nœuds compris dans une plage spécifique. Vous devez définir les demandes de ressources pour un composant dans le fichier spécifié dans le tableau.

Pour en savoir plus, consultez les sections Bonnes pratiques Kubernetes : requêtes et limites de ressources et Gérer les ressources pour les conteneurs.

De 1 à 10 nœuds

File	Ressource	Demandes de ressources de processeur	Limites de processeur	Demandes de mémoire	Limites de mémoire
`monitoring/gke-metrics-agent.yaml`	gke-metrics-agent	30 m	100 m	50 Mi	500 Mi
`logging/forwarder.yaml`	stackdriver-log-forwarder	50 m	100 m	100 Mi	600 Mi

De 10 à 100 nœuds

File	Ressource	Demandes de ressources de processeur	Limites de processeur	Demandes de mémoire	Limites de mémoire
`monitoring/gke-metrics-agent.yaml`	gke-metrics-agent	50 m	100 m	50 Mi	500 Mi
`logging/forwarder.yaml`	stackdriver-log-forwarder	60 m	100 m	100 Mi	600 Mi

Plus de 100 nœuds

Fichier	Ressource	Demandes de ressources de processeur	Limites de processeur	Demandes de mémoire	Limites de mémoire
`monitoring/gke-metrics-agent.yaml`	gke-metrics-agent	50 m	100 m	100 Mi	Non disponible
`logging/forwarder.yaml`	stackdriver-log-forwarder	60 m	100 m	100 Mi	600 Mi