[OVO] Agent System Detection Error[1]: ovodetect: Error - Execution of # ovosysdetect_oraspi.sh #

Bien, anteriormente publiqué una solución de la alerta hermana a la que se dedica este post. En este caso para sistemas Unix/Linux Agent System Detection Error[1]: ovodetect: Error - Execution of '/var/opt/OV/bin/instrumentation/ovosysdetect_oraspi.sh' returned '1'  que en este caso no es un error de timeout, si no un problema en la ejecución del script. Tras editarlo y ver exactamente como trabaja, seguía sin ver el problema, pues manualmente la ejecución ( llama a otro script ) funciona sin problemas, pero el valor sigue devolviendo 1 ( Error ).
Abriendo el caso con HP, encontré una solución en su base de datos de soluciones, y efectivamente tal y como sospechaba, es un problema de código. 

A continuación, la solución aportada por HP y que por el momento ha silenciado las alertas:

[VBS] schtasks.exe y Nagios

Siguiendo con un caso práctico, me veo en la necesidad de monitorizar el estado de las tareas programadas en un servidor. Está controlado por Nagios, así que haré uso de NRPE. Buscando en la BBDD de los plugins de Nagios, he encontrado un par, pero el principal problema es que, o bien estaba en Francés, o que no había suficiente información de como utilizarlo. Además, no me gustaba como funcionaban.

Tirando otra vez de vbs, he creado otro script tomando como patrón el que posteé anteriormente sobre perfmon. También me encontré con problemas utilizando los providers de Windows referentes a las schelude tasks así que me las ingenié con el comando schtasks.exe. El funcionamiento es simple: guardo el resultado del comando en un txt, recorto las lineas hasta quedarme con la columna "Estado", y busco si coincide con algún error. En este caso busca un "No " ( mirando el estado de tareas fallidas ), y devolverá un valor u otro.

[OVO] Agent System Detection Error[1]: ovodetect: Error - Execution of # ovosysdetect_sybspi.bat #

He estado unos días esperando el resultado de unas modificaciones que hacen referencia al siguiente error

Agent System Detection Error[1]: ovodetect: Error - Execution of 'C:/Documents and Settings/All Users/Application Data/HP/HP BTO Software/bin/instrumentation/ovosysdetect_sybspi.bat' returned '1'. Command 'cmd /c 'C:/Documents and Settings/All Users/Application Data/HP/HP BTO Software/bin/instrumentation/ovosysdetect_sybspi.bat'' Timed out...   

Aunque no ha sido una solución 100% efectiva, si que ha calmado un poco la consola de tantos mensajes que recibía. Como he marcado en negrita en la misma alerta, se queja de time out, así que he cambiado el valor del time out de 30 que viene por defecto a 60, e incluso en algunos casos en los que aún se queja ( y no pienso volver a cambiar ) , a 90.

La forma de hacer el cambio es la siguiente:

1. Hacer una backup del fichero C:\Program Files\HP\HP BTO Software\lib\ASSD\LicUtils.pm por si acaso.
2. Editar el original y en la linea 188, cambiar el valor 30 que corresponde al timeout.

[OVO] Errores DBSPI sobre Data Logging Failed

Estos errores de no corregirlos cuando toca, llegado fin de mes me encuentro con quejas de los Administradores por que no salen completas las gráficas en el PM. Normal, claro está, pues los informes no se pueden completar, no existen datos.

En la consola me encontraba constantemente mensajes de DBSPI Data Logging failed. Efectivamente, si a través del PM ejecutaba gráficas, estas ya no salía. Encontré un procedimiento que me solucionaba el problema. 
El único inconveniente es que al aplicarlo, perdía el historial de las gráficas que tenía almacenadas. De momento y en modo de prueba parece que merece la pena, ya que donde he ejecutado el procedimiento no se ha vuelto a reproducir el error.Hasta que vuelva a fallar, estos son los pasos a seguir:

En la consola de OVO con el nodo afectado seleccionado, clic botón derecho y ejecutamos en orden las siguientes tools.

1. Iniciar > DBSPI > Admin Windows > Disable Graphs and Reports
2. Iniciar > DBSPI > Admin Windows > Enable Graphs
3. Iniciar > DBSPI > Admin Windows > Enable Reports
4. Restart del componente coda
5. Restart de los servicios el Performance Collection Component

Tras ejecutar esto, podemos confirmar las alertas y comprobar que dejan de salir, y transcurrida una hora, podemos generar gráficas del nodo en el PM, si todo ha ido bien.

[VBS] Comprobar colectores de datos ( perfmon )

Hace unos días me encontraba en la situación de tener controlados unos colectores personalizados en unos servidores Windows. El planteamiento se da cuando al reiniciar la máquina, el contador se queda parado por defecto una vez vuelve a arrancar. A nivel de operador no es cómodo andar mirando que servidor tiene un colector personalizado corriendo y mirar cada vez que un servidor se reinicia si esta encendido o no.

El siguiente script comprueba si el colector que le mandemos se encuentra running. En caso de que no lo esté, lo arrancará. También podemos configurarlo para que nos mande notificaciones. Para esto utilizaremos la aplicación logman.exe que encontramos en Windows por defecto.

script

NOTA: es diferente para 2008 que para 2003. En 2008 el resultado del estado se ejecuta sin mas con logman.exe. En 2003, hay que añadirle logman.exe query.

Server 2003

iReturn = objShell.Run("CMD /C logman.exe query > C:\out.txt", , True)

Server 2008

iReturn = objShell.Run("CMD /C logman.exe  > C:\out.txt", , True)

Uso de Typeperf - Parte II

Buen Lunes a todos!!

Continuamos con la segunda parte del uso de Typeperf. Aquí vamos a utilizarlo mediante un script en vbs para monitorizar cada x minutos, por ejemplo, el valor de un contador que queramos. A partir de aquí, lo implementamos en ovo, Nagios o cualquier otra plataforma de monitorización.

El script en cuestión lo podemos encontrar en Nagios Exchage : Check Performance Monitor, el mismo lo podemos personalizar. En la página del script hay muy poca información pero es muy intuitiva, lo único que nos quedará es configurar los umbrales de alerta para cada tipo de contador, pues no siempre es el mismo y el valor que recibimos tampoco.

Comentar también en el aspecto del valor recogido, que la conversión no es tan sencilla y puede darnos algún que otro dolor de cabeza. Por ejemplo, podemos recibir por comando el valor 25 respecto a un contador, pero al pasarlo por el script, el 25 se convierta en 2500000. Las soluciones van des de ir dividiendo para eliminar esos 0 de más, o bien, para mi la más sencilla, si el umbral es de 26, configurarlo a 2600000.

Script

Este Script está preparado para recibir las variables por comando e interpretarlas después.
Entonces, para el caso de Nagios, podemos introducir dentro del INI del servidor monitorizado bajo NRPE Handlers, la siguiente linea

check_proc_time=cscript /nologo "C:\Program Files\NSClient++\scripts\perfmon4.vbs" -C "Processor" -I "_Total" -P  "% Processor Time" "% Processor Time" -f "%f %"

Lo que le pedimos es sobre el contador del procesador, queremos saber el % Processor Time y esto el script lo traduce a:

typeperf "\Processor(_Total)\% Processor Time" -sc 1

En el fichero temporal que crea, se almacena el valor que se recoge en el momento, se analiza y se compara con los umbrales que definimos o bien en el script, o bien lo podemos pasar por comando añadiendo -w 50 -c 90, por ejemplo.

Por supuesto, podemos modificar este script para que no recoja valores y ponerlos nosotros de forma manual y personalizada, pues si tenemos que configurarlo para ovo, mejor que sea un valor estático y no variable.

Y para el Viernes...

Lo típico, hoy toca pasar a producción.

Uso de typeperf.exe - Parte I

El comando typeperf se está volviendo en una utilidad bastante útil en mis labores de monitorización. Con typeperf podemos obtener valores de los contadores de los que dispone un sistema, por ejemplo, Uso de CPU/ Memoria/ Disco y de cosas más concretas como SQL o Exchange por ejemplo.

[OvO]ovconfget / ovconfchg - Variables y Parámteros

En mi búsqueda del conocimiento por la red y mis ganas de optimizar más la plataforma de monitorización, encontré este documento de gran utilidad repletos de variables y parámetros que podemos incluir ( siempre con cabeza ) en el fichero ovconfchg y nos ayudará a filtrar y organizar mejor los agentes en los servidores. CA_ANNO_NODE Flags : external Description : Setup add.l ECS annotate nodes on OVO managed nodes.

[OvO]Reached max waiting intervals for policy (OpC30-3405).No opcmon value received and reached max waiting intervals (OpC30-3404)

En la consola de ovo tenia un enorme chorro de Warnings con el mensaje de error

Error: Reached max waiting intervals for policy <policy name> (OpC30-3405).No opcmon value received and reached max waiting intervals (OpC30-3404)

El problema reside en una larga ejecución de políticas o bien timeouts por la larga espera.

Todo esto y mucho más lo podemos solucionar editando y añadiendo unas lineas a un archivo. Abrimos el símbolo del sistema en el nodo afectado con permisos de Administrador y ejecutamos el comando ovconfchg -edit. Se abrirá un fichero en el bloc de notas. Aquí, bajo el namespace eaagt tenemos que añadir las siguientes entradas:

OPC_KILL_SCHEDULE=true
OPC_KILL_SCHEDULE_TIMEOUT=-1
FAILED_COLLECTION_RETRIES=-1
FAILED_POLICY_TIME_TO_REACTIVATE=-1
MAX_RETRIES_UNTIL_POLICY_FAILED=-1
POLICY_MIN_INTERVALS_WAIT=-1
POLICY_MIN_TIME_WAIT=-1

La traducción para cada una de estas entradas se explican a continuación

# ovconfchg -ns eaagt -set OPC_KILL_SCHEDULE true
Sample ovconfpar syntax ( from mgt server against target node)
# ovconfpar -change -host <hostname> -ns eaagt -set OPC_KILL_SCHEDULE true
For the above commands run it for each parameter.
The sample syntax to clear it is # ovconfchg -ns eaagt -clear OPC_KILL_SCHEDULE
-- The rest of this section contains a detailed explanation of the parameters.
Keyword     : OPC_KILL_SCHEDULE
Flags       : external
Description : When a new request to start a process for a scheduled action arrives at the action agent, it first checks whether a process already started from the same policy is still running.
              IF YES
              THEN
                 It checks whether the process has already run longer than the configurable timeout (default 55 seconds).
                 IF YES
                 THEN
                   The old process is killed. A warning is written to the opcerror log. No end or failed message is sent to the management server. The new process is started.
                 ELSE
                   The new process is not started. A warning is written to the opcerror log. No start message is sent to the management server.
                 ENDIF
              ELSE
                 The new process is started.
              ENDIF
              OPC_KILL_SCHEDULE can be used to disable the new functionality.
namespace: eaagt (>=OVO8)
Keyword     : OPC_KILL_SCHEDULE_TIMEOUT
Flags       : external
Description : Defines the timeout period that is used to check whether an old process is killed or the new one not started.
              (See also OPC_KILL_SCHEDULE)
              It can be set to
                 0  Default of 55 seconds is used.
                >0  Number is used as the timeout period in seconds.
                <0  No timeout check is done, the old process is killed
                    immediately.
Type/Unit   : int
Default     : 55
namespace: eaagt (>=OVO8)
Keyword     : FAILED_COLLECTION_RETRIES
Flags       : external
Description : Specifies whether startup of a failed collection should be restarted for an Advanced Monitor Policy.
              0  : No retries should be done.
              -1 : This failure is ignored - the policy does not go into failed state (This is like it was with agents before A.07.26).
Type/Unit   : int
Default     : 3
namespace: eaagt (>=OVO8)
Keyword     : FAILED_POLICY_TIME_TO_REACTIVATE
Flags       : external
Description : You can automatically attempt to reactivate a policy in the failed state.
              The time before reactivation is attempted can be specified with this variable.
              The time is specified in hours. Use 0, if no reactivation should be done.
