Remoção dos agentes de plug-in de observabilidade

• Após o término do suporte para o site ob plugin, você deverá excluir cada componente individualmente.

  1. Limpe os daemonsets e configmaps.

      kubectl delete daemonset logdna-agent -n ibm-observe
      kubectl delete daemonset sysdig-agent -n ibm-observe
      kubectl delete configmap <logdna-configmap> -n ibm-observe
      kubectl delete configmap <sysdig-configmap> -n ibm-observe
      ```
  1. Opcional: Excluir o namespace. Depois que nenhum outro recurso estiver em execução no namespace.
  ```sh {: pre}
      kubectl delete namespace ibm-observe
      ```
  

Após a remoção do plug-in, reinstale os agentes de registro e monitoramento em seu cluster usando o painel do cluster, o Terraform ou manualmente.

Para obter mais informações, consulte os links a seguir:

• Envio de dados de registro de IBM Cloud Kubernetes Service para IBM Cloud Logs
• Monitorando um cluster Kubernetes

Entendendo o encaminhamento de log para um servidor externo

Ao criar uma configuração de criação de log para uma origem no cluster para encaminhar a um servidor externo, um componente Fluentd é criado no cluster. O Fluentd coleta os logs dos caminhos dessa origem e os encaminha a um servidor externo. O tráfego da origem para o serviço de criação de log na porta de entrada está criptografado.

Para quais fontes posso configurar o encaminhamento de logs?

Na imagem a seguir, você pode ver a região das fontes para as quais é possível configurar o registro em log.

1. worker: informações que são específicas para a configuração de infraestrutura que você tem para o nó do trabalhador. Os registros dos trabalhadores são capturados no syslog e contêm eventos do sistema operacional. Em auth.log, é possível localizar informações sobre as solicitações de autenticação que são feitas para o S.O.

   Caminhos

   • /var/log/syslog
   • /var/log/auth.log

2. container: informações que são registradas por um contêiner em execução. Caminhos: qualquer coisa que seja gravada em STDOUT ou STDERR.

3. application: informações sobre eventos que ocorrem no nível do aplicativo. Esta pode ser uma notificação de que um evento ocorreu, como um login bem-sucedido, um aviso sobre armazenamento ou outras operações que podem ser executadas no nível do app. Caminhos: é possível configurar os caminhos para os quais os logs são encaminhados. No entanto, para que os logs sejam enviados, deve-se usar um caminho absoluto na configuração de criação de log ou os logs não poderão ser lidos. Se o seu caminho estiver montado no seu nó de trabalho, é possível que tenha sido criado um link simbólico. Exemplo: se o caminho especificado for /usr/local/spark/work/app-0546/0/stderr, mas na verdade os logs forem para /usr/local/spark-1.0-hadoop-1.2/work/app-0546/0/stderr, os logs não poderão ser lidos.

4. storage: informações sobre o armazenamento persistente que está configurado em seu cluster. Os logs de armazenamento podem ajudar a configurar painéis e alertas de determinação de problemas como parte de seu pipeline DevOps e liberações de produção. Nota: os caminhos /var/log/kubelet.log e /var/log/syslog também contêm logs de armazenamento, mas os logs desses caminhos são coletados pelas origens de log kubernetes e worker.

   Caminhos

   /var/log/ibmc-s3fs.log

   /var/log/ibmc-block.log

   Pods

   portworx-***

   ibmcloud-block-storage-attacher-***

   ibmcloud-block-storage-driver-***

   ibmcloud-block-storage-plugin-***

   ibmcloud-object-storage-plugin-***

5. kubernetes: informações do kubelet, do kube-proxy e de outros eventos do Kubernetes que acontecem no namespace kube-system do nó do trabalhador.

   Caminhos

   /var/log/kubelet.log

   /var/log/kube-proxy.log

   /var/log/event-exporter/1..log

6. ingress: informações sobre o tráfego de rede que entra em um cluster por meio do ALB de ingresso.

   Caminhos

   /var/log/alb/ids/*.log

   /var/log/alb/ids/*.err

   /var/log/alb/customerlogs/*.log

   /var/log/alb/customerlogs/*.err

7. kube-audit: informações sobre ações relacionadas ao cluster que são enviadas para o servidor de API do Kubernetes, incluindo o horário, o usuário e o recurso afetado. A fonte kube-audit pode ser configurada com um webhook. Para obter mais informações, consulte Encaminhando logs de auditoria da API de Kubernetes para um servidor externo.

Sou responsável por manter o site Fluentd atualizado?

Para mudar as configurações de filtro ou criação de log, o componente de criação de log Fluentd deve estar na versão mais recente. Por padrão, as atualizações automáticas para o complemento são ativadas. Para desativar atualizações automáticas, consulte Atualizando componentes do cluster: Fluentd para criação de log.

Posso encaminhar alguns logs, mas não outros, de uma fonte no meu cluster?

Sim. Por exemplo, se você tiver um pod particularmente ativo, talvez você queira evitar que os logs desse pod ocupem o espaço de armazenamento de log, enquanto ainda permite que logs de outros pods sejam encaminhados. Para evitar que os logs de um pod específico sejam encaminhados, consulte Filtrando logs.

Encaminhando logs de cluster e de app

Crie uma configuração para a criação de log de cluster e de app. É possível distinguir entre as diferentes opções de registro de log utilizando as opções.

A tabela a seguir mostra as diferentes opções que você tem ao configurar a criação de log e suas descrições.

Encaminhando logs para seu próprio servidor por meio dos protocolos udp ou tcp

1. Assegure-se de que você tenha a função de acesso de plataforma Editor ou Administrador do IBM Cloud IAM.

2. Para o cluster no qual a fonte de log está localizada: efetue login na conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

3. Configure um servidor que aceite o protocolo syslog de uma das duas maneiras a seguir: : Configure e gerencie seu próprio servidor ou faça com que um provedor gerencie-o para você. Se um provedor gerenciar o servidor para você, obtenha o terminal de criação de log do provedor de criação de log.

   : Execute o syslog a partir de um contêiner. Por exemplo, você pode usar este arquivo.yaml de implantação para baixar uma imagem pública do Docker que execute um contêiner no seu cluster. A imagem publica a porta 514 no endereço IP do cluster público e usa esse endereço IP do cluster público para configurar o host do syslog.

   Você pode visualizar seus logs como JSON válido removendo os prefixos syslog. Para isso, adicione o código a seguir no início do arquivo etc/rsyslog.conf , no servidor onde o rsyslog está em execução: $template customFormat,"%msg%\n"$ActionFileDefaultTemplate customFormat

4. Crie uma configuração de encaminhamento de log. Para obter mais informações sobre os parâmetros, consulte a tabela Entendendo as opções de configuração de criação de log.

   ibmcloud ks logging config create --cluster CLUSTER_NAME_OR_ID --logsource LOG_SOURCE --namespace KUBERNETES_NAMESPACE --hostname LOG_SERVER_HOSTNAME_OR_IP --port LOG_SERVER_PORT --type syslog --app-containers CONTAINER1,2 --app-paths PATHS_TO_LOGS --syslog-protocol PROTOCOL
   

Encaminhando logs para seu próprio servidor por meio do protocolo tls

1. Assegure-se de que você tenha as funções do IBM Cloud IAM a seguir:

   • Função de acesso de plataforma Editor ou Administrador para o cluster
   • Função de acesso de serviço Gravador ou Gerenciador para o namespace kube-system

2. Para o cluster no qual a fonte de log está localizada: efetue login na conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

3. Configure um servidor que aceite o protocolo syslog de uma das duas maneiras a seguir:

   • Configure e gerencie seu próprio servidor ou faça com que um provedor gerencie-o para você. Se um provedor gerenciar o servidor para você, obtenha o terminal de criação de log do provedor de criação de log.

   • Execute o syslog a partir de um contêiner. Por exemplo, é possível usar este arquivo .yaml de implementação para buscar uma imagem pública do Docker que execute um contêiner no cluster. A imagem publica a porta 514 no endereço IP público do cluster e utiliza esse endereço IP público do cluster para configurar o host syslog. É necessário injetar a autoridade de certificação relevante e os certificados do lado do servidor e atualizar o syslog.conf para ativar o tls em seu servidor.

4. Salve o certificado de autoridade de certificação em um arquivo denominado ca-cert. Deve ser o nome exato.

5. Crie um segredo no namespace kube-system para o arquivo ca-cert. Ao criar sua configuração de registro, use o nome do segredo na opção “ --ca-cert ”.

   kubectl -n kube-system create secret generic --from-file=ca-cert
   

6. Crie uma configuração de encaminhamento de log. Para obter mais informações sobre os parâmetros, consulte a tabela Entendendo as opções de configuração de criação de log.

   ibmcloud ks logging config create --cluster <cluster name or id> --logsource <log source> --type syslog --syslog-protocol tls --hostname <ip address of syslog server> --port <port for syslog server, 514 is default> --ca-cert <secret name> --verify-mode <defaults to verify-none>
   

Filtrando logs que são encaminhados

É possível escolher quais logs encaminhar para seu servidor externo, filtrando logs específicos por um período de tempo. Você pode distinguir entre as diferentes opções de filtragem usando as opções.

1. Crie um filtro de criação de log.

   ibmcloud ks logging filter create --cluster CLUSTER_NAME_OR_ID --type LOG_TYPE --logging-configs CONFIGS --namespace KUBERNETES_NAMESPACE --container CONTAINER_NAME --level LOGGING_LEVEL --regex-message MESSAGE
   

2. Visualize o filtro de log que você criou.

   ibmcloud ks logging filter get --cluster CLUSTER_NAME_OR_ID --id FILTER_ID --show-matching-configs
   

3. Atualize o filtro de log que você criou.

   ibmcloud ks logging filter update --cluster CLUSTER_NAME_OR_ID --id FILTER_ID --type SERVER_TYPE --logging-configs CONFIGS --namespace KUBERNETES_NAMESPACE --container CONTAINER_NAME --level LOGGING_LEVEL --regex-message MESSAGE
   

4. Exclua um filtro de log que você criou.

   ibmcloud ks logging filter rm --cluster CLUSTER_NAME_OR_ID --id FILTER_ID [--all]
   

Verificando, atualizando e excluindo o encaminhamento de log

ibmcloud ks logging config update --cluster CLUSTER_NAME_OR_ID --id LOG_CONFIG_ID --namespace NAMESPACE --type SERVER_TYPE --syslog-protocol PROTOCOL --logsource SOURCE --hostname HOSTNAME_OR_INGESTION_URL --port PORT --app-containers CONTAINER1,2 --app-paths PATHS_TO_LOGS