Citrix Monitoring Guide: Metrics & Alerts

Bevezetés

A Citrix teljesítményproblémái ritkán kezdődnek teljes leállással. A bejelentkezések lassan meghosszabbodhatnak, egy VDA eltérhet a társaitól, a kapcsolati hibák száma növekedhet, vagy a munkamenet késleltetése előre látható időpontokban emelkedhet. A hatékony monitorozás segít az IT csapatoknak, hogy korán észleljék ezeket a változásokat, és megkülönböztessék az elszigetelt tüneteket a szélesebb infrastruktúra-, hálózati vagy kapacitásproblémáktól.

Ez a cikk a rendszergazdák számára a Citrix problémák hatékonyabb diagnosztizálásához szükséges eszközöket, mutatókat és korai figyelmeztető jeleket vizsgálja.

Milyen típusú rétegeket kell lefedni a Citrix megfigyelésével?

Több szorosan összekapcsolt összetevőt kell figyelembe venni a Citrix Virtual Apps és Desktop esetében. Egy felhasználói munkamenet magában foglalhatja a közvetítést, az azonosítást, a VDA-t, a Windows szolgáltatásokat, a felhasználói profilokat, a GPO-t, a tárolást, az alkalmazásokat és a hálózati kapcsolatokat, mielőtt egy alkalmazás vagy asztal egyáltalán használatra rendelkezésre állna. A jó Citrix megfigyelés négy finomságra vonatkozó láthatóságot igényel.

A munkamenet rétegben a rendszergazdák szeretnék tudni, hogy a felhasználók képesek-e csatlakozni, mennyi ideig tart a bejelentkezés, és hogy a munkamenetek továbbra is válaszolnak-e.

A Citrix szállítási rétegén a megfigyelés képes észlelni, hogy a gépek működnek és regisztrálva vannak, a kapcsolatok megszakadnak, és hogyan van kiegyensúlyozva a terhelés.

Az infrastruktúra szintjén a CPU, a memória, a tárolás és a Windows szolgáltatások tesztelhetők, hogy biztosítsák a hosztoló rendszerek képességeit.

És hálózati/történelmi szinten látnod kell, hogy a késleltetés nem befolyásolja a munkamenet válaszidejét, és hogy a tárolásra és egyéb erőforrásokra nehezedő igény idővel ne növekedjen meg.

A trükk nem az, hogy minden elérhető számlálót nyomon kövessünk, hanem hogy egy problémát a tünettől a valószínűsíthető alapinfrastruktúra rétegig kövessünk.

Mely eszközök hasznosak minden egyes felhasználási esethez?

Egyetlen monitoring kategória sem nyújt egyenlő mértékű betekintést az összes alkalmazásába és szolgáltatásába. A legjobb eszközkészlet attól függ, hogy mit szeretne látni és hibaelhárítani.

Citrix Monitor és Director

Ez az a hely, ahol a Citrix saját monitorozó eszközei ésszerű első helyet jelentenek a kereséshez.

A Citrix Monitor a Citrix DaaS és a Director a Citrix Virtual Apps és Desktops számára információt nyújt a munkamenetekről, a kapcsolódási és géphibákról, a bejelentkezési időről, a terhelésről, a gép kihasználtságáról és a gép állapotáról. Időbeli trendeket is megtekinthet, így a jelenlegi teljesítményt a történelmi adatokkal hasonlíthatja össze, nem pedig a jelenlegi teljesítményt egy adott időponthoz.

Ez a megfigyelés rávilágít a megfigyelési folyamatra magára.

Például a Citrix segítségével kaphat egy a bejelentkezés időtartamának részletezése és ahol a késlekedés bekövetkezik: bróker, gépindítás, HDX, bejelentkezési szkriptek, Csoportházirend, hitelesítés és így tovább.

Ez egy sokkal jobb módja annak, hogy a felhasználói panasz "a bejelentkezések lassúak" kifejezésből egy hasznosabb hibaelhárító kérdéshez jussunk: a bejelentkezési folyamat mely része tart tovább a kelleténél?

