Skip to end of banner
Go to start of banner

Manual descriptivo del Troubleshooting Wizard

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 22 Next »

Esta página está destinada a proporcionar información del uso del Troubleshooting Wizard, que tiene como objetivo ayudar a los clientes a ejecutar un diagnóstico completo de su servidor o servidores para determinar las causas de un posible problema con los mismos.

Abarcaremos desde la recepción del mail por parte del cliente con la descripción del problema, pasando por el análisis de servidores, archivos de configuuración de NMIS y nodos agregados, hasta conclusiones y recomendaciones para que pueda solucionarse la incidencia reportada.

Este documento está basado en las pruebas mencionadas en la página Proceso de resolución de problemas de dispositivos en NMIS.

Descripción del problema

Para poder ejecutar el Troubleshooting Wizard, debemos tener una descripción muy bien detallada por parte del cliente que nos dé un buen panorama de la situación que está presentando.

Para esto, debemos resolver algunas preguntas importantes:

a) Descripción de la incidencia: ¿qué está sucediendo? ¿desde cuándo?

b) ¿En qué servidor o servidores se está presentando la incidencia?

c) Descripción del servidor o servidores en los que se está presentando la incidencia: CPUs, RAM, DD, nodos totales.

d) ¿En que nodo o nodos se está presentando la incidencia?

e) Detalles adicionales, por ejemplo: configuración actual de cron de NMIS por lo menos, configuración actual del archivo /etc/mongod.conf, configuración de parámetros de base de datos en /usr/local/omk/conf/opCommon.nmis, si se modificó algún archivo recientemente, si alguna configuración realizada ya sea en el servidor o en los equipos provocó la incidencia.

Troubleshooting Wizard: Funcionalidades

Healthcheck del Servidor

1. Comando top

Este comando nos dará información de todos los procesos que se están ejecutando en este momento en el servidor y el porcentaje de utilización de CPU y memoria RAM.

Siempre será importante basarnos en el load average y en el %CPU, ya que si estos valores son altos, tendremos seguramente un problema en algún o algunos procesos que se están ejecutando actualmente.

top

2. Revisión de fecha y hora del servidor

Es muy importante que el servidor tenga configurada de forma correcta la fecha y hora, según la zona horaria de cada cliente; esto debido a que hay muchos procesos que se ejecutan en lapsos específicos de tiempo y también los logs del sistema y los registros de modificación de archivos, contienen marcas de tiempo para poder detectarse en caso de un error.

Es por eso que el script incluye la ejecución del comando date, para que el operador sepa que la fecha y hora del sistema son adecuadas y, en caso de que no, ajustarlas como corresponde si es que no se trabaja con un NTP (que es lo más recomendado).

3. Revisión de velocidad de lectura y escritura en discos

Con este análisis, podremos darnos cuenta si existe una falla física en los discos del servidor. Si nos damos cuenta de que hay un problema, hay que notificarlo inmediatamente al cliente.

Basta con ejecutar un par de comandos:

  • dd if=/dev/zero of=/data/omkTestFile bs=10M count=1 oflag=direct
  • dd if=/data/omkTestFile of=/dev/null 2>&1

Y después analizar la salida con los siguientes valores: 

  • 0.0X s, parámetros correctos.
  • 0.X s, hay una advertencia (y podría generar un problema).
  • X.0 s, es crítico (y existe un problema).

4. Revisión de filesystems

Se revisa el espacio en cada uno de los filesystems del sistema, esto para comprobar que la incidencia no se esté presentando por una falta de espacio en el servidor.

Se ejecutaa el comando como sigue:

  • df -h

df -h

5. Revisión de servicios del sistema

Se ejecuta una revisión de cada uno de los demonios del sistema, para comprobar que todos los esenciales se estén ejecutando de manera correcta.

Principalmente, deben revisarse los que se mencionan a continuación:

  • service omkd status
  • service nmisd status (si aplica)
  • service nmis9d status (si aplica)
  • service mongod status
  • service opchartsd status
  • service opeventsd status
  • service opconfigd status
  • service crond status
  • service httpd status

service status
De igual forma, puede ejecutarse el siguiente comando para revisar todos los servicios en ejecución (CentOS 6):

  • service --status-all

service --status-all
En caso de que se detecte que algún servicio está down, debe reiniciarse con el siguiente comando:

  • service demoniod restart

Si persiste el down, deberá revisarse el log de dicho demonio y analizarse para ver qué está sucediendo. Se recomienda revisar en la página https://support.opmantek.com/secure/Dashboard.jspa si existe algún ticket con el mismo error para de ahí encontrar alguna solución.

