Uvnitř systému se děje daleko víc věcí, než je vidět na venek. Výsledek každé akce, a je jedno jak je důležitá nebo jestli byla dokončena úspěšně, je zapisován do log souborů na serveru kde se událost stala. Soubory takového protokolu jsou lidským okem normálně čitelné, takže víme kam se podívat, když se něco děje. Nás bude zajímat hlavně SharePoint svět a tady se těmto logům říká všelijak: ULS logy, trace logy, diagnostické logy nebo SharePoint logy, ale jejich účel je vždycky stejný.

Řekněme, že se uvnitř mého systému stalo něco zlého a ještě nevím co. Jak se dostanu k logům?

Představu o tom, co se stalo, můžeme mít hned z několika různých míst, nicméně pro začátek pro nás budou důležité především ULS logy a Event logy. V kterém z nich své události najdete a jak moc Vám toho řeknou (jak moc podrobné budou) závisí hlavně na nastavení logování v Centrální Správě (Monitoring > Reporting > Configure Diagnostic Logging), ale obecně platí, že ULS logy jsou obvykle podrobnější a úplnější, než Event logy. Jak je Vaše prostředí nastaveno si můžete ověřit i PowerShell Get-SPDiagnosticConfig příkazem, který Vám zobrazí informace o nastavení probíhajícího logování.

ULS Logy jsou ukládané systémem jako textové soubory standartně v adresáři: C:\Program Files\Microsoft Shared\Web Server Extensions\1x\LOGS, kde „x“ můžete nahradit číslem 4 pro SP 2010 nebo číslem 5 pro SP 2013 a otevřít je můžete v poznámkovém bloku, který je standartně součástí každého Windows operačního systému nebo v programu k tomu určeném – ULS Viewer, LogViewer, Diagnostic Studio​ apod.

Všechno uvnitř složky LOGS má svůj řád. Jméno souboru se skládá z názvu serveru, data a času jeho pořízení ve tvaru SERVER-rokměsícden-hodinaminuta (24 hodinový formát) a každý řádek uvnitř se skládá z časového razítka, názvu procesu, kategorie, Correlation ID, EventID čísla a textu samotné zprávy, která je pro nás často to nejzajímavější.

Event logy jsou spravovány nástrojem jménem Prohlížeč událostí, který je také standartní součástí každého Windows Operačního systému, nicméně loguje události důležité pro chod celého serveru, ne jen pro SharePoint. Každá událot uvnitř je buď informace, úspěšný nebo neúspěšný výsledek nějaké akce, varování nebo chyba a řádky logu se skládají z Event ID čísla, kategorie, zprávy, zdroje, časového razítka a uživatelského účtu nebo účtu počítače.

Dobře, log co mě zajímá už mám. Jak z něj vyčtu co se stalo?

Uvnitř logů nás v drtivé většině případů zajímá (kromě časového razítka) jen Correlation ID, Event ID nebo tělo zprávy. U každého z těchto tří pojmů se na chvilku zastavím, protože jsou pro další čtení docela důležité.

Correlation ID je v rámci jednoho prostředí (jedné farmy, a vzhledem k počtu kombinací znaků, které jej tvoří, i v celém známém vesmíru) unikátní, systémem generovaný řetězec znaků, který se objeví (pouze v ULS logu) pokaždé, když se stane něco mimořádného. Vypadá zhruba takto: e0549923-f627-49cc-820c-04f95e690200 a poprvé jsme se s ním mohli sektat až u SP 2010, takže je to věc relativně nová, nicméně nesmírně užitečná. Proč? ID je generováno zpětně vždy pro celou sadu událostí které vedly až k chybě zobrazení na naší obrazovce, nejde tedy jen o jeden řádek v logu s konečným výsledkem. Hned jak se objeví, zkopírujte ho do schránky (bez mezery na konci) a koukněte do logů co se vlastně skutečně stalo, protože klasické zprávy typu “Unknown Error”, “Unexpected Error” nebo “Something went wrong” nám bohužel nic neřeknou.

Event ID vypadá trochu jinak v ULS lozích a jinak v Prohlížeči událostí, nicméně tady žádnou unikátnost nehledejte. Event ID v záznamech v Prohlížeči událostí je pro každý druh akce a skrz všechna prostředí vždy stejné, ať už se chyba stala včera nebo před hodinou a jde v principu o jeden set tří až čtyř čísel (Prohlížeč událostí) nebo znaků (ULS logy), který vypadá zhruba takto: Event  ID 6644 nebo Event ID fbv7. Jako pomůcka při hledání je oEvent ID dost starší než Correlation ID. Na jednu stranu je to dobré, že je Event ID pokaždé stejné, protože stačí otevřít Google, napsat číslo chyby a v drtivé většině případů najdete i řešení, nicméně na druhou stranu si musíte uvědomit, že tyhle zprávy jsou jen následek a jejich příčina bývá často úplně někde jinde, než se na první pohled zdá.

