Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado.

Escriba una guía de remediación para ayudar a los usuarios a solucionar problemas

Descripción general

SUSE® Observability proporciona monitores listos para usar, que proporcionan monitoreo de problemas comunes que pueden ocurrir en un clúster de Kubernetes. Estos monitores también contienen guías de remediación listas para usar que están destinadas a guiar a los usuarios en la solución precisa de problemas. Se crean utilizando las mejores prácticas y el conocimiento de la comunidad. Siga las indicaciones en esta página para aprender a escribir una guía de remediación efectiva usted mismo.

Directrices

  • Proporcione instrucciones paso a paso para guiar a un usuario en la resolución del problema detectado por el monitor;

  • Asegúrese de que las instrucciones estén ordenadas por la(s) causa(s) más probable(s).

  • Si es posible, incluya enlaces a datos y/o recursos relevantes para acelerar la investigación.

  • Mantenlo breve y al grano:

    • Evite sobreexplicar; añada enlaces a la documentación de apoyo si es el caso;

    • Evite utilizar una tabla de contenido y bloques de contenido similares;

    • Evite tener un resumen del mismo contenido;

  • Intente formatear la guía de manera estructurada. Utilice:

    • puntos de viñeta

    • numeración

    • oraciones cortas

    • párrafos

    • ejemplos con formato en línea

  • Si hay cabos sueltos (puede haber diferentes causas que aún son desconocidas), proporcione orientación para escalar el problema. Por ejemplo, proporcione al usuario un enlace o número de soporte, etc.

Ejemplo de guía de remediación

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).

Insertando enlaces

La sintaxis que utilizamos es diferente para los "enlaces profundos" frente a los "enlaces en la página". Los "enlaces profundos" redirigirán al usuario desde la página actual, mientras que los "enlaces en la página" mantendrán al usuario en la misma página.

Enlaces profundos

Para enlazar a cualquier perspectiva (por ejemplo, "destacados", "topología", "eventos", "métricas") del recurso actual, utilice la siguiente sintaxis:

[highlight page](/#/components/\{{ componentUrnForUrl \}})
[topology](/#/components/{{ componentUrnForUrl }}/topology)
[events](/#/components/{{ componentUrnForUrl }}/events)
[metrics](/#/components/{{ componentUrnForUrl }}/metrics)

Enlaces en la página

Para enlazar a cualquier dato adicional (por ejemplo, "mostrar registros", "mostrar último cambio", "mostrar estado", "mostrar configuración") sobre el recurso actual, utilice la siguiente sintaxis:

[logs](/#/components/\{{ componentUrnForUrl \}}#logs)
[last change](/#/components/\{{ componentUrnForUrl \}}#lastChange)
[status](/#/components/\{{ componentUrnForUrl \}}#status)
[configuration](/#/components/\{{ componentUrnForUrl \}}#configuration)