6. Revisión de tiempos de carga del servidor

Se usa para monitorear la carga IO del equipo del sistema. Si se tiene un alto %util, es muy probable que exista un problema que pueda llevar incluso a la pérdida de datos. Esto hay que notificarlo inmediatamente al cliente.

Se recomienda ejecutar el comando como sigue, para tener 5 pruebas del mismo:

  • iostat -xtc 3 5

iostat

7. Top de los 20 procesos del CPU

Pendiente


8. Ejecución de tcpdump


El comando tcpdump nos permitirá capturar en un archivo el tráfico de la red en la que se encuentre el servidor del cliente, para después analizarlo con algún programa como Wireshark.

Con esto, el operador podrá saber si existe algún problema en la comunicación entre el servidor y los equipos agregados a NMIS y sus módulos, ya que al analizarlo se dará cuenta si existe pérdida de paquetes en el tráfico de la red.

9. Revisión de tabla de enrutamiento de IPs locales

La ejecución del comando route permitirá conocer el estado y configuración de las tablas de rutas IP, que nos sirven para enviar y saber cómo se envían los paquete en las distintas redes que se tienen configuradas en el servidor en cuestión.

10. Revisión de la lista de usuarios activos

La ejecución del comando who permitirá saber quiénes son los usuarios que están utilizando el shell en ese moment, esto servirá para mantener una mejor administración de las personas que acceden y, en algunas ocasiones, de los que modifican algún archivo importante del sistema.

11. Revisión de logs de usuarios

Es importante conocer el inicio de sesión de cada uno de los usuarios que utilizan el sistema, esto servirá para saber si alguno de ellos realizó alguna modificación que podría haber ocasionado el mal funcionamiento del mismo.

Los archivos a revisar son: /usr/local/nmis8/logs/auth.log y /usr/local/omk/log/auth.log.


12. Revisión de los últimos comandos utilizados

Esta revisión va un poco de la mano con el punto anterior que, mediante la ejecución del comando export HISTTIMEFORMAT='%F %T : ', nos permitirá saber la fecha y hora exacta de la ejecucíón de algún comando en específico.

13. Revisión de configuración de DNS

La revisión del archivo /etc/resolve.conf es importante, ya que nos permitirá saber si la configuración de los nombres de dominio es correcta y se está redirigiendo alguna IP importante de manera correcta.

Es por eso que se ejecuta un cat /etc/resolve.conf en el que el operador podrá confirmar que la estructura del archivo señalado sea la adecuada.

14. Prueba de internet

Si el cliente cuenta con internet en sus servidores, el operador podrá darse cuenta mediante la ejecución del comando wget. Este comando nos permitirá descargar algún contenido de un servidor web, sobre todo al actualizar paquetes con yum y con cpan.

Consistencia de Configuraciones de NMIS

1. Revisión de código de NMIS


2. Ejecución de un backup de archivos de configuración


3. Comparación de archivos de configuración


4. Ejecución de fixperms

La ejecución del comando /usr/local/nmis8/admin/fixperms.pl es importante, ya que permitirá al operador la corrección general de los permisos de todos los archivos del sistema.

5. Revisión de modelos


6. Revisión de cron

Se utiliza para comprobar que cada uno de los archivos de cron con los que NMIS y los módulos están configurados de una manera correcta y que no exista alguna rutina que esté causando algún conflicto que pueda afectar el funcionamiento del sistema.

Se revisa la carpeta /etc/cron.d.

7. Revisión de librerías de CPAN


Troubleshooter de nodos

1. Polling summary

Esta herramienta ayudará a determinar el tiempo que el servidor tarda en recolectar la información de los nodos agregados a NMIS y si no se puede completar algunaa operación.

Se podrá ver cuántos nodos tienen un collect tardío, así como también un resumen de los nodos que sí colectan y los que no.

/usr/local/nmis8/admin/polling_summary.pl

2. Traceroute

Esta herramienta de diagnóstico de red, permitirá rastrear en tiempo real la ruta tomada por un paquete en una red IP desde el origen hasta el destino, informando las direcciones IP de todos los enrutadores entre los que hizo ping.

Se ejecuta traceroute IPDELNODO.

3. MTR

Esta herramienta de diagnóstico de red, proporcionará la funcionalidad de ping y traceroute.

De igual forma le permitirá al operador saber si la herramienta está instalada o no.

Se ejecuta mtr -r IP

4. Ping

Esta herramienta permitirá probar si un host en particular es alcanzable a través de una red IP. Un ping mide el tiempo que tardan los paquetes en enviarse desde el host local a una computadora de destino y viceversa.

Se ejecuta ping IP

5. SNMP


