Page tree
Skip to end of metadata
Go to start of metadata

Esta página está destinada a proporcionar un proceso de resolución de problemas de dispositivos gestionados en NMIS8 / 9 , esta estructurada con pasos claros que los administradores / operadores / usuarios pueden seguir e identificar qué está mal con la colección de dispositivos, también si tenemos huecos en los gráficos para los nodos gestionados lo cual indica un desempeño deficiente por el servidor. 


Sistema de información de gestión de red

Proceso de resolución de problemas de dispositivos



  1. Identifica el problema.  El primer paso es identificar el problema, debe considerar si se presenta en productos NMIS8 o NMIS9.
    1. Informar al soporte la versión del producto, los servidores / dispositivos / modelos involucrados.
  2. ¿Qué tipo de problema estás observando ? Un problema de dispositivo puede verse afectado por las siguientes razones.
    1. Rendimiento de la red , latencia en la red, problemas de capa 1, 2 y 3.
    2. Configuración de dispositivos , conectividad, configuración SNMP y otros. 
    3. Requisitos de hardware del servidor , parámetros con utilización alta de recursos en el servidor.
    4. Parámetros de configuración faltantes del servidor , validación de parámetros de configuración faltantes para el ajuste del servidor.
    5. Rendimiento del disco , tiempos de lectura/escritura lentos para la colección de dispositivos. 
  3. Adjuntar información , recopilar todos los gráficos, imágenes, comportamientos que puedan explicar cuál es el problema.
    1. Recopilar archivos de la herramienta de soporte La herramienta de soporte de Opmantek
      1. Ejecute el siguiente comando para recopilar la herramienta de soporte.

        #General collection.
        /usr/local/nmis8/admin/support.pl action=collect  
        
        #If the file is big, we can add the next parameter.
        /usr/local/nmis8/admin/support.pl action=collect maxzipsize=900000000
        
        #Device collection.
        /usr/local/nmis8/admin/support.pl action=collect node=<node_name> 
    2. Si está utilizando NMIS8, proporcione los archivos /usr/local/nmis8/var
      1. vaya al directorio /usr/local/nmis8/var y recopile los siguientes archivos

        -rw-rw----   1 nmis   nmis    4292 Apr  5 18:26 <node_name>-node.json
        -rw-rw----   1 nmis   nmis    2695 Apr  5 18:26 <node_name>-view.json
      2. obtener y proporcionar los resultados del update/Collect al caso de soporte:

        /usr/local/nmis8/bin/nmis.pl type=update node=<node_name> model=true debug=9 force=true > /tmp/node_name_update_$(hostname).log
        /usr/local/nmis8/bin/nmis.pl type=collect node=<node_name> model=true debug=9 force=true > /tmp/node_name_collect_$(hostname).log
    3. Si está utilizando NMIS9, incluya los archivos de la colección del nodo o nodos involucrados. 

      /usr/local/nmis9/admin/node_admin.pl act=dump
      
      {node=nodeX|uuid=nodeUUID}
      file=<MY PATH> everything=1
    4. Ejecutar una búsqueda en los logs del sistema de monitoreo, esto con alguna palabra relacionada al tema de investigación, la búsqueda puede ser una cadena parcial o una expresión regular para obtener la información filtrada de los directorios /nmis8/log y /omk/logs.

Ejemplo:

Ejemplo: search="router1|router2|switch3" logs=all
Ejemplo: search="Node Down|Node Up" logs=all


Para esto se requiere ejecutar un Script, descargar y subir al sistema mediante FTP, (Se requiere efectuar una modificación en el archivo /nmis8/conf/Config.nmis para su correcto funcionamiento los detalles se encuentran en el Script.)

Modo de emplear el Script.

Ejemplo :


[root@cnvtmxomk01 admin]#
[root@cnvtmxomk01 admin]# perl Busqueda.pl search="NMIS is disabled" logs=all
Processing /usr/local/nmis8/logs/event.log

Processing /usr/local/nmis8/logs/event.log-20210509.gz

Processing /usr/local/nmis8/logs/event.log-20210919
16-Sep-2021 12:00:04,1631811604,localhost,Alert: NMIS IS LOCKED,Fatal,,NMIS is disabled! cnvtmxomk01.cnoc.telmex.com 10.237.6.95 Delete the file NMIS_IS_LOCKED and run the command fpingd.pl
17-Sep-2021 12:00:03,1631898003,localhost,Alert: NMIS IS LOCKED,Fatal,,NMIS is disabled! cnvtmxomk01.cnoc.telmex.com 10.237.6.95 Delete the file NMIS_IS_LOCKED and run the command fpingd.pl
18-Sep-2021 00:00:03,1631941203,localhost,Alert: NMIS IS LOCKED,Fatal,,NMIS is disabled! cnvtmxomk01.cnoc.telmex.com 10.237.6.95 Delete the file NMIS_IS_LOCKED and run the command fpingd.pl
18-Sep-2021 12:00:03,1631984403,localhost,Alert: NMIS IS LOCKED,Fatal,,NMIS is disabled! cnvtmxomk01.cnoc.telmex.com 10.237.6.95 Delete the file NMIS_IS_LOCKED and run the command fpingd.pl
19-Sep-2021 00:00:03,1632027603,localhost,Alert: NMIS IS LOCKED,Fatal,,NMIS is disabled! cnvtmxomk01.cnoc.telmex.com 10.237.6.95 Delete the file NMIS_IS_LOCKED and run the command fpingd.pl

Processing /usr/local/omk/log/opCharts.log

Processing /usr/local/omk/log/opCharts.log-20210613.gz

[root@cnvtmxomk01 admin]#





[root@cnvtmxomk01 admin]#
[root@cnvtmxomk01 admin]# perl Busqueda.pl search="Node Configuration Change" logs=all
Processing /usr/local/nmis8/logs/event.log

Processing /usr/local/nmis8/logs/event.log-20210509.gz

Processing /usr/local/nmis8/logs/event.log-20210919
17-Sep-2021 15:15:04,1631909704,MINERA_MX_CORP_PARQUE_REFORMA_PISO_03_EQUIP01_STK_SW04,Node Configuration Change,Major,,Changed at 467 days 8:53:19
17-Sep-2021 15:15:04,1631909704,TEPJF_VIRGINIA_RT01,Node Configuration Change,Major,,Changed at 73 days 18:04:17
17-Sep-2021 15:20:02,1631910002,AC_ACUNA_SDWAN01,Node Configuration Change,Major,,Changed at 5 days 5:46:59

