Richard modernizuje IT: Richard a jeho monitoring

Svoji sílu (samozřejmě sílu SCOM) v oblasti monitoringu aplikací Richard představil v minulém díle. Od té doby se SCOM stal zcela zásadním pro vývojáře a monitoring aplikací. Po tom, co se tato pozitivní zpráva roznesla společností, vyjádřili i další administrátoři a vedoucí oddělení touhu pracovat s tímto dohledovým systémem a získávat z něj relevantní informace. To bylo něco pro Richarda, který si danou situaci náležitě užil. SCOM rozhodně není pouze o výstrahách a notifikacích, ale poskytuje obrovské možnosti interpretace výstupů a delegování přístupových pro různé role IT (pravil).

Monitorování SQL serverů

Přestože se může zdát, že Richard dokáže ze SCOM vyždímat prakticky cokoliv, skutečnou „práci“ odvádí někdo jiný. Tím někým je tzv. Management Pack. Jedná se o speciální balíček, který je nutné do dohledového systému naimportovat. Samozřejmě celý proces podléhá konkrétnímu postupu a je třeba se věnovat důslednému čtení dokumentů, které celý proces importu a následné konfigurace popisují. Richard samozřejmě říká: „Manuály jsem nikdy nečetl.“ Netřeba se však vším, co říká Richard, řídit. Management Pack zajistí, že se SCOM „naučí“ perfektně monitorovat vybranou oblast. Zároveň také přináší do konzole SCOM celou řadu předem připravených a velmi zajímavých pohledů na výstrahy, stavy konkrétních objektů, ale také souhrnných pohledů tzv. Dashboards. Samozřejmě tvůrčí činnost je v prostředí SCOM zcela zásadní a je možné vytvářet libovolné pohledy na stav prostředí nebo vybrané aplikace.

Richard tedy udělal v dalším kroku radost správcům SQL serverů. Po importu a správné konfiguraci Management Packu pro SQL byly v celém prostředí nalezeny všechny objekty týkající se platformy SQL a byl zahájen detailní monitoring. Jak už bylo zmíněno, do konzole SCOM byl delegován přístup administrátorům SQL, kteří v celém prostředí vidí pouze objekty, které mají ve své správě.

Na následujícím obrázku je vidět jeden vybraný Dashboard na stav SQL databází. Po výběru odpovídající DB jsou zobrazeny všechny informace o konfiguraci a výkonnosti.

Obr. 1: Pohled na SQL databáze

Předchozí záležitost se týká přímého přístupu do konzole SCOM a práce s aktuálním stavem. Často je však nutné z celé řady důvodů předkládat nebo reportovat historické informace.

Díky SCOM reportingu, který využívá SQL Reporting Services, je možné generovat velké množství reportů o stavu, dostupnosti a výkonnosti SQL platformy. Reporty je možné vybírat přímo z konzole SCOM a práce s nimi je snadná a intuitivní.

Obr. 2: SQL DB Report

Stejný proces a rozsah monitoringu je totožný pro většinu systémů a aplikací (nejen) Microsoft. Všechny Management Packy pro svět Microsoft jsou volně k dispozici „zdarma“ a je možné je aplikovat tak, jak Richard potřebuje.

Monitorování firemních aplikací pomocí grafických výstupů

Škarohlídové ihned kontrovali tím, že je to sice pěkné (už to je úspěch), ale co je to platné, když je ve společnosti provozována celá řada vlastních systémů a aplikací o kterých nemá Microsoft (cituji) ani páru? Je pochopitelné, že Microsoft (Management Pack) dokáže parádně vykreslit aplikaci, které je tvůrcem. Richard vztyčil bradu a vyřkl pouze: „Distribuované aplikace.“

Součástí konzole SCOM je tzv. Distributed Application Designer. Jedná se o prostředí, kde je možné vytvářet vlastní grafické mapy aplikací. Do těchto grafických výstupů je možné umístit libovolné objekty, které SCOM monitoruje, tedy vlastí servery, služby, procesy, databáze, síťové prvky apod. Cokoliv SCOM monitoruje, může být součástí těchto aplikací. Cílem samozřejmě je co nejpřesněji interpretovat architekturu aplikace a poskytovat reálné výstupy o její dostupnosti.

Obr. 3: Distributed Application Designer

Výsledkem takového tvoření je mapa vlastní aplikace včetně všech odpovídajících vazeb a monitorovaných objektů. Tyto pohledy jsou opět delegovány odpovídajícím uživatelům nebo administrátorům.

