LogLens: la CLI en Java para leer logs de Kubernetes

En pocas palabras: Sushrut Vaidya, ingeniero de plataforma en Apple AdPlatforms, creó LogLens, una CLI en Java 21 publicada el 25 de octubre de 2026 que convierte logs de Kubernetes en JSON, logfmt o klog en líneas legibles, con flags –trace y –stats para seguir requests y triar incidentes sin grep.

LogLens es una herramienta de línea de comandos escrita en Java 21 que lee logs desde un archivo o desde stdin y los imprime en un formato legible, sin necesitar agente, backend ni cambios en la aplicación que genera los logs. Sirve para leer logs de Kubernetes que llegan mezclados en JSON, logfmt, klog u otros formatos dentro del mismo stream, y se instala como binario nativo compilado con GraalVM.

¿Por qué cuesta tanto leer los logs de kubectl logs?

Leer logs de Kubernetes con kubectl logs cuesta porque un pod devuelve cientos o miles de líneas de una sola tirada, y si la aplicación loguea en JSON el formato es cómodo para una máquina pero incómodo para un humano mirando una terminal. Vaidya, que según cuenta en su publicación de dev.to mantiene miles de DAGs de Airflow en Apple AdPlatforms, admite que encontrar el error real a veces termina siendo más difícil que arreglarlo.

Ponele que corrés kubectl logs -f mypod y necesitás encontrar una conexión caída entre miles de líneas. Terminás grepeando un request ID y esperando no haberte perdido nada importante en el camino. ¿Alguien hace esto a mano cada vez que hay un incidente? La mayoría, sí (spoiler: no es nada cómodo).

¿Qué es LogLens y cómo transforma un log JSON en algo legible?

LogLens toma una entrada JSON como {"timestamp":"2026-08-15T10:24:10.489Z","level":"error","trace_id":"9f2c-a1","message":"Connection to 10.0.3.14:5432 timed out after 30012ms","service":"api","status":500} y la convierte en una sola línea coloreada: 10:24:10 ERROR Connection to 10.0.3.14:5432 timed out after 30012ms req=9f2c-a1 service=api status=500. La herramienta lee de un archivo o de stdin y escribe a stdout, sin agente, sin backend y sin tocar la app que generó el log. Tema relacionado: si corrés clusters locales en Mac con Apple Silicon.

Eso sí: la información original sigue intacta, solo que ahora es más fácil escanearla con la vista. Lo interesante es que LogLens se cuelga de los comandos que ya usás todos los días, en vez de pedirte un dashboard nuevo o una instalación en el clúster.

¿Cómo seguir un request específico en los logs de un pod de Kubernetes?

Para seguir un request puntual, LogLens tiene el flag –trace, que filtra el stream por un ID de correlación y lo resalta. El comando kubectl logs -f mypod | loglens --trace 9f2c-a1 muestra solo las líneas asociadas a esa transacción, sin armar un grep manual cada vez que algo se rompe.

El caso real que menciona Vaidya es un servicio Spring Boot que logueaba JSON de una sola línea con un X-Request-Id en cada entrada. Según el ejemplo publicado en el repositorio de GitHub, el flag –trace reconstruye el timeline completo de un request con –trace 9f2c-a1: primero un cache miss consultando la base, después un warning de HikariPool avisando que el pool de conexiones no tenía disponibilidad, luego el error de conexión a 10.0.3.14:5432 con timeout a los 30012ms (con su stack trace pegado al error, no suelto por ahí) y finalmente un 200 OK que tardó 171014ms en llegar. Cinco líneas y un stack trace alcanzan para entender todo el incidente, en vez de scrollear miles de entradas buscando la aguja en el pajar.

¿Cómo usar –stats para analizar un incidente con cientos de errores?

El flag –stats resume un incidente contando líneas por nivel y por fuente, agrupa mensajes parecidos en un solo hallazgo y marca el minuto donde picaron los errores. Con loglens --stats --quiet incident.log, el ejemplo del repositorio muestra un resumen de 12 líneas entre las 10:22:01 y las 10:24:52, con 6 errores, 2 warnings, 3 infos y 1 debug, y el pico ubicado a las 10:24 con 6 errores en ese minuto puntual.