Processing /usr/local/omk/log/opCharts.log

Processing /usr/local/omk/log/opCharts.log-20210613.gz

[root@cnvtmxomk01 admin]#



  1. Replicar el problema . Si es posible se puede definir cuáles son los pasos para replicar el problema.
  2. Identifica los síntomas . En este punto se puede detectar un problema específico y cuáles son los síntomas.
  3. Determinar si algo ha cambiado , es importante verificar con su equipo si algo ha cambiado, una buena forma de ver este comportamiento es monitoreando el gráfico de rendimiento para dispositivos o servidor.
  4. ¿ Es un problema individual?  Verifique si este comportamiento ocurre en un solo dispositivo / servidor.

Rendimiento de la red: servidor NMIS.

Esta sección está enfocada a realizar la revisión y validación del estado del servidor en general, nos enfocaremos en verificar el comportamiento histórico de las principales métricas para el servidor, es importante revisar todas las métricas relacionadas con el buen desempeño entre el servidor y dispositivos

Verificación de métricas de salud

  • Las métricas son importantes para el servidor, NMIS utiliza la accesibilidad, la disponibilidad y el estado para representar la red. 
  • La accesibilidad es la capacidad de ping del dispositivo,

  • La disponibilidad es (en el contexto del equipo de red) las interfaces que deberían estar activas, Up o Down, por ejemplo, las interfaces que este e el estado "no shutdown" (ifAdminStatus = up) deberían estar activas, por lo que un dispositivo con 10 interfaces de ifAdminStatus=up y ifOperStatus=up para 9 interfaces, el dispositivo estaría disponible en un 90%.


  • La salud es una métrica, formada por muchas cosas según el dispositivo, el enrutador, CPU y la memoria. Una interfaz que no tiene uso tendrá un componente de alto estado, una interfaz que se utilice mucho reducirá esa métrica. Entonces, la salud es un reflejo de la carga en el dispositivo y será muy dinámica.


  • La métrica general de un dispositivo es una métrica adjunta formada por valores ponderados de las otras métricas que se recopilan. La fórmula para esto es configurable, por lo que puede tener un peso de Alcance más alto de lo que es actualmente, o más bajo, según su elección.


Para obtener más referencias,  consulte Métricas, accesibilidad, disponibilidad y estado de NMIS

  • Es importante validar la salud del localhost, incluida la accesibilidad general, la disponibilidad y el estado. Podrá ver los datos que no siguen el patrón de datos históricos que pueden darnos una pista de dónde puede estar ocurriendo el problema o incluso si el comportamiento anormal comenzó antes de realizar una modificación en la configuración.


  • Ver los gráficos referentes al rendimiento de la red como (Tiempo de respuesta en milisegundos, Utilización de IP, Conexión TCP, Segmentos TCP) nos ayudará a identificar el comportamiento del servidor / red en un período de 2 días, podemos modificar este período de tiempo para ver más datos si es necesario.

Configuración del dispositivo.

Es importante validar si el problema ocurre en la red o es algo relacionado con la configuración del dispositivo, para poder identificar lo que está sucediendo necesitamos ejecutar los siguientes comandos en la consola del servidor.

  1. Prueba de ping,  la herramienta de ping se utiliza para 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. 

    ping x.x.x.x #add the ip address you need to reach
  2. Traceroute , es una herramienta de diagnóstico de red que se utiliza para 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.

    traceroute x.x.x.x  #add the ip address you need to reach
  3. MTR,Mtr (my traceroute) es una herramienta de diagnóstico de red de línea de comandos que proporciona la funcionalidad de ping y traceroute.

    NOTA: Instalar la herramienta en el caso de no tenerla.

    sudo apt install mtr
    sudo mtr -r 8.8.8.8
    
        [sample results below]
    
        HOST: endor                       Loss%   Snt   Last   Avg  Best  Wrst StDev
         1. 69.28.84.2                    0.0%    10    0.4   0.4   0.3   0.6   0.1
         2. 38.104.37.141                 0.0%    10    1.2   1.4   1.0   3.2   0.7
         3. te0-3-1-1.rcr21.dfw02.atlas.  0.0%    10    0.8   0.9   0.8   1.0   0.1
         4. be2285.ccr21.dfw01.atlas.cog  0.0%    10    1.1   1.1   0.9   1.4   0.1
         5. be2432.ccr21.mci01.atlas.cog  0.0%    10   10.8  11.1  10.8  11.5   0.2
         6. be2156.ccr41.ord01.atlas.cog  0.0%    10   22.9  23.1  22.9  23.3   0.1
         7. be2765.ccr41.ord03.atlas.cog  0.0%    10   22.8  22.9  22.8  23.1   0.1
         8. 38.88.204.78                  0.0%    10   22.9  23.0  22.8  23.9   0.4
         9. 209.85.143.186                0.0%    10   22.7  23.7  22.7  31.7   2.8
        10. 72.14.238.89                  0.0%    10   23.0  23.9  22.9  32.0   2.9
        11. 216.239.47.103                0.0%    10   50.4  61.9  50.4  92.0  11.9
        12. 216.239.46.191                0.0%    10   32.7  32.7  32.7  32.8   0.1
        13. ???                          100.0    10    0.0   0.0   0.0   0.0   0.0
        14. google-public-dns-a.google.c  0.0%    10   32.7  32.7  32.7  32.8   0.0
  4. snmpwalk,  es una aplicación de Protocolo simple de administración de red (SNMP) presente en la CLI del Sistema de administración de seguridad (SMS) que 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.
    The following example CLI command will return the IPS temperature information:
    
    Command:snmpwalk -v 2c -c tinapc <IP address> 1.3.6.1.4.1.10734.3.5.2.5.5
    
    Command Explanation:
    
    In this case the CLI command breaks down as following;
    
    snmpwalk                             = SNMP application
    -v 2c                                     = specifies what SNMP version to use (1, 2c, 3)
    -c tinapc                               = specifies the community string. Note: The IPS has the SNMP read-only community string of "tinapc"
    <IP address>                       = specifies the IP address of the IPS device
    1.3.6.1.4.1.10734.3.5.2.5.5 = OID parameter for the IPS temperature information
    
    Results:
    
    SNMPv2-SMI::enterprises.10734.3.5.2.5.5.1.0 = INTEGER: 27
    SNMPv2-SMI::enterprises.10734.3.5.2.5.5.2.0 = INTEGER: 50
    SNMPv2-SMI::enterprises.10734.3.5.2.5.5.3.0 = INTEGER: 55
    SNMPv2-SMI::enterprises.10734.3.5.2.5.5.4.0 = INTEGER: 0
    SNMPv2-SMI::enterprises.10734.3.5.2.5.5.5.0 = INTEGER: 85
    
    Results Explanation:
    
    SNMPv2-SMI::enterprises.10734.3.5.2.5.5.1.0 = INTEGER: 27 = The chassis temperature (27° Celsius / 80.6° Fahrenheit)
    SNMPv2-SMI::enterprises.10734.3.5.2.5.5.2.0 = INTEGER: 50 = The major threshold value for chassis temperature (50° Celsius / 122° Fahrenheit)
    SNMPv2-SMI::enterprises.10734.3.5.2.5.5.3.0 = INTEGER: 55 = The critical threshold value of chassis temperature (55° Celsius / 131° Fahrenheit)
    SNMPv2-SMI::enterprises.10734.3.5.2.5.5.4.0 = INTEGER: 0   = The minimum value of the chassis temperature range ( 0° Celsius / 32° Fahrenheit)
    SNMPv2-SMI::enterprises.10734.3.5.2.5.5.5.0 = INTEGER: 85 = The maximum value of the chassis temperature range (85° Celsius / 185° Fahrenheit)
    Es importante ver que se pueda hacer ping a un dispositivo, que no tenga latencia o pérdida de paquetes y que se recopilen los datos SNMP.

