Skip to main content
Una incidencia agrupa ocurrencias de errores que comparten una huella. Lee el resumen del grupo y una ocurrencia antes de cambiar el estado, la prioridad o el responsable. Un cambio de estado, prioridad o responsable registra una decisión del equipo. No repara el software ni reescribe los eventos capturados. Instala la CLI de LogBrew y ejecuta logbrew login antes de empezar.

​
Incidencias y ocurrencias

Una lista de incidencias devuelve un resumen del grupo, no un evento completo. Lee estos campos antes de abrir el detalle: El número de ocurrencias no es el número de usuarios afectados. Los recuentos y las horas se aplican al alcance devuelto, no a todo el historial de errores. Un filtro --since o --until limita las ocurrencias que cuenta LogBrew. Cuando informes de un recuento, indica también los filtros que lo produjeron.

​
Valores de estado

archived antes se llamaba ignored. Los dos nombres seleccionan las mismas incidencias y ambos se aceptan como entrada. logbrew read, logbrew issues y las versiones 2 y 3 de la API muestran archived. La versión 1 de la API (la predeterminada), el flujo de la observación en vivo y la respuesta de investigación de incidencias muestran ignored. El panel muestra los estados como Sin resolver, Resuelta y Archivada. El estado se aplica a toda la incidencia, no a una ocurrencia. La severidad indica la urgencia, y el estado registra la decisión. Mantén las dos cosas separadas. Una incidencia critical puede estar resolved después de una corrección verificada. Una incidencia archived conserva su severidad capturada. LogBrew no reabre automáticamente una incidencia resuelta. Cuando llega una ocurrencia nueva después de la resolución, la investigación informa lifecycle.effective_status como regressed. El status sigue siendo resolved hasta que una persona reabre la incidencia.

​
Prioridad

La prioridad define el orden en que el equipo tría las incidencias: Cada incidencia tiene una prioridad. Si nadie la define, sigue a la severidad de la incidencia: error y critical son high, warning es medium e info es low. Cuando una regla de incidencias cambia la severidad, la prioridad sigue a triage.effective_severity. En ese caso, priority_source es derived. Cuando una persona define la prioridad, esta queda fija y priority_source es manual. Para listar las incidencias que debes examinar primero:

​
Asigna incidencias

Asigna una incidencia para mostrar quién es responsable del siguiente paso. Una incidencia tiene 0 o 1 responsable: una cuenta o un equipo.
1

Averigua a quién puedes asignarla

assignees incluye todas las cuentas que pueden leer el proyecto, con user_id, name y email. teams incluye todos los equipos de la organización del proyecto, con team_id, slug y name. No puedes asignar una cuenta que no puede leer el proyecto ni un equipo de otra organización.
2

Asigna la incidencia

Usa me en lugar de un ID de usuario para asignarte la incidencia a ti. Usa logbrew issues unassign "<issue_id>" --json para quitar el responsable. Añade --project para cambiar hasta 100 incidencias de un proyecto.
3

Lee tus incidencias

Usa --assignee my_teams para ver las incidencias de tus equipos, --assignee "team:<team_id>" para las de un equipo y --assignee none para las que no tienen responsable.
Para asignar incidencias, necesitas permiso para gestionar incidencias en el proyecto. Ese mismo permiso te deja cambiar el estado, la prioridad, las reglas de propiedad y las reglas de incidencias y de logs. Los propietarios y administradores de la organización crean los equipos y eligen a sus miembros. Pertenecer a un equipo no da acceso a ningún proyecto. Cuando un miembro pierde el acceso al proyecto, las incidencias que tenía asignadas aparecen sin responsable. Cuando se elimina un equipo, las incidencias que tenía asignadas también aparecen sin responsable. Esas incidencias aparecen en las lecturas con --assignee none. Si el miembro recupera el acceso, las incidencias vuelven a mostrarlo, salvo que alguien haya cambiado o quitado el responsable mientras tanto.

​
Averigua quién es el propietario de una incidencia

