Compilar, Probar y Perfilar desde la Shell

Ejecuta compilaciones y pruebas desde la shell, captura perfiles con go tool pprof y alinea fallos con las marcas de tiempo de journalctl en hosts Linux.

Resumen

La toolchain de Go es nativa de la CLI: go build, go test y go tool pprof están diseñados para scripts, CI y sesiones SSH.

Combínalos con redirección de shell, tee y consultas de journal para que una prueba fallida en tu portátil use los mismos comandos que ejecutarás durante un incidente de producción.

Receta

Tarjeta de receta de referencia rápida - lista para copiar y pegar.

# Compilar y probar desde la raíz del módulo
go build -o bin/api ./cmd/api
go test ./... -count=1 -race 2>&1 | tee test.log
 
# Perfilar CPU de un benchmark localmente
go test -bench=. -benchmem -cpuprofile=cpu.prof -run=^$ ./...
go tool pprof -http=:0 cpu.prof
 
# Obtener perfil de un servidor en ejecución (cuando el endpoint pprof está habilitado)
curl -s "http://localhost:6060/debug/pprof/profile?seconds=30" -o live.prof
go tool pprof live.prof
 
# Correlacionar con logs de systemd
sudo journalctl -u api.service --since "10 min ago" --no-pager

Cuándo usar esto:

• Necesitas un bucle de compilación/prueba repetible antes de abrir un PR.
• La latencia ha retrocedido y quieres evidencia de CPU o heap, no suposiciones.
• Un servicio falló en una VM y debes alinear la salida de go test con las marcas de tiempo del journal.

Ejemplo de Trabajo

#!/usr/bin/env bash
set -euo pipefail
cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
 
# Compilar
mkdir -p bin
go build -ldflags="-s -w" -o bin/api ./cmd/api
 
# Probar con detector de carreras; mantener el artefacto de log
go test ./... -count=1 -race -timeout=5m 2>&1 | tee artifacts/test-$(date +%Y%m%d%H%M).log
 
# Micro-benchmark + perfil de CPU para un paquete
PKG=./internal/handler
go test "$PKG" -bench=BenchmarkHealth -benchmem \
  -cpuprofile=artifacts/cpu.prof -run=^$ -count=1
 
go tool pprof -top artifacts/cpu.prof | head -20
 
# Si api.service se ejecuta en este host, obtener líneas recientes del journal
if systemctl is-active --quiet api.service 2>/dev/null; then
  journalctl -u api.service --since "15 min ago" -n 200 --no-pager \
    | tee artifacts/api.journal.snippet
fi

Lo que esto demuestra:

• Directorio de artefactos para binarios, logs de pruebas y perfiles con marcas de tiempo.
• go test ./... habilitado para detector de carreras, adecuado para paridad con CI.
• Perfil de CPU acotado a benchmarks en lugar de perfilar todo el módulo a ciegas.
• Fragmento de journalctl capturado junto a la salida de la prueba para cuadernos de incidentes.

Profundización

Cómo Funciona

• go build compila paquetes; -o nombra el binario de salida y -ldflags inyecta metadatos de versión o elimina símbolos de depuración.
• go test ejecuta archivos _test.go; flags como -race, -count=1 y -timeout se mapean directamente a YAML de CI.
• go test -cpuprofile y -memprofile adjuntan muestreo de runtime/pprof durante pruebas o benchmarks.
• go tool pprof lee archivos de perfil o URLs y puede abrir una interfaz web local (-http) para grafos de llama.
• Los servicios en vivo exponen /debug/pprof/* cuando importas net/http/pprof y escuchan en un puerto de depuración (protege en producción).
• journalctl lee el journal de systemd; filtrar por unidad y rango de tiempo coloca las trazas de pila de Go junto a eventos OOM o de reinicio.

Flags Útiles de go test

Patrones de Obtención de pprof

Notas de Go

// cmd/api/main.go - listener de depuración opcional (solo staging)
import _ "net/http/pprof"
 
go func() {
    log.Println(http.ListenAndServe("127.0.0.1:6060", nil))
}()

Vincula a loopback, protege con autenticación o política de red antes de exponer más allá de localhost.

Trampas

• Perfilar sin carga - Un perfil de CPU de 30s en un servidor inactivo muestra pilas inactivas. Solución: reproduce tráfico con hey, k6 o pruebas de integración mientras perfilas.
• Dejar pprof en :6060 público - Los atacantes escanean puertos pprof abiertos. Solución: vincula a 127.0.0.1, usa port-forward o limita con autenticación.
• La caché de pruebas oculta fallos - Las pruebas inestables pasan localmente después de una ejecución correcta. Solución: go test -count=1 en CI y al depurar inestabilidades.
• Detector de carreras solo en Go puro - Los paquetes con mucho CGO pueden necesitar compilaciones etiquetadas. Solución: divide las ejecuciones de carreras por paquete o usa -tags consistentemente.
• Logs enormes de go test ./... - Los fallos se desplazan fuera de la pantalla en tmux. Solución: siempre usa tee a un archivo y rg FAIL después.
• Confusión de zona horaria del journal - journalctl usa la hora local por defecto; la UTC de CI difiere. Solución: pasa --utc o anota los desfases en los documentos de incidentes.

Alternativas

Preguntas Frecuentes

Relacionado

• Conceptos Básicos de la CLI de Linux - tee y canalización de logs
• Búsqueda, ripgrep y jq para Depuración - buscar salida de pruebas y logs
• systemd y Archivos de Unidad de Servicio para Binarios Go - integración de journal
• Contenedores desde la CLI: docker y kubectl - port-forward para pprof
• Conceptos Básicos de Pruebas en Go - profundidad de pruebas en Go

Versiones de Stack: Esta página fue escrita para Go 1.26.x (predeterminado Green Tea GC, go fix modernizers - verificar parche en la compilación), chi (última - verificar en la compilación), gin (última - verificar en la compilación), echo (última - verificar en la compilación), google.golang.org/grpc (última - verificar en la compilación), sigs.k8s.io/controller-runtime (última - verificar en la compilación), kubebuilder (última - verificar en la compilación), tinygo (última - verificar objetivos de placa en la compilación), wazero (última - verificar en la compilación), y golangci-lint (última - verificar conjunto de linters en la compilación).