通过

Časté dotazy zájemců o System Center Operations Manager

  • 项目

Aktuální verze je nyní SCOM 2007 R2, aktualizace Cumulative Update 1 (popisuje Pavel Repa zde).

Obcas musím vysvetlovat nekteré dotazy, které vás mohou také napadnout, pokud ješte nepracujete se systémem SCOM. Pro zjednodušení zde vetšinu techto otázek z poslední doby  zodpovím nebo se o to alespon pokusím.

1. Logy – záznamy událostí

SCOM umí pracovat s událostmi zaznamenanými  službou Windows Event Log Service – což nikoho neprekvapí. K dispozici jsou všechny logy v systému Windows, SCOM dokáže události sbírat, reagovat na varovné a chybové stavy výstrahou nebo lze vytváret dvou ci trí-stavové monitory. Monitor se dvema stavy (v porádku / problém, chyba) nebo se tremi stavy (v porádku / varování / problém) lze plne automatizovat. To znamená, že jedna událost preklopí monitor do stavu hlášení chyby s vysláním výstrahy – událost nebo sled událostí zapsaných zdravým systémem muže monitor opet preklopit do stavu hlášení bezproblémového behu sledované služby nebo aplikace.  (Príkladem jsou události Directory service – Active Directory, události služeb SQL Serveru, služeb DNS, DHCP, apod..)  

Služby nebo programy tretích stran nemusejí zapisovat jenom do aplikacního logu prostrednictvím výše uvedené služby. Mnoho aplikací zapisuje do textových souboru a SCOM dokáže na každý takový zápis reagovat a patricne jej vyhodnotit. K dispozici jsou všechny nástroje: pravidla, monitory, notifikacní pravidla.

Agent SCOMu muže být konfigurován také jako príjemce zpráv z jiných operacních systému - serveru nebo sítových zarízení – syslog messages na portu 514 protokolu UDP. Opet jsou k dispozici všechny možnosti systému SCOM .

Sítové prvky lze pomocí SCOMu dohlížet s využitím protokolu SNMP

Prehled pravidel a monitoru ve vazbe na zdroj informace.

2. Nástroje pro vytvárení výstupních zpráv – reportu

Implementované reporty jsou integrované do konzoly System Center Operations Manager. Výchozí stav po instalaci systému SCOM s komponentou SCOM Reporting poskytuje základní reporty, které lze parametrizovat a takto upravené ukládat pro opakované použití. Jde o prehledy dostupnosti serveru a služeb, analýzu nejcastejších alertu, sledování latence alertu, konfigurací, výkonových parametru a po implementaci rozšírení pro systémy UNIX/Linux také reporty pro tyto systémy. Všechny tyto reporty používají jako zdroj dat databázi OperationsManagerDW (data warehouse).

Druhá skupina dodaných reportu predstavuje ponekud odlišné reporty, které jsou postavené na dotazech do databáze OperationsManagerAC (databáze auditních záznamu systému ACS), viz také muj clánek zde. Zdrojová databáze obsahuje záznamy z bezpecnostních logu sledovaných systému a lze tak reportovat neúspešné pokusy o prihlášení, zablokování úctu, použití privilegovaných úctu s vysokým oprávnením nebo zmeny clenství ve skupinách administrátoru. K reportum je dodán datový model databáze a lze tudíž pri tvorbe nových reportu použít komponentu ReportBuilder.

clip_image002

Pri návrhu vlastních reportu mužeme v nekterých prípadech výhodne použít i standardní pracovní databázi OperationsManager a vytvorit bežným postupem dotaz SQL do této databáze (samozrejme lze se dotazovat i v obou dríve zmínených databázích) – pomocí dodávané verze SQL Server Business Inteligence Development Studio, která je soucástí instalace SQL Server reporting Services.

