(Opcional) Configurar o FluentD como um DaemonSet para enviar logs ao CloudWatch Logs - Amazon CloudWatch

(Opcional) Configurar o FluentD como um DaemonSet para enviar logs ao CloudWatch Logs

Atenção

O Container Insights Support para o FluentD está agora em modo de manutenção, o que significa que a AWS não fornecerá outras atualizações do FluentD e que estamos planejando defasá-lo em um futuro próximo. Além disso, a configuração atual do FluentD para o Container Insights está usando uma versão antiga da imagem do FluentD fluent/fluentd-kubernetes-daemonset:v1.7.3-debian-cloudwatch-1.0 que não tem os últimos patches de melhoria e segurança. Para obter a imagem do FluentD mais recente com suporte na comunidade de código aberto, consulte fluentd-kubernetes-daemonset.

É altamente recomendável migrar para usar o FluentBit com o Container Insights sempre que possível. Usar o FluentBit como encaminhador de log para o Container Insights proporciona ganhos consideráveis de performance.

Para obter mais informações, consulte Configurar o Fluent Bit como um DaemonSet para enviar logs ao CloudWatch Logs e O que se difere se você já estiver usando Fluentd.

Para configurar o FluentD para coletar logs de seus contêineres, siga as etapas em Configuração de início rápido para o Container Insights no Amazon EKS e no Kubernetes ou siga as etapas nesta seção. Nas etapas a seguir, você configura o FluentD como um DaemonSet para enviar logs ao CloudWatch Logs. Ao concluir esta etapa, o FluentD criará os grupos de log a seguir, caso eles ainda não existam.

Nome do grupo de logs Origem do log

/aws/containerinsights/Cluster_Name/application

Todos os arquivos de log em /var/log/containers

/aws/containerinsights/Cluster_Name/host

Logs de /var/log/dmesg, /var/log/secure e /var/log/messages

/aws/containerinsights/Cluster_Name/dataplane

Os logs no /var/log/journal para kubelet.service, kubeproxy.service e docker.service.

Etapa 1: Criar um namespace para o CloudWatch

Use a seguinte etapa para criar um namespace do Kubernetes chamado amazon-cloudwatch para o CloudWatch. Ignore essas etapas se você já tiver criado esse namespace.

Para criar um namespace para o CloudWatch

  • Insira o comando a seguir.

    kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cloudwatch-namespace.yaml

Etapa 2: instalar o FluentD

Inicie esse processo fazendo download do FluentD. Ao concluir essas etapas, a implantação criará os seguintes recursos no cluster:

  • Uma conta de serviço chamada fluentd no namespace amazon-cloudwatch. Essa conta de serviço é usada para executar o DaemonSet do FluentD. Para obter mais informações, consulte Gerenciar contas de serviço (em inglês) na Referência do Kubernetes.

  • Uma função do cluster chamada fluentd no namespace amazon-cloudwatch. Essa função do cluster concede permissões get, list e watch em logs de pod para a conta de serviço fluentd. Para obter mais informações, consulte Visão geral da API (em inglês) na Referência do Kubernetes.

  • Um ConfigMap chamado fluentd-config no namespace amazon-cloudwatch. Esse ConfigMap contém a configuração a ser usada pelo FluentD. Para obter mais informações, consulte Configurar um pod para usar um ConfigMap na documentação do Kubernetes Tasks.

Para instalar o FluentD

  1. Crie um ConfigMap chamado cluster-info com o nome do cluster e a região da AWS à qual os logs serão enviados. Execute o comando a seguir atualizando os espaços reservados com os nomes do cluster e da região.

    kubectl create configmap cluster-info \ --from-literal=cluster.name=cluster_name \ --from-literal=logs.region=region_name -n amazon-cloudwatch
  2. Faça download e implante o DaemonSet do FluentD no cluster executando o comando a seguir. Verifique se está usando a imagem do contêiner com a arquitetura correta. O exemplo de manifesto de só funciona em instâncias x86 e entrará em CrashLoopBackOff se você tiver instâncias Advanced RISC Machine (ARM) em seu cluster. O DaemonSet do FluentD não tem uma imagem oficial do Docker de várias arquiteturas que permita usar uma etiqueta para várias imagens subjacentes e deixar o tempo de execução do contêiner escolher o certo. A imagem de ARM do FluentD usa uma etiqueta diferente com um sufixo arm64.

    kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/fluentd/fluentd.yaml
    nota

    Devido a uma alteração recente para otimizar a configuração do FluentD e minimizar o impacto das solicitações da API do FluentD nos endpoints da API do Kubernetes, a opção “Watch” para filtros do Kubernetes foi desabilitada por padrão. Para obter mais detalhes, consulte fluent-plugin-kubernetes_metadata_filter.

  3. Valide a implantação executando o comando a seguir. Cada nó deve ter um pod chamado fluentd-cloudwatch-*.

    kubectl get pods -n amazon-cloudwatch

Etapa 3: Verificar a configuração do FluentD

Para verificar a configuração do FluentD, use as etapas a seguir.

Para verificar a configuração do FluentD para o Container Insights

  1. Abra o console do CloudWatch em https://console.aws.amazon.com/cloudwatch/.

  2. No painel de navegação, escolha Log groups (Grupos de logs). Certifique-se de que você está na região na qual implantou o FluentD para seus contêineres.

    Na lista de grupos de log na região, você deve ver o seguinte:

    • /aws/containerinsights/Cluster_Name/application

    • /aws/containerinsights/Cluster_Name/host

    • /aws/containerinsights/Cluster_Name/dataplane

    Caso você veja esses grupos de log, a configuração do FluentD está verificada.

