Skip to main content
Crea un proyecto de desarrollo. Envía un log de Node.js. Después, léelo en LogBrew. La CLI crea el proyecto y guarda su clave de ingesta. Solo hace falta iniciar sesión en el navegador cuando la CLI no tiene un acceso de cuenta válido.
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.
El ejemplo usa el proyecto 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.
Guarda el archivo de la clave de ingesta fuera del repositorio, y que solo tú puedas leerlo. No pongas esta clave de servidor en código del navegador, en un bundle público ni en un prompt.

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

Nunca uses una credencial de la cuenta como configuración del SDK. Mantén la clave del proyecto fuera de la salida de los comandos, los prompts, los tickets, los archivos de código fuente y la configuración de los paquetes.
4

Envía un log seguro con el SDK

Envía los marcadores de release y de entorno junto con un log 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.
No pongas credenciales, cabeceras, cuerpos de solicitud, datos de clientes ni rutas locales en el evento.Punto de control: el script imprime "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:
La clave de ingesta elige el proyecto que recibe el log. Un filtro --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.
Este ejemplo no configura la captura en el navegador, los mapas de origen ni la captura móvil. Para eso, empieza por Integración del SDK.

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.