> ## Documentation Index > Fetch the complete documentation index at: https://docs.logbrew.co/llms.txt > Use this file to discover all available pages before exploring further. # Referencia de la CLI de LogBrew: comandos y filtros > Consulta los comandos, los filtros, la paginación por cursor, la observación en vivo, la salida JSON y los errores de LogBrew. La [CLI de LogBrew de código abierto](https://github.com/LogBrewCo/cli) lee telemetría y gestiona los datos de la cuenta desde una terminal. Empieza con [Usar la CLI](/es/guides/cli) para la instalación, el inicio de sesión y las tareas habituales. ## 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. | Familia de comandos | Propósito | | - | - | | `login`, `whoami`, `me`, `logout` | Iniciar sesión, leer la identidad de la cuenta o cerrar la sesión local. | | `status`, `health`, `doctor`, `version`, `examples` | Leer el acceso, la preparación del proyecto, la versión de la CLI o los ejemplos para empezar. | | `setup` | Leer los manifiestos locales e imprimir un plan de configuración del SDK. No cambia archivos ni ejecuta el comando de instalación. | | `projects` | Leer el catálogo de proyectos activos. | | `projects repositories` | Leer los repositorios conectados o descubrir los componentes de un repositorio. | | `projects create`, `projects keys create` | Crear un proyecto o crear una clave de ingesta para un proyecto existente. | | `projects setup` | Registrar la configuración observada de un proyecto existente. | | `projects archive`, `projects delete` | Archivar un proyecto o eliminarlo para siempre tras una confirmación. | | `usage`, `account usage` | Leer el uso, los límites, el estado de la cuota y las fechas de reinicio. | | `mcp grants`, `mcp revoke` | Listar por nombre los clientes MCP conectados a tu cuenta o revocar una conexión. | | `read` | Leer logs, incidencias, acciones, releases, métricas, trazas o un elemento. | | `explain` | Leer evidencia limitada de una incidencia, un log, una acción, una traza, un span, una métrica o un release. | | `investigate issue` | Leer la evidencia de investigación de una incidencia o verificar un despliegue candidato. | | `issues archive`, `issues resolve`, `issues reopen` | Definir el estado de 1 incidencia o de hasta 100 incidencias de un proyecto. | | `issues priority` | Definir la prioridad de 1 incidencia o de hasta 100 incidencias de un proyecto. | | `issues assign`, `issues unassign` | Definir o quitar el responsable, una cuenta o un equipo, de 1 incidencia o de hasta 100 incidencias de un proyecto. | | `issues assignees` | Listar las cuentas y los equipos a los que se pueden asignar incidencias en un proyecto. | | `issues owners` | Listar los propietarios sugeridos de 1 incidencia. | | `issues ownership` | Leer o definir las reglas de propiedad y el archivo CODEOWNERS de un proyecto. | | `issues activity` | Leer el historial de cambios de 1 incidencia. | | `issues rule`, `logs rule` | Definir la regla de severidad de 1 incidencia o de 1 firma de log. | | `inbox` | Leer las incidencias que otras personas te asignaron a ti o a tus equipos, o marcarlas como leídas. | | `set issue`, `resolve`, `close`, `ignore`, `reopen` | Definir el estado de 1 incidencia. `close` significa `resolved`. `ignore` e `ignored` significan `archived`. | | `deploy` | Registrar un despliegue completado. | | `debug-artifacts` | Subir archivos de depuración nativos de Apple o Android, o buscar la identidad de una imagen. | | `analytics` | Leer el resumen, las propiedades, las comparaciones, las rutas, los embudos, la retención o el ciclo de vida. | | `support` | Crear, leer, responder, cerrar o reabrir tickets de soporte. | | `watch` | Recibir en vivo logs, incidencias o acciones. | ## Lee el informe de doctor de un proyecto Usa un ID de proyecto de `logbrew projects --json`: ```bash theme={null} logbrew doctor --project "" --json ``` El comando lee el estado del proyecto y un log reciente. No crea un proyecto, no cambia ninguna clave ni registra la configuración. El informe tiene `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ó. | `status` del informe | Significado y siguiente paso | | - | - | | `auth_invalid` | Falta el acceso de la cuenta o no es válido. Una persona ejecuta `logbrew login`. | | `project_missing` | Esta cuenta no puede acceder al proyecto. Usa un ID de `logbrew projects --json`. | | `api_unreachable` | La solicitud a la API no se completó. Revisa la conexión de red y vuelve a ejecutar el comando. | | `check_failed` | Una solicitud falló o su respuesta no era válida. Vuelve a ejecutar el comando sin cambios. Si vuelve a fallar, [informa de un problema](/es/guides/report-a-problem). | | `needs_ingest_key` | El proyecto no tiene ninguna clave de ingesta activa. Crea una clave solo si tienes permiso para cambiar el proyecto. | | `needs_setup` | Hace falta configurar el SDK. Sigue el [Inicio rápido](/es/quickstart). | | `needs_telemetry` | La configuración empezó, pero LogBrew no tiene telemetría del proyecto. Envía un evento de prueba. | | `ready` | El proyecto tiene una clave activa y telemetría. Lee la señal que necesitas para tu tarea. | 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ódigo `0`: ```json theme={null} { "checks": [ { "check": "api", "next": "run the API reachability check first", "status": "not_checked" }, { "check": "auth", "next": "run logbrew login", "status": "missing" }, { "check": "project", "next": "resolve the prior check first", "status": "not_checked" }, { "check": "ingest_key", "next": "resolve the prior check first", "status": "not_checked" }, { "check": "setup", "next": "resolve the prior check first", "status": "not_checked" }, { "check": "telemetry", "next": "resolve the prior check first", "status": "not_checked" }, { "check": "logs", "next": "resolve the prior check first", "status": "not_checked" } ], "next": "run logbrew login", "status": "auth_invalid" } ``` Este informe es distinto del [diagnóstico de la API de proyectos](/es/concepts/projects#diagnose-project-setup). No contiene los campos de la API `state`, `setup_status` ni `next_action`. ## Filtros | Filtro | Comandos | | - | - | | `--project ` | logs, issues, actions, releases, metrics, traces, trace | | `--release ` | logs, issues, actions, releases, metrics, traces, trace | | `--environment ` | logs, issues, actions, releases, metrics, traces, trace | | `--service ` | logs, issues, actions, releases, metrics, traces | | `--since 24h` | logs, issues, actions, releases, metrics, traces, analytics | | `--until ` | logs, issues, actions, releases, metrics, traces, analytics | | `--limit 100` | logs, issues, actions, releases, metrics, traces | | `--severity error` | logs, watch | | `--search checkout` | logs | | `--trace ` | logs | | `--status unresolved` | issues (`unresolved`, `resolved`, `archived`) | | `--priority high` | issues (`high`, `medium`, `low`) | | `--assignee me` | issues (`me`, `none`, `my_teams`, un ID de usuario o `team:`) | | `--status error` | traces (`error`, `ok`) | | `--min-duration-ms ` | traces | | `--name ` | actions, metrics | | `--user ` | actions | `--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: ```bash theme={null} logbrew read logs --severity error \ --since 2026-10-01T00:00:00Z --until 2026-10-02T00:00:00Z --json ``` El ID del proyecto selecciona el proyecto. El nombre del servicio selecciona un componente de ese proyecto. Pon entre comillas los valores que contienen espacios: ```bash theme={null} logbrew read logs --project "" \ --service checkout-api --since 24h \ --severity error --search "checkout failed" --json ``` Si el texto de búsqueda empieza por un guion, pon `--` antes del texto: ```bash theme={null} logbrew logs --json -- --timeout ``` ## 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: ```bash theme={null} logbrew read issue "" --json ``` Usa `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: ```bash theme={null} logbrew explain issue "" --occurrence latest --json ``` `--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](/es/guides/investigate-an-issue) 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: ```bash theme={null} logbrew issues archive "" --json logbrew issues priority high "" --json ``` `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: ```bash theme={null} logbrew issues resolve "" "" \ --project "" --json ``` El resultado tiene 1 entrada por cada incidencia. Cada entrada es `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](/es/reference/telemetry-response-shapes#issue-response). ## 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: ```bash theme={null} logbrew issues assignees --project "" --json ``` Asigna 1 incidencia a una cuenta, a ti con `me` o a un equipo: ```bash theme={null} logbrew issues assign "" "" --json logbrew issues assign me "" --json logbrew issues assign "team:" "" --json ``` Quita el responsable: ```bash theme={null} logbrew issues unassign "" --json ``` Añade `--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: ```bash theme={null} logbrew read issues --project "" --assignee my_teams \ --status unresolved --json ``` La salida de texto muestra el nombre del responsable, o `team #` 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 ```bash theme={null} logbrew issues owners "" --json logbrew issues ownership --project "" --json logbrew issues ownership set --project "" \ --rules ownership.txt --codeowners .github/CODEOWNERS --json logbrew issues activity "" --limit 50 --json logbrew inbox --json logbrew inbox read --json ``` `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](/es/guides/issue-workflow#find-who-owns-an-issue). ## Define reglas de severidad ```bash theme={null} logbrew issues rule "" warning --json logbrew logs rule "" info --ignore --json ``` La severidad es `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: ```bash theme={null} logbrew read logs --project "" --since 24h \ --pagination cursor --limit 100 --json ``` La respuesta tiene `logs` y `next_cursor`. Un `next_cursor` que no es nulo tiene `time` e `id`. Envíalos con `--cursor-time` y `--cursor-id`: ```bash theme={null} logbrew read logs --project "" --since 24h \ --pagination cursor --limit 100 \ --cursor-time "" \ --cursor-id "" --json ``` Mantén los mismos filtros y el mismo límite en cada página. Detente cuando `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: ```json theme={null} { "logs": [], "next_cursor": null } ``` Las incidencias, las acciones y las métricas usan la misma forma con `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. | Código de salida | Significado | | - | - | | `0` | Éxito. El JSON está en la salida estándar. | | `1` | El comando falló durante la ejecución, por ejemplo por un error de la API o de red. | | `2` | La CLI rechazó el comando antes de ejecutarlo. | 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: ```json theme={null} { "ok": false, "error": "unknown_resource", "message": "unknown resource: traces", "next": "use logbrew traces for recent traces, or logbrew trace for one trace" } ``` `logbrew read logs --limit 0 --json` termina con el código `2` y escribe: ```json theme={null} { "ok": false, "error": "invalid_limit", "message": "invalid limit: 0", "next": "use --limit with a positive whole number" } ``` Corrige el valor y vuelve a ejecutar el comando. Un comando rechazado no es un resultado vacío. Consulta [Errores de la API](/es/reference/api-errors) para los errores HTTP y [API de telemetría](/es/reference/telemetry-api) para las solicitudes directas a la API. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.