Suporte a logs de várias linhas

Em 19 de agosto de 2019, adicionamos suporte a logs de várias linhas para os logs coletados pelo FluentD.

Por padrão, o iniciador da entrada do log de várias linhas é qualquer caractere sem espaço em branco. Isso significa que todas as linhas do log que começam com um caractere que não tenha espaço em branco são consideradas como uma nova entrada de log de várias linhas.

Se seus próprios logs de aplicativo usarem um iniciador de várias linhas diferente, você poderá oferecer suporte a eles fazendo duas alterações no arquivo fluentd.yaml.

Primeiro, exclua-os do suporte padrão de várias linhas adicionando os nomes de caminho dos arquivos de log a um campo exclude_path na seção containers de fluentd.yaml. Veja um exemplo a seguir.

<source> @type tail @id in_tail_container_logs @label @containers path /var/log/containers/*.log exclude_path ["full_pathname_of_log_file*", "full_pathname_of_log_file2*"]

Adicione um bloco para seus arquivos de log ao arquivo fluentd.yaml. O exemplo abaixo é usado para o arquivo de log do agente do CloudWatch, que usa uma expressão regular de carimbo de data/hora como o iniciador de várias linhas. Você pode copiar esse bloco e adicioná-lo ao fluentd.yaml. Altere as linhas indicadas para refletir o nome do arquivo de log do aplicativo e o iniciador de várias linhas que você deseja usar.

<source> @type tail @id in_tail_cwagent_logs @label @cwagentlogs path /var/log/containers/cloudwatch-agent* pos_file /var/log/cloudwatch-agent.log.pos tag * read_from_head true <parse> @type json time_format %Y-%m-%dT%H:%M:%S.%NZ </parse> </source>
<label @cwagentlogs> <filter **> @type kubernetes_metadata @id filter_kube_metadata_cwagent </filter> <filter **> @type record_transformer @id filter_cwagent_stream_transformer <record> stream_name ${tag_parts[3]} </record> </filter> <filter **> @type concat key log multiline_start_regexp /^\d{4}[-/]\d{1,2}[-/]\d{1,2}/ separator "" flush_interval 5 timeout_label @NORMAL </filter> <match **> @type relabel @label @NORMAL </match> </label>

(Opcional) Reduzir o volume de log do FluentD

Por padrão, enviamos logs de aplicação do FluentD e metadados do Kubernetes ao CloudWatch. Para reduzir o volume de dados que estão sendo enviados ao CloudWatch, você pode impedir que uma ou ambas as fontes de dados sejam enviadas ao CloudWatch.

Para interromper os logs do aplicativo FluentD, remova a seção a seguir do arquivo fluentd.yaml.

<source> @type tail @id in_tail_fluentd_logs @label @fluentdlogs path /var/log/containers/fluentd* pos_file /var/log/fluentd.log.pos tag * read_from_head true <parse> @type json time_format %Y-%m-%dT%H:%M:%S.%NZ </parse> </source> <label @fluentdlogs> <filter **> @type kubernetes_metadata @id filter_kube_metadata_fluentd </filter> <filter **> @type record_transformer @id filter_fluentd_stream_transformer <record> stream_name ${tag_parts[3]} </record> </filter> <match **> @type relabel @label @NORMAL </match> </label>

Para remover os metadados do Kubernetes, a fim de que não sejam anexados aos eventos de log enviados ao CloudWatch, adicione uma linha à seção record_transformer do arquivo fluentd.yaml. Na origem do log em que você deseja remover esses metadados, adicione a seguinte linha.

remove_keys $.kubernetes.pod_id, $.kubernetes.master_url, $.kubernetes.container_image_id, $.kubernetes.namespace_id

Por exemplo:

<filter **> @type record_transformer @id filter_containers_stream_transformer <record> stream_name ${tag_parts[3]} </record> remove_keys $.kubernetes.pod_id, $.kubernetes.master_url, $.kubernetes.container_image_id, $.kubernetes.namespace_id </filter>

Solução de problemas

Caso não veja esses grupos de log e esteja procurando na região correta, verifique os logs para os pods do DaemonSet do FluentD para procurar o erro.

Execute o comando a seguir para certificar-se de que o status seja Running.

kubectl get pods -n amazon-cloudwatch

Nos resultados do comando anterior, observe o nome do pod que começa com fluentd-cloudwatch. Use o nome desse pod no comando a seguir.

kubectl logs pod_name -n amazon-cloudwatch

Se os logs tiverem erros relacionados às permissões do IAM, verifique a função do IAM anexada aos nós do cluster. Para obter mais informações sobre as permissões necessárias para executar um cluster do Amazon EKS, consultePolíticas, funções, e permissões do Amazon EKS IAM no Manual do usuário do Amazon EKS.

Se o status do pod for CreateContainerConfigError, obtenha o erro exato executando o comando a seguir.

kubectl describe pod pod_name -n amazon-cloudwatch

Se o status do pod forCrashLoopBackOff, verifique se a arquitetura da imagem do contêiner do Fluentd é a mesma do nó quando você instalou o Fluentd. Se o cluster tiver nós x86 e ARM64, será possível usar um rótulo kubernetes.io/arch para colocar as imagens no nó correto. Para obter mais informações, consulte kuberntes.io/arch.