Infrastruktúra és Szerverfigyelés

A Citrix diagnosztika azonban nem helyettesíti az alapul szolgáló szállítási platform figyelését.

A szervermonitorozás folyamatos CPU-használatot, memóriafeszítést, lemezaktivitást, tárolókapacitást és szokatlan folyamatviselkedést mutathat. Ezek az adatok különösen értékesek, ha a probléma a Citrixben jelentkezik, de az ok mélyebben rejlik a rendszerben.

Gondolj arra, hogyan vizsgálnád meg a bejelentkezési idők növekedését. Ha a tárolási késleltetés is magas, akkor a profilokat és a tárolást érdemes ellenőrizni. Ha a szerver rendben van, de a bejelentkezési idők meghosszabbodnak, akkor a szerver hitelesítése, a Csoportházirend vagy egy másik szállítási tényező valószínűbb.

Infrastruktúra történeti megfigyelése segít a kapacitás tervezésében is. A szerver összeomlása előtti napokban vagy hetekben fokozatosan növekvő erőforrás-fogyasztás azt mutatja, hogy van egy határ egy végpont vagy gazda esetében anélkül, hogy a komponenst ténylegesen leállítanánk.

Hálózati megfigyelés

Az alkalmazások és asztalok Citrix-en történő szállítása a felhasználói eszköz és a gazda közötti jó hálózati kapcsolatra támaszkodik.

A hálózati megfigyelés megmutathatja a késleltetés, torlódás, sávszélesség, megbízhatatlanság vagy a helyszínhez kapcsolódó problémák növekedését, amelyeket a szerverfigyelés nem tud megmagyarázni.

A Citrix session-performance analysis may also show metrics like ICA latency, ICA körutazási idő (RTT) , képkockasebesség és szabad versus felhasznált sávszélesség.

Ez az adat különösen fontos, amikor a felhasználók sikeresen csatlakoznak, de azt mondják, hogy az alkalmazásaik vagy asztalaik lassúnak tűnnek.

Digitális élmény és teljes stack monitorozás

Egyes környezetekben szükség van arra, hogy a infrastruktúra elérhetőségén túl is lássunk.

A digitális élményfigyelés és a szintetikus monitorozás képes utánozni vagy figyelni a felhasználói tevékenységeket, mint például a bejelentkezést, az alkalmazások indítását és a tranzakciók lebonyolítását. Ahelyett, hogy csak a válaszoló szervereket látnánk, a cél az, hogy megerősítsük, hogy a szolgáltatás működik a felhasználó számára.

Ez a megkülönböztetés fontos, mert a jó infrastruktúra nem biztosít jó felhasználói élményt. A nagyobb környezetek teljes körű megfigyelési platformokat is kihasználhatnak, amelyek összekapcsolják a Citrix munkamenetet a VDA-val, a Windows erőforrásokkal, az Active Directory-val, a tárolással, az alkalmazás szerverekkel és a hálózati úttal.

De valószínűleg nem szeretne még több irányítópultot. Egy monitorozó platform akkor mutatja meg az igazi értékét, amikor szűkíti a lehetséges okokat, és útmutatást ad az adminisztrátoroknak a megváltozott réteghez.

Mik a legfontosabb metrikák típusai?

Több ezer számláló érhető el a Citrix platformról. A leghasznosabb mutatók azok, amelyek a felhasználói élményhez, az infrastruktúra állapotához vagy bármilyen adott kapacitásváltozáshoz kapcsolódnak.

Bejelentkezési időtartam

A bejelentkezési idő az egyik legerősebb felhasználóközpontú mutató, mivel több területet is feltár a szolgáltatási láncban.

A teljes bejelentkezési idő a fő mutató, de elhomályosíthatja a részleteket egy diagnózis során. A Citrix képes lesz megkülönböztetni a közvetítést, a gép indítását, az HDX kapcsolatot, a bejelentkezési hitelesítést, a profil betöltését, a bejelentkezési szkripteket és a Csoportházirend feldolgozását.