Polling Summary

El sistema de monitoreo OPMANTEK cuenta con la herramienta polling_summary, esto nos ayudará a determinar cuántos nodos se esta recolectando en el momento, los datos importantes a considerar como el status del nodo, estado del protocolo snmp, política aplicada, tiempo de poleo, tiempo de update, estado general del nodo pollmessage, tienen una recolección tardía y un resumen de los nodos recopilados y no recopilados.

NMIS8

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

NMIS9

/usr/local/nmis9/admin/polling_summary9.pl 
[root@opmantek ~]#  /usr/local/nmis8/admin/polling_summary.pl
node                     attempt   status    ping  snmp  policy     delta  snmp avgdel  poll   update  pollmessage     
ACH-AIJ-DI-AL-SA6-0202010001-01 14:10:33  ontime    up    up    default    328    300  422.31  22.40  17.89                   
ACH-AIJ-RC-ET-08K-01     --:--:--  bad_snmp  up    up    default    ---    300  403.90  10.38  14.58   snmp never successful
ACH-ANA-RC-ET-08K-01     --:--:--  bad_snmp  up    down  default    ---    300  422.57  11.39  109.09  snmp never successful
ACH-ATU-RC-ET-08K-01     --:--:--  bad_snmp  up    up    default    ---    300  391.99  0.97   62.88   snmp never successful
ACH-CAB-DI-AL-SA6-0215010001-01 14:11:21  late      up    up    default    484    300  5543888.62 31.06  74.21   1x late poll    
ACH-CAB-DR-AL-P32-01     --:--:--  bad_snmp  up    up    default    ---    300  416.30  103.46 91.28   snmp never successful
ACH-CAB-GE-GM-G30-01     14:00:54  late      up    down  default    348    300  593.93  6.06   12.53   1x late poll    
ACH-CAB-RC-ET-08K-01     --:--:--  bad_snmp  up    up    default    ---    300  411.74  10.69  7.31    snmp never successful
ACH-CAB-TT-GM-30T-01     --:--:--  bad_snmp  up    down  default    ---    300  0.00    0.00   180.42  snmp never successful
ACH-CAR-RC-ET-08K-01     14:10:20  ontime    up    up    default    314    300  9054283.23 11.15  6.47                    
ACH-CAT-CN-AL-SA6-0212070008-01 14:07:39  late      up    up    default    600    300  27253590.83 12.39  22.23   1x late poll    
ACH-CAZ-TT-GM-30T-01     --:--:--  bad_snmp  up    down  default    ---    300  414.85  3.11   165.32  snmp never successful
ACH-CHM-DR-AL-P32-01     14:05:47  late      up    up    default    456    300  2686074.17 118.55 148.58  1x late poll    
ACH-CHM-GE-GM-G20-01     --:--:--  bad_snmp  up    down  default    ---    300  413.17  4.06   238.92  snmp never successful
ACH-CHM-RC-ET-09K-01     14:12:30  late      up    up    default    633    300  1983484.93 10.49  13.07   1x late poll    
ACH-CHM-TT-GM-20T-01     --:--:--  bad_snmp  up    down  default    ---    300  412.17  3.61   287.80  snmp never successful
ACH-COX-RC-ET-09K-01     13:51:14  late      up    up    default    473    300  22141.04 9.54   4.10    1x late poll    
ACH-CSM-RC-ET-08K-01     13:51:09  late      up    up    default    444    300  539117.26 11.25  5.31    1x late poll    
ACH-CSM-TT-GM-20T-01     14:08:34  late      up    down  default    709    300  1739800.92 4.01   229.73  1x late poll    
ACH-HCC-CN-AL-SA6-0212030012-01 13:50:33  ontime    up    up    default    330    300  8131293.53 23.65  23.84                   
ACH-HCC-RC-ET-08K-01     14:07:56  late      up    up    default    635    300  1802552.50 0.65   1.61    1x late poll    
ACH-HEY-DI-AL-SA6-0211010001-01 13:50:52  late      up    up    default    425    300  571.75  25.46  17.30   1x late poll    
ACH-HEY-DR-AL-P32-01     --:--:--  bad_snmp  up    up    default    ---    300  119099.96 106.25 120.92  snmp never successful
ACH-HEY-GE-GM-G20-01     --:--:--  bad_snmp  up    down  default    ---    300  0.00    0.00   112.37  snmp never successful
ACH-HEY-RC-ET-09K-01     --:--:--  bad_snmp  up    up    default    ---    300  404.62  11.01  7.49    snmp never successful
--Snip--
--Snip--
UCA-PUC-DR-AL-P32-01     14:12:04  late      up    up    default    524    300  124010.73 135.20 124.79  1x late poll    
UCA-PUC-GE-GM-G30-01     14:11:20  late      up    down  default    475    300  3868910.82 3.68   236.48  1x late poll    
UCA-PUC-GE-GM-G30-02     14:12:32  late      up    down  default    644    300  3871900.66 4.05   209.92  1x late poll    
UCA-PUC-RC-ET-09K-01     --:--:--  bad_snmp  up    up    default    ---    300  418.17  10.83  5.76    snmp never successful
UCA-PUC-TT-GM-30A-01     --:--:--  bad_snmp  up    down  default    ---    300  397.68  4.21   215.65  snmp never successful
UCA-PUC-TT-GM-30A-02     14:13:03  late      up    down  default    720    300  329362.60 3.39   208.92  1x late poll    
CC_VITATRAC_GT_Z2_MAZATE 14:13:04  demoted   down  down  default    ---    300  0.00    2.22   0.80    s
CC_VITATRAC_GT_Z3_COBAN  14:13:12  late      up    up    default    618    300  4874416.57 1.91   4.46
CC_VITATRAC_GT_Z3_ESCUINTLA 14:13:12  late      up    up    default    604    300  4902673.92 2.17   4.8
CC_VITATRAC_GT_Z7_BODEGA_MATEO 14:15:37  late      up    up    default    642    300  3844049.73 3.25
CC_VITATRAC_GT_Z8_MIXCO  14:15:42  late      up    up    default    634    300  4959081.87 2.47   6.70
CC_VITATRAC_GT_Z9_XELA   14:16:03  late      up    up    default    634    300  3943302.62 8.95   58.61
CC_VITATRAC_GT_ZONA_PRADERA 14:17:47  demoted   up    down  default    711    300  605.21  10.91  10.28
CC_VIVATEX_GT_INTERNET_VILLA_NUEVA 14:18:49  late      up    up    default    979    300  4563376.03 1.2
CC_VOLCAN_STA_MARIA_GT_INTERNET_CRUCE_BARCENAS 14:19:44  late      up    up    default    981    300  44late poll
nmisslvcc5               14:18:55  late      up    up    default    344    300  376209.90 2.33   1.23