Lo que hace –stats que un grep no hace es agrupar. Cuatro timeouts de conexión que solo cambian en la IP o en la duración exacta se muestran como un único hallazgo repetido 4 veces, en vez de cuatro líneas sueltas que obligan a leer cada una por separado para darse cuenta de que es el mismo problema. No te dice la causa raíz, pero te da una lista corta de sospechosos antes de arrancar a buscar con –trace. Relacionado: los problemas de legibilidad que también ataca KYAML.

¿Qué formatos de logs soporta LogLens?

LogLens soporta JSON lines, logfmt, klog, logs de Airflow, Python logging y el formato estilo Log4j que usan Spark, Hadoop, Kafka, Hive y Flink, además de un formato genérico de timestamp y nivel como respaldo. Según el repositorio de GitHub, cada línea pasa por una cadena ordenada de parsers, del más específico al más genérico, y si ninguno matchea, la línea se imprime tal cual, sin inventarle una estructura que no tiene.

Esa decisión de no adivinar me parece de las más sensatas del proyecto. Una herramienta de logs que transforma silenciosamente algo que no entiende en datos “parseados” termina mintiendo en algún punto, y ese es justo el tipo de bug que aparece a las tres de la mañana en medio de un incidente.

¿Cómo instalar LogLens: binario nativo o compilado con Maven?

Instalar LogLens no exige tener un JDK instalado: Vaidya compiló binarios nativos con GraalVM native-image para macOS Apple Silicon, Linux x86-64, Linux ARM64 y Windows x86-64, que se instalan con curl -fsSL https://raw.githubusercontent.com/SushrutVaidya/loglens/main/install.sh | sh. El script detecta el sistema operativo y la arquitectura, descarga el binario correcto y lo deja en el PATH.

Si preferís compilarlo vos mismo, necesitás JDK 21 o superior. El flujo es git clone del repositorio, después mvn package (que corre los 44 tests del proyecto antes de armar el jar) y finalmente java -jar target/loglens.jar –help. Si tu clúster corre sobre un VPS propio, como los que ofrece donweb.com, sumar una utilidad chica como esta no agrega fricción real al stack: es un binario, no un servicio nuevo que mantener.

¿Qué limitaciones tiene LogLens frente a una plataforma de observabilidad?

LogLens no colecciona, almacena ni indexa logs, y no tiene dashboard: el propio Vaidya aclara en su publicación que la herramienta no reemplaza a una plataforma de observabilidad, y que kubectl, tail y la infraestructura de logging existente siguen haciendo el trabajo de recolección. El filtrado por rango de tiempo (–since) todavía no está implementado, y el proyecto, liberado bajo licencia Apache 2.0, está en una etapa temprana con algunos formatos que todavía tienen huecos.

“Prefiero ser claro sobre esas limitaciones antes que pretender que una CLI chica resuelve todos los problemas de logging”, escribió Vaidya en su publicación de dev.to. Me parece una postura más honesta que la de cualquier “solución integral” que promete reemplazar todo tu stack de observabilidad con un flag. Lo explicamos a fondo en generar políticas de red a partir de los flujos de Hubble.

LogLens frente a otras formas de leer logs de Kubernetes

LogLens ocupa un lugar puntual entre el grep de toda la vida y una plataforma de observabilidad completa: filtra, pretty-printea y triangula un incidente desde la terminal, pero no guarda nada ni corre en segundo plano.

Herramienta	Qué hace	Necesita agente o backend	Mejor para
grep / jq	Filtra texto o JSON línea por línea	No	Búsquedas simples en un solo formato
lnav	TUI con base de datos de logs propia	No, pero mantiene estado	Exploración interactiva a fondo
LogLens	Pretty-print, –trace y –stats sobre un pipe	No	Leer logs de Kubernetes mezclados y triar incidentes rápido
Plataforma de observabilidad (Datadog, stack ELK)	Recolecta, indexa y grafica logs de todo el clúster	Sí, agente y backend	Retención histórica y dashboards de equipo

