Una política de salud es la definición de criterios de salud específicos de los que WebSphere Extended Deployment se puede proteger. La función de gestión de salud utiliza la política definida a
medida que busca si hay anomalías de software en el entorno del servidor de aplicaciones.
Por qué y cuándo se efectúa esta tarea
Siga los
pasos de esta tarea. También puede crear y mantener políticas de salud mediante el uso de scripts.
Consulte
Gestión de políticas de salud con scripts para obtener más información.
- En la consola administrativa, pulse Políticas operativas >
Políticas de salud > Nuevo.
- Definir las propiedades generales de la política de salud.
- Proporcione un nombre para la política de salud. El nombre debe ser exclusivo entre todas las políticas de salud y debe ajustarse a un criterio de denominación determinado. El criterio de denominación se describe en el panel de ayuda de la consola de políticas de salud.
- OptionalColonSymbol Proporcionar una descripción de la política de salud.
- Seleccione la condición de salud. Todas las condiciones disponibles admiten reinicios de servidor como reacción. Las condiciones de antigüedad y carga de trabajo son políticas basadas en la prevención y las demás son políticas basadas en la detección.
- Condición basada en antigüedad se activa cuando los miembros asociados a esta política llegan a un determinado valor de antigüedad.
- Condición de tiempo de espera de petición excesivo se activa si las peticiones dirigidas a un miembro asociado exceden el tiempo de espera y el porcentaje de casos en los que se excede el tiempo de espera supera el valor especificado. Esta condición admite vuelcos de hebras además de las reacciones de reinicios de servidor.
RestrictionColonSymbol La condición de tiempo de espera de petición excesivo no se
aplica al tráfico JMS e IIOP.
- Condición de tiempo de respuesta excesivo se activa si el tiempo de respuesta medio para las peticiones de los miembros asociados a esta política basada en la detección excede
un determinado intervalo de tiempo.
- Condición de memoria: uso de memoria excesivo se activa si el uso de memoria de los miembros asociados a esta política basada en la detección excede un porcentaje del tamaño máximo del almacenamiento dinámico para un determinado intervalo de tiempo.
- Condición de memoria: pérdida de memoria busca si hay tendencias descendentes constantes en memoria libre disponible para un servidor en el almacenamiento dinámico. El valor del nivel de detección determina cuándo se detectan estas tendencias. El valor más lento requiere más datos históricos.
Los valores estándar y más rápido requieren la misma cantidad de datos históricos, aunque el valor más rápido permite realizar el análisis antes de que el almacenamiento dinámico Java se amplíe a su tamaño máximo configurado. Esto permite una detección más temprana, aunque también es más propenso a detectar valores positivos falsos. Esta condición admite vuelcos de almacenamiento dinámico además de reinicios de servidor como reacciones.
- Condición de reducción de saturación detecta situaciones en las que las peticiones se redireccionan hacia un miembro de clúster anómalo que indica tiempos de respuesta lentos. La reducción de saturación se basa en la detección de puntos de cambio en datos de una serie determinada.
Para detectar los puntos de cambio, calcula la media izquierda y la media derecha para un punto determinado.
Para un punto, la media izquierda consta de la media de N muestras que llegan antes de esta muestra y la media derecha es la media de N muestras (incluyendo la propia muestra) que llegan más tarde.
La diferencia entre la media izquierda y derecha se almacena y compara con otras diferencias de un intervalo determinado establecido en N para determinar si la diferencia es un máximo local.
Si es la diferencia máxima, el punto al que corresponde esta diferencia se llama punto de cambio.
Las dos medidas que se utilizan para detectar la reducción de saturación son los tiempos de respuesta y los
pesos del gestor de carga de trabajo de despliegue observados para el servidor.
La política Detección más rápida, mayor probabilidad de falsas alarmas utiliza menos muestras
(N=10) para los tiempos de respuesta y los pesos del gestor de carga de trabajo dinámica, e intenta detectar un punto de cambio en cada una de las medidas basándose en el conjunto de muestras.
En consecuencia, llega a una conclusión con mayor rapidez porque espera a tener 20 muestras, 10 para la media izquierda y 10 para la media derecha, para calcular una diferencia de medias y buscar un máximo local.
Las muestras se recopilan en intervalos de 15 segundos. Por lo tanto, la reducción de saturación puede detectarse aquí en un intervalo de 5 minutos. Sin embargo, puesto que hay menos muestras, si las muestras tienen muchos puntos máximos y mínimos temporales, es más probable que se produzcan falsas alarmas.
La política Detección más lenta, menor probabilidad de falsas alarmas utiliza más muestras (N=15) par a los tiempos de respuesta y los pesos del gestor de carga de trabajo dinámica.
En consecuencia, llega a una conclusión con menor rapidez porque espera a tener 30 muestras (15 para la media izquierda y 15 para la media derecha) para calcular una deferencia de medias.
El tiempo de detección es de 7 minutos y 30 segundos. Sin embargo, puesto que el número de muestras es mayor, si hay pocas muestras con puntos máximos y mínimos temporales no afecta significativamente a las medias.
Por lo tanto, es menos probable que se produzcan falsas alarmas.
RestrictionColonSymbol La condición de reducción de saturación no se aplica al
tráfico JMS e IIOP.
- Condición de carga de trabajo se activa si los miembros asociados a esta política han atendido a un número de peticiones definido por el usuario.
- Pulse Siguiente.
- Defina propiedades de la condición de salud de la política de salud. Las propiedades de condición de salud que se visualizan varían en función de la condición de salud seleccionada.
- Propiedades de condición de salud
- Antigüedad máxima
- Este campo se utiliza para establecer el valor de antigüedad para la condición de salud basada en la
antigüedad. La política de condición basada en antigüedad reinicia los miembros asociados a ella cuando
su antigüedad alcanza un determinado valor. Los valores aceptables son números enteros positivos de días u horas entre 1 hora y 365 días. Para especificar el valor de 1,5 días, utilice 36 horas porque no se da soporte a los números decimales.
- Porcentaje de peticiones con tiempo de espera excedido para provocar la condición de incumplimiento:
- Este campo establece el umbral para el porcentaje de las peticiones con tiempo de espera excedido.
Los valores aceptables para este campo son números enteros entre 1 y 99.
- Tiempo de respuesta:
- La política de condición de tiempo de respuesta excesivo reinicia los miembros cuando el promedio
del número de peticiones completadas supera el periodo de tiempo indicado. Los valores aceptables para este campo son de 1 milisegundo a 60 minutos.
Para los beans controlados por mensajes (MDB), el tiempo de respuesta se basa en el
tiempo que tarda el método onMessage. Para los clientes síncronos, el tiempo de
respuesta es el intervalo de tiempo entre las llamadas de recepción de un cliente en
el mismo objeto de sesión. El tiempo de respuesta también incluye el tiempo
invertido en las colas del gestor de flujo de
peticiones autónomo.
- Porcentaje de tamaño máximo de almacenamiento dinámico JVM que debe supervisarse:
- La política de condición de uso excesivo de memoria reinicia los miembros cuando el uso de memoria
supera un porcentaje del tamaño del almacenamiento dinámico durante un periodo de tiempo.
Los valores aceptables para este campo son números enteros entre 1 y 99.
- Período de tiempo por encima del que se incumple el umbral de almacenamiento dinámico JVM:
- La política de condición de uso excesivo de memoria reinicia los miembros cuando el uso de memoria
supera un porcentaje del tamaño del almacenamiento dinámico durante un periodo de tiempo.
El porcentaje de memoria total utilizada se utiliza con el valor de porcentaje para determinar cuándo
se reinician los miembros. Los valores aceptables para este campo son de 1 segundo a 60 minutos.
- Total de peticiones
- Este campo está disponible cuando la política de salud seleccionada es la carga de trabajo. La política de condición de carga de trabajo reinicia los miembros cuando se haya dado servicio a un número determinado de peticiones definido por el usuario. Un valor de peticiones aceptable debe ser un número entero comprendido entre 1000 y 9223372036854775807.
- Nivel de detección para la condición:
- Seleccione una de las siguientes opciones:
- Detección más rápida, mayor probabilidad de falsas alarmas para detectar rápidamente pérdidas de memoria potenciales con una mayor probabilidad de falsos positivos
- Detección estándar, probabilidad estándar de falsas alarmas para detectar de forma más precisa y más lenta las pérdidas de memoria potenciales.
- Detección más lenta, menor probabilidad de falsas alarmas para conseguir la detección más precisa de pérdidas de memoria potenciales.
- Reacción del supervisor de gestión de salud
- Modalidad de reacción
- Seleccione Supervisada o Automática. La modalidad de reacción define el nivel de interacción de usuario cuando la condición de salud decide que es necesario realiza acciones correctivas.
En modalidad supervisada, los planes de acción sugeridos pueden aprobarse antes de ejecutarse.
La modalidad automática realiza todos los planes de acción sugeridos sin aprobación.
Utilice con cuidado las reacciones automáticas, especialmente cuando se habilitan los reinicios de servidor.
La disponibilidad constante del servicio puede interrumpirse cuando se reinicia un servidor.
- Seleccionar acciones que deben llevarse a cabo al incumplir una condición de salud
- En función de la condición de salud, puede seleccionar una o más acciones para que se ejecuten cuando se incumpla una condición de salud.
- Reiniciar el servidor
- Tomar vuelcos de hebras
- Tomar vuelcos de almacenamiento dinámico JVM sólo en el Kit de desarrollo de Java (JDK) de IBM
- Pulse Siguiente. En los siguientes paneles se le solicita que seleccione los destinos para la política.
- Seleccione los miembros que desea supervisar para la política de salud. Cuando los tipos de miembros se visualizan en la lista Disponibles para pertenecer, seleccione los tipos que desea supervisar y pulse Añadir.
- Servidores de aplicaciones y nodos
- Clústeres
- Clústeres dinámicos
- Células
Hay capas de lógica que se pueden aplicar a los miembros supervisados. Por ejemplo, es posible que desee aplicar una política de salud específica a todos los miembros de un clúster y a un servidor de aplicaciones que no estén incluido dentro del clúster. Seleccione el servidor de aplicaciones individual en el panel del servidor de aplicaciones y los clústeres en el panel de servidor de aplicaciones, que incluye todos los servidores de aplicaciones existentes y potenciales del clúster.
Los miembros del clúster aplican lógica adicional para minimizar el impacto de las reacciones en el servicio.
- Pulse Siguiente.
- Revise la nueva política y pulse Finalizar. La cabecera de la ventana de la consola muestra la opción Guardar.
- Pulse Guardar. Aparecerá una ventana con las opciones Guardar y Descartar.
Pulse Guardar de nuevo para confirmar la nueva política.
Resultado
Ahora habrá creado una política de salud y la habrá aplicado a un entorno de destino.
Qué hacer a continuación
El paso siguiente es habilitar la gestión de salud. Cuando está habilitada, la política de salud toma decisiones "inteligentes" y trabaja con la función de ubicación de aplicaciones para garantizar que las condiciones que requieren un reinicio no afecten el trabajo de las aplicaciones que esté en proceso. Consulte
Habilitación e inhabilitación de la gestión de salud para obtener más información.