Visualisation des journaux d'application sur les noeuds virtuels

Découvrez comment visualiser les journaux des applications exécutées sur des noeuds virtuels dans un cluster Kubernetes créé à l'aide de Kubernetes Engine (OKE).

Après avoir créé un cluster avec des noeuds virtuels à l'aide de Kubernetes Engine, vous disposez de deux options pour accéder aux journaux des applications exécutées sur les noeuds virtuels :

Affichez les journaux stdout et stderr à partir des conteneurs d'application à l'aide de la commande kubectl logs.
Envoyer les journaux d'application à un serveur de journaux persistants pour consultation.

Affichage des journaux stdout et stderr à l'aide de la commande kubectl logs

Pour afficher les journaux stdout et stderr à partir des conteneurs d'une application à l'aide de la commande kubectl logs, procédez comme suit :

Si vous ne l'avez pas encore fait, suivez les étapes permettant de configurer le fichier de configuration Kubeconfig du cluster et (si nécessaire) de définir la variable d'environnement KUBECONFIG de sorte qu'elle pointe vers le fichier. Vous devez configurer votre propre fichier Kubeconfig. Vous ne pouvez pas accéder à un cluster à l'aide d'un fichier Kubeconfig configuré par un autre utilisateur. Reportez-vous à Configuration de l'accès à un cluster.
Dans une fenêtre de terminal, exécutez la commande kubectl logs en saisissant la commande suivante :
```
kubectl logs <pod-name>
```
Par exemple :
```
kubectl logs nginx
```
Lorsque le pod contient plusieurs conteneurs, indiquez le conteneur pour lequel vous voulez afficher les journaux. Par exemple, si le pod myapp comporte deux conteneurs appelés nginx et logging et que vous voulez afficher les journaux du conteneur logging, entrez :
```
kubectl logs myapp logging
```

Envoi de journaux à un serveur de journaux persistant

Vous pouvez envoyer les journaux des applications en cours d'exécution sur les noeuds virtuels à un serveur de journaux distant tel que OpenSearch et afficher les journaux sur ce serveur. Etant donné que les noeuds virtuels ne prennent pas en charge le jeu de démons Kubernetes, vous ne pouvez pas exécuter d'agent de journalisation au niveau du noeud. A la place, vous pouvez exécuter un agent de journalisation léger en tant que sidecar pour chacun des pods de l'application. Vous pouvez utiliser n'importe quel agent de journalisation pouvant être exécuté en tant que sidecar sur un pod Kubernetes, tel que Fluent Bit.

Par exemple, pour exécuter Fluent Bit en tant que sidecar sur un pod afin d'envoyer des journaux d'application à un serveur de journaux OpenSearch distant :

Créez un fichier ConfigMap Kubernetes par cluster ou par espace de noms, en indiquant les paramètres de configuration du bit fluide à utiliser. Notez en particulier que vous devez spécifier l'adresse IP, le numéro de port et les paramètres d'authentification du serveur de journalisation distant.
Par exemple :
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluentbit-config
data:
  fluent-bit.conf: |
    [SERVICE]
        flush        1
        daemon       Off
 
    [INPUT]
        Name              tail
        Path              /mnt/log/*
 
    [OUTPUT]
        name  opensearch
        match *
        host <ip-address>
        port <port-number>
        tls On
        HTTP_User <username>
        HTTP_Passwd <example-password>
        Index fluent-bit
        Suppress_Type_Name On
```
où :
- host <ip-address> indique l'adresse IP du serveur Opensearch.
- port <port-number> indique le port du serveur Opensearch (9200 par défaut).
- HTTP_User <username> indique le nom utilisateur du serveur Opensearch.
- HTTP_Passwd <example-password> indique le mot de passe du serveur Opensearch.

Ajoutez un side-car Fluent Bit à chaque pod. Notez que vous devez configurer tous les pods avec un sidecar Fluent Bit pour vous assurer que les journaux d'application sont envoyés à la destination de journalisation persistante.

Dans la section volumes de chaque spécification de pod, indiquez les informations suivantes :
- emptyDir dans lequel les journaux d'application sont écrits, comme suit :
```
- name: logs
  emptyDir: {}
```
- Référence à l'élément ConfigMap que vous avez créé précédemment, comme suit :
```
- name: fluentbit-config
  configMap:
    name: fluentbit-config
```
Dans la section containers de chaque spécification de pod, vous devez indiquer que le conteneur de journalisation :
- Utilise l'image fluent/fluent-bit.
- Monte le fichier logs emptyDir et le fichier fluentbit-config ConfigMap.
Par exemple :
```
- name: logging
  image: fluent/fluent-bit
  resources:
    requests:
      cpu: 100m
      memory: 50Mi
  volumeMounts:
  - name: logs
    mountPath: /mnt/log
  - name: fluentbit-config
    mountPath: /fluent-bit/etc 
```

Voici un exemple de spécification de pod complète :

apiVersion: v1
kind: Pod
metadata:
  name: date-logging
spec:
  containers:
  - name: date
    image: busybox
    resources:
      requests:
        cpu: 500m
        memory: 200Mi
    command: ["sh", "-c"]
    args:
      - while [ 1 ]; do
        echo "Writing the date in /mnt/log/date.log";
        date >> /mnt/log/date.log;
        sleep 10;
        done
    volumeMounts:
    - name: logs
      mountPath: /mnt/log
  - name: logging
    image:
     resources:
      requests:
        cpu: 100m
        memory: 50Mi
    volumeMounts:
    - name: logs
      mountPath: /mnt/log
    - name: fluentbit-config
      mountPath: /fluent-bit/etc
  volumes:
  - name: logs
    emptyDir: {}
  - name: fluentbit-config
    configMap:
      name: fluentbit-config

Documentation Oracle Cloud Infrastructure

Visualisation des journaux d'application sur les noeuds virtuels

Affichage des journaux stdout et stderr à l'aide de la commande kubectl logs

Envoi de journaux à un serveur de journaux persistant