totalNodes=2615 totalPoll=2267 ontime=73 pingOnly=0 1x_late=2190 3x_late=3 12x_late=1 144x_late=0
time=10:10:07 pingDown=354 snmpDown=359 badSnmp=295 noSnmp=0 demoted=348
[root@opmantek ~]#

 Si existen valores en los campos x_late, necesitamos validar el rendimiento del servidor.

Estado de servicios (demonios)

NMIS está utilizando algunos servicios importantes para hacer que la solución funcione, a veces los dispositivos dejan de funcionar debido a que algunos de estos servicios se interrumpen. Siempre es una buena idea validar si se están ejecutando, para validar esto es necesario ejecutar los siguientes comandos. Esto con el fin de brindar aún más seguridad, ya que algunos de estos servicios son cruciales para el funcionamiento del sistema operativo. Por otro lado, en sistemas como Unix o Linux, los servicios también se conocen como demonios. En este caso, es imprescindible validar los servicios que componen el sistema de monitoreo OPMANTEK (NMIS).

service mongod status
service omkd status
service nmisd status
service httpd status
service opchartsd restart
service opeventsd status
service opconfigd status
service opflowd status
service crond status

#if someone of this daemons is stopped, you need to execute same commands with start/restart options.

Requisitos de hardware del servidor.

Esta sección es crucial para identificar o resolver problemas de dispositivos, debe revisar algunas consideraciones según la cantidad de nodos que administrará, la cantidad de usuarios que accederán a la GUI, ¿con qué frecuencia deben actualizarse sus datos? Si se requieren actualizaciones cada 5 minutos, entonces deberá tener el hardware para poder cumplir con estos requisitos, también los requisitos del sistema operativo deben estar bien definidos, una buena regla general es reservar 1 GB de RAM para el sistema operativo de forma predeterminada , Unidades de alta velocidad para los datos (SSD es ideal) con almacenamiento separado para la base de datos mongo y los archivos temporales. En cualquier lugar entre 4-8 núcleos con un procesador (es) de alto rendimiento, 16-64 GB de RAM deberían funcionar bien para más de 1k nodos.

Usando el comando top / htop

El comando TOP muestra todos los procesos en ejecución en el servidor. Muestra la información del sistema y la información de los procesos, como el tiempo de actividad, la carga promedio, las tareas en ejecución, numero de usuarios conectados, numero de procesos de CPU, utilización de RAM y enumera todos los procesos en ejecución / utilizados por los usuarios en su servidor, en los detalles de  parámetros se pueden observar los datos mas importantes para validar en la herramienta top marcadas en negritas.


top


top - 12:50:01 up 62 days, 22:56,  5 users,  load average: 4.76, 8.03, 4.34
Tasks: 412 total,   1 running, 411 sleeping,   0 stopped,   15 zombie
Cpu(s):  6.8%us,  3.8%sy,  0.2%ni, 74.4%id, 28.2%wa,  0.1%hi,  0.5%si,  0.0%st
Mem:  20599548k total, 18622368k used,  1977180k free,   375212k buffers
Swap:  6669720k total,  3536428k used,  3133292k free, 10767256k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                     
26306 root      20   0  478m 257m 1900 S  3.9  1.3   0:08.21 nmis.pl                                                                     
15522 root      20   0  626m 373m 2776 S  2.0  1.9  71:45.09 opeventsd.pl                                                                
27285 root      20   0 15280 1444  884 R  2.0  0.0   0:00.01 top                                                                         
    1 root      20   0 19356  308  136 S  0.0  0.0   1:07.65 init                                                                        
    2 root      20   0     0    0    0 S  0.0  0.0   0:02.14 kthreadd                                                                    
    3 root      RT   0     0    0    0 S  0.0  0.0  17359:19 migration/0                                                                 
    4 root      20   0     0    0    0 S  0.0  0.0 252:25.86 ksoftirqd/0                                                                 
    5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 stopper/0                                                                   
    6 root      RT   0     0    0    0 S  0.0  0.0   2233:33 watchdog/0                                                                  
    7 root      RT   0     0    0    0 S  0.0  0.0 340:35.60 migration/1                                                                 
    8 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 stopper/1                                                                   
    9 root      20   0     0    0    0 S  0.0  0.0   5:23.87 ksoftirqd/1                                                                 
   10 root      RT   0     0    0    0 S  0.0  0.0 214:57.35 watchdog/1    

