Usa
--json en los flujos de trabajo de agentes. Guarda las credenciales en
una configuración local protegida. Entre personas, herramientas y agentes,
comparte solo nombres de variables.Antes de empezar
Prepara lo siguiente:- Node.js 18 o posterior.
- La CLI de LogBrew v0.1.30 o posterior.
jq.- Bash o Zsh.
- Un directorio de paquete para una app de Node.js del lado del servidor.
quickstart-node, el entorno development y el
release quickstart@1. Mantén esta prueba separada de producción. Para otro
runtime, usa Integración del SDK.
Envía y lee tu primer log
1
Lee el estado de la cuenta
Instala la CLI con el comando de Usar la CLI.
Después, lee el estado de tu cuenta.Punto de control: el estado indica un acceso de cuenta autenticado. Si
no es así, una persona ejecuta
logbrew login una vez. Después, vuelve a
ejecutar logbrew status --json. Un agente no debe volver a iniciar
sesión cuando la autenticación actual funciona.2
Crea un proyecto desde la CLI
Elige un archivo nuevo en un directorio al que solo tú tengas acceso. La
CLI escribe la clave de ingesta del proyecto en ese archivo antes de
informar del éxito. Nunca imprime la clave ni la ruta del archivo.Crear un proyecto cambia el estado de la cuenta. El archivo de destino no
debe existir. Si el resultado no está claro, vuelve a ejecutar exactamente
el mismo comando. La CLI reutiliza la identidad de su solicitud pendiente.
Usa
--abandon-retry solo para empezar un intento distinto.Punto de control: la salida indica status: "created", el estado de
configuración created y un tipo de clave de ingesta. El proyecto existe
y la clave está guardada. Esto no demuestra que la telemetría llegue.
Consulta Proyectos y configuración.3
Instala el SDK de Node.js
4
Envía un log seguro con el SDK
Envía los marcadores de release y de entorno junto con un log No pongas credenciales, cabeceras, cuerpos de solicitud, datos de clientes
ni rutas locales en el evento.Punto de control: el script imprime
info que
solo contiene valores de ejemplo. La clave se define solo para este
proceso de Node.js. La identidad de la aplicación va en context.Cada ejecución crea ID de evento nuevos. Si el SDK reintenta la entrega en
la misma ejecución, envía el mismo cuerpo con los mismos ID. LogBrew no
guarda por segunda vez un evento aceptado cuando un reintento lo vuelve a
enviar."ok":true con un status_code
2xx. attempts es mayor que 1 después de un reintento. Un envío
correcto no es la última comprobación.Si la entrega falla, el script termina con el código 1 e imprime un
error JSON breve, como {"ok":false,"error":"unauthenticated"}. No
imprime el cuerpo de la solicitud ni la clave. Una clave de proyecto
rechazada provoca unauthenticated. Volver a iniciar sesión en la CLI no
lo soluciona.5
Lee el informe de doctor del proyecto
La CLI usa el acceso de cuenta que tiene guardado para esta lectura. No
uses la clave de ingesta del proyecto.Punto de control: el informe tiene
status: "ready". Lee también cada
elemento de checks. El código de salida 0 no demuestra que todas las
comprobaciones pasaran. Si el estado es otro, sigue next y la
referencia del informe de doctor.
Un proyecto en ready no demuestra que este log de prueba haya llegado.6
Lee el log de prueba
Usa el proyecto, el release y el entorno del lote del SDK.Punto de control:
LogBrew quickstart check aparece para ese
proyecto, release y entorno. Esto solo demuestra la entrega del log de
prueba.Lee el resultado de la prueba
El ejemplo envía tres eventos. Solo uno es un log. Los marcadores de release y de entorno dan contexto al log.
Deja la prueba en
info. No la cambies a error para encontrarla más
fácilmente. Usa los filtros de proyecto y de tiempo. Consulta
Valores de severidad.
La línea console.log imprime el resultado de la entrega en tu terminal. La
llamada client.log envía el log a LogBrew. Una primera entrega correcta
imprime:
--project de la CLI no mueve eventos.
Este log no tiene contexto de traza porque el ejemplo no crea un span de
solicitud. Eso no significa que el log haya fallado. La lectura de la CLI es
una instantánea. Vuelve a ejecutarla para leer eventos posteriores, o usa
logbrew watch logs --json para ver un flujo en vivo.
Decisiones habituales de recuperación
Si la telemetría sigue sin aparecer, usa las
comprobaciones de la primera telemetría.
Si esas comprobaciones no ayudan, informa de un problema.
No adjuntes credenciales, telemetría sin procesar, datos de clientes, rutas
locales ni código fuente.
Llévalo a tu aplicación
- Crea el cliente una sola vez en el código de configuración de tu app.
- Fija las versiones del SDK en tus archivos de paquetes. Prueba las actualizaciones fuera de producción.
- Carga la clave de ingesta desde tu configuración de secretos actual. Rótala si puede haber quedado expuesta. Consulta Rotar una clave de ingesta.
- Usa nombres estables de servicio, entorno y release tomados de la configuración del despliegue. Consulta Releases.
- Escribe mensajes de log que nombren la operación y su resultado, como
Report generation completed. Mantén los valores privados fuera del mensaje. No copies una solicitud completa ni un registro de usuario entero en un log. - Usa un solo emisor para cada log de la aplicación y así evitarás registros duplicados. Antes de añadir LogBrew, busca la integración que ya envía cada registro.
- Antes de desplegar en producción, envía un evento seguro por la ruta de código real y léelo en LogBrew. Comprueba su mensaje, servicio, release y entorno. Un ejemplo independiente no prueba la ruta de código de tu aplicación.
Proyectos y configuración
Lee el estado de la configuración y gestiona las claves de ingesta del
proyecto.
Integración del SDK
Elige el paquete del SDK para tu runtime.
Investigar una incidencia
Sigue la evidencia de la traza y de los logs relacionados de una
incidencia.
Informar de un problema
Envía un informe de soporte seguro y privado.