Konkrétní postupy pro nekteré kategorie reportu podle zdroje dat (jedna ze trí databází) a podle použitého nástroje (Report Builder nebo Development Studio). Jaké nástroje použít v které situaci:

  • ReportBuilder je nástrojem první volby pro zprávy generované z dat shromáždených v databázi systému ACS (databáze OperationsManagerAC na serveru ASPSCOMA). Výhodou je rychlý postup a zkrácená doba návrhu reportu. Nevýhodou je omezená paleta možností formátování výstupu a nástroju.
  • SQL Server Business Inteligence Development Studio umožnuje využít všech možností formátování výstupu, vkládat vlastní kód a procedury použité pri zpracování reportu.
  • Parametrizace existujících reportu (Linked Reports) a jejich publikování – jednoduchá metoda úpravy generických reportu z Generic Report Library, dodaných se standardní instalací systému.

Databáze:

  • OperationsManager obsahuje standardne data za 7 dní, k dispozici jsou všechna data v rozsahu importovaných definic Management Packs, tj. výstrahy (alerts), záznamy událostí (events), výkonové parametry (performance data).
  • OperationsManagerDW obsahuje standardne data záznamu událostí za 100 dnu, data výstrah za 400 dnu, neagregovaná data stavu za 180 dnu a neagregovaná výkonová data za 10 dnu. Výkonová data a stavová data agregovaná po hodinách a po dnech se uchovávají 400 dnu.
  • OperationsManagerAC obsahuje data za 14 dnu, jsou to záznamy ze Security Logs všech monitorovaných systému.

3. Informace odesílané prostrednictvím komunikacních kanálu

image

K dispozici je rozhraní pro odesílání zpráv pomocí protokolu SMTP na servery elektronické pošty, dále na server IM (instant messaging) nebo krátké textové zprávy SMS. Poslední možností posílání upozornení je velice užitecné a univerzální rešení voláním externí dávky, skriptu VBS nebo skriptu napsaného v PowerShellu.

Nejprve definujeme komunikacní kanály a príjemce zpráv upozornení. Poté muže pristoupit k definici pravidel (notification subscription), ve kterých je stanoveno, jaké úrovne musí výstraha být, která dohledová pravidla ji generují a lze stanovit mnoho dalších kritérií, která musejí být splnena, aby bylo upozornení odesláno, vcetne casového okna, kdy je prípustné zprávy posílat.

4. Vyhledání konkrétní aktivity – prihlášení uživatele

Pro dohledání prihlášení uživatele rozlišujeme použití lokálního úctu na konkrétním serveru a použití doménového úctu. V prvním prípade vyhodnocujeme a vyhledáváme záznamy událostí z konkrétního serveru, v druhém prípade musíme zajistit sber záznamu událostí ze všech doménových radicu. Díky jejich vzájemné zastupitelnosti muže doménového uživatele overit kterýkoliv z nich. Systém ACS sbírá tyto záznamy v reálném case a v jeho databázi pak mužeme pomocí vhodne definovaných a parametrizovaných reportu vytváret výstupy a prehledy o ruzných aktivitách uživatelu ve zvoleném období. Zde je nutné pripomenout, k cemu tato databáze slouží – je to zdroj informací o aktivitách na sledovaných serverech ve zvoleném období. Vzhledem k velikosti databáze (standardne obsahuje záznamy za 14 dnu) je vždy treba najít kompromis mezi maximálním stárím dat v databázi a její únosnou velikostí. Vždy to závisí na technických prostredcích, které máme k dispozici na serveru s databází ACS. Osobne bych byl opatrný s historií delší než 30 dnu a s velikostí databáze ACS nad 100 GB.

Dodané standardní reporty pro audit jsou v soucasné dobe:

Access Violation - Account Locked
Access Violation - Unsuccessful Logon Attempts
Account Management - Domain and Built-in Administrators Changes
Account Management - Passwords Change Attempts by Non-owner
Account Management - User Accounts Created
Account Management - User Accounts Deleted
Audit5 Report Template
Audit Report Template
Forensic - All Events For Specified Computer
Forensic - All Events For Specified User
Forensic - All Events With Specified Event ID
Planning - Event Counts
Planning - Event Counts by Computer
Planning - Hourly Event Distribution
Planning - Logon Counts of Privileged Users
Policy - Account Policy Changed
Policy - Audit Policy Changed
Policy - Object Permissions Changed
Policy - Privilege Added Or Removed
System Integrity - Audit Failure
System Integrity - Audit Log Cleared
Usage - Object Access
Usage - Privileged logon
Usage - Sensitive Security Groups Changes
Usage - User Logon