Ha a profil betöltésére fordított idő meghosszabbodik, a figyelem a profilkezelő áruházra terelődik. A hosszú Csoportházirend-feldolgozás máshol végzi a vizsgálatot. A lassú gépindítás a VDA-t, a gazdarendszert vagy a virtualizációs platformot a keretben hagyja.

A teljes időtartam arra utal, hogy valami eltérő, de a fázisbontás felfedi, hol van eltérés.

Session válaszidő

Egy létrehozott munkamenet nem jelzi a válaszképes munkamenetet.

ICA RTT, ICA késleltetés, képkocka sebesség és sávszélesség metrikák használhatók annak meghatározására, hogy egy csatlakoztatott asztal vagy alkalmazás megfelelően működik-e.

A kontextus továbbra is kulcsszerepet játszik. Ha egy irodában a felhasználók az egyetlenek, akik teljesítménycsökkenést tapasztalnak, akkor valószínűleg a hálózati útvonal a hibás.

Kapcsolódási és géphibák

A teljes kapcsolatvesztést sürgősen kezelni kell, de a tendencia jelentősebb lehet, mint bármely egyes esemény.

A ritkán hibázó kapcsolatok hátterében megjelenő emelkedés egy lassan kibontakozó probléma jelzője lehet, még akkor is, ha a legtöbb felhasználó továbbra is csatlakozik.

A rendszergazdáknak meg kell vizsgálniuk a hibák eloszlását. Az egyes doboz, a szállítási csoport, az iroda vagy az időszak sokkal informatívabb lehet, mint a hibák teljes listája.

Párhuzamos munkamenetek és terhelés

A párhuzamos munkamenetek száma a legtöbb infrastruktúra-mutató háttérinformációja.

A nagy CPU-csúcs egy nagyon nagy bejelentkezési roham során csak több keresletet jelent. Ugyanez a processzorigény növekedés, felhasználók változása nélkül, más okból ered.

A tervezésnek három tényezőt kell figyelembe vennie:

session volume → gazda terhelés → reakcióidő

Ha a session számok emelkednek anélkül, hogy a gazdagép terhelése vagy válaszideje is növekedne, a rendszer még mindig képes lehet ezt támogatni.

Ha ugyanannyi session nagyobb processzorterhelést, memóriafeszültséget vagy késleltetést eredményez, akkor valami más is megváltozott a munkaterhelésben.

CPU, memória és tárolás

Gondolj a CPU, a memória és a tárolás kihasználtságára mint mintákra, ne pedig egyedi százalékokra.

A CPU-val egy rövid zörej lehet, hogy nem jelent problémát. A tartós használat, a folyamatos telítettség, a növekvő alapérték vagy egy gazda, amely a kollégáihoz képest processzoridőt fogyaszt, sokkal jelentősebb.

A memória perspektívában is látható. A magas RAM-használat önmagában csak akkor aggasztó, ha folyamatos növekedés, hirtelen használat, szokatlan gazdagép-gazdagép eltérések vagy a RAM nem tudja visszaadni magát a normális állapotába egy csúcs után.

A tárolás mind kapacitás, mind teljesítményfigyelést igényel. A csökkenő szabad hely nyilvánvaló teljesítménykockázatot jelent, míg a magas lemez késleltetés vagy tárolási verseny lelassítja a profilokat, az alkalmazások indítását és a munkamenetek elindítását, ha egyébként elérhető kapacitás áll rendelkezésre.

Mik a korai figyelmeztető jelek, mielőtt Citrix problémákkal szembesülnénk?

A Citrix teljesítményproblémái általában eltérések formájában jelentkeznek, mielőtt leállásokba torkollnának. A legjobb korai jelzők így a különböző számlálók közötti korrelációk változásai, nem pedig egyetlen számláló küszöbérték átlépése.

