Log centralizado para contenedores Windows en Amazon EKS utilizando Fluent Bit

Por Harsh Rawat, Software Engineer en Amazon Web Services e
Marcio Morales, Principal Solutions Architect en Amazon Web Services.

Intro

En noviembre de 2022, Amazon Web Services (AWS) anunció el soporte de imágenes de contenedores Fluent Bit para el sistema operativo Windows. Este soporte elimina la necesidad a los clientes que utilizan Windows de implementar una solución de logging personalizada en el código de la aplicación o de administrar agentes personalizados en sus nodos Windows para extraer los logs. Para obtener más información sobre las versiones compatibles de Windows y de las imágenes de Fluent Bit, consulta nuestra documentación aquí.

Fluent Bit es un procesador y enrutador de logs rápido y flexible. compatible con varios sistemas operativos. Se utiliza para enrutar los logs a varios destinos de AWS, como Amazon CloudWatch, Amazon Kinesis Data Firehose, Amazon Simple Storage Service (Amazon S3) y Amazon OpenSearch. Además de los destinos en AWS, Fluent Bit ofrece soporte a soluciones de terceros, como Datadog, Splunk, servidores HTTP personalizados y más. Para obtener más información sobre el enrutamiento de logs en contenedores, visite el enlace del blog aquí. AWS ya admite imágenes de contenedores de Fluent Bit basadas en el sistema operativo Linux y esta versión permite a los clientes disponer de un mecanismo centralizado para procesar y enrutar sus logs en Amazon Elastic Container Service ( Amazon ECS) y Amazon Elastic Kubernetes Service (Amazon EKS) para cargas de trabajo Linux y Windows.

En esta publicación, analizamos cómo los clientes de Amazon EKS pueden desplegar imágenes Windows de Fluent Bit como un DaemonSet en sus nodos Windows para enviar los logs de Internet Information Services (IIS) generados en los pods Windows a los logs de Amazon CloudWatch, como una forma de centralizar el registro de logs. Vamos a configurar Fluent Bit para que enrute todos los logs generados por los pods en diferentes namespaces a los respectivos grupos de logs de CloudWatch. Además, cada entrada de log se enriquecería con metadatos adicionales de Kubernetes, como el namespace, el nombre del pod, el nombre del contenedor, el nombre de la imagen, el nombre del host, etc. Para obtener más información sobre la implementación de Fluent Bit en el clúster de Amazon ECS Windows, visite nuestra entrada de blog aquí.

Prerrequisitos

Prerrequisitos y premisas:

• Amazon EKS Cluster (1.20 o posterior) instalado y en ejecución. Consulte esta guía paso a paso.
• Iniciar los nodos Windows de Amazon EKS. Consulte esta guía paso a paso.
• Instalación y configuración adecuada de la interfaz de línea de comandos de Amazon (AWS CLI), eksctl y kubectl.
• Para crear una imagen de contenedor Windows, inicie una instancia de Windows en Amazon Elastic Compute Cloud (Amazon EC2) con Docker instalado, que se basa en la misma versión de Windows que nodos de Amazon EKS. Como alternativa, también puede utilizar Amazon EC2 Image Builder para crear la imagen del contenedor.
• Crear el repositorio Amazon Elastic Container Registry (Amazon ECR) para alojar la imagen del contenedor Windows. Consulte este tutorial paso a paso.

Descripción general de la solución

En este blog, realizaremos las siguientes tareas:

1. Verificar que los nodos Windows estén funcionando.
2. Crear el namespace de Kubernetes Amazon-CloudWatch, donde se ejecutará Fluent Bit.
3. Configurar las políticas de AWS Identity and Access Management (AWS IAM) necesarias para permitir que Fluent Bit envíe los logs a los destinos requeridos.

4. Crear un config map con la configuración necesaria.
5. [Opcional] Crear una imagen de contenedor Windows que contenga IIS y LogMonitor.
6. Implementar FluentBit en el nodo de trabajo Windows como un DaemonSet.
7. Implementar una imagen de Windows en un contenedore que contenga IIS y LogMonitor.
8. [Opcional] Acceder a los pods de IIS para generar los logs.
9. Comprobar los logs en Amazon CloudWatch.
10. Eliminar los recursos creados.

kubectl get nodes -o wide

Puede esperar el siguiente resultado:

NAME                                           STATUS   ROLES    AGE   VERSION                INTERNAL-IP      OS-IMAGE                         KERNEL-VERSION                 CONTAINER-RUNTIME
ip-192-168-24-199.us-west-2.compute.internal   Ready    <none>   13h   v1.23.12-eks-d2d28e7   192.168.24.199   Windows Server 2019 Datacenter   10.0.17763.3532                docker://20.10.17
ip-192-168-47-140.us-west-2.compute.internal   Ready    <none>   13h   v1.23.12-eks-d2d28e7   192.168.47.140   Windows Server 2019 Datacenter   10.0.17763.3532                containerd://1.6.6
ip-192-168-9-130.us-west-2.compute.internal    Ready    <none>   13h   v1.23.9-eks-ba74326    192.168.9.130    Amazon Linux 2                   5.4.209-116.367.amzn2.x86_64   docker://20.10.17

Como puede ver, tenemos dos nodos con Windows Server 2019 basados en la versión 1.23 de Amazon EKS, que utilizan el entorno de ejecución (runtime) docker y containerd respectivamente .

2. Crear el namespace de Kubernetes Amazon-CloudWatch, donde se ejecutará Fluent Bit.

Los namespaces, o espacios de nombres de Kubernetes, proporcionan un medio para organizar las carga de trabajo dentro del clúster. Para consolidar todas las funciones de Fluent Bit, crearemos un namespace llamado amazon-cloudwatch.

2.1 Cree un archivo con el siguiente contenido y asígnele el nombrenamespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: amazon-cloudwatch
  labels:
    name: amazon-cloudwatch

2.2 Ejecute el siguiente comando para crear el namespace:

kubectl apply -f namespace.yaml

3. Configurar las políticas de IAM necesarias para permitir que Fluent Bit envíe los logs a los destinos requeridos

Fluent Bit requiere permisos de IAM específicos para enviar los logs a los destinos en AWS. Los permisos necesarios para un plug-in de salida de Fluent Bit se mencionan en la documentación de Fluent Bit para este tema específico. Por ejemplo, vamos a utilizar Amazon CloudWatch como destino de para los logs. Se aplica el siguiente permiso de IAM:

{
    "Version": "2012-10-17",
    "Statement": [
    {
        "Effect": "Allow",
        "Action": [
            "logs:CreateLogStream",
            "logs:CreateLogGroup",
            "logs:PutLogEvents"
        ],
        "Resource": "*"
    }
    ]
}

También puedes consultar detalles adicionales en la documentación oficial de Fluent Bit.

Siguiendo el principio del menor privilegio, en lugar de crear y distribuir sus credenciales de AWS para los contenedores o utilizar el instance role de Amazon EC2, puede utilizar los roles de IAM para cuentas de servicio, o IAM Roles for Service Accounts (IRSA), y configurar sus pods para que usen la cuenta de servicio de Kubernetes. Para obtener más información, consulte la documentación aquí.

Como alternativa, Fluent Bit puede usar los permisos del rol de IAM adjuntos a la instancia de Amazon EC2. Para obtener más información sobre cómo adjuntar políticas de IAM específicas al crear nodegroups mediante eksctl, consulte la documentación del schema aquí. También puede adjuntar políticas de IAM después de que el nodegroup se haya creado. Consulte la documentación aquí.

3.1 Para configurar los roles de IAM para las cuentas de servicio (es decir, IRSA) en Amazon EKS, necesitamos asociar un proveedor IAM OpenID Connect (OIDC) al clúster de Amazon EKS. Compruebe que su clúster de Amazon EKS tiene un proveedor de IAM OIDC existente mediante la ejecución del siguiente comando:

# Please replace <CLUSTER_NAME> and <REGION> with the actual values 
# before running the command.
aws eks describe-cluster --name <CLUSTER_NAME> --region <REGION> --query "cluster.identity.oidc.issuer" --output text

3.2 Si necesita crear un proveedor IAM OIDC, ejecute el siguiente comando:

# Please replace <CLUSTER_NAME> and <REGION> with the actual values 
# before running the command.
eksctl utils associate-iam-oidc-provider  --region <REGION> --cluster <CLUSTER_NAME> --approve 

3.3 Cree un archivo llamado fluent-bit-policy.json con la política mencionada anteriormente. Ejecute el siguiente comando para crear la política de IAM.