Este comando utiliza solicitudes SNMP GETNEXT para consultar información en un dispositivo de red. Se puede proporcionar un identificador de objeto (OID) en la línea de comando.

Permitirá saber si el nodo en cuestión está respondiendo de forma correcta al protocolo y comprobar que NMIS esté recopilando sus métricas adecuadamente.

Se ejecuta snmpwalk -v 2c -c SNMP IPNODO OID

6. Update
 nodes

Es importante comprobar que el update manual a uno o más nodos se haga de forma correcta.

/usr/local/nmis8/bin/nmis.pl type=update node=NOMBRENODO

7. Collect nodes

Es importante comprobar que el collect manual a uno o más nodos se haga de forma correcta.

/usr/local/nmis8/bin/nmis.pl type=collect node=NOMBRENODO

8. Búsqueda de eventos de nodo

La ejecución de una búsqueda de eventos en particular permitirá comprobar si hay alguno que esté afectando el funcionamiento del nodo en cuestión.

grep -lir "evento" nmis.log

9. Ejecución de un backup del archivo Nodes.nmis

Es importante que el operador realice un backup del archivo original de nodos antes de realizar cualquier modificación que tenga que ver con los equipos agregados a NMIS.

cp /usr/local/nmis8/conf/Nodes.nmis /usr/local/nmis8/conf/Nodes.nmis.bkp

10. Ejecución de Support zip


Esta herramienta permite recopilar todos los archivos importantes puedan explicar cuál es el problema que se está presentando mediante los dos comandos señalados a continuación:

/usr/local/nmis8/admin/support.pl action=collect maxzipsize=9000000000000

/usr/local/omk/bin/support.pl action=collect

Diagnóstico Inteligente

Incluye todas las secciones anteriores, con un extra.

Show version of RRD/mongo



Zombies checkup




Primer borrador

Análisis de causas

En este apartado se realizará la evaluación de todas los posibles motivos que llevaron a que la incidencia ocurriera según reporta el cliente en cuestión, revisando cada uno de los parámetros de importancia del servidor, desde archivos de configuración importantes, pasando por hardware, software y, de ser necesario, revisión a fondo de los nodos involucrados.

Es importante que el cliente envíe un NMIS Support Tool y/o un OMK Support Tool desde el inicio, esto para tener una copia de los archivos de configuración más importantes en el momento del reporte de la incidencia.

2.1. Análisis de Support Tool

Dependiendo del escenario, comenzaremos revisando los archivos importantes contenidos en el Support Tool, se mencionan algunos de ellos a continuación:

  • Carpeta conf: Config.nmis, Nodes.nmis, Users.nmis
  • Carpeta logs: error_log, event.log, nmis.log.
  • Carpeta models: revisar si hubo algún cambio reciente que pudiera afectar.
  • Carpeta system_status: cpuinfo, disk_info, iostat, meminfo, top.
  • Carpeta system_status/apache: revisar los archivos de configuración.
  • Carpeta system_status/cron: revisar si el crontab contiene algún comando que pueda crear conflicto con otro cron.
  • Carpeta system_status/cron.d: revisar si no hay un cron duplicado y que al menos el cron de nmis esté configurado de manera correcta.

NMIS Support Tool

2.2. Análisis de cambio de configuraciones

En este análisis nos servirá de mucha ayuda el Support Tool enviado por el cliente, ya que podremos darnos cuenta si algún archivo de configuración fue modificado en los últimos días.

De igual forma, debemos tener acceso al servidor en cuestión, para poder verificar si se hizo algún backup y así poder restablecer el archivo a los parámetros anteriores.

Las principales carpetas a revisar son:

  • /usr/local/nmis8/conf
  • /usr/local/omk/conf
  • /etc/cron.d


2.4. Análisis de nodos

En este punto, se ejecutará un análisis a fondo de los nodos en los cuales se haya detectado algún problema durante el momento de la incidencia.

Se recomienda revisar las siguientes gráficas en NMIS:

  • Gráfica de KPIs

KPIs

  • Gráfica de Reachability, Availability and Health

Reachability, Availability and Health

  • Gráfica de Response Time

Response Time

  • Gráfica de IP Utilisation

IP Utilisation

De igual forma, se recomienda realizar búsquedas mediante un ps -fea | grep nombredenodo de los nombres de los nodos en las carpetas:

  • /usr/local/nmis8/logs
  • /usr/local/omk/logs

Esto con la finalidad de encontrar detalles que pudieron afectar los collects y/o los updates de los nodos, o algún tema en los módulos que impliquen lo

3. Análisis de resultados

En

4. Conclusiones y recomendaciones

En


  • No labels