Log centralizado para Windows Containers no Amazon EKS usando o FluentBit

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

Introdução

Em novembro de 2022, a Amazon Web Services (AWS) anunciou o suporte para imagens de container Fluent Bit para o sistema operacional Windows. Esse suporte elimina a necessidade de clientes que utilizam Windows implementarem qualquer solução de logs personalizada no código da aplicação ou gerenciarem agentes personalizados em seus nós do Windows para extrair logs. Para obter mais detalhes sobre as versões suportadas do Windows e as tags de imagem do Fluent Bit, visite nossa documentação aqui.

O Fluent Bit é um processador e roteador de logs rápido e flexível, suportado por vários sistemas operacionais. Ele é usado para rotear logs para vários destinos na AWS, como Amazon CloudWatch, destinos no Amazon Kinesis Data Firehose, Amazon Simple Storage Service (Amazon S3) e Amazon OpenSearch. Além dos destinos na AWS, o Fluent Bit oferece suporte a soluções comuns de parceiros, como Datadog, Splunk, servidores HTTP personalizados e muito mais. Para obter mais detalhes sobre  roteamento de logs de containeres, visite o link do blog aqui. A AWS já oferece suporte às imagens de container Fluent Bit com base em sistema operacional Linux e essa versão permite que os clientes tenham um mecanismo centralizado para processar e rotear seus logs no Amazon Elastic Container Service (Amazon ECS) e no Amazon Elastic Kubernetes Service (Amazon EKS) para cargas de trabalho Linux e Windows.

Neste post, abordamos como os clientes do Amazon EKS podem implementar imagens do Fluent Bit Windows como um DaemonSet em seus nós Windows, afim de transmitir os logs do Internet Information Services (IIS) gerados nos pods Windows para os logs do Amazon CloudWatch, como forma de centralizar o registro. Vamos configurar o Fluent Bit para rotear todos os logs gerados por pods em diferentes namespaces para os respectivos CloudWatch Logs Groups. Além disso, cada entrada de log seria enriquecida com metadados adicionais do Kubernetes, como namespace, nome do pod, nome do container, nome da imagem, nome do host etc. Para obter mais detalhes sobre a implementação do Fluent Bit no cluster Windows do Amazon ECS, visite nossa postagem no blog aqui.

Pré-requisitos

Pré-requisitos e premissas:

• Cluster Amazon EKS (1.20 ou mais recente) instalado e funcionando. Veja este guia passo a passo.
• Iniciar os Windows worker nodes do Amazon EKS. Veja este guia passo a passo.
• Instalação e configuração apropriada da Amazon Command Line Interface (AWS CLI), eksctl e kubectl.
• Para criar uma imagem de container do Windows, iniciar uma instância Windows no Amazon Elastic Compute Cloud (Amazon EC2) com o Docker instalado, que é baseado na mesma versão Windows dos worker nodes do Amazon EKS. Como alternativa, você também pode usar o Amazon EC2 Image Builder para criar sua imagem de container.
• Criar o repositório Amazon Elastic Container Registry (Amazon ECR) para hospedar a imagem do Windows Container. Veja este tutorial passo a passo.

Visão geral da solução

Neste blogpost, executaremos as seguintes tarefas:

1. Validar se os Windows worker nodes estão em funcionamento.
2. Criar o namespace Kubernetes amazon-cloudwatch no qual o Fluent Bit será executado.
3. Configurar as políticas do AWS Identity and Access Management (AWS IAM) adequadas para permitir que o Fluent Bit envie os logs para os destinos necessários.
4. Criar um config map com a configuração necessária.
5. [Opcional] Criar uma imagem de Windows Container contendo IIS e LogMonitor.
6. Implementar o FluentBit no Windows worker node como um DaemonSet.
7. Implementar a imagem de Windows Container contendo IIS e LogMonitor.
8. [Opcional] Acessar os pods do IIS para gerar logs.
9. Verificar logs no Amazon CloudWatch.
10. Limpar os recursos criados.

Arquitetura de configuração usada neste blogpost

Passo a passo

1. Valide se os Windows worker nodes estão funcionando

Para acompanhar este tutorial, você deve ter um cluster Amazon EKS existente com Windows Nodes em execução. Para criar o mesmo, siga nosso guia aqui.

• Para verificar se os Windows worker nodes estão prontos, execute o seguinte comando.

kubectl get nodes -o wide

Você pode esperar o seguinte 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 você pode ver, temos dois nós Windows Server 2019 baseados no Amazon EKS versão 1.23, que estão usando docker e containerd runtime, respectivamente.

2. Crie o namespace Kubernetes amazon-cloudwatch para Fluent Bit

