|
Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official. |
Escreva um guia de remediação para ajudar os usuários a resolver problemas
Visão Geral
SUSE® Observability fornece monitores prontos para uso, que oferecem monitoramento sobre problemas comuns que podem ocorrer em um cluster Kubernetes. Esses monitores também contêm guias de remediação prontos para uso, que têm como objetivo orientar os usuários na resolução precisa de problemas. Eles são criados com as melhores práticas e conhecimento da comunidade. Siga as indicações nesta página para aprender a escrever um guia de remediação eficaz você mesmo.
Diretrizes
-
Forneça instruções passo a passo para guiar um usuário na resolução do problema detectado pelo monitor;
-
Certifique-se de que as instruções estejam ordenadas pelas causas mais prováveis.
-
Se possível, inclua links para dados e/ou recursos relevantes para acelerar a investigação.
-
Mantenha-o curto e direto ao ponto:
-
Evite explicações excessivas - adicione links para documentação de apoio se for o caso;
-
Evite usar um índice e blocos de conteúdo semelhantes;
-
Evite ter um resumo do mesmo conteúdo;
-
-
Tente formatar o guia de maneira estruturada. Use:
-
itens em lista
-
numeração
-
frases curtas
-
parágrafos
-
exemplos formatados inline
-
-
Se houver pontos em aberto (podem haver causas diferentes que ainda são desconhecidas), forneça orientações para escalar o problema. Por exemplo, forneça ao usuário um link/número de suporte, etc.
Exemplo de guia de remediação
When a Kubernetes container has errors, it can enter into a state called CrashLoopBackOff, where Kubernetes attempts to restart the container to resolve the issue. The container will continue to restart until the problem is resolved.Take the following steps to diagnose the problem:
### Pod Events
Check the pod events to identify any explicit errors or warnings.
1. Go to the "Events" section in the middle of the [Pod highlight page](/#/components/\{{ componentUrnForUrl \}})
2. Check if there is are events like "BackOff", "FailedScheduling", "FailedAttachVolume" or "OOMKilled" in the Alert Category by clicking on 'Alerts'.
3. You can see the details of the event (click on the event) to give more information about the issue.
4. If the 'Show related event' option is enabled all events of resources related to this resource like a deployment will also show up and can give you a clue if any change on them is causing this issue. You can see this by checking if there is a correlation between the time of a deployment and a change of behaviour seen by the metrics and events of this pod.
For easy correlation you can use 'shift'-'click' to add markers to the different graph, log and event widgets.
### Container Logs
Check the container logs for any explicit errors or warnings
Inspect the [Logs](/#/components/\{{ componentUrnForUrl \}}#logs) of all the containers in this pod.
Search for hints in the logs by:
1. Looking for changes in logging pattern, by looking at the number of logs per time unit (The histogram bars).
In many cases the change in pattern will indicate what is going on.
You can click-drag on the histogram bars to narrow the logs displayed to that time-frame.
2. Searching for "Error" or "Fatal" in the search bar.
3. Looking at the logs around the time that the monitor triggered
### Recent Changes
Look at the pod age in the "About" section on the [Pod highlight page](/#/components/\{{ componentUrnForUrl \}}) to identify any recent deployments that might have caused the issue
1. The "Age" is shown in the "About" section on the left side of the screen
2. If the "Age" and the time that the monitor was triggered are in close proximity then take a look at the most recent deployment by clicking on [Show last change](/#/components/\{{ componentUrnForUrl \}}#lastChange).
Inserindo links
A sintaxe que usamos é diferente para "links profundos" e "links na página". Os "links profundos" redirecionarão o usuário da página atual, enquanto os "links na página" manterão o usuário na mesma página.
Links profundos
Para vincular a qualquer perspectiva (por exemplo, "destaques", "topologia", "eventos", "métricas") do recurso atual, use a seguinte sintaxe:
[highlight page](/#/components/\{{ componentUrnForUrl \}})
[topology](/#/components/{{ componentUrnForUrl }}/topology)
[events](/#/components/{{ componentUrnForUrl }}/events)
[metrics](/#/components/{{ componentUrnForUrl }}/metrics)
Links na página
Para vincular a quaisquer dados adicionais (por exemplo, "mostrar logs", "mostrar última alteração", "mostrar status", "mostrar configuração") no recurso atual, use a seguinte sintaxe:
[logs](/#/components/\{{ componentUrnForUrl \}}#logs)
[last change](/#/components/\{{ componentUrnForUrl \}}#lastChange)
[status](/#/components/\{{ componentUrnForUrl \}}#status)
[configuration](/#/components/\{{ componentUrnForUrl \}}#configuration)