Cette page explique comment configurer un cluster d'utilisateur pour Google Distributed Cloud afin que les journaux personnalisés et les métriques des applications utilisateur soient envoyés à Cloud Logging et à Cloud Monitoring. Les métriques des applications utilisateur sont collectées avec Google Cloud Managed Service pour Prometheus.
Activer Managed Service pour Prometheus pour les applications utilisateur
La configuration de Managed Service pour Prometheus est stockée dans un objet Stackdriver nommé stackdriver
.
Ouvrez l'objet
stackdriver
à modifier :kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver
Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'utilisateur.
Sous
spec
, définissezenableGMPForApplications
surtrue
:apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: projectID: ... clusterName: ... clusterLocation: ... proxyConfigSecretName: ... enableGMPForApplications: true enableVPC: ... optimizedMetrics: true
Fermez le fichier modifié. Cette opération démarre l'exécution des composants Prometheus gérés par Google (GMP) dans le cluster.
Pour vérifier les composants, exécutez la commande suivante :
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG --namespace gmp-system get pods
La sortie de la commande ressemble à ceci :
NAME READY STATUS RESTARTS AGE collector-abcde 2/2 Running 1 (5d18h ago) 5d18h collector-fghij 2/2 Running 1 (5d18h ago) 5d18h collector-klmno 2/2 Running 1 (5d18h ago) 5d18h gmp-operator-68d49656fc-abcde 1/1 Running 0 5d18h rule-evaluator-7c686485fc-fghij 2/2 Running 1 (5d18h ago) 5d18h
Managed Service pour Prometheus est compatible avec l'évaluation des règles et les alertes. Pour configurer l'évaluation des règles, consultez la page Évaluation des règles.
Exécuter un exemple d'application
Dans cette section, vous allez créer une application qui émet des métriques Prometheus et utiliser le service Prometheus géré par Google pour collecter les métriques. Pour en savoir plus, consultez la page Google Cloud Managed Service pour Prometheus.
Déployer l'exemple d'application
Créez l'espace de noms
gmp-test
pour les ressources que vous créez dans le cadre de l'exemple d'application :kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create ns gmp-test
Le service géré fournit un fichier manifeste pour un exemple d'application qui émet des métriques Prometheus sur le port
metrics
. L'application utilise trois instances dupliquées.Pour déployer l'exemple d'application, exécutez la commande suivante :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n gmp-test apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.4.1/examples/example-app.yaml
Configurer une ressource PodMonitoring
Pour ingérer les données de métriques émises par l'exemple d'application, vous utilisez le scraping de données cibles. Le service géré utilise des ressources personnalisées PodMonitoring pour configurer le scraping et l'ingestion de métriques cibles. Vous pouvez convertir les ressources prometheus-operator existantes en ressources personnalisées PodMonitoring.
Une RS PodMonitoring ne scrape les cibles que dans l'espace de noms dans lequel la RS est déployée. Pour scraper des cibles dans plusieurs espaces de noms, déployez la même RS PodMonitoring dans chaque espace de noms. Vous pouvez vérifier que la ressource PodMonitoring est installée dans l'espace de noms prévu en exécutant la commande suivante :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get podmonitoring -A
Pour obtenir une documentation de référence sur toutes les ressources personnalisées Managed Service pour Prometheus, consultez la documentation prometheus-engine/doc/api reference.
Le fichier manifeste suivant définit une ressource PodMonitoring, prom-example
, dans l'espace de noms gmp-test
. La ressource trouve tous les pods de l'espace de noms qui portent le libellé app
avec la valeur prom-example
. Les pods correspondants sont récupérés sur un port nommé metrics
, toutes les 30 secondes, sur le chemin HTTP /metrics
.
apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: prom-example spec: selector: matchLabels: app: prom-example endpoints: - port: metrics interval: 30s
Pour appliquer cette ressource, exécutez la commande suivante :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n gmp-test apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.4.1/examples/pod-monitoring.yaml
Managed Service pour Prometheus récupère désormais les pods correspondants.
Données des métriques de requêtes
Le moyen le plus simple de vérifier que vos données Prometheus sont exportées consiste à utiliser les requêtes PromQL dans l'explorateur de métriques de la console Google Cloud.
Pour exécuter une requête PromQL, procédez comme suit:
Dans la console Google Cloud, accédez à la page Surveillance ou cliquez sur le bouton suivant :
Dans le volet de navigation, sélectionnez Explorateur de métriques.
Utilisez le langage de requête Prometheus (PromQL) pour spécifier les données à afficher sur le graphique:
Dans la barre d'outils du volet Sélectionner une métrique, sélectionnez Éditeur de code.
Sélectionnez PromQL dans les options du bouton Langage. Le bouton de langage se trouve en bas du volet Éditeur de code.
Saisissez une requête dans l'éditeur de requête. Par exemple, pour représenter graphiquement le nombre moyen de secondes que les processeurs passent dans chaque mode au cours de l'heure passée, utilisez la requête suivante:
avg(rate(kubernetes_io:anthos_container_cpu_usage_seconds_total {monitored_resource="k8s_node"}[1h]))
Pour en savoir plus sur l'utilisation de PromQL, consultez PromQL dans Cloud Monitoring.
La capture d'écran suivante montre un graphique affichant la métrique anthos_container_cpu_usage_seconds_total
:
Si vous collectez une grande quantité de données, vous pouvez filtrer les métriques exportées afin de limiter les coûts.
Activer Cloud Logging pour les applications utilisateur
La configuration de Logging est stockée dans un objet Stackdriver nommé stackdriver.
Ouvrez l'objet
stackdriver
à modifier :kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG --namespace kube-system edit stackdriver stackdriver
Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'utilisateur.
Sous
spec
, définissezenableCloudLoggingForApplications
surtrue
:apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: projectID: ... clusterName: ... clusterLocation: ... proxyConfigSecretName: ... enableCloudLoggingForApplications: true enableVPC: ... optimizedMetrics: true
Fermez le fichier modifié.
Exécuter un exemple d'application
Dans cette section, vous allez créer une application qui écrit des journaux personnalisés.
Enregistrez le fichier de manifeste de déploiement suivant dans un fichier nommé
my-app.yaml
.apiVersion: apps/v1 kind: Deployment metadata: name: "monitoring-example" namespace: "default" labels: app: "monitoring-example" spec: replicas: 1 selector: matchLabels: app: "monitoring-example" template: metadata: labels: app: "monitoring-example" spec: containers: - image: gcr.io/google-samples/prometheus-dummy-exporter:latest name: prometheus-example-exporter imagePullPolicy: Always command: - /bin/sh - -c - ./prometheus-dummy-exporter --metric-name=example_monitoring_up --metric-value=1 --port=9090 resources: requests: cpu: 100m
Créez le déploiement :
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-app.yaml
Afficher des journaux d'application
Console
Accédez à l'explorateur de journaux dans la console Google Cloud.
Cliquez sur Ressource. Sous ALL_RESOURCE_TYPES, sélectionnez
Kubernetes Container
.Sous CLUSTER_NAME, sélectionnez le nom de votre cluster d'utilisateur.
Sous NAMESPACE_NAME, sélectionnez
default
.Cliquez sur Ajouter, puis sur Exécuter la requête.
Les entrées de journal du déploiement
monitoring-example
sont affichées sous Résultats de la requête. Exemple :{ "textPayload": "2020/11/14 01:24:24 Starting to listen on :9090\n", "insertId": "1oa4vhg3qfxidt", "resource": { "type": "k8s_container", "labels": { "pod_name": "monitoring-example-7685d96496-xqfsf", "cluster_name": ..., "namespace_name": "default", "project_id": ..., "location": "us-west1", "container_name": "prometheus-example-exporter" } }, "timestamp": "2020-11-14T01:24:24.358600252Z", "labels": { "k8s-pod/pod-template-hash": "7685d96496", "k8s-pod/app": "monitoring-example" }, "logName": "projects/.../logs/stdout", "receiveTimestamp": "2020-11-14T01:24:39.562864735Z" }
gcloud
Exécutez cette commande :
gcloud logging read 'resource.labels.project_id="PROJECT_ID" AND \ resource.type="k8s_container" AND resource.labels.namespace_name="default"'
Remplacez PROJECT_ID par l'ID de votre projet de journalisation et de surveillance.
Le résultat affiche les entrées de journal du déploiement
monitoring-example
. Exemple :insertId: 1oa4vhg3qfxidt labels: k8s-pod/app: monitoring-example k8s- pod/pod-template-hash: 7685d96496 logName: projects/.../logs/stdout receiveTimestamp: '2020-11-14T01:24:39.562864735Z' resource: labels: cluster_name: ... container_name: prometheus-example-exporter location: us-west1 namespace_name: default pod_name: monitoring-example-7685d96496-xqfsf project_id: ... type: k8s_container textPayload: | 2020/11/14 01:24:24 Starting to listen on :9090 timestamp: '2020-11-14T01:24:24.358600252Z'
Filtrer les journaux d'application
Le filtrage des journaux d'applications peut réduire la facturation de la journalisation des applications et le trafic réseau du cluster vers Cloud Logging. À partir de la version 1.15.0 de Google Distributed Cloud, lorsque enableCloudLoggingForApplications
est défini sur true
, vous pouvez filtrer les journaux d'application selon les critères suivants:
- Étiquettes des pods (
podLabelSelectors
) - Espaces de noms (
namespaces
) - Expressions régulières pour le contenu du journal (
contentRegexes
)
Google Distributed Cloud n'envoie que les résultats des filtres à Cloud Logging.
Définir les filtres de journaux d'application
La configuration de Logging est spécifiée dans un objet Stackdriver nommé stackdriver
.
Ouvrez l'objet
stackdriver
à modifier :kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \ edit stackdriver stackdriver
Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'utilisateur.
Ajoutez une section
appLogFilter
au fichierspec
:apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: enableCloudLoggingForApplications: true projectID: ... clusterName: ... clusterLocation: ... appLogFilter: keepLogRules: - namespaces: - prod ruleName: include-prod-logs dropLogRules: - podLabelSelectors: - disableGCPLogging=yes ruleName: drop-logs
Enregistrez et fermez le fichier modifié.
(Facultatif) Si vous utilisez
podLabelSelectors
, redémarrez le DaemonSetstackdriver-log-forwarder
pour appliquer vos modifications dès que possible:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG --namespace kube-system \ rollout restart daemonset stackdriver-log-forwarder
Normalement, les
podLabelSelectors
sont effectifs après 10 minutes. Redémarrer le DaemonSetstackdriver-log-forwarder
permet aux modifications de prendre effet plus rapidement.
Exemple: Inclure les journaux ERROR
ou WARN
uniquement dans l'espace de noms prod
L'exemple suivant illustre le fonctionnement d'un filtre de journal d'application. Définissez un filtre qui utilise un espace de noms (prod
), une expression régulière (.*(ERROR|WARN).*
) et une étiquette de pod (disableGCPLogging=yes
). Ensuite, pour vérifier que le filtre fonctionne, exécutez un pod dans l'espace de noms prod
afin de tester ces conditions de filtre.
Pour définir et tester un filtre de journal d'application, procédez comme suit:
Spécifiez un filtre de journal d'application dans l'objet Stackdriver:
Dans l'exemple
appLogFilter
suivant, seuls les journauxERROR
ouWARN
de l'espace de nomsprod
sont conservés. Tous les journaux des pods portant l'étiquettedisableGCPLogging=yes
sont supprimés :apiVersion: addons.gke.io/v1alpha1 kind: Stackdriver metadata: name: stackdriver namespace: kube-system spec: ... appLogFilter: keepLogRules: - namespaces: - prod contentRegexes: - ".*(ERROR|WARN).*" ruleName: include-prod-logs dropLogRules: - podLabelSelectors: - disableGCPLogging=yes # kubectl label pods pod disableGCPLogging=yes ruleName: drop-logs ...
Déployez un pod dans l'espace de noms
prod
et exécutez un script qui génère les entrées de journalERROR
etINFO
:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG run pod1 \ --image gcr.io/cloud-marketplace-containers/google/debian10:latest \ --namespace prod --restart Never --command -- \ /bin/sh -c "while true; do echo 'ERROR is 404\\nINFO is not 404' && sleep 1; done"
Les journaux filtrés ne doivent contenir que les entrées
ERROR
, et non les entréesINFO
.Ajoutez l'étiquette
disableGCPLogging=yes
au pod:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG label pods pod1 \ --namespace prod disableGCPLogging=yes
Le journal filtré ne doit plus contenir d'entrées pour le pod
pod1
.
Définition de l'API de filtre de journal d'application
La définition du filtre de journal d'application est déclarée dans la définition de ressource personnalisée Stackdriver.
Pour obtenir la définition de ressource personnalisée Stackdriver, exécutez la commande suivante:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get crd stackdrivers.addons.gke.io \
--namespace kube-system -o yaml