https://api.logbrew.co. Los SDK
públicos envían sus lotes gestionados a POST /v1/events. Los clientes
nativos personalizados envían sobres nativos a POST /api/telemetry/ingest.
Las dos rutas de ingesta requieren un token bearer de ingesta limitado al
proyecto.
Las lecturas y los cambios propios de la cuenta usan un token bearer de cuenta.
Nunca uses un token bearer de cuenta ni una sesión del navegador en la
configuración del SDK o de la ingesta. Nunca envíes un token bearer de ingesta
a una ruta de lectura.
Envía una solicitud acotada
Usa esta lista de comprobación antes de que un cliente envíe una solicitud:- Elige la ruta y el método HTTP en la tabla de endpoints.
- Usa el token bearer correcto: uno de ingesta para la ingesta y uno de cuenta para todo lo demás.
- Selecciona el alcance de proyecto que admite la ruta. No amplíes el alcance después de una respuesta vacía.
- Añade solo las claves de consulta que acepta la ruta. Consulta Filtros de consulta.
- Envía
Content-Type: application/jsoncuando la ruta tenga un cuerpo JSON. - Lee el estado HTTP y el cuerpo de la respuesta antes de reintentar.
- Mantén los tokens bearer, los tickets de actividad en vivo y los cuerpos completos de las respuestas fuera de los logs y de los prompts de los agentes.
Endpoints
Ingesta
Deja que el SDK construya los lotes de
/v1/events. No los construyas a mano.
Para el sobre nativo, consulta Integración del SDK.
Lecturas de telemetría
Despliegues
Registra un despliegue desde la automatización de releases cuando termine bien
o falle. El cuerpo de
PUT tiene project_id, release, environment,
service_name, status (succeeded o failed), started_at, finished_at
y un commit_sha opcional. Usa los mismos valores de release,
environment y service_name que envía tu SDK. La cuenta debe ser
propietaria del proyecto.
deployment_id es tu propio ID para el despliegue. Un reintento con el mismo
ID y el mismo cuerpo devuelve el despliegue guardado. El mismo ID con un cuerpo
distinto falla con 409 e idempotency_conflict. Usa un ID nuevo para un
despliegue distinto.
Investigaciones
Cada ruta de investigación devuelve un paquete de evidencia acotado de un sujeto. El comandologbrew explain de la CLI lee estas
rutas y valida la respuesta.
Analíticas de producto
Las rutas
POST de analíticas reciben un cuerpo JSON, no claves de consulta.
Consulta Analíticas de producto.
Actividad en vivo
Cuenta e inicio de sesión
Las rutas de uso, cuota, suscripción y cierre de sesión están en la API de cuenta.Códigos de estado de éxito
Una respuesta
200 no demuestra que la evidencia esté completa. Lee los campos
de cobertura, truncado y estado de la respuesta.
Filtros de consulta y paginación
Cada ruta de lectura acepta sus propias claves de consulta. Los alias cómodos comoproject, trace y user no son claves de consulta. Las rutas de lista
devuelven por defecto un array simple, y un sobre con cursor con
pagination=cursor. La lista de despliegues siempre devuelve un objeto de
página. Consulta
Filtros de consulta.
Respuestas y errores
- Formatos de respuesta muestra un ejemplo de cada familia de respuestas.
- Errores de la API enumera los códigos de error y las acciones de recuperación.
code antes que el mensaje para personas. Usa next_action para el
comportamiento del programa y next como guía para las personas. No analices
el texto de error ni de next.
Actualiza incidencias
Estas solicitudes usan un token bearer de cuenta. Es distinto a propósito deLOGBREW_INGEST_BEARER. La cuenta debe tener permiso para gestionar
incidencias en el proyecto de la incidencia. Si no lo tiene, la solicitud falla
con 403 y forbidden. El mismo permiso cubre los cambios de estado, de
prioridad y de responsable, y las reglas de incidencias y de logs.
Cada solicitud define 1 o más de estos campos:
Una solicitud sin ninguno de estos campos falla con
422 y
validation_failed.
Una incidencia tiene 0 o 1 responsable: una cuenta o un equipo. Una cuenta
debe poder leer el proyecto, y un equipo debe pertenecer a la organización del
proyecto. Si no se cumple, la solicitud falla con 422 y validation_failed,
y LogBrew no cambia nada. Obtén las cuentas que puedes asignar con
Lista los responsables. Cualquier otro valor de assignee
también falla con 422 y validation_failed.
Una prioridad que defines se mantiene fija. Sin una prioridad definida por ti,
la prioridad sigue la severidad de la incidencia: error y critical son
high, warning es medium e info es low.
Un campo que ya tiene el valor solicitado no cambia. Puedes volver a enviar la
misma solicitud después de un tiempo de espera agotado. Un tiempo de espera
agotado no demuestra que el cambio no ocurriera. Vuelve a leer la incidencia
antes de enviar un cambio distinto.
Actualiza una incidencia
Añaderesponse_version=4 para obtener archived, la prioridad y el
responsable en la respuesta. En la versión 4, assignee es
{ "type": "user", "user_id", "name", "email" },
{ "type": "team", "team_id", "slug", "name" } o null. La versión 3 muestra
como null un responsable que es un equipo.
Actualiza incidencias en bloque
Envíaproject_id y de 1 a 100 ID de incidencias distintos de ese proyecto:
project_id y results, con 1 resultado por cada ID de incidencia, en
el orden de la solicitud. Cada resultado tiene issue_id, outcome e issue.
issue es la incidencia actual en la versión 3 de la respuesta, o null con
not_found. Añade "response_version": 2 al cuerpo para obtener cada
incidencia en la versión 4 de la respuesta.
Una lista vacía, más de 100 ID o un ID repetido fallan con
422 y
validation_failed. Divide un conjunto más grande en más solicitudes. Si la
cuenta no puede leer el proyecto, la solicitud falla con 404 y not_found.
Lista los responsables
Envía el ID del proyecto para obtener todas las cuentas a las que se pueden asignar incidencias en ese proyecto:user_id, name y email. name es null cuando la cuenta no tiene
nombre. Añade response_version=2 para obtener también teams: todos los
equipos de la organización del proyecto, con team_id, slug y name.
Consulta la
respuesta de la lista de responsables.
Cualquier cuenta que pueda leer el proyecto puede obtener esta lista. Si la
cuenta no puede leer el proyecto, la solicitud falla con 404 y not_found.
Cuando un miembro pierde el acceso al proyecto, las incidencias asignadas a ese
miembro no muestran responsable. Si el miembro recupera el acceso, las
incidencias vuelven a mostrarlo, salvo que alguien haya cambiado o quitado el
responsable mientras tanto.
Propiedad y propietarios sugeridos
GET /api/telemetry/issues/ownership?project_id=<project-uuid> devuelve
rules, codeowners, updated_at y unresolved_owners. Cualquier cuenta que
pueda leer el proyecto puede leerlo. PUT con project_id y rules,
codeowners o ambos sustituye ese texto y requiere permiso para gestionar
incidencias. Un campo que no envías conserva su texto, y una cadena vacía lo
borra. Cada texto ocupa 128 KiB como máximo. Un texto no válido falla con
422 e indica la línea.
GET /api/telemetry/issues/{issue_id}/owners?response_version=2 devuelve
suggested_assignee, owners e inputs. Cada propietario tiene type
(user o team), source (ownership_rule, codeowners o
recent_activity), rule, line y matched. La versión 1, la
predeterminada, solo muestra cuentas.
Historial de la incidencia
GET /api/telemetry/issues/{issue_id}/activity?response_version=2 devuelve
activity, de lo más reciente a lo más antiguo, y next_cursor. Cada entrada
tiene type (status, priority, assigned, unassigned, severity_rule
o first_seen), value, actor_id, actor, assignee_id, assignee,
team y at. limit va de 1 a 200, y es 50 de forma predeterminada. Envía
cursor_time y cursor_id de next_cursor para obtener la página siguiente.
Notificaciones
GET /api/telemetry/issues/notifications devuelve notifications, unread,
read_at y next_cursor. Cada notificación es una asignación de una
incidencia a ti o a tu equipo hecha por otra cuenta.
POST /api/telemetry/issues/notifications/read con un objeto JSON vacío, o con
read_at, mueve tu marca de lectura. La marca nunca retrocede.
Define reglas de incidencias y de logs
Una regla cambia cómo muestra LogBrew las señales que coinciden. No elimina datos. Laseverity capturada no cambia, y la respuesta muestra la regla en
triage.
severity es info, warning, error, critical o source. source quita
la anulación y vuelve a mostrar la severidad capturada. En una regla de logs,
ignored: true oculta los logs que coinciden de la lista de logs
predeterminada. Léelos con status=ignored o status=all. La regla se aplica
a las señales que coinciden, tanto conservadas como futuras. Cualquier otro
valor falla con 422 y validation_failed.