Použití ReportBuilderu pri vytvorení ctyr reportu z databáze ACS je napr. na blogu DSE (Audit Report Scenarios: How to create custom reports with System Center Operations Manager 2007 R2 and Audit Collection Services (ACS))

  • Scenario 1: Computers joined to the domain (names and description)
  • Scenario 2: User passwords expired
  • Scenario 3: User accounts locked out
  • Scenario 4: Group policy changes

Reakce na prihlášení  privilegovaného úctu ADMIN / zmenu clenství Admins – rešíme pravidlem v SCOM, nikoliv dotazem v databázi ACS. Pravidlo lze definovat tak, že napr. po zvoleném poctu neplatných pokusu generuje výstrahu a notifikacní pravidlo pak odešle zprávu (e-mail, SMS, InstantMessage)

Podrobné postupy pro ctyri scénáre jsou na stejném blogu DSE (Audit Alert Scenarios System Center Operations Manager (OpsMgr) 2007 R2):

  • Scenario 1: Alert for changes to the ‘Domain Admin’ group membership
  • Scenario 2: Alert when the Audit Policy is changed (Default Domain or Domain Controller)
  • Scenario 3: Alert when xx number of unsuccessful logons occur within nn hours
  • Scenario 4: Account locked out x number of times in a 24 hour period

5. Statistika událostí a výstrah (alert)

Pokud nás zajímá napr. pocet událostí ve zvoleném období pro vybrané servery, které generovaly výstrahu úrovne Critical / High, je to úkol pro reporty pracující s daty v data warehouse

Základní knihovny výstupu pomocí reportu jsou Generic Report + ODR Report Library: (ODR = operational data reports)

  image image

6. Historická data

Databáze SCOMu a ACS uchovávají data pouze stanovenou dobu. Mužeme ji prodloužit nebo zkrátit podle potreb našeho konkrétního provozu, ale po urcité dobe jsou data z databáze odstranena. Charakter použití pracovní databáze a data warehouse je rozdílný, na jedné strane jsou provozní data a informace o práve rešených problémech, takže doba jejich uchování jeden týden je ve vetšine prípadu dostatecná. Na druhé strane jsou data urcená k zobrazení v grafech a prehledových tabulkách, takže se v databázi udržují celý rok. Slouží k vykreslení trendu záteže, zaplnování disku, dostupnosti služeb v case. Rocní doba uchování dat je pro tento zpusob využití uložených informací rozumný kompromis a vyhovuje i použití výstupu v prehledech použitých v plánování rozvoje sledovaných systému.

Odlišný je charakter dat uložených v databázi ACS a charakter jejich využití. Informace zde uložené mají sloužit pro vysledování stop, které zanechá v systémech uživatel s nekalými úmysly nebo vysledování obecného bezpecnostního problému. Potom nemusí být standardní doba uchování dat (dva týdny) dostatecná. Prodloužením dosáhneme i nekolikanásobne delšího casového “okna”, ale jsou prípady, kdy je predpisy požadováno uchovat auditní informace i nekolik let. V takovém prípade nastupují rešení tretích firem, zde uvedu jen nejznámejší Secure Vantage a jejich Archiver. Zaznamenal jsem i rešení “uživatelské” – založené na pravidelném archivování databáze ACS, napríklad ve standardním dvoutýdenním cyklu. Požadovaná historická data se potom zprístupní v oddeleném databázovém systému a modifikací standardních reportu je možné v nich vyhledat žádanou informaci.

7. Demonstrace a vlastní zkušenosti se systémem SCOM

Pred casem jsem zde uvádel výber odkazu ze stránky MSevents, to jsem napocítal pouhé tri položky týkající se SCOM verze R2. Dnes je zde k dispozici nekolik virtuálních testovacích labu a dlouhá rada záznamu prednášek s vizuální demonstrací. Zvukové záznamy nepocítám. Vlastní zkušenosti získáte nejen v testovacím labu, který je vám k dispozici jeden a pul hodiny, ale také zkušební verzi Microsoft System Center Operations Manager 2007 R2 Evaluation Download – ta vám vydrží 180 dní.

Znacky Technorati: System Center Operations Manager,Audit Collection System