aws iam create-policy --policy-name fluent-bit-policy --policy-document file://fluent-bit-policy.json

3.4 Cree la cuenta de servicio IAM y adjunte la política creada anteriormente.

Ejecute el siguiente comando para crear una cuenta de servicio IAM medianteeksctl:

# Please replace <CLUSTER_NAME>, <REGION>, and 
# <FLUENT_BIT_POLICY_ARN> with the actual values before running the commands.
eksctl create iamserviceaccount --cluster <CLUSTER_NAME> \ 
--region <REGION> \
--attach-policy-arn <FLUENT_BIT_POLICY_ARN> \ 
--name fluent-bit-windows \
--namespace amazon-cloudwatch \
--approve

Para realizar la misma configuración mediante el CLI de AWS, consulte la documentación aquí.

4. Crear un config map con la configuración necesaria

Necesitamos proporcionar algunos detalles a Fluent Bit para su configuración. Esto incluye el nombre y la región del clúster. Podemos hacerlo mediante Config Maps.

4.1 Ejecute el siguiente comando para crear un config map que proporcione las opciones de configuración a Fluent Bit:

# Please replace <CLUSTER_NAME> and <REGION> with the actual values before running the commands.
ClusterName=<CLUSTER_NAME>
RegionName=<REGION>
FluentBitReadFromHead='Off'

kubectl create configmap fluent-bit-cluster-info \
--from-literal=cluster.name=${ClusterName} \
--from-literal=logs.region=${RegionName} \
--from-literal=read.head=${FluentBitReadFromHead} -n amazon-cloudwatch 

De forma predeterminada, Fluent Bit lee los archivos de registro desde la cola y solo captura los registros nuevos después de la implementación. Si desea lo contrario, defina FluentBitReadFromHead=’ON’ y recopilará todos los registros del sistema de archivos.

5. [Opcional] Crear una imagen de contenedor Windows que contenga IIS y LogMonitor

Si ya tienes una imagen de contenedor Windows para tu aplicación, no dudes en saltarte esta sección.

5.1 Para probar la funcionalidad explicada en esta publicación, creamos una imagen de contenedor Windows que contenga IIS y LogMonitor. De forma predeterminada, los contenedores Windows envían logs al Event Tracing de Windows (ETW), al Event Log y a los registros de logs personalizados. Sin embargo, los procesadores de logs como Fluent Bit y fluentd, buscan logs de contenedores en el pipeline STDOUT que no existe en los contenedores Windows. LogMonitor es un plug-in  open source creado por Microsoft para crear un pipeline STDOUT dentro del contenedor Windows, de modo que estas herramientas puedan buscar los logs correctamente tal como lo hacen en un entorno Linux.

Para obtener más instrucciones sobre cómo usar LogMonitor, visita el repositorio oficial de GitHub o la entrada del blog de Microsoft al respecto.

En el siguiente ejemplo tenemos un Dockerfile que crea una imagen de contenedor Windows que contiene IIS y LogMonitor.

FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
 
#Set powershell as default shell
SHELL ["powershell", "-NoLogo", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]
 
#Add X-Forward-For Header to IIS Default website log
RUN Add-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' -filter "system.applicationHost/sites/siteDefaults/logFile/customFields" -name "." "-value @{logFieldName='X-Forwarded-For';sourceName='X-Forwarded-For';sourceType='RequestHeader'}" 
 
#Add STDOUT LogMonitor binary and config in json format
COPY LogMonitor.exe LogMonitorConfig.json 'C:\LogMonitor\'
WORKDIR /LogMonitor
 
ENTRYPOINT ["C:\\LogMonitor\\LogMonitor.exe", "powershell.exe"]
CMD ["C:\\ServiceMonitor.exe w3svc;"]

LogMonitorConfig.json

Este ejemplo de configuración de LogMonitorConfig recupera todos los archivos de log con la extensión.log guardados en C:\inetpub\logs y sus subdirectorios, incluidos los registros de acceso a IIS.

