Sur un de nos serveurs Zabbix de prod (pas encore migré sous MonitorX 🙂 ) nous avons rencontré l’erreur :
Zabbix unreachable poller processes more than 75 % busy
En effet, plusieurs hosts ne répondaient plus en SNMP, afin de supprimer ce message direction le fichier “zabbix_server.conf” afin de modifier le “StartPollersUnreachable” et de le passer à 20 (StartPollersUnreachable=20)
“C’est quoi le StartPollersUnreachable” 😉 .
Plus d’info chez Zabbix
MonitorX is a Zabbix non-official appliance dedicated to “XenApp” (which uses the XenApp 6.5 template). It allows you to monitor your XenApp 6.5 environment, including your Web Interface/StoreFront/NetScaler 10.x.
The appliance runs on a Debian Wheezy 7.8 (2 vCPU, 4Gb RAM and 40Gb thin provisioned disk), configured to use DHCP with the following modules:
Continue reading “MonitorX (us version)”
MonitorX est une appliance non officielle ZABBIX dédiée “XenApp” (qui reprend notamment le template XenApp 6.5), permettant rapidement et simplement de superviser/Monitorer un environnement XenApp 6.5 (avec ses Webi /StoreFront/Netscaler 10x. ).
L’appliance repose sur une Debian Wheezy 7.8, (2 Vcpu, 4Go de ram et 40 Go de DD en thin) en DHCP (le mot de passe root est “password!01” on vous conseille fortement de le changer) avec les modules ci-dessous :
Au préalable, si vous ne connaissez pas ZABBIX , nous vous conseillons d’aller faire un tour sur http://www.zabbix.com et http://www.monitoring-fr.org/solutions/zabbix/.
Dans un premier temps, veuillez décompacter le fichier MonitorX.rar (607 Mo), une fois décompacté vous obtenez deux dossiers :
Installation de l’appliance :
Les fans de Sexilog auront reconnu le SexiMenu que nous avons adapté à MonitorX 🙂
Lancez dans un navigateur l’url “http://IpMonitorX”
Renseignez les champs Username (admin) et Password (zabbix)
Activation du serveur Zabbix :
Cliquez sur Disabled afin d’activer la supervision/monitoring serveur Zabbix
Ajout des hosts :
La première étape est de changer l’IP du serveur Zabbix configuré par l’IP de votre serveur MonitorX (menu 1)
Une fois le déploiement terminé, un fichier de log (StatutAgentInstall.txt) est disponible dans le dossier Zabbix_Agent_Install.
Si vous utilisez Edgesight (plus pour très longtemps 😉 ) ou UPM il vous faudra activez les items dans le template “TPL_Citrix_XenApp_6.5”.
Allez Dans l’onglet Configuration-Template , puis cliquez sur TPL_Citrix_XenApp_6.5 et allez dans Items.
Cliquez sur Disabled afin d’activer les items
Renommez le serveur dans Zabbix (Si vous avez renommé le serveur MonitorX):
Modifiez le nom du serveur Zabbix ($ZBX_SERVER = ‘ZAB01’; et $ZBX_SERVER_NAME = ‘ZAB01’; ) et enregistrez le fichier (commande vi “:wq”), pour les réfractaires au “vi” vous pouvez passer par WinSCP.
Si vous ne renommez pas le Hostname dans Zabbix vous obtiendrez l’erreur ci-dessous :
Zabbix server is not running: the information displayed may not be current
Pas d’inquiétude cependant, ce message dans le cas présent n’a pas d’impact sur les mises à jour des hosts ou autres
Administrer la base Zabbix
http://IpMonitorX/phpmyadmin ( root/password!01)
Et voila ce que ça donne 🙂 .
Les graphiques par host (onglet screen de chaque host)
Le graphique des CCU de la ferme XenApp (Onglet Monitoring-Screens)
MonitorX.rar
Sur un de nos StoreFront (Windows 2008 R2 SP1 fr – SF 2.60.5031) nous avons rencontré du jour au lendemain un problème d’authentification (le problème était identique en authentification direct sur les SF ou en passant par l’authentification via les Netscaler), les utilisateurs rentraient leurs login/mot de passe et étaient à nouveau re-promptés.
En regardant les events du StoreFront nous avons trouvé l’event ci-dessous :
Nom du journal :Citrix Delivery Services
Source : Citrix Authentication Service
ID de l’événement :3
Catégorie de la tâche :(1005)
Niveau : Erreur
Description :
Échec de AG Web Service sur : https://VotreUrl/CitrixAuthService/AuthService.asmx avec l’erreur suivante. Ce point de terminaison sera ignoré jusqu’à : 07/05/2015 22:05:54
Citrix.DeliveryServices.Authentication.CitrixAGBasic.Exceptions.AGCommunicationException, Citrix.DeliveryServices.Authentication.CitrixAGBasic, Version=2.6.0.0, Culture=neutral, PublicKeyToken=null
Une erreur de communication s’est produite lors de la tentative de contact du service d’authentification NetScaler Gateway sur https://VotreUrl/CitrixAuthService/AuthService.asmx. Vérifiez que le service d’authentification est en cours d’exécution.
à Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.AGClient.GetAccessInfo(String sessionId, String username, String domain)
à Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.CitrixAGBasicWebService.GetAccessInfo(String sessionId, String username, String domain)
Via le serveur StoreFront nous avons constaté que l’url “https://VotreUrl” n’était plus résolu correctement (sur les serveurs DNS l’alias pointait sur une ancienne IP).
Si vous avez la main sur les serveurs DNS il vous suffira de mettre à jour l’alias en question. Si vous n’avez pas la main sur les serveurs DNS vous pouvez rajouter dans le fichier Host (situé dans C:\Windows\System32\drivers\etc) du serveur StoreFront une entrée pointant sur votre alias (exemple : 10.10.20.11 votreurl) en attendant la mise à jour des DNS.
Il y a quelques jours nos scripts de prod (d’une de nos fermes XenApp 6.5 R04) renvoyaient les informations d’une ferme de qualification, en regardant de plus près nous avons constaté que le scope d’exécution du SDK avait été changé sur un de nos serveurs d’administration.
Un Get-XADefaultComputerName confirma que le scope n’était pas le bon, afin de rétablir le scope sur la ferme d’appartenance du serveur il faut passer par un Set-XADefaultComputerName -ComputerName “VotreServeur”.
Ce billet juste pour souligner qu’un changement de scope ne concerne pas que la session dans laquelle il est lancé mais le serveur en lui-même, l’information étant présente dans la valeur “DefaultComputerName” situé dans [HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\XenAppCommands].
Si vous souhaitez ne pas changer de scope, les cmdlets du SDK permettant de faire du remote avec l’utilisation de l’argument -computername.
Cela faisait quelques temps que nous souhaitions changer l’affichage des valeurs de nos graphiques de CCU, en effet par défaut Zabbix affiche les valeurs égales ou supérieures à 1000 dans un format “multiplicateur” (exemple 1500 = 1.50 K) si vous ne spécifiez pas une unité de mesure (‘%’, ‘ms’, ‘rpm’, ‘RPM’).
Avec les fameux K
Afin de pouvoir afficher les valeurs dans leur format d’origine il faut rajouter dans la blacklist de Zabbix un caractère (ou symbole) qui une fois inséré dans le champ “Unit” des hosts permettra d’afficher la valeur dans son format initial accompagné du caractère (ou symbole) rajouté dans la blacklist (on vous déconseille de rentrer une valeur null 😉 ).
Pour insérer un caractère (ou symbole) dans la blacklist il faut modifier le fichier “func.inc.php” situé dans votre server Zabbix (usr/share/zabbix/include) et rajouter dans la variable $blacklist votre caractère (ou symbole).
Exemple : $blackList = array(‘%’, ‘ms’, ‘rpm’, ‘RPM’, ‘c’);
Sans les K c’est mieux 🙂
Quelques liens où on parle de blacklist Zabbix :
Comme vous le savez chez nous la supervision (et le monitoring) XenApp c’est une religion, c’est pourquoi au détour d’une discussion avec notre collègue Corvette_Man (à qui nous devons l’idée originale de ce billet) l’idée d’une supervision global des silos (serveurs) d’une ferme XenApp nous est venue.
Le but de cette démarche est double, premièrement permettre à la Citrix team d’avoir une vision des silos avec leur taux d’utilisation et deuxièmement offrir aux équipes applicatives une vue de leurs silos respectifs avec le taux d’utilisation.
Nous avons donc mis en place un script PowerShell permettant d’afficher une page html au sein de laquelle sont regroupés tous les silos de serveurs (ayant au moins un serveur). La disponibilité de ces silos est exprimée en pourcentage au travers d’un graphique (le pourcentage est issu du total de la charge des serveurs du silo) , un clic sur un silo déclenche l’ouverture d’une page html regroupant la totalité des serveurs membres du silo avec leur charge respective.
Le script tourne au travers d’une boucle s’exécutant toutes les 5 mn (à adapté selon vos besoin, de notre côté le script tourne via une tache planifiée), Les graphiques sont issus de justGage.com (justGage est basé sur la librairie Raphaël).
L’avantage de justGage est qu’il est personnalisable, rapide et facile à mettre en place. Le graphique change de couleur en fonction de la valeur entrée dans le graphique, vert en dessous de 34 %, jaune de 34 % jusqu’à 66 % et rouge à partir de 67 %.
La vue globale d’une ferme XenApp 6.5
Le chiffre à côté du pourcentage de chaque silo correspond aux nombre de serveurs membre du silo
La vue d’un silo avec la charge de chaque serveur
Les pages générées sont compatibles avec Chrome, Firefox et IE (9).
XenApp_LoadMonitor.rar
XenApp_Check passe en 1.4, la liste des ajouts et corrections sont ci-dessous :
Pour télécharger XenaApp_Usr c’est par ici
———————–
MAJ : 28/06/2015
Version : 1.1
———————–
Tout est dans le titre 🙂 , via XenApp_Gpupdate vous avez désormais la possibilité de faire (en remote) des “gpupdate /force” sur des serveurs membres d’un silo applicatif au sein d’une ferme XenApp 6.5.
XenApp_Gpupdate (comme XenApp_Usr) est un script Powershell réalisé pour la partie GUI avec Powershell Studio de Sapien.
Le “gpupdate /force” est fait via un “Invoke-WmiMethod” (il faut donc que le port TCP 135 soit ouvert entre le serveur exécutant XenApp_Gpupdate et les serveurs XenApp des divers silos de la ferme courante, avant de lancer le GpUpdate un socket tcp est envoyé afin de vérifier que le port 135 est bien ouvert sur le ou les serveurs du silo choisis.
Le fonctionnement de XenApp_Gpupdate est simple, il suffit d’afficher la liste des silos (dossiers serveurs) ou la liste des applications via les boutons Applications ou Servers Silo (il est aussi possible de faire une recherche sur un silo ou une application), puis de sélectionner le silo (ou l’application) souhaité. Une fois le dossier ou l’application sélectionné(e) la liste des serveurs s’affichera sur la partie droite (lors de la première sélection un temps d’attente est à prévoir), une fois la liste des serveurs affichés vous pouvez lancer un gpupdate /force sur un ou plusieurs serveurs.
C’est une V1 n’hésitez pas à nous faire part de vos retours (suggestions, critiques etc… )
Nous travaillons actuellement sur le retour des “gpupdate /force” afin de déterminer si ces derniers ont bien été réalisés sur le ou les serveurs sélectionnés.
XenApp_Gpupdate.rar
Cela faisait quelque temps que nous souhaitions mettre en place un template Zabbix dédié XenApp 6.5 (pas de monitoring de type ZDC/XML broker ou Webi, ça fera l’objet d’un prochain billet 😉 ), au passage ce template a été réalisé sous Zabbix 2.4.
Afin que ce template XenApp 6.5 puisse être le plus compatible tout langage, nous avons utilisé les “ID” des compteurs perfmon (ce que permet facilement Zabbix, concernant les compteurs perfmon propre à XenApp ils ne sont pas concernés car nous avons constaté qu’entre un 2008 Fr et un 2008 Us les “ID” ne correspondaient pas, mais comme on est sympa on vous a mis dans le champ description des items XenApp la version perfmon US).
Le template comprend 30 items (certains items sont liés afin de permettre des valeurs calculées), 21 trigers, un screen avec cinq graphiques (afin de pouvoir rapidement lors d’une recherche sur un host de pouvoir visualiser graphiquement.
Bien sur ces items correspondent à un monitoring et une supervision globale (si vous avez d’autres items à rajouter n’hésitez pas à les partager)
Le template comprend cinq graphiques et un screen (le screen reprenant les cinq graphiques afin de permettre un affichage rapide des graphiques).
Ok notre labs est par hyper sollicité 🙂
zbx_template_XenApp_65.xml
La page des templates Zabbix de zabbix.org est ici (elle comprend notamment un template XenApp regroupant les parties Web Interface, ZDC etc..).
La page des templates officiels de zabbix.com est ici.
