Un alumno en prácticas me plantea una cuestión “una máquina puede presentar un cuello de botella, se puede degradar su performance por múltiples causas, ser atacada por diversos métodos, incluidos los de denegación de servicio, etc., pero, ¿cómo puedo detectar esta situación?"
Sin duda alguna es la cuestión que, en el punto en el que nos encontramos, se debería plantear. En un primer momento, existen dos posibilidades.:
- No hacer nada y que sean los propios usuarios de nuestros sistemas los que, cuando un sistema presente un mal funcionamiento o una degradación en sus prestaciones, nos avise.
- Disponer de distintos sistemas de monitorización y alarmas en los sistemas administrados o, al menos, en servidores relevantes. Señalar que en este punto no estamos hablando de sistemas como puedan ser los IDSs, que entrarían en otro apartado relacionados con la monitorización y detección de intrusiones, o los sistemas de análisis de vulnerabilidades.
La primera opción supone tener que curar a un paciente cuando está en una situación crítica, sin contar todas las implicaciones de prestar un mal servicio a nuestros usuarios-clientes. Bajo ningún concepto debemos proceder de esta manera. En todo momento deberemos pensar en un mínimo de herramientas que nos faciliten la monitorización de los sistemas.
En este punto, iniciamos la aventura con las opciones básicas de "accounting" de procesos y usuarios.
El clásico paquete acct nos proporcionará unas herramientas básicas de monitorización de procesos y usuarios. Comandos como el ac, lastcomm, sa, last, lastb, entre otros, nos proporcionan algunas posibilidades básicas. Se estudian los parámetros de salida de los mismos.
En un segundo nivel se analiza el paquete sysstat como herramienta básica de monitorización de los distintos subsistemas gestionados por los sistemas operativos de nuestras máquinas, tanto en "tiempo real" como sobre bases de datos históricas, que nos permiten analizar el "performance" de las máquinas en cualquier momento pasado.
En toda monitorización un parámetro que debemos definir es el período de muestreo. Obviamente este deberá ajustarse a los objetivos de los posibles estudios sobre las muestras. Señalar que toda monitorización también supone una sobrecarga en el sistema que, de ser necesario, debería cuantificarse. En el marco del paquete sysstat se analiza la salida obtenida por los comandos iostat, mpstat, sar, top, vmstat y free, así como las opciones para garantizar el muestreo histórico de parámetros del sistema y el tratamiento de los mismos por los "scripts" sa1, sadc y sa2. También se incluye el comando sadf para exportar los datos a CSV o XML. Nuevamente se analizan los principales parámetros de salida de todos ellos.
Se incluye una herramienta no menos importante, la ISAG (Interactiva System Activity Grapher) que, sobre un entorno gráfico permite seleccionar un fichero del subsistema sysstat en binario (saXX) y mostrar los datos de muestreo históricos de forma gráfica. Sin duda alguna estos gráficos nos proporcionan de una forma visual mucha información sobre la evolución del "performance" en los distintos subsistemas gestionados por el sistema operativo.
Para concluir, señalar que de nada nos sirve disponer de muchos datos sin una cierta capacidad de análisis y, o, sistemas de alarma. Es necesario "conocer" las salidas producidas y las posibles interacciones e implicaciones de las mismas para, con ellas, sacar conclusiones que nos permitan tomar decisiones. Nuevamente llegamos a la “palabreja” que aparece cada poco en la asignatura, "tomar decisiones". Sin duda alguna, el profesional que nunca toma decisiones, o hace que sean otros los que las tomen, nunca se equivocará. Pero este es otro de los muchos puntos que diferencia un buen profesional de uno mediocre. Todo responsable del sector TIC debe potenciar a aquellos profesionales que toman decisiones y, muy especialmente, a los que asumen las posibles responsabilidades de las mismas, incluso en los casos no acertados.
