Cette page permet de créer des stratégies de santé, qui effectuent diverses évaluations de la santé des clusters, des clusters dynamiques et des instances de serveur d'applications s'exécutant sur les noeuds.
Pour afficher cette page de la console d'administration, cliquez sur .
Les privilèges des règles de santé diffèrent selon le rôle administratif
de l'utilisateur. Les rôles sont les suivants : contrôleur, opérateur,
configurateur et administrateur. Si vous êtes utilisateur avec le rôle
contrôleur ou opérateur, vous pouvez uniquement afficher les informations de la
règle de santé. Si vous êtes utilisateur avec le rôle configurateur ou
administrateur, vous possédez tous les privilèges de configuration des
règles de santé.
Lorsque vous avez rempli toutes les zones requises, cliquez sur
Suivant pour continuer.
Condition de santé prédéfinie
La condition de santé définit la règle mise en oeuvre. Les conditions de santé prédéfinies sont celles fournies avec Intelligent Management.
Certaines règles sont basées sur la prévention, d'autres sur la
détection.
Les règles basées sur la prévention permettent d'éviter les
conditions pouvant provoquer des problèmes, tandis que les règles basées sur
la détection identifient les conditions existantes et offrent une résolution. Vous pouvez utiliser ces règles pour effectuer des évaluations fondées sur
la santé des clusters, des clusters dynamiques et des instances de serveur
d'applications exécutées sur les noeuds. Dans le cas des clusters dynamiques,
et quelle que soit la règle de santé utilisée, le nombre minimal
d'instances de cluster dynamique reste actif.
- Lorsqu'une infraction à la condition basée sur l'ancienneté est commise, les actions de santé associées sont exécutées.
Ce
redémarrage efface toutes les données acquises mises en cache et en mémoire. Si
vous sélectionnez une condition basée sur l'ancienneté, vous devez définir les
critères d'ancienneté.
La condition basée sur l'ancienneté est prise en charge sur tous les types de serveurs.
- La condition de dépassement du nombre de demandes arrivées à
expiration effectue le suivi de la mémoire utilisée pour les demandes
arrivant à expiration. Lorsque le pourcentage des demandes arrivant à
expiration dépasse la limite de la condition, les actions de santé associées sont exécutées. Si
vous sélectionnez cette condition, vous devez définir le seuil de pourcentage
de mémoire utilisée. La condition de dépassement du nombre de demandes arrivées à
expiration est prise en charge sur tous les types de serveurs.
Restriction : La condition de dépassement du nombre de demandes arrivées à expiration ne s'applique pas au trafic JMS (Java Message Service) et IIOP (Internet Inter-ORB Protocol).
- La stratégie de la condition de dépassement de temps de
réponse effectue le suivi des demandes et la durée d'exécution
requise.
Lorsque vous sélectionnez la
stratégie de dépassement de temps de réponse, vous devez définir le seuil du
temps de réponse. Si, dans un intervalle de temps donné, le temps de réponse moyen pour les demandes dépasse la valeur de seuil, la stratégie de santé est déclenchée. La condition de dépassement du temps de réponse est prise en charge sur tous les types de serveurs.
- La condition de mémoire : dépassement de mémoire effectue
le suivi de l'utilisation de mémoire correspondant à un membre. Les actions de santé sont exécutées lorsque l'utilisation de la mémoire dépasse un certain pourcentage du délai précisé pour la taille de segment. Lorsque vous
sélectionnez la stratégie de dépassement de temps de réponse, vous devez
définir la mémoire utilisée et le seuil de dépassement du temps de réponse. La condition de dépassement de mémoire est prise en charge uniquement sur des serveurs d'applications sur des noeuds exécutant WebSphere Application Server ou WebSphere Application Server Community Edition. Il n'est pas possible de définir la condition de dépassement de mémoire pour d'autres types de serveurs middleware.
- La stratégie condition de mémoire : fuite de mémoire
effectue le suivi des tendances régulières de baisse de la mémoire disponible
pour un serveur dans le segment Java.
Le paramètre de détection de niveau
détermine le moment où ces tendances sont détectées.
Lorsque vous sélectionnez
la stratégie condition de mémoire : fuite de mémoire, vous devez définir un
niveau de détection. Le niveau de détection le plus lent nécessite la quantité
maximale de données historisées. Les niveaux de détection normal et rapide nécessitent la même quantité de données
historisées, mais la détection rapide autorise l'analyse avant que le segment
Java n'ait atteint sa taille maximale configurée. Ceci permet une détection anticipée, mais plus encline aux faux positifs. En cas d'infraction à cette règle, les actions de santé sont exécutées. La condition de fuite de mémoire n'est pas prise en charge pour d'autres types de serveurs middleware.
- La stratégie condition de drainage incorrect des demandes
effectue le suivi des demandes restées bloquées. Les actions de santé associées à cette règle sont exécutées lorsque le niveau de détection indiqué est atteint. La
détection de drainage incorrect des demandes fait appel à la détection des
points de transition dans des données de série temporelle précises. Les
critères de mesure utilisés pour détecter un drainage incorrect des demandes
sont les temps de réponse et les pondérations du gestionnaire de charge de travail de
déploiement qui sont observés pour le serveur. La condition de drainage
incorrect des demandes s'applique uniquement aux clusters dynamiques et aux
cellules. Si vous sélectionnez cette stratégie, vous devez sélectionner le
niveau de détection.
Pour détecter des points de transition, le contrôleur de santé calcule une moyenne de
gauche et une moyenne de droite pour un point donné. Pour un point, la moyenne de gauche correspond à la valeur moyenne
de N échantillons qui arrivent avant cet échantillon et la moyenne de droite est la valeur
moyenne de N échantillons, y compris le point en cours, qui arrivent après. La différence des valeurs moyennes de gauche et de droite est enregistrée et comparée à d'autres différences dans un ensemble de valeurs à N pour déterminer si cette différence est un maxima local. Si cette différence correspond à la différence maximale, alors le point auquel cette différence correspond, est appelé point de transition. Les deux métriques utilisées pour détecter un drainage incorrect des demandes sont les temps de réponse et les pondérations du gestionnaire de charge de travail dynamique qui sont observés pour le serveur.
La condition de drainage incorrect des demandes est prise en charge sur tous les types de serveurs.Restriction : La condition de drainage incorrect des demandes ne s'applique pas au trafic JMS et IIOP.
- La règle fondée sur la condition de charge de travail exécute les actions de santé associées lorsque le nombre de demandes défini par l'utilisateur a été traité. Lorsque vous
sélectionnez la stratégie de charge de travail, vous devez définir les critères
du nombre total de demandes. La condition de charge de travail est prise en charge sur tous les types de serveurs.
- La règle fondée sur la condition de pourcentage de récupération de place contrôle une machine virtuelle Java (JVM) ou un ensemble de machines pour déterminer si celles-ci consacrent à cette activité un pourcentage de temps supérieur à celui indiqué au cours de la période d'échantillonnage. Etant donné que la récupération de place augmente l'utilisation du processeur, cette règle peut vous informer si cette opération a des effets négatifs sur les performances.