{
  "LogConfig": {
    "sources": [
      {
        "type": "EventLog",
        "startAtOldestRecord": true,
        "eventFormatMultiLine": false,
        "channels": [
          {
            "name": "system",
            "level": "Error"
          }
        ]
      },
      {
        "type": "File",
        "directory": "c:\\inetpub\\logs",
        "filter": "*.log",
        "includeSubdirectories": true
      },
      {
        "type": "ETW",
        "providers": [
          {
            "providerName": "IIS: WWW Server",
            "ProviderGuid": "3A2A4E84-4C21-4981-AE10-3FDA0D9B0F83",
            "level": "Information"
          },
          {
            "providerName": "Microsoft-Windows-IIS-Logging",
            "ProviderGuid": "7E8AD27F-B271-4EA2-A783-A47BDE29143B",
            "level": "Information",
            "keywords": "0xFF"
          }
        ]
      }
    ]
  }
}

Cuando la compilación finalice, suba la imagen a su registro de Amazon ECR.

6. Implementar Fluent Bit en los nodos (worker nodes) Windows como un DaemonSet

Un DaemonSet garantiza que todos (o algunos de) los nodos ejecuten una copia de un pod. A medida que se agregan nodos al clúster, también se les agregan los pods. Para asegurarnos de que todos los nodos Windows tengan una copia del pod de Windows Fluent Bit, implementamos un DaemonSet mediante el archivo de implementación que se especifica en los siguientes pasos.

6.1 Copia el siguiente manifiesto en un archivo llamado fluent-bit-daemon-set.yaml.

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: fluent-bit-windows-role
  namespace: amazon-cloudwatch
