Skip to content

Commit d50a1cd

Browse files
MarcosNBJMarcosNBJ
committed
adding pt-br translation for System Logs page
1 parent f6fb295 commit d50a1cd

File tree

1 file changed

+136
-0
lines changed

1 file changed

+136
-0
lines changed

‎content/pt-br/docs/concepts/cluster-administration/system-logs.md

Lines changed: 136 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,136 @@
1+
---
2+
reviewers:
3+
- dims
4+
- 44past4
5+
title: Logs de Sistema
6+
content_type: concept
7+
weight: 60
8+
---
9+
10+
<!-- overview -->
11+
12+
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)
13+
14+
<!-- body -->
15+
16+
## Klog
17+
18+
[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.
19+
generates log messages for the Kubernetes system components.
20+
21+
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/)
22+
23+
Um exemplo do formato padrão dos logs da biblioteca:
24+
```
25+
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]
26+
```
27+
28+
### Logs Estruturados
29+
30+
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
31+
32+
{{< warning >}}
33+
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.
34+
35+
A formatação e serialização dos logs ainda estão sujeitas a alterações.
36+
{{< /warning>}}
37+
38+
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
39+
40+
Formato dos logs estruturados::
41+
42+
```ini
43+
<klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ...
44+
```
45+
46+
Exemplo:
47+
48+
```ini
49+
I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
50+
```
51+
52+
53+
### Logs em formato JSON
54+
55+
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
56+
57+
{{<warning >}}
58+
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/).
59+
60+
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
61+
62+
O nome dos campos e a serialização JSON ainda está sujeita a mudanças.
63+
{{< /warning >}}
64+
65+
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):
66+
```json
67+
{
68+
"ts": 1580306777.04728,
69+
"v": 4,
70+
"msg": "Pod status updated",
71+
"pod":{
72+
"name": "nginx-1",
73+
"namespace": "default"
74+
},
75+
"status": "ready"
76+
}
77+
```
78+
79+
Chaves com significados especiais:
80+
* `ts` - Data e hora no formato Unix (obrigatório, float)
81+
* `v` - Nível de detalhe (obrigatório, int, padrão 0)
82+
* `err` - Mensagem de erro (opcional, string)
83+
* `msg` - Mensagem (obrigatório, string)
84+
85+
Lista dos componentes que suportam o formato JSON atualmente:
86+
* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
87+
* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
88+
* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
89+
* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
90+
91+
### Limpeza dos Logs
92+
93+
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
94+
95+
{{<warning >}}
96+
A limpeza dos logs pode causar impactos significativos na performance, sendo portanto contraindicado em produção.
97+
{{< /warning >}}
98+
99+
A opção `--experimental-logging-sanitization` habilita o filtro de limpeza dos logs.
100+
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.
101+
102+
Lista dos componentes que suportam a limpeza de logs atualmente:
103+
* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
104+
* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
105+
* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
106+
* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
107+
108+
{{< note >}}
109+
O filtro de limpeza dos logs não impede a exposição de dados sensíveis nos logs das aplicações em execução.
110+
{{< /note >}}
111+
112+
### Nível de detalhe dos logs
113+
114+
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.
115+
116+
### Localização dos Logs
117+
118+
Existem dois tipos de componentes do sistema: aqueles que são executados em um container e aqueles que não são. Por exemplo:
119+
120+
* 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.
121+
* 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.
122+
123+
Em máquinas com systemd, o kubelet e o container runtime gravam os logs no journald.
124+
Em outros casos, eles escrevem os logs em arquivos `.log` no diretório `/var/log`.
125+
Já os componentes executados dentro de containers, sempre irão escrever os logs em arquivos `.log`
126+
no diretório `/var/log`, ignorando o mecanismo padrão de log.
127+
128+
De forma similar aos logs de container, os logs de componentes do sistema no diretório `/var/log` devem ser rotacionados.
129+
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,
130+
ou quando o tamanho do arquivo excede 100MB.
131+
132+
## {{% heading "Próximos passos" %}}
133+
134+
* Leia sobre [Arquitetura de Logs do Kubernetes](/pt-br/docs/concepts/cluster-administration/logging/)
135+
* Leia sobre [Logs Estruturados](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging)
136+
* Leia sobre [Convenções sobre os níveis de logs](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)

0 commit comments

Comments
 (0)