1.Primera línea: tiempo y carga

La primera línea del comando superior indica en el orden siguiente.

top - 12:50:01 up 62 days, 22:56,  5 users,  load average: 4.76, 8.03, 4.34
  • hora actual (12:50:01)
  • tiempo de actividad de la máquina (hasta 62 días, 22:56)
  • sesiones de usuarios conectados (5 usuarios)
  • carga promedio en el sistema (promedio de carga: 4.76, 8.03, 4.34) los 3 valores se refieren al último minuto, cinco minutos y 15 minutos ####### Esto no es bueno si tenemos valores altos

2. Segunda fila: tarea

La segunda fila le proporciona la siguiente información.

Tasks: 412 total,   1 running, 411 sleeping,   0 stopped,   15 zombie
  • Procesos totales en ejecución (412 en total)
  • Procesos en ejecución (1 en ejecución)
  • Procesos de dormir (411 durmiendo)
  • Procesos detenidos (0 detenidos)
  • Procesos que esperan ser detenidos desde el proceso principal (15 zombis) ####### Esto no es bueno para el estado del server.
    Proceso Zombie: Un proceso que ha completado la ejecución, pero todavía tiene una entrada en la tabla de procesos. Esta entrada aún necesita permitir que el proceso padre lea su estado de salida secundario.

3. Sección de CPU.+