El resultado muestra los propietarios sugeridos, del más probable al menos probable, y un suggested_assignee. Cada propietario tiene un source: inputs cuenta las rutas de los marcos de pila, los módulos, la plantilla de ruta, las etiquetas y las reglas que revisó LogBrew. Si la lista está vacía e inputs no muestra rutas, a la incidencia le falta evidencia para buscar coincidencias; eso no significa que no tenga propietario. Escribe las reglas de propiedad en un archivo de texto, una regla por línea:
Un patrón path coincide con el final de la ruta de un marco de pila, así que src/payments/** coincide con marcos de cualquier directorio de despliegue. * coincide con cualquier texto. Los propietarios son correos de cuentas o #team-slug. La última regla que coincide va primero. Después envía las reglas, un archivo CODEOWNERS de GitHub o ambos:
En CODEOWNERS, un correo identifica una cuenta y @org/team-slug identifica el equipo con ese slug. Las reglas que nombran una cuenta sin acceso al proyecto o un equipo desconocido fallan con 422. Los propietarios de CODEOWNERS que no corresponden a nadie aparecen en unresolved_owners. Un archivo vacío borra su texto.

​
Lee el historial de la incidencia

El historial muestra cada cambio de estado, prioridad, responsable y regla de severidad, del más reciente al más antiguo, con la cuenta que lo hizo. Termina con first_seen. Si una cuenta perdió el acceso al proyecto, solo se conserva su ID. Usa --limit y los valores de next_cursor para leer más.

​
Lee tu bandeja de entrada

La bandeja de entrada muestra las incidencias que otras personas te asignaron a ti o a tus equipos, de la más reciente a la más antigua. unread cuenta las asignaciones posteriores a tu marca de lectura. logbrew inbox read mueve la marca de lectura al momento actual. LogBrew no envía correos por estas asignaciones. La bandeja de entrada solo muestra los proyectos que puedes leer ahora.

​
Flujo de trabajo recomendado

1

Lista las incidencias sin resolver de un alcance

Mantén los mismos filtros en las lecturas de listas posteriores. Un resultado vacío significa que ninguna incidencia coincide con este alcance. No demuestra que el proyecto no tenga errores. Copia el ID exacto de la incidencia, no el título.
2

Lee el detalle de la incidencia

Confirma que el proyecto devuelto es el correcto antes de continuar. Las lecturas devuelven una instantánea. Vuelve a leer la incidencia antes de cambiar el estado.
3

Investiga una ocurrencia

Las lecturas de detalle y de investigación no usan los filtros de lista. Compara subject.project_id, event.occurred_at, el release y el entorno con tu alcance. La ocurrencia recomendada puede ser más antigua que la más reciente. Sigue Investigar una incidencia para revisar toda la evidencia.
4

Sigue la evidencia de la traza solo si está disponible

Lee la traza solo cuando correlations.trace.status sea available. Usa el ID de traza de la respuesta. Nunca te lo inventes.
La lectura de la traza no tiene filtro de tiempo. Si el estado es not_linked, continúa con la evidencia de la incidencia.
5

Verifica el despliegue candidato

Usa la ocurrencia investigada como base. Obtén el ID del despliegue de la evidencia del despliegue o de tu proceso de releases.
Que no haya recurrencia en el intervalo de tiempo de observación no demuestra una corrección permanente. Si status es insufficient_traffic o unavailable, deja la incidencia en unresolved. Sigue la siguiente acción devuelta.
6

Cambia el estado, la prioridad o el responsable

Ejecuta un comando. Estos comandos no piden confirmación, así que comprueba antes el ID de la incidencia.
Sin --project, cada comando acepta 1 ID de incidencia. Comprueba el código de salida y los valores devueltos de status, priority y assignee. Si falta el resultado, vuelve a leer la incidencia antes del siguiente cambio.Los scripts antiguos pueden usar logbrew set issue "<issue_id>" resolved y los atajos resolve, ignore y reopen. ignore define archived.

​
Cambia muchas incidencias a la vez

Añade --project para cambiar hasta 100 incidencias de un proyecto con un solo comando:
El comando aplica un mismo cambio a todas las incidencias. Cada ID de incidencia solo puede aparecer una vez. La CLI rechaza más de 100 ID o un ID repetido antes de enviar la solicitud. El resultado tiene 1 entrada por incidencia, en el orden del comando: Cada entrada tiene issue_id, outcome e issue. issue es la incidencia actual, o null para not_found. Puedes volver a ejecutar el mismo comando tras un fallo de red. Las incidencias que ya cambiaron muestran unchanged. Para más de 100 incidencias, ejecuta más comandos. Con un resultado not_found, vuelve a copiar el ID de una lista de incidencias de ese proyecto. Consulta Actualiza incidencias en bloque para ver la solicitud a la API.

​
Elige el siguiente estado

  • Déjala en unresolved cuando el fallo esté activo o la corrección no esté verificada. Que falte una traza no es motivo para archivar una incidencia.
  • Define resolved cuando el equipo acepte la evidencia de la corrección. Una corrección propuesta no es evidencia.
  • Define archived para una condición aceptada o una señal que solo procede de pruebas. La decisión se aplica a todas las ocurrencias de la incidencia. El comando no tiene campo de motivo, así que anota el motivo en el registro de trabajo de tu equipo.
  • Reábrela con unresolved cuando llegue una ocurrencia nueva después de la resolución. lifecycle.regression.first_reappeared_occurrence la identifica. Compárala con la ocurrencia que se usó para la resolución. No crees otra incidencia.

​
Entrega la investigación

Da a la siguiente persona referencias, no un volcado de eventos sin procesar:
  • ID, estado, prioridad, responsable y severidad de la incidencia.
  • Proyecto, servicio, entorno y release.
  • Hora en que se vio por primera vez, hora en que se vio por última vez y número de ocurrencias.
  • ID de la ocurrencia seleccionada y occurrence_selection.reason.
  • fix.status, cause.status y su provenance.
  • Estado de la traza e ID de traza, si está disponible.
  • Estado de la reproducción y evidencia ausente.
  • Resultado de la verificación del despliegue candidato.
  • La siguiente acción que devolvió la respuesta.
Etiqueta las causas y correcciones propuestas como propuestas.

​
Soluciona los errores de la CLI

Comprueba el código de salida del proceso antes de analizar la salida. Si todo va bien, el JSON va a la salida estándar. Un error de análisis termina con el código 2. Un error de ejecución termina con el código 1. Los errores JSON van a la salida de error estándar y contienen ok: false, error, message y next. Muestra next como orientación. No lo ejecutes automáticamente. Por ejemplo, logbrew issues archive "<issue_id_1>" "<issue_id_2>" --json no tiene --project. Termina con el código 2 antes de enviar la solicitud, con el error invalid_issue_command. Cuando la API rechaza una solicitud, error es api_error. Lee status para el estado HTTP y api_code para el código de error de la API. Una respuesta fallida no demuestra que un cambio de estado, prioridad o responsable no haya tenido efecto. Lee la incidencia antes de volver a intentarlo.

​
Qué hace útil a una incidencia

  • Un título claro y un mensaje legible.
  • Una huella estable.
  • Marcos de pila, cuando estén disponibles.
  • Contexto de release, entorno y servicio.
  • Contexto de la traza, cuando se capturó con la ocurrencia.
  • Atributos pequeños y relevantes, no volcados completos del contenido.
Consulta API de telemetría para los filtros de lista y los contratos de respuesta.