Alertes et notifications
Surveiller les alertes
Les alertes sont affichées dans Director sur le tableau de bord et d’autres vues de haut niveau avec des symboles d’alerte d’avertissement et critique. Les alertes sont disponibles pour les sites sous licence Platinum. Les alertes se mettent à jour automatiquement toutes les minutes ; vous pouvez également les mettre à jour à la demande.
Une alerte d’avertissement (triangle orange) indique que le seuil d’avertissement d’une condition a été atteint ou dépassé.
Une alerte critique (cercle rouge) indique que le seuil critique d’une condition a été atteint ou dépassé.
Vous pouvez afficher des informations plus détaillées sur les alertes en sélectionnant une alerte dans la barre latérale, en cliquant sur le lien Accéder aux alertes en bas de la barre latérale ou en sélectionnant Alertes en haut de la page Director.
Dans la vue Alertes, vous pouvez filtrer et exporter les alertes. Par exemple, les machines de système d’exploitation de serveur défaillantes pour un groupe de mise à disposition spécifique au cours du dernier mois, ou toutes les alertes pour un utilisateur spécifique. Pour plus d’informations, consultez Exporter des rapports.
Alertes Citrix. Les alertes Citrix sont des alertes surveillées dans Director qui proviennent des composants Citrix. Vous pouvez configurer les alertes Citrix dans Director sous Alertes > Stratégie d’alertes Citrix. Dans le cadre de la configuration, vous pouvez définir l’envoi de notifications par e-mail à des individus et des groupes lorsque les alertes dépassent les seuils que vous avez définis. Vous pouvez également configurer la notification sous forme de webhooks Octoblu ou de traps SNMP. Pour plus d’informations sur la configuration des alertes Citrix, consultez Créer des stratégies d’alertes.
Alertes SCOM. Les alertes SCOM affichent les informations d’alerte de Microsoft System Center 2012 Operations Manager (SCOM) pour fournir une indication plus complète de la santé et des performances du centre de données au sein de Director. Pour plus d’informations, consultez Alertes SCOM.
Le nombre d’alertes affichées à côté des icônes d’alertes avant d’étendre la barre latérale est la somme combinée des alertes Citrix® et SCOM.
Créer des stratégies d’alertes
Pour créer une nouvelle stratégie d’alertes, par exemple, pour générer une alerte lorsqu’un ensemble spécifique de critères de nombre de sessions est rempli :
- Accédez à Alertes > Stratégie d’alertes Citrix et sélectionnez, par exemple, Stratégie de système d’exploitation de serveur.
- Cliquez sur Créer.
- Nommez et décrivez la stratégie, puis définissez les conditions qui doivent être remplies pour que l’alerte soit déclenchée. Par exemple, spécifiez les nombres d’avertissements et de critiques pour les sessions connectées maximales, les sessions déconnectées maximales et les sessions simultanées totales maximales. Les valeurs d’avertissement ne doivent pas être supérieures aux valeurs critiques. Pour plus d’informations, consultez Conditions des stratégies d’alertes.
- Définissez l’intervalle de ré-alerte. Si les conditions de l’alerte sont toujours remplies, l’alerte est déclenchée à nouveau à cet intervalle de temps et, si configuré dans la stratégie d’alerte, une notification par e-mail est générée. Une alerte ignorée ne génère pas de notification par e-mail à l’intervalle de ré-alerte.
- Définissez la portée. Par exemple, définissez-la pour un groupe de mise à disposition spécifique.
- Dans les préférences de notification, spécifiez qui doit être averti par e-mail lorsque l’alerte est déclenchée. Vous devez spécifier un serveur de messagerie sur l’onglet Configuration du serveur de messagerie afin de définir les préférences de notification par e-mail dans les stratégies d’alertes.
- Cliquez sur Enregistrer.
Pour plus d’informations sur la configuration des webhooks Octoblu, consultez Configurer les stratégies d’alertes avec les webhooks Octoblu.
Pour plus d’informations sur la configuration des traps SNMP, consultez Configurer les stratégies d’alertes avec les traps SNMP.
La création d’une stratégie avec 20 groupes de mise à disposition ou plus définis dans la portée peut prendre environ 30 secondes. Un indicateur de chargement s’affiche pendant ce temps.
La création de plus de 50 stratégies pour un maximum de 20 groupes de mise à disposition uniques (1000 cibles de groupes de mise à disposition au total) peut entraîner une augmentation du temps de réponse (plus de 5 secondes).
Le déplacement d’une machine contenant des sessions actives d’un groupe de mise à disposition à un autre peut déclencher des alertes de groupe de mise à disposition erronées définies à l’aide de paramètres de machine.
Conditions des stratégies d’alertes
| Condition de la stratégie d’alerte | Description et actions recommandées |
|---|---|
| Sessions connectées maximales | Nombre maximal de sessions connectées. Vérifiez la vue Tendances des sessions de Director pour les sessions connectées maximales. Assurez-vous qu’il y a suffisamment de capacité pour gérer la charge de sessions. Ajoutez de nouvelles machines si nécessaire. |
| Sessions déconnectées maximales | Nombre maximal de sessions déconnectées. Vérifiez la vue Tendances des sessions de Director pour les sessions déconnectées maximales. Assurez-vous qu’il y a suffisamment de capacité pour gérer la charge de sessions. Ajoutez de nouvelles machines si nécessaire. Fermez les sessions déconnectées si nécessaire. |
| Sessions simultanées totales maximales | Nombre maximal de sessions simultanées. Vérifiez la vue Tendances des sessions de Director pour les sessions simultanées maximales. Assurez-vous qu’il y a suffisamment de capacité pour gérer la charge de sessions. Ajoutez de nouvelles machines si nécessaire. Fermez les sessions déconnectées si nécessaire. |
| CPU | Pourcentage d’utilisation du processeur. Identifiez les processus ou les ressources qui consomment du processeur. Terminez le processus si nécessaire. La fin du processus entraînera la perte des données non enregistrées. Si tout fonctionne comme prévu, ajoutez des ressources CPU supplémentaires à l’avenir. Remarque : Le paramètre de stratégie, Activer la surveillance des ressources, est autorisé par défaut pour la surveillance des compteurs de performance du processeur et de la mémoire sur les machines avec des VDA. Si ce paramètre de stratégie est désactivé, les alertes avec des conditions de processeur et de mémoire ne seront pas déclenchées. Pour plus d’informations, consultez Stratégie de surveillance. |
| Mémoire | Pourcentage d’utilisation de la mémoire. Identifiez les processus ou les ressources qui consomment de la mémoire. Terminez le processus si nécessaire. La fin du processus entraînera la perte des données non enregistrées. Si tout fonctionne comme prévu, ajoutez de la mémoire supplémentaire à l’avenir. Remarque : Le paramètre de stratégie, Activer la surveillance des ressources, est autorisé par défaut pour la surveillance des compteurs de performance du processeur et de la mémoire sur les machines avec des VDA. Si ce paramètre de stratégie est désactivé, les alertes avec des conditions de processeur et de mémoire ne seront pas déclenchées. Pour plus d’informations, consultez Paramètres de stratégie de surveillance. |
| Taux d’échec de connexion | Pourcentage d’échecs de connexion au cours de la dernière heure. Calculé en fonction du nombre total d’échecs par rapport au nombre total de tentatives de connexion. Vérifiez la vue Tendances des échecs de connexion de Director pour les événements enregistrés dans le journal de configuration. Déterminez si les applications ou les bureaux sont accessibles. |
| Nombre d’échecs de connexion | Nombre d’échecs de connexion au cours de la dernière heure. Vérifiez la vue Tendances des échecs de connexion de Director pour les événements enregistrés dans le journal de configuration. Déterminez si les applications ou les bureaux sont accessibles. |
| ICA RTT (Moyenne) | Temps d’aller-retour ICA moyen. Vérifiez NetScaler HDX Insight pour une analyse détaillée du RTT ICA afin de déterminer la cause première. Si NetScaler n’est pas disponible, consultez la vue Détails de l’utilisateur de Director pour le RTT ICA et la latence et déterminez s’il s’agit d’un problème réseau ou d’un problème XD/XA. Pour plus d’informations, consultez la documentation de NetScaler Insight Center, Cas d’utilisation : HDX Insight. |
| RTT ICA (nombre de sessions) | Nombre de sessions qui dépassent le temps d’aller-retour ICA seuil. Vérifiez NetScaler HDX Insight pour le nombre de sessions avec un RTT ICA élevé. Pour plus d’informations, consultez la documentation de NetScaler Insight Center, Rapports HDX Insight. Si NetScaler n’est pas disponible, collaborez avec l’équipe réseau pour déterminer la cause première. |
| RTT ICA (% de session) | Pourcentage de sessions qui dépassent le temps d’aller-retour ICA moyen. Vérifiez NetScaler HDX Insight pour le nombre de sessions avec un RTT ICA élevé. Pour plus d’informations, consultez la documentation de NetScaler Insight Center, Rapports HDX Insight. Si NetScaler n’est pas disponible, collaborez avec l’équipe réseau pour déterminer la cause première. |
| RTT ICA® (utilisateur) | Temps d’aller-retour ICA appliqué aux sessions lancées par l’utilisateur spécifié. L’alerte est déclenchée si le RTT ICA est supérieur au seuil dans au moins une session. |
| Machines défaillantes (OS de bureau) | Nombre de machines OS de bureau défaillantes. Les défaillances peuvent survenir pour diverses raisons, comme indiqué dans le tableau de bord Director et les vues Filtres. Exécutez les diagnostics Citrix Scout pour déterminer la cause première. Pour plus d’informations, consultez Résoudre les problèmes utilisateur. |
| Machines défaillantes (OS de serveur) | Nombre de machines OS de serveur défaillantes. Les défaillances peuvent survenir pour diverses raisons, comme indiqué dans le tableau de bord Director et les vues Filtres. Exécutez les diagnostics Citrix Scout pour déterminer la cause première. |
| Durée moyenne d’ouverture de session | Durée moyenne d’ouverture de session pour les ouvertures de session qui ont eu lieu au cours de la dernière heure. Consultez le tableau de bord Director pour obtenir des métriques à jour concernant la durée d’ouverture de session. Un grand nombre d’utilisateurs se connectant dans un court laps de temps peut entraîner des ouvertures de session prolongées. Vérifiez la ligne de base et la répartition des ouvertures de session pour affiner la cause. Pour plus d’informations, consultez Diagnostiquer les problèmes d’ouverture de session utilisateur. |
| Durée d’ouverture de session (utilisateur) | Durée d’ouverture de session pour les ouvertures de session de l’utilisateur spécifié qui ont eu lieu au cours de la dernière heure. |
| Index d’évaluation de charge | Valeur de l’index d’évaluation de charge au cours des 5 dernières minutes. Vérifiez Director pour les machines de système d’exploitation de serveur qui pourraient avoir une charge de pointe (charge maximale). Consultez le tableau de bord (échecs) et le rapport Tendances de l’index d’évaluation de charge. |
Configurer les stratégies d’alertes avec les webhooks Octoblu
Outre les notifications par e-mail, vous pouvez configurer des stratégies d’alertes avec des webhooks Octoblu pour lancer des services IoT.
Remarque : Cette fonctionnalité nécessite la version 7.11 ou ultérieure du ou des Delivery Controller(s).
Les exemples de services IoT pouvant utiliser les alertes incluent l’envoi de notifications SMS au personnel de support ou l’intégration avec des plateformes de résolution d’incidents personnalisées pour aider au suivi des notifications.
Vous pouvez configurer une stratégie d’alerte avec un rappel HTTP ou une requête HTTP POST à l’aide des cmdlets PowerShell. Elles sont étendues pour prendre en charge les webhooks.
Pour plus d’informations sur la création d’un nouveau workflow Octoblu et l’obtention de l’URL de webhook correspondante, consultez le Octoblu Developer Hub.
Pour configurer une URL de webhook Octoblu pour une nouvelle stratégie d’alerte ou une stratégie existante, utilisez les cmdlets PowerShell suivantes.
Créer une nouvelle stratégie d’alertes avec une URL de webhook :
$policy = New-MonitorNotificationPolicy -Name <Policy name> -Description <Policy description> -Enabled $true -Webhook <Webhook URL>
Ajouter une URL de webhook à une stratégie d’alertes existante :
Set-MonitorNotificationPolicy - Uid <Policy id> -Webhook <Webhook URL>
Pour obtenir de l’aide sur les commandes PowerShell, utilisez l’aide PowerShell, par exemple :
Get-Help <Set-MonitorNotificationPolicy>
Les notifications générées par la stratégie d’alerte déclenchent le webhook avec un appel POST à l’URL du webhook. Le message POST contient les informations de notification au format JSON :
{"NotificationId" : \<Notification Id\>,
"Target" : \<Notification Target Id\>,
"Condition" : \<Condition that was violated\>,
"Value" : \<Threshold value for the Condition\>,
"Timestamp": \<Time in UTC when notification was generated\>,
"PolicyName": \<Name of the Alert policy\>,
"Description": \<Description of the Alert policy\>,
"Scope" : \<Scope of the Alert policy\>,
"NotificationState": \<Notification state critical, warning, healthy or dismissed\>,
"Site" : \<Site name\>}
<!--NeedCopy-->
Configurer les stratégies d’alertes avec des traps SNMP
Lorsqu’une alerte configurée avec un trap SNMP se déclenche, le message de trap SNMP correspondant est transmis à l’écouteur réseau configuré pour un traitement ultérieur. Les alertes Citrix prennent en charge les traps SNMP version 2 et ultérieures. Actuellement, le message de trap peut être transmis à un seul écouteur.
Remarque : Cette fonctionnalité nécessite la version 7.12 ou ultérieure du ou des Delivery Controller(s).
Pour configurer les traps SNMP, utilisez les cmdlets PowerShell suivantes :
-
Obtenir la configuration actuelle du serveur SNMP :
Get-MonitorNotificationSnmpServerConfiguration -
Définir la configuration du serveur pour SNMP version 2 :
Set-MonitorNotificationSnmpServerConfiguration -ServerName <Server IP> -PortNumber <Port ID> -SnmpSender <Sender name> -CommunityString public -Protocol V2 -
Définir la configuration du serveur pour SNMP version 3 :
$authpass = "<authentication password>" | ConvertTo-SecureString -AsPlainText -Force $privpass = "<Privacy password>" | ConvertTo-SecureString -AsPlainText -Force Set-MonitorNotificationSnmpServerConfiguration -ServerName <Server IP> -PortNumber <Port ID> -SnmpSender <Sender name> -EngineId <Engine Id> -AuthPassword $authpass -PrivPassword $privpass -PrivPasswordProtocol <Privacy password protocol> -AuthPasswordProtocol <Authentication password protocol> -Protocol V3 <!--NeedCopy--> -
Activer le trap SNMP pour une stratégie d’alerte existante :
Set-MonitorNotificationPolicy -IsSnmpEnabled $true -Uid <Policy ID> -
Créer une nouvelle stratégie d’alerte avec la configuration de trap SNMP :
$policy = New-MonitorNotificationPolicy -Name <Policy name> -IsSnmpEnabled $true -Description <Policy description> -Enabled $true
La structure des OID dans les messages de trap SNMP de Director est la suivante : 1.3.6.1.4.1.3845.100.1.<UID> Ici, <UID> est généré en série pour chaque stratégie d’alerte définie dans Director. Les OID sont donc uniques à chaque environnement utilisateur.
- Utilisez 1.3.6.1.4.1.3845.100.1 pour filtrer tous les messages de trap de Director.
- Utilisez 1.3.6.1.4.1.3845.100.1.<UID> pour filtrer et gérer les messages de trap pour des alertes spécifiques.
Utilisez la cmdlet suivante pour obtenir les UID des stratégies d’alerte définies dans votre environnement :
Get-MonitorNotificationPolicy
Vous pouvez transférer les traps SNMP vers SCOM. Pour ce faire, configurez SCOM avec le Delivery Controller™ pour écouter les messages de trap.
Configurer l’intégration des alertes SCOM
L’intégration de SCOM avec Director vous permet d’afficher les informations d’alerte de SCOM sur le tableau de bord et dans d’autres vues de haut niveau dans Director.
Les alertes SCOM sont affichées à l’écran à côté des alertes Citrix. Vous pouvez accéder aux alertes SCOM et les explorer à partir de l’onglet SCOM dans la barre latérale.
Vous pouvez consulter les alertes historiques datant de moins d’un mois, trier, filtrer et exporter les informations filtrées vers des formats de rapport CSV, Excel et PDF. Pour plus d’informations, consultez Exporter des rapports.
L’intégration SCOM utilise PowerShell distant 3.0 ou version ultérieure pour interroger les données du serveur de gestion SCOM et elle maintient une connexion d’espace d’exécution persistante dans la session Director de l’utilisateur. Director et le serveur SCOM doivent avoir la même version de PowerShell.
Les exigences pour l’intégration SCOM sont :
- Windows Server 2012 R2
- System Center 2012 R2 Operations Manager
- PowerShell 3.0 ou version ultérieure (la version de PowerShell sur Director et le serveur SCOM doit correspondre)
- Processeur Quad Core avec 16 Go de RAM (recommandé)
- Un serveur de gestion principal pour SCOM doit être configuré dans le fichier web.config de Director. Vous pouvez le faire à l’aide de l’outil DirectorConfig.
Remarque :
- Citrix recommande que le compte d’administrateur Director soit configuré avec le rôle d’opérateur SCOM afin que toutes les informations d’alerte puissent être récupérées dans Director. Si cela n’est pas possible, un compte d’administrateur SCOM peut être configuré dans le fichier web.config à l’aide de l’outil DirectorConfig.
- Citrix recommande de ne pas configurer plus de 10 administrateurs Director par serveur de gestion SCOM pour garantir des performances optimales.
Sur le serveur Director :
-
Tapez Enable-PSRemoting pour activer la communication à distance PowerShell.
-
Ajoutez le serveur de gestion SCOM à la liste TrustedHosts. Ouvrez une invite PowerShell et exécutez la ou les commandes suivantes :
- Obtenir la liste actuelle des TrustedHosts
Get-Item WSMAN:\localhost\Client\TrustedHosts
<!--NeedCopy-->
1. Add the FQDN of the SCOM Management Server to the list of TrustedHosts. \<Old Values\> represents the existing set of entries returned from Get-Item cmdlet
Set-Item WSMAN:\localhost\Client\TrustedHosts -Value "<FQDN SCOM Management Server>,<Old Values>"
<!--NeedCopy-->
- Configurez SCOM à l’aide de l’outil DirectorConfig.
C:\inetpub\wwwroot\Director\tools\DirectorConfig.exe /configscom
<!--NeedCopy-->
Sur le serveur de gestion SCOM :
-
Attribuez les administrateurs Director à un rôle d’administrateur SCOM.
-
Ouvrez la console de gestion SCOM et accédez à Administration > Sécurité > Rôles utilisateur.
-
Dans Rôles utilisateur, vous pouvez créer un nouveau rôle utilisateur ou modifier un rôle existant. Il existe quatre catégories de rôles d’opérateur SCOM qui définissent la nature de l’accès aux données SCOM. Par exemple, un rôle en lecture seule ne voit pas le volet Administration et ne peut pas découvrir ou gérer les règles, les machines ou les comptes. Un rôle d’opérateur est un rôle d’administrateur complet.
Remarque : Les opérations suivantes ne sont pas disponibles si l’administrateur Director est affecté à un rôle non-opérateur :
-
S’il existe plusieurs serveurs de gestion configurés et que le serveur de gestion principal n’est pas disponible, l’administrateur Director ne peut pas se connecter au serveur de gestion secondaire. Le serveur de gestion principal est le serveur configuré dans le fichier web.config de Director, c’est-à-dire le même serveur que celui spécifié avec l’outil DirectorConfig à l’étape 3 ci-dessus. Les serveurs de gestion secondaires sont des serveurs de gestion pairs du serveur principal.
-
Lors du filtrage des alertes, l’administrateur Director ne peut pas rechercher la source de l’alerte. Cela nécessite une autorisation de niveau opérateur.
-
-
Pour modifier un rôle utilisateur, cliquez avec le bouton droit sur le rôle, puis cliquez sur Propriétés.
-
Dans la boîte de dialogue Propriétés du rôle utilisateur, vous pouvez ajouter ou supprimer des administrateurs Director du rôle utilisateur spécifié.
-
-
Ajoutez les administrateurs Director au groupe Utilisateurs de gestion à distance sur le serveur de gestion SCOM. Cela permet aux administrateurs Director d’établir une connexion PowerShell à distance.
-
Tapez Enable-PSRemoting pour activer la communication à distance PowerShell.
-
Définissez les limites des propriétés WS-Management :
-
Modifier MaxConcurrentUsers :
Dans la CLI :
winrm set winrm/config/winrs @{MaxConcurrentUsers = "20"}Dans PS :
Set-Item WSMan:\localhost\Shell\MaxConcurrentUsers 20 -
Modifier MaxShellsPerUser :
Dans la CLI :
winrm set winrm/config/winrs @{MaxShellsPerUser="20"}Dans PS :
Set-Item WSMan:\localhost\Shell\MaxShellsPerUser 20 -
Modifier MaxMemoryPerShellMB :
Dans la CLI :
winrm set winrm/config/winrs @{MaxMemoryPerShellMB="1024"}Dans PS :
Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1024
-
-
Pour vous assurer que l’intégration SCOM fonctionne dans des environnements de domaines mixtes, définissez l’entrée de registre suivante.
Chemin : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Clé : LocalAccountTokenFilterPolicy
Type : DWord
Valeur : 1
Attention : Toute modification incorrecte du registre peut entraîner de graves problèmes qui pourraient vous obliger à réinstaller votre système d’exploitation. Citrix ne peut garantir que les problèmes résultant d’une utilisation incorrecte de l’Éditeur du Registre pourront être résolus. Utilisez l’Éditeur du Registre à vos propres risques. Assurez-vous de sauvegarder le registre avant de le modifier.
Une fois l’intégration SCOM configurée, vous pourriez voir le message « Impossible d’obtenir les dernières alertes SCOM. Consultez les journaux d’événements du serveur Director pour plus d’informations ». Les journaux d’événements du serveur aident à identifier et à corriger le problème. Les causes peuvent inclure :
- Perte de connectivité réseau sur la machine Director ou SCOM.
- Le service SCOM n’est pas disponible ou est trop occupé pour répondre.
- Échec de l’autorisation en raison d’une modification des autorisations pour l’utilisateur configuré.
- Une erreur dans Director lors du traitement des données SCOM.
- Incompatibilité de version de PowerShell entre Director et le serveur SCOM.