Cómo funciona la CLI
Usa texto legible en una terminal. Usa--json en scripts y agentes de
programación.
Las lecturas de la cuenta necesitan un inicio de sesión de cuenta. Antes de
iniciar sesión, ejecuta logbrew status --json. Una persona debe completar la
autorización en el navegador. Las claves de ingesta del proyecto envían
telemetría. No pueden sustituir al inicio de sesión de la cuenta.
La creación de proyectos, la creación de claves, los cambios de estado, de
prioridad y de responsable de las incidencias, los despliegues y las
actualizaciones de soporte cambian los datos de la cuenta. Antes de ejecutar
uno, comprueba que la acción y el destino sean correctos.
Ejecuta logbrew --help para ver todos los comandos. Añade --help a un
comando, como logbrew read logs --help, para ver sus opciones. Ejecuta
logbrew help json para ver las reglas de JSON.
Lee el informe de doctor de un proyecto
Usa un ID de proyecto delogbrew projects --json:
status, checks y next. Cada comprobación tiene check,
status y next. Las comprobaciones son api, auth, project,
ingest_key, setup, telemetry y logs.
El código de salida 0 significa que la CLI escribió un informe. No significa
que el proyecto esté listo. Lee el status del informe y cada comprobación. Una
comprobación not_checked no se superó.
Cuando la lectura del proyecto funciona, la comprobación
logs es visible,
empty, unavailable, error o invalid_response. Esta comprobación no
cambia el status del informe. Un resultado de logs vacío no dice nada de las
demás señales. Una lectura fallida no es un resultado vacío.
Usa next como guía de recuperación. No da permiso para cambiar el estado de
la cuenta ni del proyecto.
Ejemplo: falta el acceso de la cuenta
Sin credenciales de cuenta, el comando no hace ninguna solicitud a la API. Escribe este informe en la salida estándar y termina con el código0:
state, setup_status ni next_action.
Filtros
--since acepta una duración como 24h o 7d, o una marca de tiempo RFC 3339.
--until acepta una marca de tiempo RFC 3339. Es un final exclusivo y debe ser
posterior a --since. La lectura de una incidencia por ID no acepta --until.
La severidad de un log es info, warning, error o critical. El estado de
una incidencia es su estado en el flujo de trabajo, no su severidad.
--status ignored es un nombre antiguo de --status archived. --status open
significa unresolved, y --status closed significa resolved.
--assignee none selecciona las incidencias sin responsable, y
--assignee my_teams selecciona las incidencias de tus equipos. Cualquier otro
valor de --assignee falla con invalid_assignee.
La CLI también acepta estos alias: --project-id, --env, --service-name,
--trace-id, --distinct-id y --level para --severity. Usa los nombres de
la tabla en los scripts nuevos.
Este comando lee los errores de 1 día:
-- antes del texto:
Selecciona una ocurrencia de una incidencia
Una incidencia agrupa las ocurrencias que coinciden. Lee la incidencia para ver su estado, el número de ocurrencias y las horas en que se vio por primera y por última vez:explain issue o investigate issue para ver la evidencia de una
ocurrencia. Sin --occurrence, LogBrew selecciona la ocurrencia recomendada.
No siempre es el evento más reciente. Para leer el evento más reciente:
--occurrence también acepta recommended, first o un ID de ocurrencia que
devolvió LogBrew. Estos comandos rechazan los filtros de proyecto, release,
entorno y tiempo. Antes de comparar la evidencia, lee la marca de tiempo de la
ocurrencia seleccionada. Consulta
Investigar una incidencia para ver los campos de
la evidencia.
Cambia el estado y la prioridad de las incidencias
Usa 1 ID de incidencia para cambiar 1 incidencia:archive define archived, resolve define resolved y reopen define
unresolved. La prioridad es high, medium o low. Una prioridad que
defines se mantiene fija. Si no, la prioridad sigue la severidad de la
incidencia.
Para cambiar más de 1 incidencia, añade --project. Todas las incidencias
deben estar en ese proyecto. Un comando cambia hasta 100 incidencias:
updated,
unchanged o not_found. Una incidencia unchanged ya tenía el valor
solicitado. Puedes volver a ejecutar el mismo comando después de un fallo de
red.
Estos comandos no piden confirmación. Revisa antes los ID de las incidencias.
Las lecturas y los cambios de incidencias muestran archived en lugar de
ignored, y el priority, el priority_source y el assignee de cada
incidencia. Consulta la
respuesta de incidencia.
Asigna incidencias
Una incidencia tiene 0 o 1 responsable: una cuenta o un equipo. Lista las cuentas y los equipos que puedes asignar en un proyecto:me o a un equipo:
--project para cambiar hasta 100 incidencias de ese proyecto, igual
que con el estado y la prioridad. Una cuenta debe poder leer el proyecto, y un
equipo debe pertenecer a la organización del proyecto. Para encontrar las
incidencias asignadas a ti o a tus equipos:
team #<slug> si es
un equipo. Si la cuenta no tiene nombre, muestra la dirección de correo
electrónico y, si no, el ID de usuario. Una incidencia sin responsable muestra
unassigned.
Propietarios, historial y bandeja de entrada
issues owners muestra los propietarios sugeridos y la evidencia que revisó.
issues ownership set envía archivos locales de 128 KiB como máximo cada uno.
Un archivo vacío borra su texto. issues activity e inbox aceptan --limit
de 1 a 200, y --cursor-time con --cursor-id a partir de next_cursor.
Consulta
Averigua quién es el propietario de una incidencia.
Define reglas de severidad
info, warning, error, critical o source. source
vuelve a mostrar la severidad capturada. --ignore oculta los logs que
coinciden en la lista de logs predeterminada. Sin --ignore, la regla los
muestra.
Lee la página siguiente
Los logs, las incidencias, las acciones, las métricas y las trazas aceptan la paginación por cursor. Los releases no. Usa--pagination cursor en la
primera página:
logs y next_cursor. Un next_cursor que no es nulo tiene
time e id. Envíalos con --cursor-time y --cursor-id:
next_cursor sea null. Usa el cursor, no el número de filas, para saber si
hay más páginas. La última página puede estar vacía:
issues, actions o metrics en lugar de logs.
Observación en vivo
logbrew watch --json envía en vivo logs, incidencias y acciones. Añade
logs, issues o actions para recibir un solo tipo. tail, follow y
stream son alias de watch. Watch no admite trazas ni spans.
Watch necesita --json. Sin él, el comando escribe watch streams JSON for agents y termina con el código 1.
Los eventos de incidencias de watch muestran una incidencia archivada como
ignored, sin prioridad. Lee la incidencia para obtener su estado y su
prioridad actuales.
Watch solo acepta --severity, como --severity error,critical.
logbrew watch actions no acepta --severity. La CLI aplica este filtro
después de recibir los eventos. No reduce lo que envía el servidor. Watch no
tiene filtro de proyecto, release, entorno ni tiempo. Para esos filtros, usa un
comando read. Después de una desconexión temporal, la CLI espera y vuelve a
conectarse.
Lee los resultados y los errores
Pon--json antes o después del comando. Lee el código de salida antes de usar
la salida. No analices la salida para personas. Puede cambiar entre versiones.
La salida correcta conserva la forma de la respuesta de la API. Puede ser un
array o un objeto. Sin paginación por cursor, una lectura de logs devuelve un
array. Un array vacío significa que ningún log coincide. No es un error.
Los errores van a la salida de error estándar. La excepción es
debug-artifacts --json, que escribe los errores en la salida estándar. Un
error JSON tiene ok, error, message y next. Usa error como código de
fallo estable. Revisa next antes de ejecutar el comando que sugiere.
Por ejemplo, logbrew watch traces --json termina con el código 2 y escribe:
logbrew read logs --limit 0 --json termina con el código 2 y escribe: