Herramientas de supervisión

Prácticas recomendadas para el desarrollo de aplicaciones > Supervisión de aplicaciones de ThingWorx > Herramientas de supervisión

La plataforma de ThingWorx se basa en tecnología de Java. Las herramientas de diagnóstico y supervisión que se explican en esta sección están diseñadas para recopilar métricas de rendimiento y otros datos de la máquina virtual Java (JVM). Utilice estas herramientas para supervisar las aplicaciones de ThingWorx a través de la capa de JVM. Las herramientas obtienen los siguientes datos de JVM:

• Operaciones de memoria: se debe verificar si el servidor tiene suficientes recursos de memoria asignados y cuánto tardan las operaciones de recopilación de basura (GC) de JVM.

• Rendimiento de los subprocesos: se debe verificar si hay incidencias de transacciones o subprocesos largos que pueden provocar incidencias de rendimiento en la aplicación de ThingWorx.

PTC System Monitor (PSM)

PTC System Monitor (PSM) es un sistema de supervisión de rendimiento de aplicaciones con tecnología de Dynatrace. PTC tiene Dynatrace personalizado para los requisitos de supervisión de las aplicaciones de ThingWorx. PSM proporciona a los administradores del sistema herramientas para detectar, diagnosticar y reparar problemas que afectan al estado operativo de la aplicación. Permite supervisar los sistemas de prueba y producción. No afecta al rendimiento de la aplicación de ThingWorx. Este módulo está disponible como parte del contrato de mantenimiento y no requiere la adquisición de licencias adicionales para la supervisión de la plataforma principal.

PSM permite supervisar la actividad en el nivel de subproceso que se produce en el nivel de JVM y sintetiza esta actividad en una tecnología patentada que se denomina PurePaths. En PSM PurePath se proporcionan detalles sobre la ruta de ejecución del servicio ThingWorx en el servidor y el tiempo de ejecución. También se incluye información del contexto, como instrucciones SQL ejecutadas.

Capacidades de PSM

PSM permite:

• Aumentar el tiempo de actividad de la aplicación antes de que falle:

◦ Enviar notificaciones cuando se infringen los umbrales, por ejemplo, debido a un uso elevado de la CPU. De este modo, el administrador puede tomar medidas correctivas para solucionar las incidencias antes de que se conviertan en un problema de todo el sistema.

◦ Proporcionar una vista histórica del uso de los recursos del sistema. De este modo, se pueden estimar los requisitos de capacidad futuros para los recursos del sistema.

• Mejorar las funciones de supervisión:

◦ Se utilizan tableros simplificados y personalizables para resumir el estado del sistema y los componentes.

◦ Se proporcionan funciones de exploración en profundidad de transacciones individuales, usuarios y componentes de servidor para obtener más detalles.

◦ Se incluye una lista de incidentes integrada para las incidencias que afectan al estado del sistema.

• Mejorar las funciones de diagnóstico con datos en tiempo real:

◦ Se utiliza la tecnología PurePath para recopilar datos de diagnóstico en tiempo real y se registran métricas de rendimiento histórico.

◦ Permite eliminar las horas empleadas en la reproducción de incidencias con configuración detallada adicional y en la resolución de problemas con el soporte técnico de PTC.

PSM permite recopilar y registrar continuamente datos en tiempo real de la aplicación de ThingWorx y los almacena durante períodos de tiempo prolongados. Los datos que recopila PSM permiten supervisar continuamente las siguientes métricas de rendimiento, que afectan a las aplicaciones personalizadas. Esto ayuda al equipo de desarrollo o a los servicios de soporte técnico de PTC a reproducir los eventos que provocan la incidencia de rendimiento:

• Rendimiento de la memoria de JVM

• Tiempos de ejecución de servicio mediante datos de tiempo de PurePath

• Métricas de la memoria del sistema operativo, de la CPU y de la base de datos

• Errores de registro y otros incidentes de ThingWorx

Supervisión directa de JVM

Las herramientas de supervisión directa de JVM las proporciona Oracle o la extensión Support Tools de ThingWorx. Estas herramientas se pueden utilizar junto con PSM para obtener datos de rendimiento detallados. Si no se utiliza PSM, la recopilación de datos directamente desde la JVM es una buena alternativa para identificar y corregir las incidencias de rendimiento. Se recomienda supervisar los siguientes diagnósticos de JVM para las aplicaciones de ThingWorx:

• Supervise el rendimiento de la memoria a lo largo del tiempo mediante el registro de recopilación de basura, una función integrada de JVM.

• Recopilación y análisis del nivel de subproceso mediante la extensión Support Tools de ThingWorx.

Supervisión del uso de la memoria de un servidor ThingWorx

La máquina virtual Java (JVM) gestiona su propia memoria (montón) de forma nativa mediante el recolector de basura (GC). GC permite identificar y quitar objetos del montón de Java que no se están utilizando. El uso de la memoria de un servidor ThingWorx se puede supervisar mediante el registro de los detalles que recopila GC.

El fichero de registro de GC se puede utilizar para identificar tendencias en el consumo de memoria. En función de las tendencias, se puede verificar si se debe cambiar el parámetro de montón máximo del servidor Apache Tomcat para obtener un mejor rendimiento. Por lo tanto, se recomienda configurar el registro de GC en el servidor Tomcat de Apache.

JVM tiene señalizadores a los que se llama en tiempo de ejecución. Estos señalizadores se utilizan para escribir estadísticas sobre eventos de GC, como el tipo de evento de GC, la cantidad de memoria consumida al inicio del evento, la cantidad de memoria que libera el evento de GC y la duración del evento de GC.

El fichero de registro de GC se sobrescribe cada vez que se inicia JVM. Se recomienda realizar una copia de seguridad del fichero de registro durante el reinicio del servidor. De este modo, se puede analizar si el uso de la memoria ha provocado el reinicio del servidor.

Se pueden utilizar herramientas de análisis como, por ejemplo, GCEasy.io y Chewiebug GC Viewer, para analizar los registros de la recopilación de basura.

Procedimiento para configurar el registro de recopilación de basura en Linux (setenv.sh)

Realice los siguientes pasos para configurar el registro de recopilación de basura en Linux:

1. Abra el script $CATALINA_HOME/bin/setenv.sh en un editor de texto.

Es posible que el fichero del script setenv.sh no esté disponible en todas las instalaciones. Si el fichero no existe, cree un fichero setenv.sh nuevo en la ubicación.

2. Añada el siguiente texto al final de la variable JAVA_OPTS entre comillas dobles.

-XX:+UseG1GC -Xloggc:/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails

Si no se especifica JAVA_OPTS en el fichero setenv.sh o el fichero setenv.sh es nuevo, añada la siguiente línea en el fichero:

JAVA_OPTS=”-XX:+UseG1GC -Xloggc:/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails”

Debe tenerse en cuenta lo siguiente:

▪ La opción -XX:+PrintGC permite devolver un registro de salida menos detallado. Por ejemplo, en el registro de salida se incluyen los siguientes detalles:

2017-10-10T13:22:49.363-0400: 3.096: [GC (Allocation Failure) 116859K->56193K(515776K), 0.0728488 secs]

▪ La opción -XX:+PrintGCDetails permite devolver el registro de salida detallado. Por ejemplo, en el registro de salida se incluyen los siguientes detalles:

2017-10-10T13:18:36.663-0400: 35.578: [GC (Allocation Failure) 2017-10-10T13:18:36.663-0400: 35.578: [ParNew: 76148K->6560K(76672K), 0.0105080 secs] 262740K->193791K(515776K), 0.0105759 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]

3. Añada las siguientes líneas al final del script setenv.sh. Este código realiza automáticamente una copia de seguridad de un fichero gc.out existente en gc.out.restart antes de iniciar el servidor Apache Tomcat:

# Backup the gc.out file to gc.out.restart when a server is started.
if [ -e "$CATALINA_HOME/logs/gc.out" ]; then
cp -f "$CATALINA_HOME/logs/gc.out" "$CATALINA_HOME/logs/gc.out.restart"
fi

4. Guarde los cambios en el fichero.

5. Reinicie el servicio de Apache Tomcat mediante el controlador de servicios que sea aplicable al sistema operativo.

Procedimiento para configurar el registro de recopilación de basura en Windows (Apache Service Manager)

Realice los siguientes pasos para configurar el registro de recopilador de basura en Windows:

1. En el Explorador de Windows, vaya a <Tomcat_home>\bin.

2. Inicie el ejecutable que incluye w en su nombre. Por ejemplo, Tomcat<version number>w.exe.

3. Pulse en la ficha Java.

4. En el campo Java Options, añada las siguientes líneas:

-Xloggc:logs/gc_%t.out
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails

Para obtener información sobre las opciones -XX:+PrintGC y -XX:+PrintGCDetails, consulte la sección Procedimiento para configurar el registro de recopilación de basura en Linux (setenv.sh).

5. Pulse en Aplicar para guardar los cambios realizados en la configuración del servicio.

6. En la ficha General, pulse en Detener.

7. Pulse en Iniciar para reiniciar el servicio de Apache Tomcat.

El nuevo registro de recopilación de basura se escribe en el fichero %CATALINA_HOME%\logs\gc_<Tomcat_Restart_Timestamp>.out.

Recopilación de datos de diagnóstico mediante la extensión Support Tools

La extensión Support Tools de ThingWorx se utiliza para recopilar información para el soporte técnico de ThingWorx. Esta información se utiliza durante la resolución de problemas en la aplicación de ThingWorx. La extensión permite recopilar los siguientes datos de diagnóstico:

• Volcados de subprocesos de Java: detalles sobre todos los subprocesos que se ejecutan en una máquina virtual Java en un momento específico. Puede registrar la actividad de los subprocesos para los períodos especificados.

• Volcados de montón de Java: detalles sobre todos los objetos del espacio del montón de una máquina virtual Java en un momento específico.

PTC recomienda instalar esta extensión en la instancia de ThingWorx. La extensión está disponible en la página de descargas de software de PTC en support.ptc.com.

VisualVM y otras herramientas de supervisión de JMX

VisualVM es una herramienta de supervisión que recopila datos para aplicaciones Java. VisualVM se puede utilizar para supervisar aplicaciones de ThingWorx. Permite recopilar información sobre la utilización de la memoria y la CPU. Permite generar y analizar volcados de montón y realizar seguimientos de las pérdidas de memoria. Se pueden recopilar datos para aplicaciones que se ejecutan localmente o en ordenadores remotos.

VisualVM proporciona una interfaz que permite ver gráficamente la información sobre las aplicaciones Java.

VisualVM está disponible junto con Java JDK. Consulte la sección en el centro de ayuda de ThingWorx Configuración de la opción de Apache Tomcat Java para obtener más información sobre la configuración de conexión de VisualVM.

En otras herramientas que se integran con JVM mediante Java Management Extensions (JMX) también se proporcionan funciones de supervisión similares.

VisualVM permite capturar las siguientes métricas clave que afectan al rendimiento de la aplicación:

• Rendimiento de la memoria de JVM

• Tiempo necesario para ejecutar subprocesos

• Memoria del sistema operativo y métricas de CPU

• Supervisión de agrupaciones de conexiones de base de datos

VisualVM permite realizar un seguimiento de los datos en tiempo real durante aproximadamente 20 minutos.

Supervisión de registros de aplicaciones de ThingWorx

Los registros de la aplicación ThingWorx se deben supervisar periódicamente para comprobar si hay errores u otras operaciones anómalas. Los errores se pueden producir en la capa de la plataforma o en los scripts personalizados que se utilizan con ThingWorx. Se recomienda revisar los mensajes del registro de errores diariamente.

Configuración de la opción LoggingSubsystem para escribir referencias de pila para errores

La opción Activar seguimiento de pila de LoggingSubsystem permite escribir mensajes de error y las referencias de pila asociadas en ficheros de registro. Por defecto, LoggingSubsytem no está configurado para escribir referencias de pila (pilas de llamadas) en el disco. Defina la opción Activar seguimiento de pila para escribir pilas de llamadas de excepciones y mensajes de error en el fichero ErrorLog.log, que está disponible en la carpeta ThingworxStorage/logs. Se recomienda definir esta opción para tener los detalles de las llamadas de función en la referencia de pila durante la depuración de un error.

Conservación de los registros de aplicación

El nivel de registro determina la cantidad de granularidad que se debe mostrar en los registros. Se recomienda mantener el nivel de registro de la aplicación en el nivel de detalle mínimo, como Información o Avisar, a menos que se esté solucionando activamente una incidencia. Se debe tener cuidado al aumentar el nivel de detalle del registro a Depurar, Seguimiento o Todo. Esto puede tener un efecto adverso en el rendimiento de ThingWorx. Puede provocar un comportamiento impredecible de la aplicación si los recursos disponibles en la plataforma no son suficientes.

Los registros se guardan como ficheros independientes del servidor en la carpeta /ThingworxStorage/logs. Los registros se archivan en la carpeta archives, que se encuentra en la carpeta logs. Las reglas de rotación del registro se basan en las configuraciones de tamaño de fichero y tiempo que están definidas en Configuración de conservación del registro del subsistema de registro. Esta configuración se puede cambiar y aplicar en tiempo de ejecución.

Se pueden especificar las siguientes configuraciones de sustitución incremental en Sistema > Subsistemas > LoggingSubsystem > Configuración:

• Tamaño del fichero: el fichero de registro se archiva cuando su tamaño alcanza o supera el tamaño definido en el campo Tamaño máximo de fichero en KB. El tamaño de fichero por defecto para un registro se define en 100.000 KB. El tamaño máximo de fichero que se puede definir es 1.000.000 KB.

• Tiempo: los ficheros se sustituyen diariamente a medianoche, cuando se activa un evento de registro. Los registros se mueven a la carpeta archives. Por defecto, si un registro permanece en la carpeta archives durante más de siete días, se borra. El valor por defecto se puede cambiar en el campo Número de días máximo de archivo. Se pueden especificar entre 1 y 90 días.

Es importante supervisar los tamaños de registro. Se deben depurar los ficheros de registro de forma constante realizando una copia de seguridad de los ficheros en primer lugar o descartándolos cuando contengan información obsoleta.