Errores comunes al usar LogLens

Hay un par de trampas en las que es fácil caer apenas empezás a usar esta CLI, sobre todo si venís acostumbrado a otras herramientas.

• Esperar que reemplace al stack de observabilidad. LogLens no guarda histórico ni te avisa cuando algo se rompe a las 3 de la mañana: solo hace legible lo que ya tenés frente a los ojos en ese momento.
• Bajar el binario desde el navegador en Mac. Gatekeeper lo pone en cuarentena automáticamente; el instalador por curl evita ese problema, o se saca con xattr -d com.apple.quarantine loglens.
• Buscar un flag –since que todavía no existe. El filtrado por rango de tiempo no está implementado en esta versión, así que por ahora hay que combinar –trace o –grep con un poco de paciencia.
• Usar grep en vez de –stats para contar errores repetidos. Grep te muestra todas las líneas sueltas; –stats las agrupa como un solo hallazgo, que es justo lo que querés ver primero en un incidente grande.

Preguntas Frecuentes

¿Qué es LogLens y para qué sirve?

LogLens es una CLI en Java 21 creada por Sushrut Vaidya que lee logs desde un archivo o stdin y los imprime en una sola línea legible por entrada. Sirve para leer logs de Kubernetes mezclados en distintos formatos, seguir un request puntual con –trace y triar un incidente con –stats, todo sin agregar un backend ni un agente al clúster.

¿Cómo instalar LogLens en Linux, Mac o Windows?

Se instala con una línea: curl -fsSL https://raw.githubusercontent.com/SushrutVaidya/loglens/main/install.sh | sh, que detecta el sistema operativo y la arquitectura y descarga el binario nativo correspondiente. Hay binarios para macOS Apple Silicon, Linux x86-64, Linux ARM64 y Windows x86-64, ninguno necesita un JDK instalado. Esto se conecta con lo que analizamos en probarlo contra la demo de microservicios de Google.

¿Cómo seguir un request específico en los logs de un pod de Kubernetes?

Se usa el flag –trace con el ID de correlación del request: kubectl logs -f mypod | loglens --trace 9f2c-a1. LogLens detecta automáticamente campos comunes como requestId, X-Request-Id o trace_id, y mantiene los stack traces pegados a su error padre en vez de mostrarlos sueltos.

¿LogLens reemplaza a una plataforma de observabilidad como Datadog o ELK?

No. LogLens no colecciona, almacena ni indexa logs, y no tiene dashboard; el propio Vaidya lo aclara en su publicación original. Sigue dependiendo de kubectl, tail o la infraestructura de logging existente para la recolección, y funciona como un filtro de terminal, no como un sistema de monitoreo.

¿Qué formatos de logs soporta LogLens?

Soporta JSON lines, logfmt, klog, logs de Airflow, Python logging y el formato Log4j que usan Spark, Hadoop, Kafka, Hive y Flink, además de un formato genérico de timestamp y nivel como respaldo. Si una línea no matchea ningún parser, LogLens la imprime sin cambios en vez de adivinar su estructura.

Conclusión

LogLens no inventa una categoría nueva de herramienta: toma un problema conocido, el de leer logs de Kubernetes mezclados y dispersos, y le pone una solución chica y sin pretensiones. Si trabajás con pods que logean en JSON, klog y logfmt al mismo tiempo (que es básicamente cualquier clúster real), probar –trace y –stats te puede ahorrar bastante tiempo de grep manual. Lo que no hace es reemplazar tu stack de observabilidad, y eso está dicho con todas las letras por su propio autor. Para equipos chicos sin presupuesto de plataforma, es un pipe más en la caja de herramientas; para equipos grandes, sirve como complemento rápido antes de escalar a un dashboard con historial.

Fuentes

• Publicación original de Sushrut Vaidya en dev.to – cómo y por qué construyó LogLens
• Repositorio oficial de LogLens en GitHub – documentación, flags, instalación y código fuente