Lee el estado de un servidor y saca conclusiones

Antes de mirar la máquina, la idea que hace útil todo lo demás.

Ningún número por sí solo significa nada. «8 GB de memoria» no es bueno ni malo. «300 días encendida» tampoco. «31 % de memoria en un proceso» tampoco.

Lo que significa algo es la relación entre datos, y sobre todo la comparación con lo normal:

• 8 GB de memoria con 7,8 usados → apretada
• 8 GB con 1,2 usados → holgada
• 300 días encendida y una versión de hace tres años → sin actualizar
• 300 días encendida y una versión reciente → bien mantenida, se actualiza en caliente
• Un proceso con 31 % de memoria si es la base de datos → normal
• Un proceso con 31 % de memoria si corre desde /tmp → incidente

Fíjate en que el mismo número cambia de significado según qué tiene al lado. Eso es exactamente lo que hiciste en el panel de la clínica: 4.600 peticiones no era el dato: el dato era 4.600 frente a 40 de los demás.

Abre el laboratorio. Vas a hacer el recorrido completo de llegada a una máquina, que son cuatro preguntas y siempre en este orden:

1. Qué es esta máquina.

cat /proc/version

Sistema y versión. Te dice qué fallos conocidos aplican.

2. Desde cuándo lleva así.

cat /proc/uptime

El primer número entre 86.400 son los días. Junto con la versión, te dice si está al día.

3. Con qué recursos cuenta.

cat /proc/meminfo
cat /proc/cpuinfo

Memoria total, memoria disponible y cuántos procesadores. Te dice si tiene margen o va justa.

4. Y qué está haciendo.

Los procesos. En este escenario no hay, pero es el cuarto paso y el que más dice — lo verás en el módulo 3.

Con esos cuatro tienes un retrato de la máquina en menos de un minuto. Y todos son archivos de texto, que es la parte que sigue siendo asombrosa.

Ya tienes los datos de esta máquina. Ponlos juntos y contesta como contestarías en un informe.

La memoria total son unos 8 GB, y la disponible unos 3,8. No va apretada: tiene margen.

El tiempo encendido, dividido entre 86.400, son unos dos días. Poco. Y aquí hay que tener cuidado con la lectura fácil.

Dos días de uptime significa que reinició hace dos días. Y eso admite dos explicaciones opuestas:

• Alguien aplicó actualizaciones y reinició. Buena señal.
• Alguien la reinició sin avisar, o se cayó. Mala señal.

El dato no distingue. Para distinguir hay que mirar otro sitio: los registros del sistema, que es donde queda apuntado quién reinició y por qué. Lo verás en el módulo 3, con cat sistema.log.

Y esa es la conclusión que se lleva de esta sala, que vale para todo lo que viene después:

Los datos del sistema te dicen QUÉ. Los registros te dicen QUIÉN y CUÁNDO. Hacen falta los dos.

Quien mira solo los datos ve una foto sin contexto. Quien mira solo los registros ve la película sin saber en qué máquina pasa.