Cpu(s):  6.8%us,  3.8%sy,  0.2%ni, 74.4%id, 28.2%wa,  0.1%hi,  0.5%si,  0.0%st
  • Procesos de usuario de CPU en porcentaje (6,8% us)
  • Procesos del sistema de CPU en porcentaje (3.8% sy)
  • Mejora de prioridad agradable de CPU en porcentaje (0.2% ni)
  • Porcentaje de la CPU no utilizada (74,4% id)
  • Procesos en espera de operaciones de E / S de la CPU en porcentaje (28,2% wa) ####### Esto no es bueno para el rendimiento del servidor.
  • Sirviendo interrupciones de hardware de la CPU en porcentaje (0.1% hi - Hardware IRQ
  • Porcentaje de interrupciones de software de servicio de la CPU (0.0% si - Interrupciones de software

La cantidad de CPU "stolen" de esta máquina virtual por el hipervisor para otras tareas (como ejecutar otra máquina virtual) será 0 en el escritorio y el servidor sin la máquina virtual. (0.0% st - Steal Time)

4. Memoria

Estas filas le proporcionarán la información sobre el uso de RAM. Muestra la memoria total en uso, libre, búferes almacenados en caché.

Mem:  20599548k total, 18622368k used,  1977180k free,   375212k buffers
Swap:  6669720k total,  3536428k used,  3133292k free, 10767256k cached  

5. Lista de procesos

Está la última fila para discutir el uso de la CPU que se estaba ejecutando actualmente.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                     
26306 root      20   0  478m 257m 1900 S  3.9  1.3   0:08.21 nmis.pl                                                                     
15522 root      20   0  626m 373m 2776 S  2.0  1.9  71:45.09 opeventsd.pl                                                                
27285 root      20   0 15280 1444  884 R  2.0  0.0   0:00.01 top                                                                         


  • PID - ID del proceso (26306)
  • USUARIO : el usuario que es el propietario del proceso (raíz)
  • PR - prioridad del proceso (20)
  • NI - El valor "NICE" del proceso (0)
  • VIRT : memoria virtual utilizada por el proceso (478 m)
  • RES : memoria física utilizada en el proceso (3,3 g)
  • SHR - memoria compartida del proceso (1900)
  • S - indica el estado del proceso: S = inactivo R = en ejecución Z = zombi (S)
  • % CPU : este es el porcentaje de CPU utilizado por este proceso (3.9) ####### Esto no es bueno para el rendimiento del servidor.
  • % MEM - Este es el porcentaje de RAM usado por el proceso (1.3) ####### Esto no es bueno para el rendimiento del servidor.
  • TIEMPO + - Este es el tiempo total de actividad de este proceso (0: 08.21) ####### Esto no es bueno para el rendimiento del servidor.
  • COMANDO - Y este es el nombre del proceso (exim)

Es importante monitorear este comando para ver si el servidor está funcionando correctamente ejecutando todos los procesos internos necesarios.

Opciones de configuración del servidor.

Para decirle al servidor, cómo administrar los dispositivos, es necesario validar que todos los elementos/parámetros estén bien configurados, puede ver el rendimiento del servidor mientras recopila información yendo a la sección, sistema> Diagnóstico del host> Gráfico de tiempo de ejecución NMIS ingles 

Si el tiempo total de ejecución / recopilación es demasiado alto, debemos ajustar los parámetros de recopilación según la versión del administrador que esté utilizando.

Procesos NMIS 8

El proceso principal de NMIS 8 se llama desde diferentes trabajos cron para ejecutar diferentes operaciones: recopilar, actualizar, resumir, limpiar trabajos, etc. Como ejemplo:

* * * * * root /usr/local/nmis8/bin/nmis.pl type=collect abort_after=60 mthread=true ignore_running=true;

La configuración cron se puede encontrar en /etc/crond.d/nmis

Para una recopilación o actualización, el subproceso principal está configurado de forma predeterminada para bifurcar los procesos de trabajo para realizar las operaciones solicitadas utilizando subprocesos y mejorando el rendimiento. Una de cada operación se ejecutará cada minuto (de forma predeterminada) y procesará tantos nodos como el ciclo de recopilación de sondeo esté configurado para procesar.


Procesos NMIS 9

El proceso principal de NMIS 9

* * * * * root /usr/local/nmis8/bin/nmis.pl type=collect abort_after=60 mthread=true ignore_running=true;



Configuraciones que afectan el rendimiento

Hay algunas configuraciones importantes que afectan el rendimiento:

  • Además, esta configuracion debe tener siempre también la opción mthreads = true. 

    #configuracion de cron
    nmis8/bin/nmis.pl type=collect abort_after=60 mthread=true ignore_running=true;
    
  • abort_after  Desde NMIS 8.6.8G hay una nueva opción de línea de comando, abort_after, que evita que el hilo principal se ejecute durante mucho tiempo, evitando que colisione con el siguiente trabajo cron. De forma predeterminada, este parámetro es de 60 segundos, ya que el trabajo cron está configurado para ejecutarse cada 60 minutos de forma predeterminada. 

  • max_thread : La otra opción de configuración importante es max_thread, que evitará que el número de hijos del proceso principal crezca demasiado. Consideraciones:
    • Si la operación de recopilación tiene muchos nodos para procesar, la cantidad de niños no alcanzará el límite instantáneamente. Mientras el hilo principal se bifurca, los niños completan su trabajo y saldrán. Además, el proceso principal esperará a que cambien de estado, por lo que el número aumentará lentamente.
    • NMIS puede tener más de una instancia del proceso principal en ejecución, y el número de hijos podría ser mayor que max_threads, ya que el límite es solo por instancia. 
  • sort_due_nodes:  cuando NMIS decide qué sondear, puede hacerlo en un orden pseudoaleatorio que es el predeterminado, si su servidor está sobrecargado, probablemente verá algunos nodos que nunca se sondean, por lo tanto, pseudoaleatorio, por lo que para servidores muy cargados, habilite sort_due_nodes, en la configuración NMIS agregue con el valor establecido en 1.
  • Referencia  NMIS 8 - Opciones de configuración para el ajuste del rendimiento del servidor

Configuración de archivo CRON (NMIS) y Config.nmis

Aquí procederemos a verificar la configuración de recolección de datos hacia los dispositivos, por lo que validamos los parámetros Collect, maxthreads y mthread.

En el archivo NMIS cron vemos lo siguiente:


Cron NMIS

Crond NMIS
######################################################
# NMIS8 Config
######################################################

# Run Full Statistics Collection
*/5 * * * *     root     /usr/local/nmis8/bin/nmis.pl type=collect maxthreads=100 mthread=true
*/5 * * * *     root     /usr/local/nmis8/bin/nmis.pl type=services mthread=true
# ######################################################

# Optionally run a more frequent Services-only Collection
# */3 * * * *   root     /usr/local/nmis8/bin/nmis.pl type=services mthread=true

######################################################

# Run Summary Update every 2 minutes
*/2 * * * *     root     /usr/local/nmis8/bin/nmis.pl type=summary

Procedemos a verificar que el valor mthread esté activado y que maxthreads tenga el mismo valor en el archivo Config.nmis
Sección Config.nmis

Sección Config.nmis
    'nmis_group' => 'nmis',
    'nmis_host' => 'nmissTest_OMK.omk.com',
    'nmis_host_protocol' => 'http',
    'nmis_maxthreads' => '100',
    'nmis_mthread' => 'false',
    'nmis_summary_poll_cycle' => 'false',
    'nmis_user' => 'nmis',

Podemos ver que el valor de mthread está desactivado y que el valor de maxthreads sí corresponde al mismo declarado en el cron de nmis, por lo que procedemos a activarlo y realizar una actualización y recopilación al nodo.
Update_Collect

Update_Collect
/usr/local/nmis8/bin/nmis.pl type=update node=<Name_Node> force=true

/usr/local/nmis8/bin/nmis.pl type=collect node=<Name_Node> force=true

Nota: Si estos valores declarados en el cron y en el archivo Config.nmis no funcionan, se recomienda hacer lo siguiente:
Ejemplo Crond

Example Crond
# Ejemplo 1:
/usr/local/nmis8/bin/nmis.pl type=collect abort_after=300 mthread=true maxthreads=100 ignore_running=true

# Ejemplo 2
/usr/local/nmis8/bin/nmis.pl type=collect abort_after=240 mthread=true maxthreads=100 ignore_running=true

El valor del parámetro maxthreads (se recomienda probar entre 50, 80 y 100) debe ser el mismo en ambos archivos (cron nmis y Config.nmis)

El valor del parámetro abort_after (se recomienda probar entre )


Aplicar los comandos Update y collect al final de cada prueba y verificar el comportamiento en la GUI de NMIS, esto consiste en revisar el Gráfico de tiempo de ejecución de NMIS, Network_summary y Polling_summary.

Elementos de configuración para productos omk

En entornos con poca memoria, la reducción del número de trabajadores de omkd proporciona la mayor inestabilidad de mejora,  incluso más que el ajuste de mongod.conf. El valor predeterminado es 10, pero en un entorno con baja concurrencia de usuarios, se puede reducir a 3-5.

omkd_workers

La configuración también de  omkd_max_requests ayudará a que los subprocesos se reinicien correctamente antes de que crezcan demasiado. 

omkd_max_requests

Limitador de seguridad del tamaño del proceso: si se configura un máximo y es> = 256 mb y estamos en Linux, ejecute una verificación del tamaño del proceso cada 15 sy apague correctamente el trabajador si está sobredimensionado.

omkd_max_memory

Procese el número máximo de conexiones simultáneas, el valor predeterminado es 1000:

omkd_max_clients

Los registros de rendimiento son realmente útiles para la depuración, pero también pueden afectar el rendimiento. Por lo tanto, se recomienda apagarlos cuando no sean necesarios: 

omkd_performance_logs => false

NMIS8

NMIS 8: opciones de configuración para el ajuste del rendimiento del servidor

NIMS9

NMIS 9: opciones de configuración para el ajuste del rendimiento del servidor

Revisión del rendimiento del disco.

Esta sección está dedicada a identificar cuando el servidor no está escribiendo todos los datos para los dispositivos, esto puede tener como resultado un gráfico con interrupciones, por lo que esto ocasiona problemas de nivel 2 (Impacto severo - Sistema de producción poco confiable) o incluso en algunas ocasiones nivel 1 (Crítico para el negocio, pérdida total de servicio, pérdida de datos) al cliente, por lo que es fundamental determinar qué está sucediendo y brindar un diagnóstico.

Estado del servidor a nivel de servicio.
El servicio de monitorización se ve afectado lentamente al acceder a la GUI, y su principal impacto se centra en la falla en la ejecución de recopilaciones y actualizaciones a los nodos, las CPU se saturan y el sistema de monitorización ejecuta la recopilación de información cada minuto o 5 minutos, el sistema estar sobrecargado se ve obligado a matar los procesos que afectan el almacenamiento de la información de los nodos en los archivos del RRD

Vista de nodo en NMIS:

Se podrá visualizar gráficos de dispositivos con espacios, este es un ejemplo de cómo reconocer este comportamiento.

 



Resumen de coleccion NMIS (menú: Sistema> Diagnóstico de host> Resumen de sondeo NMIS)

La opción Polling Summary que nos brinda NMIS es muy útil ya que en ella podemos ver el detalle del tiempo de recolección de los nodos, nodos activos, nodos recolectados, etc. Estos valores deben ser acordes al número de nodos monitoreados, así mismo, el el tiempo de recolección debe estar dentro del rango de minutos configurado en el crond nmis.

Sistema de archivos

Es importante validar que las particiones de los directorios tengan espacio libre, si tenemos una partición llena la herramienta dejará de funcionar:

echo -e "\n \e[31m Información de espacio en el disco \e[0m" && df -h && echo -e "\n\n \e[31m Información de uso de RAM \e[0m" && free -m && echo -e "\n\n \e[31m Detalle de discos \e[0m" && fdisk -l

Resultado:

[root@opmantek ~]# echo -e "\n \e[31m Información de espacio en el disco \e[0m" && df -h && echo -e "\n\n \e[31m Información de uso de RAM \e[0m" && free -m && echo -e "\n\n \e[31m Detalle de discos \e[0m" && fdisk -l

  Información de espacio en el disco

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_nmis64-lv_root
                       59G  2.7G   54G   5% /
tmpfs                 3.9G     0  3.9G   0% /dev/shm
/dev/sda1             477M  109M  343M  25% /boot
/dev/mapper/vg_nmis64_data-lv_data
                      321G   11G  295G   4% /data
/dev/mapper/vg_nmis64-lv_var
                      147G  1.5G  138G   2% /var

  Información de uso de RAM
             total       used       free     shared    buffers     cached
Mem:          7984       6891       1093          0        216       1077
-/+ buffers/cache:       5596       2387
Swap:         4071       1589       2482

  Detalle de discos
Disk /dev/sda: 536.9 GB, 536870912000 bytes
255 heads, 63 sectors/track, 65270 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0008cec3

Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          64      512000   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              64        5222    41430016   8e  Linux LVM
/dev/sda3            5222       42570   299997810   8e  Linux LVM
/dev/sda4           42570       65256   182225295   8e  Linux LVM

Disk /dev/sdb: 42.9 GB, 42949672960 bytes
255 heads, 63 sectors/track, 5221 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/vg_nmis64-lv_root: 64.4 GB, 64432898048 bytes
255 heads, 63 sectors/track, 7833 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/vg_nmis64-lv_swap: 4269 MB, 4269801472 bytes
255 heads, 63 sectors/track, 519 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/vg_nmis64_data-lv_data: 350.1 GB, 350140497920 bytes
255 heads, 63 sectors/track, 42568 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/vg_nmis64-lv_var: 160.3 GB, 160314687488 bytes
255 heads, 63 sectors/track, 19490 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

[root@opmantek ~]#


% wa-  Es importante revisar el promedio de carga y iowait, si vemos que estos valores son altos eso representa problemas para el servidor ---- con el TOP


 


Lista de procesos con estado de suspensión ininterrumpida.

El comando ps nos proporciona información sobre los procesos de un sistema Linux o Unix.
A veces, las tareas pueden bloquearse, encolarce o dejar de responder. Por otras razones, o pueden continuar ejecutándose, pero consumen demasiado tiempo de CPU o RAM, o se comportan de una manera igualmente antisocial. A veces, las tareas deben eliminarse como misericordia para todos los involucrados. El primer paso. Por supuesto, es para identificar el proceso en cuestión.

Los procesos en un estado "D" o de suspensión ininterrumpida generalmente están esperando en E / S.

[root@nmis-Test log]# ps -auxf | egrep " D| Z"
root     13417  0.6  0.8 565512 306812 ?       D    10:38   0:37  \_ opmantek.pl webserver             -
root     17833  9.8  0.0      0     0 ?        Z    12:19   0:00      \_ [opeventsd.pl] <defunct>
root     17838 10.3  0.0      0     0 ?        Z    12:19   0:00      \_ [opeventsd.pl] <defunct>
root     17842 10.6  0.0      0     0 ?        Z    12:19   0:00      \_ [opeventsd.pl] <defunct>nmisslvcc5 log]# ps -auxf | egrep " D| Z"
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ
root      1563  0.1  0.0      0     0 ?        D    Mar17  10:47  \_ [jbd2/dm-2-8]
root      1565  0.0  0.0      0     0 ?        D    Mar17   0:43  \_ [jbd2/dm-3-8]
root      1615  0.3  0.0      0     0 ?        D    Mar17  39:26  \_ [flush-253:2]
root      1853  0.0  0.0  29764   736 ?        D<sl Mar17   0:04 auditd
root     17898  0.0  0.0 103320   872 pts/5    S+   12:20   0:00  |       \_ egrep  D| Z
apache   17856 91.0  0.2 205896 76212 ?        D    12:19   0:01  |   \_ /usr/bin/perl /usr/local/nmis


Pruebe el rendimiento de E / S del disco con el comando dd

El comando dd es muy sensible con respecto a los parámetros que maneja ya que puede ocasionar serios problemas en tu servidor, OMK usa este comando para obtener y medir el rendimiento y latencia del servidor, por lo que con esto determinamos que la velocidad de escritura y lectura del disco.

[root@SRVLXLIM32 ~]# dd if=/dev/zero of=/data/omkTestFile bs=10M count=1 oflag=direct
1+0 records in
1+0 records out
10485760 bytes (10 MB) copied, 0.980106 s, 15.0 MB/s
[root@SRVLXLIM32 ~]# dd if=/data/omkTestFile of=/dev/null 2>&1
20480+0 records in
20480+0 records out
10485760 bytes (10 MB) copied, 6.23595 s, 1.7 MB/s
[root@SRVLXLIM32 ~]#



Parámetros:
0.0X s para ser correctos.
0.X s, hay una advertencia (y habría un problema)
X.0 s sería crítico (y habría un problema).

Tenga en cuenta que se escribió un gigabyte para la prueba y 47 MB ​​/ s fue el rendimiento y el tiempo que tomó escribir el bloque fue de 0.223301 segundos desde el servidor para esta prueba.

Dónde:

  • if = /dev/zero (if =/dev/ input.file): El nombre del archivo de entrada desde el que desea leer.
  • of =/data/omkTestFile (of =/path/to/output.file): El nombre del archivo de salida en el que desea escribir el archivo de entrada.
  • bs = 10M (bs = block-size): establezca el tamaño del bloque que desea que use dd. Tenga en cuenta que Linux necesitará espacio RAM libre. Si su sistema de prueba no tiene suficiente RAM disponible, use un parámetro más pequeño para bs (como 128 MB o 64 MB, etc. o incluso puede probar con 1, 2 o incluso 3 gigabytes).
  • count = 1 (count = number-of-blocks): El número de bloques que desea que dd lea.
  • oflag = dsync (oflag = dsync): utilice E / S sincronizadas para los datos. No omita esta opción. Esta opción elimina el almacenamiento en caché y le brinda resultados buenos y precisos
  • conv = fdatasyn: De nuevo, esto le dice a dd que requiera una “sincronización” completa una vez, justo antes de salir. Esta opción es equivalente a oflag = dsync.

Ver información sobre el uso del disco

Este comando nos ayuda a monitorear la carga de un dispositivo de entrada y salida, observando el tiempo que los dispositivos están activos en relación al promedio de sus tasas de transferencia. También se puede utilizar para comparar la actividad entre discos.

El uso de 100% iowait / Utilization indica que hay un problema, en la mayoría de los casos, un gran problema que incluso puede provocar la pérdida de datos. Esencialmente, hay un cuello de botella en algún lugar del sistema. Quizás una de las unidades se esté preparando para morir / fallar.

OMK recomienda ejecutar el comando de la siguiente manera, ya que esto da un escenario mejor que lo que sucede con los discos.
Ejemplo: el comando muestra 5 muestras realizadas cada 3 segundos, lo que queremos es que al menos 3 de las muestras reflejen datos dentro del rango estable para el servidor, de lo contrario esto indica que hay un problema con los discos.


[root@opmantek ~]# iostat -xtc 3 5
Linux 2.6.32-754.28.1.el6.x86_64 (opmantek)     04/05/2021      _x86_64_        (8 CPU)

04/05/2021 09:23:40 PM
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           12.47    0.00    0.73   10.53    0.00   86.72

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    4.50   35.50   148.00   452.00    15.00   110.98 4468.74  274.22 5000    0.60    100.00
sdb               0.00    42.50    0.00    6.50     0.00   392.00    60.31     0.13   20.00    0.00   20    0.34    92.12
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0    0.65    56.00
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0    0.86    10.50
dm-2              0.00     0.00    4.50   52.00   140.00   416.00     9.84   149.56 5229.59  274.22 5658    0.21    25.03
dm-3              0.00     0.00    0.00    0.50     0.00     4.00     8.00    66.00    0.00    0.00    0    0.45    14.40


04/05/2021 09:23:43 PM
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           18.17    0.00    5.29    6.31    0.00   76.82

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00    50.00    9.50   19.00   596.00   260.00    30.04   130.41 2569.47  283.11 3712     0.60    92.36
sdb               0.00    36.50    0.50   59.00     8.00   764.00    12.97    25.34  425.82   18.00  429     0.25    78.82
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0     0.23    92.45
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0     0.86    88.93
dm-2              0.00     0.00    8.00  163.50   440.00  1308.00    10.19   240.76  966.94  337.38  997     0.37    68.28
dm-3              0.00     0.00    0.00   33.00     0.00   264.00     8.00    48.31    0.00    0.00    0     0.18    12.75 

04/05/2021 09:23:46 PM
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.50    0.00    1.21    11.37    0.00   75.56

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    9.50   18.00   268.00   220.00    17.75   112.91 1763.73  143.42 2618     0.85    100.00
sdb               0.00    10.00    2.00    1.50   112.00    92.00    58.29     0.01    3.86    6.25    0     0.94     97.54
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0     0.45     75.39
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0     0.78     24.96
dm-2              0.00     0.00   13.50   11.50   552.00    92.00    25.76   185.21 3029.96  101.85 6467     0.25     67.18 
dm-3              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0     0.86     43.91

04/05/2021 09:23:49 PM
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           12.10    0.00    7.21    9.17    0.00   87.92

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00    55.50    7.00   44.00    92.00   488.00    11.37   110.52  929.20  139.86 1054     0.75    89.54
sdb               0.00    65.00    0.50   34.00     4.00   792.00    23.07     0.83   24.09    1.00   24     0.55    93.61
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0     0.14    99.99
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0     0.36    78.98
dm-2              0.00     0.00    7.00  242.50    84.00  1940.00     8.11   179.44  240.22  137.36  243     0.75    25.30
dm-3              0.00     0.00    0.00    5.00     0.00    40.00     8.00     1.30  305.90    0.00  305     0.23    45.12

04/05/2021 09:23:52 PM
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9.50    0.00    11.21    19.30    0.00   92.92

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.16   114.34    7.02  191.18   132.04  2444.27    13.00     3.60   18.18   81.41   15     0.14    99.99    
sdb               0.03   205.87    2.36   70.03    31.22  2207.55    30.92     5.81   80.25   53.76   81     0.94    97.54
dm-0              0.00     0.00    0.10    1.01    11.77     8.07    17.90     0.84  755.10   72.31  822     0.60    98.36
dm-1              0.00     0.00    0.09    0.13     0.74     1.03     8.00     0.22  985.66  153.25 1580     0.47    94.48
dm-2              0.00     0.00    9.25  575.59   129.18  4604.83     8.09     6.09    9.74   74.24    8     0.61    82.37
dm-3              0.00     0.00    0.12    4.74    21.57    37.89    12.24     2.52  518.00  131.58  527     0.23    93.15

[root@opmantek ~]#


Este problema se solucionó moviendo la MV a un ambiente con discos de estado sólido, el cliente validó que la MV estaba usando discos mecánicos (HDD), por lo que un clon de una MV de laboratorio no funcionaria ya que se presenta el mismo problema. Al reemplazar los discos HDD a discos de estado sólido, la MV y los servicios de monitoreo se estabilizan, la memoria RAM, CPU y uso del disco es normal, esto de acuerdo con los nodos que el sistema está monitoreando.


  • No labels