Type/Unit   : int
Default     : 24
namespace: eaagt (>=OVO8)
Keyword     : MAX_RETRIES_UNTIL_POLICY_FAILED
Flags       : external
Description : This is the number of attempt that a policy makes to
              collect data.
              This is important for usage with external program sources. If an external program has a problem, policy handling should not be stopped immediately. Therefore, external  collection is stopped and restarted a number of times.
              This variable specifies how often the collection is started.  Use 1 if no retries should be made.
Type/Unit   : int
Default     : 3
namespace: eaagt (>=OVO8)
Keyword     : POLICY_MIN_TIME_WAIT
Flags       : external
Description : Minimum time to wait before stopping a policy if it does not receive any data. The time is specified in minutes.
              Important for program sources where the execution time of an external program depends on the current system performance.
              If the system is very busy, it is possible that the execution takes longer than the configured interval. Reconfiguring the time interval that the monitor agent waits for external programs to finish can be helpful.
              To specify the number of intervals, see POLICY_MIN_INTERVALS_WAIT.
Type/Unit   : int
Default     : 2
namespace: eaagt (>=OVO8)
Keyword     : POLICY_MIN_INTERVALS_WAIT
Flags       : external
Description : Minimum number of wait intervals before stopping a policy if it does not receive any data.
              Important for program sources where the execution time of an external program depends on the current system performance.
              If the system is very busy, it is possible that the execution takes longer than the configured interval. Reconfiguring the  time interval that the monitor agent waits for the external programs to finish can be helpful.
              Use -1 if POLICY_MIN_TIME_WAIT should be used.
              Use  0 if the policy should not wait.
Type/Unit   : int
Default     : -1
namespace: eaagt (>=OVO8)

Esta es una solución que a muchos puede irle bien a y otros simplemente podrán suavizar la avalancha de alertas de este tipo. Si de verdad no deseas recibir ninguna de estas alertas, solo tienes que añadir al montón la siguiente entrada OPCMONA_ERRORMSG_ONLY_OPCERROR=true.

CUIDADO!: Añadiendo esta ultima entrada estarás suprimiendo todos los mensajes de OpC30-3400 a

OpC30-3409

[VBS] Comprobación de plataforma 32/64 bits

Este pequeño pero útil Script en vbs conecta a una lista de servidores que hemos definido previamente y conecta a cada una de ellas exportando los resultado a un fichero *.txt donde encontraremos el nombre de la máquina junto las propiedades del procesador.

[OvO] Componente rtmd - aborted en agente

En muchas ocasiones cuando un componente del agente ovo cae, lo más fácil y sencillo pues así se acaba solucionando es hacer un restart del agente ( opcagt -restart / opcragt -restart servidor - si es en remoto). Sin embargo no siempre es tan fácil, y en este caso sucedió con el componente rtmd. El componente aparecía aborted . Por mas que reinicies el agente, mates procesos... sigue estando aborted.

Tras marearme encontré esta solución:

Acceder y editar el fichero C:\ProgramData\HP\HP BTO Software\perfd.ini

Modificar las siguiente linea#ipv4=false # Handle IPv4 protocol only a  #ipv4=true # Handle IPv4 protocol only
 Ejecutar en comando opcagt -restart


Volvemos a comprobar el estado del agente tras el restart, y deberíamos poder observar que el componente rtmd se encuentra running.

La monitorización

Que gran sistema! Cuando el cliente te avisa de que su plataforma se ha tirado un pedo, tu ya llevas rato oliéndolo. Sin embargo no siempre es todo tan preciso, pues la misma plataforma que utilizar para monitorizar, también debe ser monitorizada ya que esos pequeños fallos en la ejecución de los procesos para enterarnos de todo lo que sucede nos hacen perder la cabeza y enrrojecer frente al cliente.

Aunque no es amplia mi experiencia con muchas de estas herramientas me topo cada día con problemas y errores que hay que solucionar cuanto antes.

Los aportes se basarán principalmente en OVO ( hpom ), Sitescope, Nagios XI y compartiré pequeños scripts que he ido diseñando para facilitar muchos procesos y me han ayudado a optimizar y monitorizar.

Let's monitoring!