Os namespaces Kubernetes fornecem um escopo para nomes e organizam sua carga de trabalho dentro do cluster. Para consolidar todos os recursos do Fluent Bit, criaremos um namespace chamadoamazon-cloudwatch.

2.1 Crie um arquivo com o seguinte conteúdo e nomeie como namespace.yaml:namespace.yaml:

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

2.2 Execute o seguinte comando para criar o namespace:

kubectl apply -f namespace.yaml

3. Configure as políticas do IAM necessárias para permitir que o Fluent Bit envie os logs para os destinos necessários

O Fluent Bit exige permissões específicas do IAM para enviar os logs aos destinos na AWS. As permissões necessárias para um plug-in de saída do Fluent Bit são mencionadas na documentação do mesmo. Por exemplo, usamos o Amazon CloudWatch como destino dos logs. A seguinte permissão do IAM se aplica:

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

Você também pode verificar detalhes adicionais na documentação oficial do Fluent Bit.

Seguindo o princípio do menor privilégio, em vez de criar e distribuir suas credenciais AWS para os containeres ou usar a instance role do Amazon EC2, você pode usar o IAM Roles for Service Accounts (IRSA) e configurar seus pods para usar a conta de serviço Kubernetes. Para obter mais detalhes, consulte a documentação aqui.

Como alternativa, o Fluent Bit pode usar as permissões da IAM Role anexada à instância do Amazon EC2. Para obter mais detalhes sobre como anexar políticas específicas do IAM ao criar nodegroups usando eksctl, visite a documentação de schema aqui. Você também pode anexar as políticas do IAM depois que o nodegroup for criado. Consulte a documentação aqui.

3.1 Para configurar IAM Roles para contas de serviço (ou seja, IRSA) no Amazon EKS, precisamos associar um provedor IAM OpenID Connect (OIDC) ao cluster Amazon EKS. Verifique se seu cluster Amazon EKS tem um provedor IAM OIDC existente, executando o seguinte 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 Se você precisar criar um provedor IAM OIDC, execute o seguinte 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 Crie um arquivo chamado fluent-bit-policy.json com a política mencionada acima. Execute o comando a seguir para criar a política do IAM.

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

3.4 Crie a conta de serviço do IAM e anexe a política criada anteriormente.

Execute o comando a seguir para criar uma conta de serviço do IAM usandoeksctl:

# 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 executar a mesma configuração usando a AWS CLI, consulte a documentação aqui.

4. Crie um config map com a configuração necessária

Precisamos fornecer alguns detalhes ao Fluent Bit para configurá-lo. Isso inclui o nome e a região do cluster. Podemos fazer isso usando Config Maps.

4.1 Execute o seguinte comando para criar um config map, afim de fornecer opções de configuração para o 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 

Por padrão, o Fluent Bit lê arquivos de log a partir da ponta (tail) e captura somente novos logs após sua implantação. Se você quiser o contrário, defina FluentBitReadFromHead='On' e ele coletará todos os logs no sistema de arquivos.

5. [Opcional] Crie uma imagem de container do Windows contendo IIS e LogMonitor

Se você já tem uma imagem de container do Windows para sua aplicação, sinta-se à vontade para pular esta seção.

5.1 Para testar a funcionalidade explicada nesta postagem, criamos uma imagem de container Windows contendo IIS e LogMonitor. Por padrão, os Windows Containers enviam logs para o Event Tracing for Windows (ETW), Event Log e arquivos de logs personalizados. No entanto, processadores de log, como Fluent Bit e fluentd, buscam logs de containers de um pipeline STDOUT que não existe em Windows Containers. O LogMonitor é um plug-in de código aberto criado pela Microsoft para criar um pipeline STDOUT dentro do Windows Container, para que essas ferramentas possam buscar logs com sucesso da mesma forma que fazem em um ambiente Linux.

Para obter mais instruções sobre como usar o LogMonitor, acesse o repositório oficial do GitHub ou a postagem no blog da Microsoft sobre o mesmo.

No exemplo abaixo, temos um Dockerfile que cria uma imagem de Windows Container contendo IIS e 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

Esse exemplo de configuração do LogMonitorConfig recupera todos os arquivos de log com a extensão .log salvos em C:\inetpub\logs e subdiretórios, incluindo os logs de acesso do 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"
          }
        ]
      }
    ]
  }
}

Quando a compilação for concluída, envie a imagem para seu Amazon ECR registry.

6. Implemente o Fluent Bit nos Windows Worker Nodes como um DaemonSet