Korai figyelmeztető jel	Mit kell következőként megvizsgálni
A bejelentkezések fokozatosan lassabbá válnak.	Bejelentkezési fázisok, profilok, Csoportházirend, hitelesítés és tárolás
A kapcsolati hibák egy alacsony alapvonalról növekednek.	Gépek, Kiszállítási Csoportok, legutóbbi változások és hálózati viselkedés
A forráspikek minden nap ugyanabban az időben jelentkeznek.	Bejelentkezési terhelések, ütemezett feladatok, alkalmazások és elérhető kapacitás
Egy hoszt folyamatosan eltérően viselkedik a társaitól.	Folyamatok, szolgáltatások, konfiguráció és terheléselosztás
A session késleltetése nő, miközben a gazda erőforrásai normálisak maradnak.	Hálózati útvonal, végpont helye és sávszélesség
CPU vagy memória emelkedik további felhasználók nélkül	Alkalmazások, folyamatok, javítások és konfigurációs változások
A szabad lemezterület előre jelezhetően csökken.	Profilok, naplók, ideiglenes adatok és alkalmazás tárolás
A teljesítmény azonnal megváltozik egy frissítés után	Recent patch, policy, application or configuration changes

A közös elem a várt normától való eltérés. A megfigyelés sokkal hatékonyabbá válik, amikor az IT szakemberek felteszik a kérdést: "ez az érték magas?" a "miért eltér a normától?" mellett.

Miért kellene inkább a kiindulási értékekre összpontosítania, mint a rögzített küszöbértékekre?

A rögzített küszöbértékek továbbra is szükségesek. Az adminisztrátoroknak figyelmeztetésekre van szükségük, hogy tudják, mielőtt a lemezek elfogynak, mielőtt a CPU eléri a telítettséget, és mielőtt egy szolgáltatás meghibásodik és befolyásolja a rendelkezésre állást.

De egyetlen, mindent átfogó küszöb nem fog megfelelni minden Citrix környezetnek.

Tegyük fel, hogy egy környezet általában 15 másodpercet vesz igénybe a felhasználói bejelentkezések befejezéséhez, és ez a mutató elkezd 25 másodperc felé és azon túl emelkedni. Ez egy olyan terület, amelyet érdemes megvizsgálni, még akkor is, ha a szervezet 30 másodpercet határoz meg riasztási küszöbként.

Egy másik környezetben, ahol a bejelentkezési sebességek általában 30 másodperc körül mozognak, ez a szám nem lenne különösebben aggasztó - egy újabb példa arra, hogy a különböző abszolút számok nagyon eltérő jelentésekkel bírhatnak különböző körülmények között.

Szokásos funkciójuk szerint a kiindulópontok figyelmeztethetnek a következőkre:

• lassú teljesítményváltozások
• posztfrissítés ugrások
• csúcsidőszakokban bekövetkező változások
• növekvő munkaterhek
• a hasonló szerverek közötti különbségek
• építési kapacitás korlátai

A riasztásokkal ellátott benchmark egyszerű: Riasztás a rendellenes változásokról és abszolút határokról.

Hogyan tudja az IT csapata összekapcsolni a Citrix mutatóit?

Az egyedi Citrix mutatók valóban megmutatják értéküket, amikor az infrastruktúrával és a hálózati viselkedéssel korrelálnak. Gondolj ezekre a gyakori párosításokra:

Citrix tünet	Korrelált bizonyíték	Nyomozási irány
A bejelentkezések lassabbá válnak	A lemez késleltetése is nő.	Profilok, tárolás és lemez I/O
A bejelentkezések lassabbá válnak	CPU, memória és tárolás normális marad	Hitelesítés, GPO-k, profilok, közvetítés vagy egyéb bejelentkezési szakaszok
A munkamenet válasza romlik	A gazdagép állapota stabil marad	Hálózati útvonal, sávszélesség vagy végpont helye
A CPU használat növekszik	A párhuzamos munkamenetek száma változatlan.	Folyamatok, alkalmazásváltozások, javítások vagy ütemezett munkaterhelések
Egy VDA gyengén teljesít.	A hasonló VDÁ-k normálisak maradnak	Helyi szolgáltatások, konfiguráció vagy terhelés azon a gépen
A hibák száma növekszik egy változás után	A korábbi alapvonal stabil volt	Legutóbbi frissítés, irányelv vagy konfigurációs visszaesés

