Data mají příběh, který mohou vyprávět
- Posted by Jana Babáčková
- On 1.10.2015
- 0
SharePoint 2013 už je nějaký ten pátek na trhu a všichni víme, že jeho architektura přinesla několik více či méně zásadních změn, mezi které paří také Analýzy využívání webů. Veškeré analýzy jsou teď součástí servisní aplikace vyhledávání a i když se logicky dělí do dvou hlavních kategorií „Search Analytics“ a „Usage Analytics“ už jen těžko můžeme fyzicky oddělit jednu službu od druhé tak, jako to kdysi uměl SharePoint 2010. A ono to v tomhle konkrétním případě není vůbec na škodu.
„Search analytics“ analyzují indexovaný obsah a „Usage Analytics“ způsob, jakým uživatelé pracují s obsahem. Počítáme tedy zobrazení a otevření každé položky uvnitř portálu, sledujeme relevantnost výsledků vyhledávání, identifikujeme nejaktivnější uživatele nebo nejvíce užitečný obsah, hledáme opakující se vzorce v tom, co lidé hledají a jak často hledají, abychom jim mohli příště doporučit to, co potřebují. Z hotových reportů se můžeme také dozvědět jak je to s návštěvností našich stránek, oblíbeností blogů, které stánky je lepší smazat nebo kde je potřeba zapracovat na aktualizacích, ale kdo měl už někdy v minulosti tu možnost podívat se jak pracují Google Analytics, ten bude stejně zklamaný…
Vždy, když otevřete nějaký soubor, najdete soubor prostřednictvím vyhledávací služby a nebo začnete sledovat nějaký obsah funkcí „follow“, systém si všechno poznamená.
Sledování („follow“) dokumentů
Výsledky celé téhle práce pak najdeme na mnoha místech portálu:
Například při práci s reporty
A nebo při vyhledávání, které řadí výsledky nejen podle relevantnosti, ale také popularity
Nebo při práci se „Search-Driven“ web party
…a tak dále.
Na úvod by možná jestě stálo za to vysvětlit, jak je to s tou popularitou. Je celkem logické, že čím je dokument starší, tím víc šancí jsme měli na něj behěm jeho života klikout a tak se pravděpodobně zařadí na stránce s výsledky výš, než dokument, který jsme vyrobili včera. I tohle jde však do jisté míry ovlivnit pomocí nejrůznějších nástrojů vyhledávání, o kterých budeme mluvit někdy příště (query rules & promoted results, best bets, keywords a pod.) Popularita se opravdu počítá jen na základě kliků, otevření nebo doporučení.
Jak to celé funguje? Pokud je analytické logování zapnuto a nastaveno, stačí jen chvíli počkat než uživatelé otevřou několik prvních dokumentů a můžeme začít sbírat data. „Usage Analytics“ statistiky, tedy adresy, uživatelská jména a časová razítka se ukládají nejdříve do podoby fyzických souborů na discích web-front-endů (tzv. Event Store), odkud si je bere „processing“ komponenta, která má hned několik funkcí – třídí sesbíraná data podle nějakých předem připravených pravidel, přesouvá zpracovaná data do odpovídajících destinací (Analytics Reporting db, Index) a zároveň čistí z databází vše, co má časové razítko starší, než „retention interval“ nastavený v administraci Centrální správy (standartně 14 dní). „Search Analytics“ statistiky se sbírají z ULS logů „…15\LOGS“ složky, odkud si je opět přebírá „processing“ komponenta a zpracovává je velmi podobným způsobem jako v předchozím případě, jen databáze jsou tentokrát dvě: Analytics Reporting & Search Link db.
Event store
…\15\LOGS
Diagnostické logy (ULS) a logy z analýz sdílejí jednu a tu samou složku. Pokud chcete odsunout analýzy pryč, můžete otevřít Centrální správu nebo použít PowerShell příkaz „set-SPUsageService“, pokud chcete odsunout ULS logy pryč, můžete opět použít Centrální správu nebo PowerShell a příkaz “set-SPDiagnosticConfig“.
To byly fyzické soubory na disku. Teď databáze. Struktura analytické databáze (standartně WSS_UsageApplication) vypadá na první pohled docela složitě, protože se tu každý sledovaný parameter dělí do tabulek s dovětkem partition0 až partitionN (10, 13 i 19) a jedině jejich sloučením dostaneme data za danou kriterii všechna, nicméně i na to vývojáři mysleli a připravili nám rozumně pojmenované pohledy („database views“).
Co všechno sbíráme do logů (a jak dlouho informace uchováváme) si můžeme zkontrolovat následujícím jednoduchým PowerShell příkazem „Get-SPUsageDefinition“
Co je na seznemu se statusem „Enabled“, to sbíráme. Sloupeček „Retention“ pak říká, kolik dní takovou informaci uchováváme. Standartní interval uchovávání dat je nastavený na 14 dní. Pokud chceme cokoliv ze zobrazeného listu změnit, stačí vyměnit sloveso „get“ za „set“ s kouzelným parametrem „DaysRetained“ jako na příkladu níže:
Set-SPUsageDefinition –Identity „Page Requests“ –DaysRetained 3
Sbíraná data plní databáze a disky serverů, možná nepotřebujete úplně všechno, co je na seznamu. Nebo to nemusíte držet v databázích tak dlouho, jak se píše. Pokud chcete přestat sledovat data pro kteroukoliv z kategorií jednou pro vždy, jednoduše nastavte „Retention“ interval na „0“. Pozor, změny se projeví až po spuštění obou služeb, které se o sběr dat a analýzy starají:
- Microsoft SharePoint Foundation Usage Data Import
- Microsoft SharePoint Foundation Usage Data Processing
Obě najdete v administraci Centrální správy pod sekcí Sledování > Konfigurace shromažďování dat a využití stavů > odkaz Plán sběru protokolů (a protože je ten český překlad naprosto příšerný, raději přidávám cestu k oběma službám ještě v angličtině: Monitoring > Configure Usage & health data collection > Log Collection Schedule).Výsledek analytické práce si můžete prohlédnout pomocí obyčejného Excelu, pro který je připraveno několik základních reportů na úrovni webu i kolekce.
No není to ta nejhezčí věc na světě… Ale po drobných úpravách stylů z toho nakonec může být docela pěkný report i pro vedení. Důležité je, že to všechno funguje víceméně automaticky bez nutnosti našeho zásahu. V některém z příštích dílů si pak ukážeme, jak takové statistiky „číst“ a jak do nich zakomponovat také monitorování systému (CPU, pamět, procesy, zápisy na disk apod.), s trochou toho PowerShellu.
0 comments on Data mají příběh, který mohou vyprávět