Um DaemonSet garante que todos (ou alguns) nós executem uma cópia de um pod. À medida que os nós são adicionados ao cluster, os pods também são adicionados a eles. Para garantir que todos os Windows worker nodes tenham uma cópia do pod  Windows Fluent Bit, implantamos um DaemonSet usando o arquivo de implementação especificado nas etapas a seguir.

6.1 Copie o seguinte manifesto em um arquivo chamadofluent-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

Com base na configuração acima, o Fluent Bit deveria:

• Usar o plugin tail output para encontrar novas entradas de logs que são anexadas aos arquivos de log específicos do container, mantidos pelo tempo de execução do container.
• Usar o filtro Kubernetes Fluent Bit para acrescentar metadados adicionais a cada entrada de log. Isso é feito consultando o servidor Kube-API.
• Usar o  Amazon CloudWatch Logs Group que que tem ao final do nome default para enviar logs de aplicações de pods em execução no namespace default do Kubernetes.
• Usar o  Amazon CloudWatch Logs Group que tem ao final do nome amazon-cloudwatch para enviar logs gerados por pods do Fluent Bit executados no namespace Kubernetes amazon-cloudwatch.

A tag com cada entrada de registro tem o formato application.C.var.log.container.<POD_NAME>_<NAMESPACE_NAME>_<CONTAINER_NAME>-<DOCKER_ID>. No exemplo de configuração do Fluent Bit acima, roteamos os logs com base em namespaces usando o regex nas configurações do Match para plug-ins de saída. Para obter mais detalhes sobre como o Fluent Bit pode ser configurado para usar Tag e Match, visite a documentação aqui.

Você também pode visitar nossa documentação aqui para obter instruções sobre como personalizar seu logs group ou stream do Amazon CloudWatch com metadados do Kubernetes.

Observação: nesta postagem, configuramos o filtro Kubernetes para usar o Kube API Server em vez do endpoint kubelet para consultar os metadados adicionais. Isso ocorre porque o kubelet no Windows é executado no host network namespace, enquanto o Fluent Bit é executado na rede de containers. Podemos usar o endpoint kubelet se os pods do Fluent Bit forem lançados como pods do tipo HostProcess.

6.2 Implemente esse manifesto usando o seguinte comando:

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

7. Implemente uma imagem de container Windows contendo IIS e LogMonitor

Nesta etapa, implantaremos os pods Windows nos Windows worker nodes.

7.1 Crie um arquivo de implantação chamado windows_manifest.yaml com o seguinte conteúdo:

# 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 Implante o manifesto usando o seguinte comando:

kubectl apply -f windows_manifest.yaml

8. [Opcional] Acesse os pods de IIS para gerar logs

Essa é uma etapa opcional. Você pode esperar que o tráfego real chegue ao pod Windows que hospeda o servidor web IIS. Como alternativa, você pode entrar em seu container e forçar os logs.

8.1 Execute o seguinte comando para fazer login em seu container:

kubectl -it exec <your_winiis_pod_name> powershell

8.2 De dentro do container, execute o seguinte comando para acessar o servidor web:

Invoke-WebRequest winiis -UseBasicParsing

9. Verificando logs no Amazon CloudWatch

Nesta etapa, fazemos login no console do Amazon CloudWatch e observamos os logs que foram gerados. O console do Amazon CloudWatch pode ser acessado por meio do link aqui. Acesse o console Log Group a partir do painel lateral por meio de Logs/Log Groups.

Você pode esperar logs groups com o nome:

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

Cada logs group deveria conter logs dos pods implantados nos respectivos namespaces do Kubernetes.

Limpando

Ao terminar o tutorial desta postagem, limpe os recursos associados a ele para evitar cobranças por recursos que você não está usando:

• Exclua a implantação Windows

kubectl delete -f windows_manifest.yaml

• Exclua o FluentBitDaemonSet

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

• Exclua os logs groups criados pelo 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

Conclusão

Neste post, mostramos como implementar o Fluent Bit como um DaemonSet nos Windows worker nodes no Amazon EKS.

Usar o FluentBit como um roteador de logs é uma forma benéfica de centralizar os logs no Amazon EKS para cargas de trabalho Linux e Windows. O Fluent Bit pode enviar os logs para várias soluções de destino, permitindo flexibilidade para os clientes.

Este artigo foi traduzido do Blog da AWS em Inglês.

Sobre os autores

Harsh Rawat é um Software Engineer na Amazon Web Services.

Marcio Morales é Principal Solutions Architect da Amazon Web Services. Marcio é um SME global para Windows Containers e ajuda os clientes da AWS a projetar, criar, proteger e otimizar cargas de trabalho de Windows Containers na AWS.

Revisor

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 14 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.

Luciano Bernardes