Nejedná se pouze o grafický a statický výstup, ale skutečný monitoring. Každý objekt v reálném čase reportuje svůj stav a jakýkoliv výpadek kterékoliv komponenty se okamžitě projevuje (chcete-li) v dostupnosti celé aplikace. Je důležité, aby tyto Distribuované aplikace byly vytvořeny důsledně a jednoznačně prokazovaly skutečný stav aplikace. Pokud dojde k nedostupnosti aplikace v kterékoliv její části, operátoři okamžitě zjistí příčinu a komponentu, které se výpadek týká. O tyto informace se Richard zcela zásadně opírá, neboť Distribuované aplikace monitorují kritické aplikace společnosti, ale hlavně automaticky zakládají incidenty v Service Manageru v případě výpadku.

Obr. 4: Sales App aplikace vytvořená jako DA

Další důležitou částí je měření SLA, které je navázáno právě na objekt Distribuované aplikace. Vedoucí IT má tak neustále přehled o (ne)dostupnosti všech kritických aplikací, a reportování se od těchto dob stalo triviální záležitostí. Odpadají jakékoliv diskuze nebo debaty o dostupnosti či nedostupnosti služeb. Pro vše existují odpovídající pohledy a reporty.

Obr. 5: SCOM SLA pro aplikaci Sales App

Cílový stav je takový, že v kanceláři Richarda je na zdi pověšený (veliký) televizor, na kterém jsou zobrazeny distribuované aplikace společnosti. Na první pohled je vidět jejich stav a případná identifikace problému (pokud zrovna nedávají Receptář).

Identifikace výkonnostních problémů aplikací z monitoringu

V předchozím příspěvku Richard popisoval nasazení a konfiguraci monitoringu aplikací pomocí APM. Po několika dnech provozu se začaly v prostředí SCOM objevovat informace spojené právě s monitoringem aplikací. Richard se rozhodl poskytnout pohled na informace, se kterými vývojáři pracují.

Pokud je v aplikacích identifikována jakýkoliv chyba nebo výkonnostní problém dle definic vývojářů, je generována odpovídající výstraha. Na obrázku je vidět popis generované výstrahy, který už často významně napovídá, kde se nachází problém. Richard dodal: „Chytrému napověz, hloupého trkni.“ (no ták).

Obr. 6: APM výstraha pro aplikaci

Pokud chce řešitel získat podrobnější informace, stačí kliknout (znalci vědí, že jednou) na odkaz umístěný v popisu výstrahy. Otevře se nové okno, které obsahuje celou řadu záložek poskytujících množství informací o zjištěných detailech a naměřených hodnotách.

Obr. 7: Detail výstrahy aplikace

Řešitel znalý věci zde nalezne velice rychle požadované informace a může okamžitě začít situaci řešit a aplikaci vyladit ku prospěchu celé společnosti. Níže je vidět pohled na čítače, které se týkají monitorování výkonnosti. Lze tak sledovat průběh chování aplikace atd.

Obr. 8: Čítače výkonnosti aplikace

Vrátili jsme se tedy trochu k vyhodnocování posledně nastaveného (APM), a k pohledu na práci s výstrahou a detailním pohledem na monitorované oblasti aplikace.

Nasazování nových verzi aplikací

Pokud pečlivě sledujete Richardův příběh, jistě víte, že vybrané aplikace Richard instaluje jako celky pomocí šablon služeb ve Virtual Machine Manager. Může tak činit opakovaně a do vybraných prostředí. Aplikace je tedy tímto způsobem implementována, je pro ni vytvořena odpovídající Distribuovaná aplikace pro monitoring a samozřejmě také aplikován monitoring pomocí APM.

Pokud je aplikace instalována ze šablony VMM, je neustále udržována vazba mezi původní šablonou a všemi instalacemi (instancemi). Vývojář zjistil na základě monitoringu chybu v aplikaci a rozhodl se ji napravit novou verzí. V prostředí Richarda tedy stačí původní šablonu zkopírovat a vytvořit její novou verzi. Tuto novou verzi šablony upravíme dle potřeb a aplikujeme do ní novou verzi aplikace.

Obr. 9: Šablona aplikace ve VMM

Po aplikování požadovaných změn řekneme VMM, že chceme na původní instanci aplikace provést update pomocí této nově vytvořené šablony. Těmito kroky nás provede průvodce, který se nás zeptá na pár detailů, například, chceme-li update provést formou in-place. Zde není rozhodně na místě držet se zásady, že zálohují pouze zbabělci. Po potvrzení všech kroků se spustí ihned instalace nové verze přes původní instanci s použitím nové šablony.

Obr. 10: Proces upgradu pomocí šablony

Pokud budete mít v šabloně a tedy i provozované aplikaci více instancí v určitě vrstvě (například web), in-place upgrade bude probíhat tak, že budou postupně nahrazovány jednotlivé instance serverů, aby nedošlo k nedostupnosti služby.

Obr. 11: Průběh upgradu aplikace ve VMM

Po dokončení celého procesu je v provozu nová verze aplikace a vše je opět plně funkční, dostupné a s odpovídajícím výkonem.

Jan Matějka, MVP
www.mainstream.cz