rules:
  - nonResourceURLs:
      - /metrics
    verbs:
      - get
  - apiGroups: [""]
    resources:
      - namespaces
      - pods
      - pods/logs
      - nodes
      - nodes/proxy
    verbs: ["get", "list", "watch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: fluent-bit-windows-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: fluent-bit-windows-role
subjects:
# Assuming that the Service Account was created earlier with name fluent-bit-windows.
- kind: ServiceAccount
  name: fluent-bit-windows
  namespace: amazon-cloudwatch
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-windows-config
  namespace: amazon-cloudwatch
  labels:
    k8s-app: fluent-bit-windows
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush                       5
        Log_Level                   info
        Daemon                      off
        net.dns.resolver            LEGACY
        Parsers_File                parsers.conf
        
    @INCLUDE application-log.conf
 
  application-log.conf: |
    [INPUT]
        Name                tail
        Tag                 application.*
        Exclude_Path        C:\\var\\log\\containers\\fluent-bit*
        Path                C:\\var\\log\\containers\\*.log
        Docker_Mode         On
        Docker_Mode_Flush   5
        Docker_Mode_Parser  container_firstline
        Parser              docker
        DB                  C:\\var\\fluent-bit\\state\\flb_container.db
        Read_from_Head      ${READ_FROM_HEAD}
 
    [INPUT]
        Name                tail
        Tag                 application.*
        Path                C:\\var\\log\\containers\\fluent-bit*
        Parser              docker
        DB                  C:\\var\\fluent-bit\\state\\flb_log.db
        Read_from_Head      ${READ_FROM_HEAD}
 
    [FILTER]
        Name                kubernetes
        Match               application.*
        Kube_URL            https://kubernetes.default.svc.cluster.local:443
        Kube_Tag_Prefix     application.C.var.log.container.
        Merge_Log           On
        Merge_Log_Key       log_processed
        K8S-Logging.Parser  On
        K8S-Logging.Exclude Off
        Labels              Off
        Annotations         Off
        Use_Kubelet         Off
        Buffer_Size         0
 
    [OUTPUT]
        Name                cloudwatch_logs
        Match               application.*_default_*
        region              ${AWS_REGION}
        log_group_name      /aws/containerinsights/${CLUSTER_NAME}/default
        log_stream_prefix   ${HOST_NAME}-
        auto_create_group   true
        extra_user_agent    container-insights
 
    [OUTPUT]
        Name                cloudwatch_logs
        Match               application.*_amazon-cloudwatch_*
        region              ${AWS_REGION}
        log_group_name      /aws/containerinsights/${CLUSTER_NAME}/amazon-cloudwatch
        log_stream_prefix   ${HOST_NAME}-
        auto_create_group   true
        extra_user_agent    container-insights
 
  parsers.conf: |
    [PARSER]
        Name                docker
        Format              json
        Time_Key            time
        Time_Format         %Y-%m-%dT%H:%M:%S.%LZ
 
    [PARSER]
        Name                container_firstline
        Format              regex
        Regex               (?<log>(?<="log":")\S(?!\.).*?)(?<!\\)".*(?<stream>(?<="stream":").*?)".*(?<time>\d{4}-\d{1,2}-\d{1,2}T\d{2}:\d{2}:\d{2}\.\w*).*(?=})
        Time_Key            time
        Time_Format         %Y-%m-%dT%H:%M:%S.%LZ
 
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-windows
  namespace: amazon-cloudwatch
  labels:
    k8s-app: fluent-bit-windows
    version: v1
    kubernetes.io/cluster-service: "true"
spec:
  selector:
    matchLabels:
      k8s-app: fluent-bit-windows
  template:
    metadata:
      labels:
        k8s-app: fluent-bit-windows
        version: v1
        kubernetes.io/cluster-service: "true"
    spec:
      containers:
      - name: fluent-bit-windows
        image: public.ecr.aws/aws-observability/aws-for-fluent-bit:windowsservercore-latest
        imagePullPolicy: Always
        env:
          - name: AWS_REGION
            valueFrom:
              configMapKeyRef:
                name: fluent-bit-cluster-info
                key: logs.region
          - name: CLUSTER_NAME
            valueFrom:
              configMapKeyRef:
                name: fluent-bit-cluster-info
                key: cluster.name
          - name: HOST_NAME
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
          - name: READ_FROM_HEAD
            valueFrom:
              configMapKeyRef:
                name: fluent-bit-cluster-info
                key: read.head
        resources:
          limits:
            memory: 600Mi
          requests:
            cpu: 500m
            memory: 600Mi
        volumeMounts:
        # Only read only access to the following mounts is required
        - name: fluentbitstate
          mountPath: C:\var\fluent-bit\state
        - name: varlog
          mountPath: C:\var\log
          readOnly: true
        - name: varlibdockercontainers
          mountPath: C:\ProgramData\docker\containers
          readOnly: true
        - name: fluent-bit-config
          mountPath: C:\fluent-bit\etc\
          readOnly: true          
      terminationGracePeriodSeconds: 30
      volumes:
      - name: fluentbitstate
        hostPath:
          path: C:\var
      - name: varlog
        hostPath:
          path: C:\var\log
      - name: varlibdockercontainers
        hostPath:
          path: C:\ProgramData\docker\containers
      - name: fluent-bit-config
        configMap:
          name: fluent-bit-windows-config
      nodeSelector:
        kubernetes.io/os: windows          
      serviceAccountName: fluent-bit-windows

Según la configuración anterior, el Fluent Bit debería:

• Utilizar el plugin tail output para buscar nuevas entradas en los logs que se adjunten a los archivos de logs específicos del contenedor, gestionados por el motor de ejecución del contenedor.
• Utilizar el Kubernetes Fluent Bit filter para añadir metadatos adicionales a cada entrada del log. Esto se hace consultando el servidor Kube-API.
• Utilizar el grupo de logs de Amazon CloudWatch, que contiene default al final del nombre, para enviar los logs de las aplicaciones de los pods que se ejecutan en el namespace default de Kubernetes.
• Utilizar el grupo de logs de Amazon CloudWatch, que contiene amazon-cloudwatch al final del nombre, para enviar los logs generados por los pods de Fluent Bit que se ejecutan en el namespace amazon-cloudwatch de Kubernetes.

La etiqueta o tag en cada entrada de registro tiene el formato application.C.var.log.container.<POD_NAME>_<NAMESPACE_NAME>_<CONTAINER_NAME>-<DOCKER_ID>.  En el ejemplo de configuración de Fluent Bit anterior, enrutamos los logs en función de namspaces utilizando regex en la configuración de Match para los plug-ins de salida. Para obtener más información sobre cómo se puede configurar Fluent Bit para usar Tag y Match, consulte la documentación aquí.

También puede consultar nuestra documentación aquí para obtener instrucciones sobre cómo personalizar su Log Group o Stream  de Amazon CloudWatch con metadatos de Kubernetes.

Nota: En esta publicación, configuramos el filtro de Kubernetes para usar el servidor de Kube-API en lugar del endpoint kubelet para consultar metadatos adicionales. Esto se debe a que kubelet en Windows se ejecuta en el host network namespace, mientras que Fluent Bit se ejecuta en la red de contenedores. Podemos utilizar el endpoint o punto de acceso al kubelet si los pods de Fluent Bit se lanzan como pods de tipoHostProcess.

6.2 Implemente este manifiesto mediante el siguiente comando:

kubectl apply -f fluent-bit-daemon-set.yaml

7. Implementar una imagen de Windows en un contenedore que contenga IIS y LogMonitor

En este paso, implementaremos los pods Windows en los nodos Windows.

7.1 Cree un archivo de despliegue denominado windows_manifest.yaml con el siguiente contenido:

# Please replace <IIS_CONTAINER_IMAGE> with the image created in step 5.1
---
apiVersion: v1
kind: Service
metadata:
  name: winiis
  labels:
    run: winiis
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    run: winiis
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: winiis
  name: winiis
  namespace: default
spec:
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      run: winiis
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        run: winiis
    spec:
      containers:
      - image: <IIS_CONTAINER_IMAGE>
        imagePullPolicy: IfNotPresent
        name: winiis
      dnsPolicy: ClusterFirst
      nodeSelector:
        kubernetes.io/os: windows
      restartPolicy: Always
      terminationGracePeriodSeconds: 30

7.2 Implemente el manifiesto mediante el siguiente comando:

kubectl apply -f windows_manifest.yaml

8. [Opcional] Acceder a los pods de IIS para generar registros

Este es un paso opcional. Puede esperar que el tráfico real llegue al pod Windows que aloja el servidor web con IIS (Internet Information Services). Como alternativa, puedes entrar en tu contenedor y forzar los logs.

8.1 Ejecute el siguiente comando para iniciar sesión en su contenedor:

kubectl -it exec <your_winiis_pod_name> powershell

8.2 Desde el contenedor, ejecute el siguiente comando para acceder al servidor web:

Invoke-WebRequest winiis -UseBasicParsing

9. Comprobar los logs en Amazon CloudWatch

En este paso, iniciamos sesión en la consola de Amazon CloudWatch y observamos los logs que se generaron. Puede acceder a la consola de Amazon CloudWatch a través del enlace que aparece aquí. Acceda a la consola de Log Group desde el panel lateral a través de Logs/Log Groups .

Puede esperar log groups con el nombre:

• /aws/containerinsights/<CLUSTER_NAME>/default
• /aws/containerinsights/<CLUSTER_NAME>/amazon-cloudwatch

Cada log group debe contener los logs de los pods implementados en los respectivos namespaces de Kubernetes.

Limpieza

Cuando termines el tutorial de esta publicación, borra los recursos asociados a él para evitar cargos por las funciones que no utilices:

• Eliminar la implementación de Windows

kubectl delete -f windows_manifest.yaml

• Eliminar el FluentBit DaemonSet

kubectl delete -f fluent-bit-daemon-set.yaml

• Eliminar los log groups creados por Fluent Bit

aws logs delete-log-group —log-group-name /aws/containerinsights/<CLUSTER_NAME>/default
aws logs delete-log-group --log-group-name /aws/containerinsights/<CLUSTER_NAME>/amazon-cloudwatch

Conclusión

En esta publicación, le mostramos cómo implementar Fluent Bit como DaemonSet en los nodos Windows de Amazon EKS.

El uso de FluentBit como enrutador de logs es una forma efectiva de centralizar los logs en las cargas de trabajo de Amazon EKS para Linux y Windows. Fluent Bit puede enviar los logs a varias soluciones de destino, lo que proporciona flexibilidad a los clientes.

Este artículo fue traducido del Blog da AWS em Inglés.

Acerca de los autores

Harsh Rawat es ingeniero de software en Amazon Web Services.

Marcio Morales es Principal Solutions Architect en Amazon Web Services. Marcio es SME global en contenedores Windows y ayuda a los clientes de AWS a diseñar, crear, proteger y optimizar  cargas de trabajo basadas en contenedores Windows en AWS.

Revisor

Borja Prado es Senior Solutions Architect en AWS, especializado en tecnologías Microsoft. Trabaja ayudando a nuestros clientes en la migración, despliegue y modernización de cargas de trabajo Windows en AWS. Además, está especializado en el diseño y arquitectura de soluciones escalables con .NET y es SME en Sitecore.