Es una de las tareas más comunes para cualquiera que administre un servidor: ¿cuántos errores tiene este log? Parece trivial, pero es justo donde tropiezan muchos —incluso perfiles con experiencia—. El comando que casi todos usan devuelve un número que no son los errores. En este artículo verás por qué grep -c y wc -l engañan, y cómo contar (y clasificar) errores de verdad, como un administrador de sistemas.
El reflejo que falla
Te dan un log de producción (de esos que pesan decenas de megabytes) y la pregunta de siempre: ¿cuántos errores hay? El reflejo casi universal es este:
grep -c "error" app.log
Y reportar el número que sale. El problema es que ese número no son los errores. Es algo distinto, y confundirlo lleva a reportes absurdos del tipo "el servidor tuvo 150 mil errores anoche" cuando en realidad fueron unos pocos miles.
Trampa 1: un error NO es una línea
En un log real, un solo error ocupa muchas líneas. Cuando algo falla en Java, se imprime la traza de pila o stack trace: la línea del error y, debajo, decenas de líneas que empiezan con at ... mostrando por dónde pasó el fallo. Todo ese bloque es un error, no cuarenta.
Por eso, si cuentas líneas con wc -l, obtienes el tamaño del archivo, no la cantidad de errores. Y la diferencia no es pequeña: puede ser de 50 veces.
Trampa 2: grep -c no cuenta lo que crees
Aquí está el error más sutil. Mucha gente cree que grep -c "error" cuenta cuántas veces aparece la palabra "error". No. grep -c cuenta cuántas líneas contienen el patrón al menos una vez. Si una línea menciona "error" tres veces, suma 1, no 3.
⚠️ El doble engaño de grep -c error
Cómo se cuenta BIEN
La clave es entender la estructura del log antes de procesarlo. En muchos servidores (como WebSphere), cada evento real empieza con una marca de tiempo entre corchetes y tiene una letra de nivel: E para error. Las líneas de stack trace NO empiezan con corchete. Así que los errores reales son las líneas que son el inicio de un evento de nivel E:
# Errores REALES (no líneas, no la palabra "error") grep "^\[" app.log | grep -c " E "
Y para ir un paso más allá —lo que de verdad hace un administrador— no te quedas en "hay 3.512 errores", sino que los clasificas por tipo para saber por dónde empezar a arreglar:
# Ranking de los tipos de error más frecuentes grep "^\[" app.log | grep " E " \ | grep -oE "[A-Z]+[0-9]+E" | sort | uniq -c | sort -rn | head
Ese patrón —grep | sort | uniq -c | sort -rn— es el que un sysadmin usa todos los días. No es un comando mágico que se memoriza: es entender que cada herramienta hace una cosa y se conectan con tuberías.
Por qué esto importa (y no es un detalle)
La diferencia entre reportar 154.422 y 3.512 no es de sintaxis: es de criterio. Quien reporta mal el número toma malas decisiones y no sabe dónde está el problema real. Saber usar grep no es saber teclear grep: es entender qué estás contando y por qué.
Aprende a hacerlo con un log real
Leer sobre esto no basta: hay que practicarlo. En el curso Linux: De Cero a Sysadmin de Kimün Academy lo haces en una terminal real desde el navegador, con un log de producción de verdad (anonimizado), y construyes tú mismo el script que cuenta los errores bien. El primer módulo es gratis.
Si puedes explicarle a alguien por qué el número correcto es 3.512 y no 154.422, estás en el camino de ser un buen administrador de sistemas. Si todavía no, eso es exactamente lo que te enseñamos.