Ez megakadályozza az IT-adminisztrátorokat abban, hogy minden figyelmeztetéssel külön-külön foglalkozzanak. Ehelyett ez a következő lépés a gyökérok elemzésében:

tünet → kapcsolódó mutatók → érintett réteg → valószínű ok

Ez a különbség a monitorozási adatok birtoklása és azok hatékony kihasználása között.

Hogyan kell konfigurálnia a Citrix értesítéseit?

Egy jó figyelmeztetés időben értesítheti az adminisztrátort, hogy intézkedjen, mielőtt a szolgáltatási szintek szenvednének. Állapítsa meg az alap szinteket a bejelentkezési idők, egyidejű munkamenetek, hibák, szerver erőforrások, tárolási hatékonyság és munkamenet válaszidő tekintetében. Használja az információt a figyelmeztető és kritikus állapotok meghatározásához.

Az értesítéseknek jelentős eltérést kell mutatniuk a normától, amely még mindig lehetővé teszi az adminisztrációs időt, míg a kritikus események nem várhatnak cselekvésre.

A Citrix támogatja a figyelmeztetési és kritikus riasztási politikákat több intézkedés és adat esetén, azonban a statikus küszöbértékek a leghatékonyabbak, ha korábbi információkkal rendelkezünk a trendekről és a válasz pontosságáról.

A legjobb érték az értesítések esetében az információk biztosítása anélkül, hogy felesleges értesítéseket generálnánk, amelyek megterhelik az adminisztrátorokat, és fontos küszöbértékek átlépésének elmulasztásához vezetnek. A fókusz azon van, hogy gyorsan ismétlődik-e, folyamatosan a normál felett van-e, vagy anomália.

Mi a legjobb Citrix megfigyelési munkafolyamat?

A felhasználó panaszkodik, hogy a "Citrix lassú" - a problémák elkülönítése, amikor egyszerre több beállítást módosítanak, időigényes lehet. Egy jól meghatározott munkafolyamat segít a probléma szűkítésére összpontosítani, mielőtt megpróbálnánk megoldani.

1. Mi a terjedelem?

Csak egy felhasználót, több felhasználót, egy alkalmazást, egy VDA-t, egy Delivery Group-ot, egy helyszínt vagy minden környezetet érint?

A hatály azonnal kizárja a sok lehetséges okot.

2. Mi a szakasz?

3. A késés a kapcsolat előtt, a bejelentkezés/azonosítás során, az alkalmazás indítása közben, vagy miután belépett a munkamenetbe? A lassú bejelentkezés és a lassú munkamenet két különböző dolog.

3. Citrix-specifikus nyomok

Keresés a session információk, kapcsolati hiba/hibák, géphiba/hibák között, VDA hibák , bejelentkezési fázis és egyéb munkamenet-teljesítmény számlálók.

Ez megmutatja, hogy a Citrix már jelzi-e, melyik szakasz lassú vagy romló.

4. Hivatkozza össze az infrastruktúráját és a hálózati adatait

Hasonlítsa össze a Citrix adatokat a CPU, memória, tárolás és hálózati számlálók adataival ugyanarra az időszakra. Hasonlítsa össze jó gépekkel, nem egymással, hogy elkerülje az elfogultságot, ha lehetséges.

5. Nézzen vissza a múltba

Mióta tart ez a viselkedés? Ez egy Windows-frissítés, alkalmazásfrissítés, csoportházirend-változás, profilváltozás vagy infrastruktúra-változás után kezdődött?

