Streamen Sie GKE-Anwendungsprotokolldateien zu Cloud Logging

Viele Anwendungen protokollieren in Dateien. In einer Containerumgebung funktioniert das nicht gut. Das Dateisystem wird nicht persistiert und die Protokolle gehen verloren. In GKE können Sie mit dem Cloud Logging-Agenten Protokolldateien in Cloud Logging persistieren. Der Agent gibt jedoch nicht den erforderlichen Ressourcentyp an. Das führt dazu, dass die Protokolle als Nicht-Kubernetes-Container-Protokolle erscheinen. Dieser Blog zeigt, wie Sie das Problem lösen können.

Cloud Logging Agent in GKE

Der Cloud Logging Agent ist ein Fluentd-Dienst, der mit dem Google Cloud-Ausgabe-Plugin konfiguriert ist. Ereignisse, die an das Ausgabe-Plugin gesendet werden, müssen einen Cloud Operations for GKE-Ressourcentyp enthalten. Denn ohne einen Ressourcentyp wird das Ereignis als VM-Instanz-Protokollsatz in Cloud Logging registriert.

Legen Sie den Kubernetes Container Ressourcentyp fest

Kubernetes Container-Ereignisse verwenden den Ressourcentyp k8s_container.[namespace].[pod].[container] und werden durch das Attribut logging.googleapis.com/local_resource_id unter Verwendung eines Fluentd-Filters angegeben.

<filter **>
  @type record_transformer
  enable_ruby true
  <record>
    "logging.googleapis.com/local_resource_id" ${"k8s_container.#{ENV['K8S_NAMESPACE']}.#{ENV['K8S_POD']}.#{ENV['K8S_CONTAINER']}"}
  </record>
</filter>

Die gesamte Konfigurationsdatei ist auf GitHub verfügbar.

Der Filter verwendet die Downward API von Kubernetes, um Ressourcentypdaten aus Umgebungsvariablen zu lesen.

    spec:
      containers:
        - name: application
        - name: logging-agent
          env:
          - name: K8S_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
          - name: K8S_POD
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: K8S_CONTAINER
            value: application

Installieren Sie den GKE-Protokollierungsagenten

Der Logging Agent verwendet eine Sidecar-Container-Bereitstellung, um auf Anwendungsprotokolldateien zuzugreifen.

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: app
          volumeMounts:
            - name: logs
              mountPath: /app/log
        - name: gke-fluentd
          env:
          - name: K8S_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
          - name: K8S_POD
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: K8S_CONTAINER
            value: app # Use the application container name
          volumeMounts:
            - name: logs
              mountPath: /app/log
      volumes:
        - name: logs
          emptyDir: {}

Probieren Sie es selbst mit der Beispielanwendung auf GitHub aus.

Diskussion

Der Logging Agent ermöglicht es uns, Protokolle aufzubewahren. Allerdings lösen wir damit nicht das Problem der Verwendung von Protokolldateien in einer Container-Umgebung... In Container-Umgebungen sollten Sie Cloud-native Logger verwenden oder alle Protokolle auf die Konsole streamen. Wenn Sie den Logger ändern, sollten Sie die Konfigurationsdatei für die Abhängigkeit aktualisieren; und wenn Sie das Verhalten des Loggers ändern, sollten Sie die Konfigurationsdatei für den Logger aktualisieren.

Fazit

Mit dem Cloud Logging-Agenten können Sie in Container-Umgebungen weiterhin Protokolldateien verwenden. Da in der Standardkonfiguration nicht die entsprechenden GKE-Ressourcentypen angegeben sind, müssen Sie den Agenten pflegen. Daher empfehle ich Ihnen, Ihre Anwendungsprotokollierung zu korrigieren. Erlauben Sie die Konfiguration eines Cloud-nativen Loggers und verwenden Sie eine strukturierte Protokollierung, um sich für alle wichtigen Protokollanalysedienste zu entscheiden. Image by Free-Photos from Pixabay