![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
gestion de santé
Le système de surveillance et de gestion de santé permet de mettre en place des stratégies pour surveiller l'environnement de serveur d'applications et exécuter des actions lorsque certains critères sont détectés.
Sous-système de contrôle et de gestion de santé
Le sous-système de gestion de santé surveille en continu l'état des serveurs et les tâches qu'ils effectuent dans votre environnement. Le sous-système de gestion de santé se compose de deux éléments principaux : le contrôleur de santé et les stratégies de santé.
Le contrôleur de santé est le gestionnaire autonome qui contrôle le sous-système de contrôle et de gestion de santé, et agit sur vos règles de santé afin d'assurer l'existence d'un certain nombre de conditions. Le contrôleur de santé est une ressource distribuée gérée par le gestionnaire de haute disponibilité et qui existe dans tous les processus d'agent de noeud et de gestionnaire de déploiement. Il est actif dans l'un de ces processus. Si le processus actif échoue, le contrôleur de santé devient actif dans un autre processus d'agent de noeud ou de gestionnaire de déploiement.
Le contrôleur de santé s'exécute sur un cycle de contrôle. La durée du cycle de contrôle définit l'intervalle entre les contrôles de l'environnement lancés par le contrôleur de santé. A l'issue du cycle de contrôle, le contrôleur de santé vérifie l'environnement et génère des tâches d'exécution pour éviter le non-respect des conditions de santé.
Vous définissez des stratégies de santé, qui incluent les conditions de santé à surveiller dans votre environnement et les actions de santé à effectuer si ces conditions ne sont pas remplies.
Vous pouvez désactiver ou activer la fonction de gestion de santé à l'aide du contrôleur de santé même si plusieurs stratégies de santé sont définies sur le système. Vous pouvez limiter la fréquence de redémarrage du serveur ou interdire les redémarrages au cours de périodes données.
Le sous-système de gestion de santé fonctionne lorsque la Gestion intelligente se trouve en mode d'exploitation automatique ou supervisé. Lorsque le mode de réaction associé à la stratégie est automatique, le système de gestion de santé effectue une action si un non respect de la stratégie est détecté. En mode Supervisé, le système de gestion de santé crée une tâche d'exécution qui offre une ou plusieurs actions. L'administrateur système peut approuver ou refuser les actions proposées.
Conditions de santé
- Condition d'ancienneté
- Suit le délai nécessaire à l'exécution du serveur. Si le délai dépasse le seuil défini, les actions de santé s'exécutent.
- Condition Dépassement du délai d'expiration des demandes
- Indique le pourcentage de demandes HTTP qui peuvent dépasser le délai expiration. Lorsque le pourcentage dépasse la valeur définie, les actions de santé sont exécutées. La valeur du délai dépend de la configuration de l'environnement. Pour plus d'informations sur la condition de santé de dépassement du délai d'expiration des demandes, voir Valeur du délai d'expiration cible de la stratégie de santé de dépassement du délai d'expiration des demandes.
- Condition Temps de réponse excessif
- Suit le délai nécessaire à l'exécution des demandes. Si le délai dépasse le seuil défini pour le délai de réponse, les actions de santé s'exécutent.Avertissement : Les demandes qui dépassent le seuil de délai d'attente défini ne sont pas incluses dans les calculs de temps de réponse excessifs. Par exemple, si la valeur de délai d'attente par défaut de 60 secondes est en vigueur, les demandes qui dépassent ce seuil et ce délai d'attente ne sont pas incluses dans les calculs de temps de réponse excessifs. Cette restriction s'applique même si vous n'avez pas défini de condition de santé Dépassement du délai d'expiration des demandes dans votre environnement.
- Condition de mémoire : Condition de dépassement de mémoire
- Suit la quantité de mémoire utilisée sur un membre. Lorsque la quantité de mémoire utilisée dépasse un pourcentage de la taille de segment de mémoire pendant une durée donnée, les actions de santé s'exécutent pour corriger cette erreur.
- Condition de mémoire : fuite de mémoire
- Suit les tendances à la baisse régulières de mémoire disponible pour un serveur dans la pile Java™. Lorsque la pile Java atteint la taille maximale configurée, vous pouvez effectuer des vidages de pile ou redémarrer les serveurs.
- Condition de drainage incorrect des demandes
- Suit les demandes pour lesquelles le temps de réponse a fortement baissé. Cette stratégie repose sur la détection des points de changement dans des données de séries temporelles précises.
- Condition de charge de travail
- Indique le nombre de demandes traitées avant le redémarrage des membres de la stratégie pour nettoyer la mémoire et les données en mémoire cache.
- Condition de pourcentage de récupération de place
- Supervise une machine virtuelle Java (JVM) ou un ensemble de machines virtuelles Java pour déterminer si elles passent plus de temps que le pourcentage défini pour la récupération de place au cours d'une période de temps spécifiée.
A ces conditions de stratégie de santé prédéfinies sont associées des actions pour l'optimisation de la distribution des données nécessaires, à la réduction de l'impact sur la surveillance et à l'application de la stratégie de santé dans votre environnement.
Vous pouvez également définir des conditions personnalisées pour la stratégie de santé si les conditions de santé prédéfinies ne répondent pas vos besoins. Les conditions personnalisées sont définies comme une sous-expression qui est testée par rapport à des mesures dans votre environnement. Lorsque vous définissez une condition personnalisée, prenez en compte le coût de la collecte des données, de l'analyse des données et si nécessaire, de l'application de la stratégie de santé. Ce coût peut augmenter en fonction du trafic et du nombre de serveurs sur votre réseau. Analysez les performances de vos conditions de santé personnalisées avant de les utiliser dans un environnement de production.PMIMetric_FromServerStart$systemModule$cpuUtilization > 90L
Actions de santé
Les actions de santé définissent le processus à appliquer lorsqu'une condition de santé n'est pas remplie. Les actions varient en fonction des conditions que vous définissez. Le tableau ci-après répertorie les actions de santé prises en charge dans différents environnements de serveur :
Action de santé | Serveurs d'applications WebSphere qui s'exécutent dans la même cellule Intelligent Management | Autres serveurs middleware (y compris les serveurs d'applications WebSphere externes) |
---|---|---|
Redémarrage du serveur | Pris en charge | Pris en charge |
Prise de clichés d'unités d'exécution | Pris en charge | Pas de prise en charge |
Prendre des clichés de tas de machine virtuelle Java (JVM) | Prise en charge pour les serveurs qui s'exécutent sur IBM® Software Development Kit | Pas de prise en charge |
Passage du serveur en mode maintenance | Pris en charge | Pris en charge |
Passage du serveur en mode maintenance et interruption d'affinité avec le serveur pour les demandes HTTP et SIP | Pris en charge | Pris en charge |
Désactivation du mode maintenance pour le serveur | Pris en charge | Pris en charge |
Interruption SNMP (Simple Network Management Protocol) | Pris en charge | Pris en charge |
- Redémarrage standard (arrêt du serveur et redémarrage du serveur). Ce redémarrage se produit systématiquement lorsqu'un cluster dynamique est en mode manuel.
- Démarrage de l'instance du serveur sur un autre noeud et arrêt du serveur défaillant.
- Arrêt du serveur défaillant uniquement, en supposant que les autres instances d'application peuvent satisfaire la demande.
Vous pouvez également définir une action personnalisée. Une action personnalisée permet de définir un fichier exécutable à lancer en cas de violation de la condition de santé. Vous devez définir des actions personnalisées avant de créer la stratégie de santé qui doit les contenir.
Cibles des stratégies de santé
Les cibles des stratégies de santé peuvent être un serveur unique, chacun des serveurs d'un cluster ou un cluster dynamique, le routeur On-Demand (ODR), ou chacun des serveurs d'une cellule. Vous pouvez définir plusieurs stratégies de santé pour surveiller le même ensemble de serveurs.
Si vous utilisez des conditions de santé prédéfinies, la prise en charge dépend du type de serveur. Certains serveurs middleware ne prennent pas en charge tous les types de règles. La table ci-dessous récapitule les stratégies de santé prises en charge selon le type de serveur :Stratégie de santé prédéfinie | Serveurs d'applications WebSphere qui s'exécutent dans la même cellule Intelligent Management | Autres serveurs middleware (y compris les serveurs d'applications WebSphere externes) |
---|---|---|
Stratégie basée sur l'ancienneté | Pris en charge | Pris en charge |
Stratégie de charge de travail | Pris en charge | Pris en charge |
Détection des fuites de mémoire | Pris en charge | Pas de prise en charge |
Dépassement de mémoire | Pris en charge | Prise en charge pour les serveurs WebSphere Application Server Community Edition. Non prise en charge pour les autres types de serveur middleware. |
Dépassement du délai d'expiration des demandes | Pris en charge | Prise en charge pour les autres serveurs middleware vers lesquels le routeur On Demand achemine des demandes. |
Temps de réponse excessif | Pris en charge | Pris en charge |
Drainage incorrect des demandes | Pris en charge | Pris en charge |
Pourcentage de récupération de place | Pris en charge | Pas de prise en charge |
Stratégie de santé par défaut
Vous pouvez créer des stratégies de santé par défaut en utilisant les conditions de santé prédéfinies installées avec le produit.
Pour créer une stratégie de santé par défaut, cliquez sur
et sélectionnez l'une des conditions de santé prédéfinies.- Fuite de mémoire par défaut : Niveau de détection standard par défaut. La stratégie de fuite de mémoire par défaut utilise la fonction du conseiller de performance. Le conseiller de performances est donc activé lorsque cette stratégie est activée. Pour désactiver le conseiller de performances, supprimez cette stratégie de santé ou limitez les membres de la stratégie de santé. Pour conserver la stratégie de santé pour une utilisation ultérieure, conservez la stratégie de fuite de mémoire par défaut mais supprimez tous les membres. Pour modifier les membres, cliquez sur . Vous pouvez modifier les membres de la stratégie de santé en ajoutant ou en supprimant des membres de la stratégie.
- Dépassement de mémoire par défaut : 95% de la taille de segment JVM pour 15 minutes
- Dépassement du délai d'expiration des demandes par défaut : 5 % des demandes arrivent à expiration.
- Dépassement du temps de réponse par défaut : 120 secondes
- Drainage incorrect par défaut : niveau de détection standard par défaut
- Pourcentage de récupération de place : 10 pour cent. La période d'échantillonnage par défaut est de 2 minutes.
Pour afficher les recommandations faites par les règles de santé par défaut et appliquer les actions préconisées, cliquez sur
.