BORG-OSC heeft ruim 170 IT professionals aan het werk, allemaal met kennis en ervaring op het gebied van IT infrastructuur. Ieder met een unieke expertise binnen dit vakgebied. Wat maken zij mee? Welke opdrachten doen ze? Hoe ziet een werkdag eruit? Hier lees je hun verhalen.

Vandaag het verhaal van één van onze Citrix Specialisten die monitoring veel efficiënter heeft gemaakt voor zijn opdrachtgever.

 

SCOM

Bij de start van mijn opdracht werd er nog niet aan monitoring van de omgevingen gedaan. Door middel van SCOM werden wat standaard dingen gemonitord, maar er was nog geen applicatie specifieke monitoring. Naast mijn dagelijkse werkzaamheden kreeg ik het verzoek om dit in te regelen voor de omgevingen.

 

Inventariseren

Monitoring gebeurd met SPLUNK. Hier had ik zelf nog nooit mee gewerkt, maar ik vond het een leuke uitdaging. Ik heb me eerst laten informeren door collega’s in mijn eigen team en het SPLUNK-team, over de mogelijkheden ervan en wat er allemaal nodig is om dit in te regelen.
Vervolgens ben ik met het team en de Product Owner om tafel gegaan om te bepalen wat we allemaal gemonitord willen hebben. Dit was in het begin simpel. De beheerder van de dag voert elke ochtend een controle uit van de Citrix servers door in te loggen op een van de servers, de console starten en wat checks uit te voeren of alles wel “up and running” is. Dit kost per dag ongeveer een uur. Dit moest makkelijker gemaakt kunnen worden.

 

SPLUNK Forwarder

Op het te monitoren systeem werd een SPLUNK Forwarder geïnstalleerd. Daarbij werden firewall rules opgezet naar de Indexer van SPLUNK.
Nadat de Forwarder geïnstalleerd is, worden er standaard events naar de Indexer gestuurd. Vanuit de SPLUNK console kun je dan diverse data van events opvragen.
SPLUNK heeft zelf ook verschillende apps van waaruit applicatie specifieke data verzameld en doorgestuurd kan worden. Voor ons was het van belang om zoveel mogelijk Citrix data uit SPLUNK te halen. Hiervoor was er een XenDesktop app beschikbaar. Deze is door het SPLUNK-team opgenomen en gedeployed naar de machines.

 

Dashboard

Nu alles “in place” is voor monitoring, is het nu de taak om hier data voor te verzamelen in een dashboard. Een dashboard bestaat uit verschillende “panels” die data in tabel vorm of grafisch kan weergeven.
Het verzamelen van data gaat op basis van de hostnaam. Om niet voor elke zoekopdracht de hostnaam in te vullen, heb ik gebruik gemaakt van een “Lookup table file”. Dit is een .csv bestand waarin ik de hostnames van alle infra servers heb opgenomen. Per server wordt in verschillende kolommen de naam, rol en datacenter opgenomen. Op deze manier kan ik een bestand gebruiken voor mijn hele dashboard.
Per Citrix component (rol), heb ik bepaald welke services kritisch zijn voor de werking van de betreffende server. Voor een Citrix Provisioning Server is het bijvoorbeeld van belang dat de Stream Service draait, anders kan deze server zijn functie (het streamen van het image) niet vervullen.

Om dit in SPLUNK te laten weergeven ziet de search functie er ongeveer zo uit:

index=”xd” sourcetype=”WMI:Services” DisplayName=”*Citrix*” -> Geef alle services weer met “Citrix” in de naam
| search [
| inputlookup Lookup.csv        -> Zoek in de Lookup table file naar de rol “PVS” en geef daar de hostnamen van weer
| where Rol=”PVS”
| fields host]
“Name=StreamService”           -> De naam van het Stream Service
| stats latest(State) AS State by host      -> Sorteer op laatste status
| lookup Lookup.csv host output DC
| table host, DC, State              -> Geef de naam, datacenter en status weer

Dit heb ik ook voor de andere rollen (Delivery Controllers, StoreFront en Director servers) bepaald. De code is soortgelijk aan die als hierboven.

 

Panels

Als je dit alles dan in Panels weer laat geven, dan ziet dat er ongeveer zo uit:

Hiermee zie je dus in één keer de status van de Citrix infra servers. Dit scheelt weer tijd in plaats van op alle servers in te moeten loggen en alles handmatig te bekijken.

Nu dit eenmaal in een dashboard te hebben gezet, hebben we de kolommen uitgebreid met meerdere panels. Status van de schijven, CPU utilization, Pending updates, etc.

Dat alles bij elkaar ziet er ongeveer zo uit:

Hiermee hebben we de ochtend controle terug gebracht van een uur werk naar één oogopslag!

 

XenDesktop App

Maar we hadden ook de XenDesktop app binnen SPLUNK waarmee we Citrix gerelateerde informatie konden laten weergeven. Om dit te laten werken, moesten we de SPLUNK Forwarder service met een service account laten draaien. Dat service account moest binnen de Citrix farm leesrechten hebben, anders kan er geen data weergegeven worden. De data wordt namelijk verzameld op basis van scripts die uitgevoerd worden. Als er geen rechten zijn kan er ook geen informatie weergegeven worden.
Als dat eenmaal ingeregeld is, kun je ook informatie opvragen over het aantal gebruikers, welke applicaties er gestart worden, welke desktops er gestart worden, etc. Dit ziet er dan ongeveer zo uit:

Deze informatie kan gebruikt worden om rapportages te maken over het gebruik van je omgeving.

 

24/7 support alerts

Mijn team is verantwoordelijk voor de infra componenten van alle Citrix omgevingen. Eén van die omgevingen heeft 24/7 support. Dat houdt dus in dat hier na kantoortijd en in het weekend ook support op gegeven wordt. Hiervoor worden er ook stand-by diensten gedraaid.
De persoon die stand-by stond, voerde op de zaterdag en zondag ook altijd een ochtend controle uit door op alle systemen in te loggen.

Nu we een dashboard hebben ingericht hoeft er niet meer ingelogd te worden op alle systemen, maar er moet natuurlijk wel in de ochtend naar de dashboard gekeken worden.
Nu we via SPLUNK de monitoring van de infra componenten uitvoeren, hebben we ook de mogelijkheid om alerts in te stellen. Deze alerts kunnen we dan via een koppeling tussen SPLUNK en het telefoonsysteem doorzetten naar de stand-by dienst. Dit zou het overbodig moeten maken om op zaterdag en zondag ochtend het dashboard te moeten bekijken. In overleg met het team en de Product Owner heb ik dit in gang gezet.
De search functie voor een alert ziet er iets anders uit dan bij het maken van een dashboard. Bij een dashboard wil je namelijk altijd een uitkomst hebben en dat weergeven. Bij een alert wil je alleen iets weergeven als er wat aan de hand is. Als we het voorbeeld van de StreamService van de Provision servers weer nemen, dan willen we dus een alert hebben als de service niet meer loopt.

De search functie daarvoor ziet dan zo uit:
index=”xd” sourcetype=”WMI:Services” DisplayName=”*Citrix*” -> Geef alle services weer met “Citrix” in de naam
| search [
| inputlookup Lookup.csv        -> Zoek in de Lookup table file naar de rol “PVS” en geef daar de hostnamen van weer
| where Rol=”PVS”
| fields host]
“Name=StreamService”          -> Naam van de Stream Service
NOT “State=Running”               -> Status is NIET “Running”

Hier krijg je dan pas een uitkomst als de StreamService niet “Running” is. Dit kan je dan doorzetten als alert naar de stand-by dienst.
Voor alle kritische services per Rol is op deze manier een alert aangemaakt die doorgezet wordt naar de stand-by dienst.

Zo hebben we een hoop tijd bespaard voor de beheerder van de dag door in SPLUNK dashboards in te richten. En voor de stand-by dienst die in het weekend geen ochtendcontrole meer hoeft uit te voeren.

 

Hostnames en DC zijn onherkenbaar gemaakt om privacy redenen.

 

 

Wat is jouw expertise? Welke opdrachtgever ga jij efficiënter laten werken? Ben je benieuwd wat wij voor jou kunnen betekenen? Of ben je op zoek naar mogelijkheden om je IT carrière een boost te geven? Neem dan contact met ons op. We komen graag met je in gesprek. We zijn altijd op zoek naar IT-talent. Reageer op een van onze openstaande vacatures of kom kennismaken.