Jak v log souborech najít příslušnou chybu?

V případě, že pátráte po konkrétní chybě pomocí zkopírovaného Correlation ID a nemáte k dispozici žádný nástroj třetí strany, otevřete LOGS složku, najděte soubor s přibližně odpovídajícím datem a časem chyby, která Vás zajímá, otevřete ho v poznámkovém bloku a pustťe se do hledání.

V případě, že jste našli chybu v Prohlížeči událostí a víte jak na ni zareagovat, máte vyhráno. Pokud si nejste jisti co znamená, zkuste najít její její popis na TechNetu nebo kdekoliv v Interntu pomocí Vašeho oblíbeného vyhledávače.

Hledáte konkrétní Correlation ID, ale nevíte který ze souborů Váš problém ukrývá a nechce se Vám otevírat jeden po druhém? Zkuste PowerShellový příkaz Merge-SPLogFile, který projde všechny dostupné logy a výsledek hledání vypíše do souboru, který si pak můžete prohlédnout zas obyčejným poznámkovým blokem nebo ULS Viewerem. Příkaz je dostupný pro SP 2010 i 2013 se zadává ve tvaru:

Merge-SPLogFile -Path „C:\CorrIDerror.log“ -Correlation „5ca5269c-8de5-4091-3f1b-f179af4d5121“


Druhý takový užitečný je Get-SPLogEvent​, který prohledá aktuální soubor logu a vypíše všechny záznamy související s Correlation ID, které jste zadali. Zapisuje se ve tvaru:

Get-SPLogEvent | ?{$_Correlation -eq „5ca5269c-8de5-4091-3f1b-f179af4d5121“ }

Nemusíte se však omezovat jen na konkrétní ID, dobře funguje také pro „Level“ (vážnost) zaznamenané zprávy:

Get-SPLogEvent -MinimumLevel „Unexpected“

Pokud chcete výsledek jako textový soubor a ne jen text v příkazovém řádku, doplňte na konec příkazu řetězec Format-List > C:\CorrIDerror.log.

Jestli máte k dispozici ULS Viewer, LogViewer nebo jiné nástroje jim podobné, budete mít hledání o něco jednodušší. Otevřete kterýkoliv z nich, přetáhněte dovnitř libovolný počet souborů co Vás zajímají (protože díky těmto nástrojům můžete pracovat s více jak jedním souborem najednou a klidně z několika různých serverů farmy najednou) a začněte s hledáním. Oba výše zmíněné programy Vás dokonce samy upozorní na nejkritičtější části logu podbarvením řádků nebo bublinovou zprávou a neskutečnou výhodou při hledání je možnost rychlého filtrování podle kteréhokoliv z atributů (sloupců) logu, export vybraných položek nebo real-time „odchytávání“ logů. Ani jeden nástroj sice není firmou Microsoft oficiálně podporovaný, nicméně velmi často doporučovaný.

Chybu jsem našel a vím jak ji opravit.

Super, pokud víte čím byla chyba způsobena a jak ji opravit, Vaše hledání končí. Spousty zpráv nám opravdu něco řeknou, jako například tato o chybějícím jazykovém balíčku pro jeden z nainstalovaných produktů:

Failed to open the file ‚C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Resources\ProjectResources.en-US.resx‘.
#20015: Cannot open „“: no such file or folder.
(#2: Cannot open „“: no such file or folder.)

Stačí balíček do „Resourcers“ složky dohrát a všechno zase bude v pořádku.

Chybu jsem našel, ale text zprávy mi nic neříká. Co s tím?

Jsou zprávy, které nás navedou na řešení hned a jsou zprávy naprosto nic neříkající. Jestli si ani po prohlédnutí logů nejste jisti co se stalo a jak chybu opravit, otevřete Váš oblíbený vyhledávač a zkuste chvíli pátrat po Internetu. Pro pořádek dodávám, že článků vždycky zkuste otevřít více, než se pustíte do oprav. Nesnažte se zkoušet to co najdete hned v tom prvním a přemýšlejte o tom, co děláte. Rozhodně není potřeba pro nefunkční BLOB cache spouštět PSConfig nebo pro nenahranou fotku v profilu mazat Config Cache. I Internetem kolují nesmysly.

Tip: Pokud jen proaktivně kontrolujete zdraví Vaší farmy, můžete si každodenní práci usnadit když si vyrobíte vlastní filtr v Prohlížeči událostí co bude monitorovat jen zprávy určité závažnosti nebo určitého zdroje a nebo můžete hlídat sloupec „Level“ ULS logů, zda neobsahuje klíčové slovo „Error“ nebo „Unexpected“.