Cuando trabajas como Application Support Engineer, Linux se convierte en una de las herramientas más importantes para investigar incidentes en producción ya que aquí es donde la magia se crea.
Un problema puede comenzar con un mensaje tan sencillo como:
“La aplicación está lenta.”
Pero detrás de esa alerta puede existir un filesystem lleno, falta de memoria, un proceso Java consumiendo CPU, problemas de conectividad, errores en logs, certificados vencidos o simplemente un servicio que dejó de responder.
Por eso, estos son algunos de los comandos Linux que considero más útiles en la operación diaria de soporte L3.
1. Verificar el espacio disponible: df
Uno de los primeros comandos que utilizo cuando existe una alerta de filesystem es:
df -hPermite identificar rápidamente particiones con poco espacio disponible.
También puedes revisar un filesystem específico:
df -h /opt
df -h /var
df -h /tmpUna partición al 100% puede provocar que una aplicación no pueda generar logs, archivos temporales o incluso iniciar correctamente.
2. Encontrar qué directorios consumen más espacio: du
Después de encontrar un filesystem lleno, necesitamos saber qué está consumiendo el espacio.
du -sh *Para ordenar los directorios por tamaño:
du -sh * | sort -hOtra opción muy útil:
du -x /var | sort -n | tail -20Esto ayuda a localizar logs, dumps, temporales o archivos antiguos que están consumiendo almacenamiento.
3. Encontrar archivos: find
find es indispensable para investigar servidores.
Buscar archivos .log:
find /opt -type f -name "*.log"Buscar archivos mayores a 1 GB:
find / -type f -size +1G 2>/dev/nullBuscar archivos modificados durante las últimas 24 horas:
find /opt/app -type f -mtime -1Buscar archivos modificados durante los últimos 30 minutos:
find /opt/app -type f -mmin -304. Investigar logs con grep
Probablemente uno de los comandos más utilizados en soporte de aplicaciones.
Buscar errores:
grep -i "error" application.logBuscar excepciones Java:
grep -i "exception" application.logBuscar múltiples patrones:
grep -Ei "error|exception|failed|critical" application.logMostrar el número de línea:
grep -in "error" application.log5. Analizar archivos con less
Cuando un log tiene cientos de MB o varios GB, abrirlo con un editor no siempre es buena idea.
less application.logDentro de less podemos buscar:
/errorSiguiente coincidencia:
nCoincidencia anterior:
NSalir:
q6. Monitorear logs en tiempo real con tail
Para observar lo que está haciendo una aplicación:
tail -f application.logMostrar las últimas 100 líneas:
tail -100 application.logCombinarlo con grep:
tail -f application.log | grep -i errorEste comando resulta especialmente útil durante deployments, restarts y troubleshooting en producción.
7. Revisar procesos con ps
Para verificar si una aplicación Java está ejecutándose:
ps -ef | grep javaBuscar WebLogic:
ps -ef | grep -i weblogicBuscar Tomcat:
ps -ef | grep -i tomcatUna combinación que utilizo frecuentemente es:
ps -ef | grep java | grep -v grep8. Analizar CPU y memoria con top
Cuando recibimos un incidente indicando que “la aplicación está lenta”, uno de los primeros pasos es revisar los recursos del servidor.
topAquí podemos observar:
- CPU utilizada
- memoria
- load average
- procesos
- PID
- tiempo de CPU
También podemos analizar un proceso específico:
top -p PID9. Revisar memoria con free
Para verificar rápidamente la memoria del servidor:
free -hNos permite revisar memoria total, utilizada, disponible y swap.
Es particularmente útil cuando investigamos problemas relacionados con aplicaciones Java.
10. Identificar puertos abiertos con ss
Una aplicación puede estar ejecutándose pero no estar escuchando en el puerto esperado.
ss -lntpBuscar un puerto específico:
ss -lntp | grep 7001Por ejemplo, si esperamos que WebLogic escuche en el puerto 7001, este comando permite comprobarlo rápidamente.
En servidores antiguos también podemos encontrar:
netstat -lntp11. Probar conectividad con curl
En soporte de aplicaciones modernas, curl es indispensable para probar APIs y servicios HTTP.
curl https://server/applicationMostrar headers:
curl -I https://server/applicationMostrar información detallada de la conexión:
curl -v https://server/applicationProbar una API:
curl -X GET https://api.example.com/statusAdemás de HTTP, curl -v puede proporcionar información muy valiosa durante troubleshooting de TLS, certificados, proxies y APIs REST.
12. Probar DNS con nslookup y dig
Muchos problemas aparentemente relacionados con aplicaciones terminan siendo problemas de resolución DNS.
nslookup server.example.comTambién podemos utilizar:
dig server.example.comUna prueba rápida:
dig +short server.example.com13. Probar conectividad hacia un puerto
Para verificar si un servidor remoto acepta conexiones:
nc -vz server.example.com 443Otro ejemplo:
nc -vz database.example.com 1521Esto ayuda a diferenciar rápidamente entre un problema de aplicación y uno de red, firewall o conectividad.
14. Revisar archivos abiertos con lsof
Para saber qué proceso está utilizando un puerto:
lsof -i :8080También podemos revisar archivos abiertos por un proceso:
lsof -p PIDO encontrar procesos utilizando determinado archivo:
lsof /path/application.log15. Revisar información de un proceso en /proc
Una de las ventajas de Linux es que podemos investigar directamente información del proceso.
Por ejemplo:
cat /proc/PID/statusRevisar variables de ambiente:
tr '\0' '\n' < /proc/PID/environRevisar el comando utilizado para iniciar el proceso:
tr '\0' ' ' < /proc/PID/cmdlineEsto puede ser extremadamente útil investigando aplicaciones Java.
16. Revisar servicios con systemctl
En sistemas modernos basados en systemd:
systemctl status applicationIniciar:
systemctl start applicationDetener:
systemctl stop applicationReiniciar:
systemctl restart applicationRevisar logs:
journalctl -u application17. Revisar logs del sistema con journalctl
Consultar eventos recientes:
journalctl -xeLogs de un servicio:
journalctl -u application.serviceÚltimas 100 líneas:
journalctl -u application.service -n 100Seguir los eventos en tiempo real:
journalctl -u application.service -f18. Buscar información histórica con history
Durante un incidente también puede ser útil saber qué comandos fueron ejecutados recientemente:
historyBuscar comandos relacionados con una aplicación:
history | grep weblogicBuscar reinicios:
history | grep restartNaturalmente, el historial disponible dependerá de la configuración del shell y del usuario.
19. Verificar quién está conectado al servidor
whoTambién:
wY para revisar accesos anteriores:
lastEsto puede ser útil cuando varias personas están trabajando simultáneamente durante un incidente crítico.
20. Analizar archivos con awk
awk es extremadamente útil para procesar logs y resultados de comandos.
Por ejemplo, obtener la quinta columna:
awk '{print $5}' archivo.logEn archivos CSV:
awk -F',' '{print $5}' archivo.csvTambién podemos combinarlo con otros comandos:
ps -ef | awk '{print $1,$2,$8}'21. Procesar texto con sed
Por ejemplo, reemplazar texto:
sed 's/ERROR/WARNING/g' archivo.txtMostrar determinadas líneas:
sed -n '100,120p' application.logsed, awk y grep forman una combinación extremadamente poderosa para analizar grandes cantidades de información.
22. Ordenar y contar resultados
Comandos como sort, uniq y wc son muy útiles durante troubleshooting.
sort archivo.txtContar líneas:
wc -l archivo.logContar valores únicos:
sort archivo.txt | uniq -cOrdenarlos por frecuencia:
sort archivo.txt | uniq -c | sort -nrEsto puede ayudarnos, por ejemplo, a encontrar los errores que aparecen con mayor frecuencia.
23. Revisar conexiones de red
ss -antPodemos analizar conexiones hacia un puerto:
ss -ant | grep :443O contar conexiones por estado:
ss -ant | awk '{print $1}' | sort | uniq -cMuy útil cuando investigamos problemas de saturación o conectividad.
24. Revisar certificados SSL/TLS con openssl
En ambientes empresariales, muchos incidentes están relacionados con certificados.
Consultar un servidor:
openssl s_client -connect server.example.com:443Mostrar información del certificado:
openssl s_client -connect server.example.com:443 </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -datesEsto permite revisar rápidamente el subject, issuer y fechas de validez.
25. Revisar carga del servidor con uptime
Un comando sencillo pero extremadamente útil:
uptimeAdemás del tiempo que lleva encendido el servidor, muestra el load average de los últimos 1, 5 y 15 minutos.
Un escenario real de troubleshooting L3
Supongamos que recibimos el incidente:
“La aplicación de producción no responde.”
En lugar de reiniciar inmediatamente el servicio, podemos investigar:
1. ¿El servidor tiene recursos?
uptime
free -h
df -h
top2. ¿La aplicación está ejecutándose?
ps -ef | grep java3. ¿Está escuchando en el puerto?
ss -lntp | grep 80804. ¿Responde localmente?
curl -v http://localhost:8080/application5. ¿Qué dicen los logs?
tail -100 application.log
grep -Ei "error|exception|failed" application.log6. ¿Existe conectividad con las dependencias?
nc -vz database-server 1521
nc -vz api-server 4437. ¿Existe algún problema DNS?
dig api-server.example.comCon unos cuantos comandos podemos comenzar a determinar si estamos frente a un problema de aplicación, JVM, filesystem, memoria, CPU, red, DNS, base de datos o servicio externo.
Cheat Sheet — Linux para Application Support L3
FILESYSTEM
df -h
du -sh *
find / -type f -size +1G
LOGS
tail -f application.log
less application.log
grep -Ei "error|exception|failed" application.log
PROCESSES
ps -ef | grep java
top
free -h
NETWORK
ss -lntp
nc -vz host port
dig hostname
HTTP / APIs
curl -v URL
curl -I URL
SERVICES
systemctl status service
journalctl -u service
SSL/TLS
openssl s_client -connect host:443
TEXT PROCESSING
grep
awk
sed
sort
uniq
wc
SERVER
uptime
who
w
lastConclusión
Trabajar como Application Support Engineer no significa simplemente reiniciar servicios cuando algo falla.
El verdadero trabajo consiste en recopilar evidencia, correlacionar logs, analizar procesos, revisar recursos, validar conectividad y encontrar la causa raíz del problema.
Después de años trabajando con Linux, middleware, aplicaciones Java, APIs, bases de datos y ambientes distribuidos, comandos aparentemente sencillos como grep, find, ps, top, curl, ss, awk y tail terminan convirtiéndose en algunas de las herramientas más importantes para resolver incidentes críticos.
Dominar Linux no significa memorizar cientos de comandos.
Significa saber qué comando utilizar cuando producción está fallando y necesitas descubrir por qué.