diff --git a/content/pt-br/docs/concepts/cluster-administration/system-logs.md b/content/pt-br/docs/concepts/cluster-administration/system-logs.md new file mode 100644 index 0000000000..d1edb9769d --- /dev/null +++ b/content/pt-br/docs/concepts/cluster-administration/system-logs.md @@ -0,0 +1,136 @@ +--- +reviewers: +- dims +- 44past4 +title: Logs de Sistema +content_type: concept +weight: 60 +--- + + + +Logs de componentes do sistema armazenam eventos que acontecem no cluster, tornando-os muito úteis para depuração. Seu nível de detalhe pode ser ajustado para mais ou para menos. Podendo se ater por exemplo a mostrar apenas os erros que ocorrem no componente, ou chegar a mostrar cada passo de um evento. (Como acessos HTTP, mudanças no estado dos pods, ações dos controllers, ou decisões do scheduler) + + + +## Klog + +[Klog](https://github.com/kubernetes/klog) é a biblioteca de logs do Kubernetes. Responsável por gerar as mensagens de log para os componentes do sistema. +generates log messages for the Kubernetes system components. + +Para mais informações acerca da sua configruação, veja a documentação da [ferramenta de linha de comando](https://kubernetes.io/docs/reference/command-line-tools-reference/) + +Um exemplo do formato padrão dos logs da biblioteca: +``` +I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756] +``` + +### Logs Estruturados + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +{{< warning >}} +A migração pro formato de logs estruturados é um processo em andamento. Nem todos os logs estão dessa forma na versão atual. Dessa forma, para realizar o parsing de arquivos de log, você também precisa lidar com logs não estruturados. + +A formatação e serialização dos logs ainda estão sujeitas a alterações. +{{< /warning>}} + +A estruturação dos logs trás uma estrutura uniforme para as mensagens de log, facilitando a extração programacional de informações. Logs estruturados podem ser armazenados e processados com menos esforço e custo. Esse formato é totalmente retrocompatível e é habilitado por padrão + +Formato dos logs estruturados:: + +```ini + "" ="" ="" ... +``` + +Exemplo: + +```ini +I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready" +``` + + +### Logs em formato JSON + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +{{}} +Algumas opções da biblioteca klog ainda não funcionam com o os logs em formato JSON. Para ver uma lista completa de quais são, veja a documentação da [ferramenta de linha de comando](/docs/reference/command-line-tools-reference/). + +Nem todos os logs estarão garantidamente em formato JSON (como por exemplo durante o início de processos). Se você pretender realizar um parsing dos logs, seu código deverá saber tratar também linhas que não são JSON + +O nome dos campos e a serialização JSON ainda está sujeita a mudanças. +{{< /warning >}} + +A opção `--logging-format=json` muda o formato dos logs do formato padrão da klog para JSON. Abaixo segue um exemplo de um log em formato JSON (identado): +```json +{ + "ts": 1580306777.04728, + "v": 4, + "msg": "Pod status updated", + "pod":{ + "name": "nginx-1", + "namespace": "default" + }, + "status": "ready" +} +``` + +Chaves com significados especiais: +* `ts` - Data e hora no formato Unix (obrigatório, float) +* `v` - Nível de detalhe (obrigatório, int, padrão 0) +* `err` - Mensagem de erro (opcional, string) +* `msg` - Mensagem (obrigatório, string) + +Lista dos componentes que suportam o formato JSON atualmente: +* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} +* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} + +### Limpeza dos Logs + +{{< feature-state for_k8s_version="v1.20" state="alpha" >}} + +{{}} +A limpeza dos logs pode causar impactos significativos na performance, sendo portanto contraindicado em produção. +{{< /warning >}} + +A opção `--experimental-logging-sanitization` habilita o filtro de limpeza dos logs. +Quando habilitado, esse filtro inspeciona todos os argumentos dos logs procurando por campos contendo dados sensíveis (como senhas, chaves e tokens). Tais campos não serão expostos nas mensagens de log. + +Lista dos componentes que suportam a limpeza de logs atualmente: +* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} +* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} + +{{< note >}} +O filtro de limpeza dos logs não impede a exposição de dados sensíveis nos logs das aplicações em execução. +{{< /note >}} + +### Nível de detalhe dos logs + +A opção `-v` controla o nível de detalhe dos logs. Um valor maior aumenta o número de eventos registrados, começando a registrar também os eventos menos importantes. Um valor menor restringe os logs apenas aos eventos mais importantes. O valor padrão 0 registra apenas eventos críticos. + +### Localização dos Logs + +Existem dois tipos de componentes do sistema: aqueles que são executados em um container e aqueles que não são. Por exemplo: + +* O [Kubernetes scheduler](https://kubernetes.io/pt-br/docs/concepts/overview/components/#kube-scheduler) e o [kube-proxy](https://kubernetes.io/pt-br/docs/concepts/overview/components/#kube-proxy) são executados em um container. +* O [kubelet](https://kubernetes.io/pt-br/docs/concepts/overview/components/#kubelet) e o [container runtime](https://kubernetes.io/pt-br/docs/concepts/overview/components/#container-runtime), como o Docker por exemplo, não são executados em containers. + +Em máquinas com systemd, o kubelet e o container runtime gravam os logs no journald. +Em outros casos, eles escrevem os logs em arquivos `.log` no diretório `/var/log`. +Já os componentes executados dentro de containers, sempre irão escrever os logs em arquivos `.log` +no diretório `/var/log`, ignorando o mecanismo padrão de log. + +De forma similar aos logs de container, os logs de componentes do sistema no diretório `/var/log` devem ser rotacionados. +Nos clusters Kubernetes criados com o script `kube-up.sh`, a rotação dos logs é configurada pela ferramenta `logrotate`. Essa ferramenta rotaciona os logs diariamente, +ou quando o tamanho do arquivo excede 100MB. + +## {{% heading "Próximos passos" %}} + +* Leia sobre [Arquitetura de Logs do Kubernetes](/pt-br/docs/concepts/cluster-administration/logging/) +* Leia sobre [Logs Estruturados](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) +* Leia sobre [Convenções sobre os níveis de logs](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)