**Ajudar a melhorar esta página** 

Para contribuir com este guia de usuário, escolha o link **Editar esta página no GitHub**, disponível no painel direito de cada página.

# Inicie o log no AWS Fargate para o seu cluster
<a name="fargate-logging"></a>

O Amazon EKS no Fargate oferece um roteador de log integrado baseado no Fluent Bit. Isso significa que você não executa explicitamente um contêiner do Fluent Bit como um sidecar, mas a Amazon o executa para você. Tudo o que você precisa fazer é configurar o roteador de log. A configuração acontece por meio de um `ConfigMap` que deve atender aos seguintes critérios:
+ Nomeado `aws-logging` 
+ Criado em um namespace dedicado chamado `aws-observability` 
+ Não pode exceder 5.300 caracteres.

Depois de criar o `ConfigMap`, o Amazon EKS no Fargate o detecta automaticamente e configura o roteador de log com ele. O Fargate usa uma versão do AWS para Fluent Bit, uma distribuição do Fluent Bit a montante, compatível e gerenciada pela AWS. Para obter mais informações, consulte [AWS for Fluent Bit](https://github.com/aws/aws-for-fluent-bit) no GitHub.

O roteador de log permite que você use toda a variedade de serviços da AWS para analytics de log e armazenamento. Você pode transmitir logs do Fargate diretamente para o Amazon CloudWatch, Amazon OpenSearch Service. Você também pode transmitir logs para destinos como [Amazon S3](https://aws.amazon.com/s3/), [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) e ferramentas de parceiros por meio do [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/).
+ Um perfil existente do Fargate que especifica um namespace existente do Kubernetes em que você implanta pods do Fargate. Para obter mais informações, consulte [Etapa 3: criar um perfil do Fargate para o cluster](fargate-getting-started.md#fargate-gs-create-profile).
+ Um perfil de execução existente de pod do Fargate. Para obter mais informações, consulte [Etapa 2: criar um perfil de execução de pods do Fargate](fargate-getting-started.md#fargate-sg-pod-execution-role).

## Configuração do roteador de log
<a name="fargate-logging-log-router-configuration"></a>

**Importante**  
Para que os logs sejam publicados com êxito, é necessário haver acesso de rede da VPC em que seu cluster está localizado até o destino do log. Isso diz respeito principalmente aos usuários que personalizam as regras de saída para suas VPCs. Para obter um exemplo de uso do CloudWatch, consulte [Usar o CloudWatch Logs com endpoints da VPC de interface](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html) no *Guia do usuário do Amazon CloudWatch Logs*.

Nas etapas a seguir, substitua cada *valor de exemplo* por seus próprios valores.

1. Crie um namespace dedicado do Kubernetes chamado `aws-observability`.

   1. Salve o seguinte conteúdo no seu computador, em um arquivo chamado `aws-observability-namespace.yaml`: O valor para `name` deve ser `aws-observability` e o rótulo `aws-observability: enabled` é obrigatório.

      ```
      kind: Namespace
      apiVersion: v1
      metadata:
        name: aws-observability
        labels:
          aws-observability: enabled
      ```

   1. Crie o novo namespace.

      ```
      kubectl apply -f aws-observability-namespace.yaml
      ```

1. Crie um `ConfigMap` com um valor de dados do `Fluent Conf` para enviar logs de contêiner a um destino. Fluent Conf é o Fluent Bit, uma linguagem de configuração de processador de logs rápida e leve usada para encaminhar logs de contêiner para um destino de sua escolha. Para obter mais informações, consulte [Configuration File](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/classic-mode/configuration-file) (Arquivo de configuração) na documentação do Fluent Bit.
**Importante**  
As principais seções incluídas em um `Fluent Conf` típico são `Service`, `Input`, `Filter` e `Output`. No entanto, o roteador de log do Fargate só aceita:  
As seções `Filter` e `Output`.
Uma seção `Parser`.
Se você fornecer outras seções, elas serão rejeitadas.

   O roteador de log do Fargate gerencia as seções `Input` e `Service`. Ele tem a seção `Input` a seguir, que não pode ser modificada e não é necessária no `ConfigMap`. Porém, ela pode oferecer informações, como o limite do buffer de memória e a tag aplicada aos logs.

   ```
   [INPUT]
       Name tail
       Buffer_Max_Size 66KB
       DB /var/log/flb_kube.db
       Mem_Buf_Limit 45MB
       Path /var/log/containers/*.log
       Read_From_Head On
       Refresh_Interval 10
       Rotate_Wait 30
       Skip_Long_Lines On
       Tag kube.*
   ```

   Ao criar o `ConfigMap`, leve em consideração as seguintes regras que o Fargate usa para validar os campos:
   +  `[FILTER]`,`[OUTPUT]`, e `[PARSER]` devem ser especificados sob cada chave correspondente. Por exemplo, o `[FILTER]` deve estar em `filters.conf`. Você pode ter um ou mais `[FILTER]`s em `filters.conf`. As seções `[OUTPUT]` e `[PARSER]` também devem estar sob suas chaves correspondentes. Ao especificar várias seções `[OUTPUT]`, você pode rotear os logs para destinos diferentes ao mesmo tempo.
   + O Fargate valida as chaves necessárias para cada seção. `Name` e `match` são necessários para cada `[FILTER]` e `[OUTPUT]`. `Name` e `format` são necessários para cada `[PARSER]`. As chaves não diferenciam maiúsculas de minúsculas.
   + Variáveis de ambiente como `${ENV_VAR}` não são permitidas no `ConfigMap`.
   + O recuo tem que ser o mesmo para o par de diretivas ou chave-valor dentro de cada `filters.conf`, `output.conf` e `parsers.conf`. Pares chave-valor têm que ser recuados mais do que as diretivas.
   + O Fargate valida de acordo com os seguintes filtros compatíveis: `grep`, `parser`, `record_modifier`, `rewrite_tag`, `throttle`, `nest`, `modify` e `kubernetes`.
   + O Fargate valida de acordo com os seguintes filtros compatíveis: `es`, `firehose`, `kinesis_firehose`, `cloudwatch`, `cloudwatch_logs` e `kinesis`.
   + É necessário fornecer ao menos um plug-in `Output` com suporte no `ConfigMap` para habilitar o registro em log. `Filter` e `Parser` não são necessários para habilitar o registro em log.

     Você também pode executar o Fluent Bit no Amazon EC2 usando a configuração desejada para solucionar quaisquer problemas decorrentes da validação. Crie o `ConfigMap` usando um dos exemplos a seguir.
**Importante**  
O registro em log do Fargate no Amazon EKS não oferece suporte para a configuração dinâmica de `ConfigMap`. Quaisquer alterações em um `ConfigMap` são aplicadas somente aos novos pods. As alterações não são aplicadas a pods existentes.

     Crie um `ConfigMap` usando o exemplo para o destino de log desejado.
**nota**  
Você também pode usar o Amazon Kinesis Data Streams para seu destino de log. Se você usar o Kinesis Data Streams, verifique se a função de execução do pod recebeu a permissão `kinesis:PutRecords`. Para obter mais informações, consulte as [Permissões](https://docs.fluentbit.io/manual/pipeline/outputs/kinesis#permissions) do Amazon Kinesis Data Streams no *Fluent Bit: manual oficial*.  
**Example**  

------
#### [ CloudWatch ]

   Você tem duas opções de saída ao usar o CloudWatch:
   +  [Um plugin de saída criado em C](https://docs.fluentbit.io/manual/v/1.5/pipeline/outputs/cloudwatch) 
   +  [Um plugin de saída criado em Golang](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) 

   O exemplo a seguir mostra como usar o plug-in `cloudwatch_logs` para enviar logs para o CloudWatch.

   1. Salve o conteúdo a seguir em um arquivo denominado `aws-logging-cloudwatch-configmap.yaml`. Substitua *region-code* pela região da AWS em que o cluster se encontra. Os parâmetros em `[OUTPUT]` são necessários.

      ```
      kind: ConfigMap
      apiVersion: v1
      metadata:
        name: aws-logging
        namespace: aws-observability
      data:
        flb_log_cw: "false"  # Set to true to ship Fluent Bit process logs to CloudWatch.
        filters.conf: |
          [FILTER]
              Name parser
              Match *
              Key_name log
              Parser crio
          [FILTER]
              Name kubernetes
              Match kube.*
              Merge_Log On
              Keep_Log Off
              Buffer_Size 0
              Kube_Meta_Cache_TTL 300s
        output.conf: |
          [OUTPUT]
              Name cloudwatch_logs
              Match   kube.*
              region region-code
              log_group_name my-logs
              log_stream_prefix from-fluent-bit-
              log_retention_days 60
              auto_create_group true
        parsers.conf: |
          [PARSER]
              Name crio
              Format Regex
              Regex ^(?<time>[^ ]+) (?<stream>stdout|stderr) (?<logtag>P|F) (?<log>.*)$
              Time_Key    time
              Time_Format %Y-%m-%dT%H:%M:%S.%L%z
      ```

   1. Aplique o manifesto ao cluster.

      ```
      kubectl apply -f aws-logging-cloudwatch-configmap.yaml
      ```

------
#### [ Amazon OpenSearch Service ]

   Se quiser enviar logs para o Amazon OpenSearch Service, é possível usar a saída [es](https://docs.fluentbit.io/manual/v/1.5/pipeline/outputs/elasticsearch), que é um plug-in escrito em C. O exemplo a seguir mostra como usar o plug-in para enviar logs para o OpenSearch.

   1. Salve o conteúdo a seguir em um arquivo denominado `aws-logging-opensearch-configmap.yaml`. Substitua cada *valor de exemplo* por seus próprios valores.

      ```
      kind: ConfigMap
      apiVersion: v1
      metadata:
        name: aws-logging
        namespace: aws-observability
      data:
        output.conf: |
          [OUTPUT]
            Name  es
            Match *
            Host  search-example-gjxdcilagiprbglqn42jsty66y.region-code.es.amazonaws.com
            Port  443
            Index example
            Type  example_type
            AWS_Auth On
            AWS_Region region-code
            tls   On
      ```

   1. Aplique o manifesto ao cluster.

      ```
      kubectl apply -f aws-logging-opensearch-configmap.yaml
      ```

------
#### [ Firehose ]

   Você tem duas opções de saída ao enviar logs para o Firehose:
   +  [kinesis\$1firehose](https://docs.fluentbit.io/manual/pipeline/outputs/firehose): um plug-in de saída escrito em C.
   +  [firehose](https://github.com/aws/amazon-kinesis-firehose-for-fluent-bit) - Um plug-in de saída escrito em Golang.

     O exemplo a seguir mostra como usar o plug-in `kinesis_firehose` para enviar logs para o Firehose.

     1. Salve o conteúdo a seguir em um arquivo denominado `aws-logging-firehose-configmap.yaml`. Substitua *region-code* pela região da AWS em que o cluster se encontra.

        ```
        kind: ConfigMap
        apiVersion: v1
        metadata:
          name: aws-logging
          namespace: aws-observability
        data:
          output.conf: |
            [OUTPUT]
             Name  kinesis_firehose
             Match *
             region region-code
             delivery_stream my-stream-firehose
        ```

     1. Aplique o manifesto ao cluster.

        ```
        kubectl apply -f aws-logging-firehose-configmap.yaml
        ```

------

1. Configure as permissões para o perfil de execução do pod do Fargate para enviar logs ao seu destino.

   1. Baixe a política do IAM do seu destino para o computador.  
**Example**  

------
#### [ CloudWatch ]

      Baixe a política de IAM do CloudWatch no computador. Você também pode [visualizar a política](https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/cloudwatchlogs/permissions.json) no GitHub.

      ```
      curl -O https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/cloudwatchlogs/permissions.json
      ```

------
#### [ Amazon OpenSearch Service ]

      Baixe a política do IAM OpenSearch para o seu computador. Você também pode [visualizar a política](https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/amazon-elasticsearch/permissions.json) no GitHub.

      ```
      curl -O https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/amazon-elasticsearch/permissions.json
      ```

      Verifique se o controle de acesso do OpenSearch Dashboards está configurado corretamente. O `all_access role` no OpenSearch Dashboards precisa que o perfil de execução de pods do Fargate e o perfil do IAM sejam mapeados. O mesmo mapeamento deve ser feito para a função `security_manager`. Você pode adicionar os mapeamentos anteriores selecionando `Menu`, depois `Security`, depois `Roles` e, em seguida, selecionar as respectivas funções. Para obter mais informações, consulte [How do I troubleshoot CloudWatch Logs so that it streams to my Amazon ES domain?](https://aws.amazon.com/tr/premiumsupport/knowledge-center/es-troubleshoot-cloudwatch-logs/) (Como solucionar problemas do CloudWatch Logs para que ele transmita para o meu domínio do Amazon ES?).

------
#### [ Firehose ]

      Baixe a política do IAM do Firehose para o seu computador. Você também pode [visualizar a política](https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/kinesis-firehose/permissions.json) no GitHub.

      ```
      curl -O https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/kinesis-firehose/permissions.json
      ```

------

   1. Crie uma política do IAM com base no arquivo de política que você baixou.

      ```
      aws iam create-policy --policy-name eks-fargate-logging-policy --policy-document file://permissions.json
      ```

   1. Anexe a política do IAM à função de execução de pod especificada para o seu perfil do Fargate com o comando a seguir. Substitua *111122223333* pelo ID da sua conta. Substitua *AmazonEKSFargatePodExecutionRole* pelo perfil de execução de pods (para obter mais informações, consulte [Etapa 2: criar um perfil de execução de pods do Fargate](fargate-getting-started.md#fargate-sg-pod-execution-role)).

      ```
      aws iam attach-role-policy \
        --policy-arn arn:aws:iam::111122223333:policy/eks-fargate-logging-policy \
        --role-name AmazonEKSFargatePodExecutionRole
      ```

### Suporte ao filtro Kubernetes
<a name="fargate-logging-kubernetes-filter"></a>

O filtro Kubernetes Fluent Bit permite adicionar metadados do Kubernetes aos arquivos de log. Para mais informações sobre o filtro, consulte [Kubernetes](https://docs.fluentbit.io/manual/pipeline/filters/kubernetes) na documentação do Fluent Bit. É possível aplicar um filtro usando o endpoint do servidor da API.

```
filters.conf: |
    [FILTER]
        Name             kubernetes
        Match            kube.*
        Merge_Log           On
        Buffer_Size         0
        Kube_Meta_Cache_TTL 300s
```

**Importante**  
 `Kube_URL`, `Kube_CA_File`, `Kube_Token_Command` e `Kube_Token_File` são parâmetros de configuração de propriedade do serviço e não devem ser especificados. O Amazon EKS Fargate preenche esses valores.
 `Kube_Meta_Cache_TTL` é o tempo em que o Fluent Bit aguarda até se comunicar com o servidor de API para obter os metadados mais recentes. Se `Kube_Meta_Cache_TTL` não for especificado, o Amazon EKS Fargate acrescentará um valor padrão de 30 minutos para diminuir a carga no servidor de API.

### Para enviar logs de processo do Fluent Bit para sua conta
<a name="ship-fluent-bit-process-logs"></a>

Opcionalmente, você pode enviar logs de processo do Fluent Bit para o Amazon CloudWatch usando o `ConfigMap` a seguir. O envio de logs do processo Fluent Bit para o CloudWatch exige custos adicionais de ingestão e armazenamento de logs. Substitua *region-code* pela região da AWS em que seu cluster se encontra.

```
kind: ConfigMap
apiVersion: v1
metadata:
  name: aws-logging
  namespace: aws-observability
  labels:
data:
  # Configuration files: server, input, filters and output
  # ======================================================
  flb_log_cw: "true"  # Ships Fluent Bit process logs to CloudWatch.

  output.conf: |
    [OUTPUT]
        Name cloudwatch
        Match kube.*
        region region-code
        log_group_name fluent-bit-cloudwatch
        log_stream_prefix from-fluent-bit-
        auto_create_group true
```

Os logs estão no CloudWatch, na mesma região da AWS que o cluster. O nome do grupo de logs é ` my-cluster-fluent-bit-logs`, e o nome do fluxo de logs do Fluent Bit é `fluent-bit-podname-pod-namespace `.

**nota**  
Os logs de processo são enviados somente quando o processo do Fluent Bit é iniciado corretamente. Caso haja uma falha ao iniciar o Fluent Bit, os logs do processo serão perdidos. Só é possível enviar logs de processo ao CloudWatch.
Para depurar o envio de logs de processo em sua conta, você pode aplicar o `ConfigMap` anterior para obter os logs de processo. A falha de inicialização do Fluent Bit geralmente ocorre porque o `ConfigMap` não foi analisado ou aceito pelo Fluent Bit ao iniciar.

### Para interromper os logs do processo de envio do Fluent Bit
<a name="stop-fluent-bit-process-logs"></a>

O envio de logs do processo Fluent Bit para o CloudWatch exige custos adicionais de ingestão e armazenamento de logs. Para excluir registros do processo em uma configuração `ConfigMap` existente, siga as etapas a seguir.

1. Localize o grupo de logs do CloudWatch criado automaticamente para os logs do processo do Fluent Bit do cluster do Amazon EKS, após habilitar o registro em log do Fargate. Ele segue o formato ` my-cluster-fluent-bit-logs`.

1. Exclua os fluxos de log existentes do CloudWatch criados para os logs de processo de cada pod no grupo de logs do CloudWatch.

1. Edite `ConfigMap` e configure `flb_log_cw: "false"`.

1. Reinicie todos os pods existentes no cluster.

## Testar a aplicação
<a name="fargate-logging-test-application"></a>

1. Implante um pod de exemplo.

   1. Salve o seguinte conteúdo no seu computador, em um arquivo chamado `sample-app.yaml`:

      ```
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: sample-app
        namespace: same-namespace-as-your-fargate-profile
      spec:
        replicas: 3
        selector:
          matchLabels:
            app: nginx
        template:
          metadata:
            labels:
              app: nginx
          spec:
            containers:
              - name: nginx
                image: nginx:latest
                ports:
                  - name: http
                    containerPort: 80
      ```

   1. Aplique o manifesto ao cluster.

      ```
      kubectl apply -f sample-app.yaml
      ```

1. Visualize os logs do NGINX usando os destinos que você configurou no `ConfigMap`.

## Considerações sobre tamanho
<a name="fargate-logging-size-considerations"></a>

Sugerimos que você planeje até 50 MB de memória para o roteador de log. Se você espera que a aplicação gere logs com um throughput muito alto, planeje até 100 MB.

## Solução de problemas
<a name="fargate-logging-troubleshooting"></a>

Para confirmar se o recurso de registro em log está habilitado ou desabilitado por algum motivo, como um `ConfigMap` inválido, e por que ele está inválido, verifique os eventos de pods com `kubectl describe pod pod-name `. A saída pode incluir eventos de pods que esclarecem se o registro em log está habilitado ou não, como a saída de exemplo a seguir.

```
[...]
Annotations:          CapacityProvisioned: 0.25vCPU 0.5GB
                      Logging: LoggingDisabled: LOGGING_CONFIGMAP_NOT_FOUND
[...]
Events:
  Type     Reason           Age        From                                                           Message
  ----     ------           ----       ----                                                           -------
  Warning  LoggingDisabled  <unknown>  fargate-scheduler                                              Disabled logging because aws-logging configmap was not found. configmap "aws-logging" not found
```

Os eventos de pods são temporários, com um intervalo de tempo que depende das configurações. Você também pode visualizar as anotações de um pod usando `kubectl describe pod pod-name `. A anotação do pod informa se o recurso de registro em log está habilitado ou desabilitado e o motivo.