Hasonlítsa össze a jelenlegi helyzetet a múltbeli teljesítménnyel; ami hirtelen zuhanásnak tűnik, az kiderülhet, hogy egy hosszú távú trend kiterjesztése.

Ez egy megismételhető eljárást biztosít:

tünet → terjedelem → szakasz → korrelált mutatók → legutóbbi változás → valószínű ok

Citrix Monitoring: Mikor válik architektúra kérdéssé?

A monitorozás bonyolultsága nem jelenti azt, hogy a Citrixet ki kellene cserélnie.

Néhány nagyobb vagy összetettebb telepítésnek továbbra is szüksége lesz a Citrix virtualizációs, alkalmazás-átviteli, HDX és menedzsment funkcióira. Ezekben a környezetekben a többrétegű monitorozás csupán része annak a paradigmának, amely lehetővé teszi az architektúra egészének működését.

Ahol a monitorozás más problémát tár fel, az az, hogy az architektúra messzebb terjed, mint amennyire szükség van ennek az alkalmazásnak a szállításához.

Ez akkor kezdődik, amikor nagy mennyiségű infrastruktúra- és adminisztrációs erőforrást költesz egy olyan szállításra, amelyet nagyon egyszerűen lehet közzétenni a Windows rendszerében.

Jelzők lehetnek:

• a működési erőfeszítés túl sok szállító entitás között oszlik meg
• nem kell ennyire figyelemmel kísérni a telepítéshez képest
• túl sok infrastruktúra van a egyszerű alkalmazáskiadás körül, és távoli hozzáférés
• a felhasználóknak csak böngészőre vagy RDP-hozzáférésre van szükségük az alkalmazáshoz
• az adminisztrációs költségek és az infrastruktúra lábnyoma súlyos problémákká válnak

Röviden, ez már nem hibaelhárítási kérdés. Ez egy architektúra kérdés. A kérdés átalakulhatott arról, hogy "Hogyan figyeljük meg jobban ezt a Citrix környezetet?" arra, hogy "Szüksége van még ennek az esetnek az architektúrára?"

Hogyan lehet a TSplus alternatíva a Citrix számára?

A Citrix megfigyelés felfedheti, amikor az infrastruktúra és az adminisztratív erőfeszítések aránytalanokká válnak egy viszonylag egyszerű követelményhez képest, amely Windows alkalmazások vagy asztalok távoli felhasználók számára történő közzétételére vonatkozik.

Ebben a helyzetben a probléma valószínűleg kevésbé a megfigyelés javításáról szól, és inkább arról, hogy a szállítási architektúra még mindig megfelel-e a tényleges felhasználási esetnek.

TSplus Távhozzáférés egyszerűbb architektúrát kínál többfelhasználós alkalmazás- és asztali szolgáltatáshoz RDP-kompatibilis kapcsolatokon vagy egy HTML5 webportálon keresztül. Megfelelhet azoknak a szervezeteknek, amelyeknek egyszerű hozzáférésre van szükségük Windows alkalmazásokhoz és asztalokhoz anélkül, hogy a teljes Citrix környezet szélesebb virtualizációs és kezelési rétegeivel kellene foglalkozniuk.

Következtetés

A hatékony Citrix megfigyelés kevésbé arról szól, hogy minden elérhető mutatót összegyűjtsünk, mint inkább arról, hogy megértsük, hogyan kapcsolódnak az fontosak egymáshoz. A bejelentkezési időtartam, a munkamenet reakcióképessége, a hibák, a gazdagép erőforrásai, a tárolás és a hálózati viselkedés akkor válik a leghasznosabbá, ha történelmi alapvonalakkal és egymással összehasonlítjuk őket.

Ez a korreláció segít az IT csapatoknak egy homályos tünettől az érintett réteghez és egy valószínű okhoz eljutni. Azt is felfedheti, hogy a probléma a teljesítményben rejlik, amelyet javítani kell, vagy egy olyan architektúrában, amelynek működési összetettsége szélesebb áttekintést érdemel.