Navigace:  MobilChange™ - Dokumentace > Administrace a funkčnost MobilChange™ > Monitorování systému > Aplikační logy >

Obecná pravidla

Předchozí stránkaDomůDalší stránka

knihaUmístění a názvy aplikačních logů

listStandardní úroveň logování

 

provozní záležitosti ukládány do textových logů, které ovšem nepopisují změny konfigurací, ale spíše co reálně v daný okamžik který proces dělá) které jsou spíše určeny pro případné hledání provozních chyb a problémů. Nemáme seznam hlášek které se v těchto lozích mohou objevit a myslím že ani není možné jej vytvořit neb se mění podle jednotlivých komponent a hlavně interakce jejich okolí, např pokud operátor zapíše při pokusu o odeslání chybovou/stavovou hlášku je tam uložena tak jak ji poslal operátor. V konfiguraci nastavená úroveň říká OD které úrovně výše budou inforace do textových logů ukládány. Např je-li nastaveno  WARNING, budou se ukládat informace typu WARNING, ERROR, a FATAL ale NE  INFO a DEBUG.

Pojmenování textových logů vychází z pravidel :

 

Standardní pojmenování souborů

Po standardní instalaci musí komponenty logovat do těchto souborů:

Systémové komponenty:

%DatasysUms%\Log\%Komponenta%\%Program%_%d.log

Skripty MX aplikací:

%DatasysUms%\Log\MobilChange\Script\%Program%_%d.log

Uživateslké komponenty:

%Local AppData%\Datasys\Ums\Log\%Komponenta%\%Program%_%d.log

kde

%DatasysUms% je instalační cesta (typicky C:\Program Files\Datasys\Ums\).

V instalátoru je cesta "%DatasysUms%\Log\" dostupná pomocí "UmsSetupLibrary.Pathstorage.CommonLog.Destination" a při konfigurování instalovaných komponent je vhodné ji používat.

%Local AppData% je cesta pro lokální (neroamující) uživatelská aplikační data (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Local AppData)

v C++ je možno ji zjistit pomocí

SHGetSpecialFolderPath(NULL,buf,CSIDL_LOCAL_APPDATA,TRUE);

v .Net pomocí

Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)

%Komponenta% je jméno komponenty UMS (CallChange, FaxChange, MobilChange, VoiceChange nebo Common pro společné části)

%Program% je jméno programu (nebo skriptu), ke které log patří.

Příklady pojmenování logů dle těchto pravidel pro systémové komponenty:

C:\Program Files\Datasys\Ums\Log\Common\SmtpReceiver_%d.log

C:\Program Files\Datasys\Ums\Log\CallChange\CcRouter_%d.log

C:\Program Files\Datasys\Ums\Log\FaxChange\FxServer_%d.log

C:\Program Files\Datasys\Ums\Log\MobilChange\MxKernel_%d.log

C:\Program Files\Datasys\Ums\Log\MobilChange\Script\mx_mcfo_%d.log

C:\Program Files\Datasys\Ums\Log\VoiceChange\Line0_%d.log

 

Kódování

Logy by měly být kódovány v UTF-8 (včetně BOM signatury na začátku souboru).

Úrovně logování

Je-li v konfiguraci nastavena úroveň logování na některou z níže uvedených hodnot, jsou do textových logů ukládány hlášky které jsou rovny nebo vyšší nastavené hodnotě.

Úroveň

Význam

Typické použití

FATAL

Chyby bránící v korektním běhu aplikace

Chybná konfigurace. Např. chybí povinné položky, hodnoty jsou mimo povolený rozsah či jsou jinak neplatné.

Byla detekována interní chyba aplikace. Například program zjistil, že není splněna nějaká podmínka, která by, pokud by v programu nebyla chyba, splněna být měla (assert).

Problém s nedostupností klíčového zdroje, pro který není v programu definováno nouzové chování. (Dle typu programu to může, ale také nemusí být např. málo paměti, nedostupná databáze, nečekané chyby při zápisu na disk apod.)

Po zalogování této hlášky se typicky aplikace okamžitě ukončuje. V některých případech ale může být rozhodnuto, že např. i některé interní chyby aplikace (nečekané výjimky plynoucí obvykle ze zapomenutého ošetření nějakého výjimečného stavu) budou řešeny bez ukončení aplikace, že se například pouze zahodí jedna zpráva, při jejímž vykonávání k neošetřené chybě došlo.

ERROR

Chyby, pro které je definováno nouzové chování

Nedostupný či špatně pracující zdroj (například databáze, disk, jiná služba), pro který je definováno nouzové chování (např. pokus se bude opakovat, nebo požadavek nebude splněn a chyba bude propagována tomu, kdo po aplikaci operaci požadoval apod.)

Po zalogování této hlášky typicky aplikace právě zpracovávaný požadavek buď zahodí, nebo se ho pokusí zopakovat později.

WARNING

Neplatná vstupní data

Informace o odmítnutí provedení nevalidního požadavku.

Informace o zpracování (či ignorování) nevalidních zpráv.

Informace o zpracování (či ignorování) neplatných údajů zadaných z UI.

INFO

Základní úroveň

V této úrovni je logována naprostá většina informací.

V této úrovni jsou aplikace provozovány v ostrém provozu.

V úrovni INFO by log neměl být zaplaven periodickými hlášeními typu "ověřuji frontu požadavků - je prázdná", "ověřuji, zda se nemám ukončit - nemám" apod., která se logují, i když se zrovna nic zajímavého neděje. Tato hlášení znepřehledňují log a proto se primárně zapisují do DEBUG.

Je ale vhodné takové zprávy zalogovat jako INFO při jejich prvním výskytu a následně v dostatečně dlouhých intervalech (např. po jedné hodině), aby bylo i z INFO zřejmé, že tato činnost stále probíhá a aplikace žije.

DEBUG

Periodická hlášení

V této úrovni by měly být pouze hlášení, která při ostrém provozu není vhodné logovat. Vše ostatní má být již v úrovni INFO. Do DEBUG patří:

Periodická klidová hlášení typu "nic se neděje". Pokud se nic neděje, v úrovni INFO by měl být log (téměř) prázdný a teprve v úrovni DEBUG je vidět, že aplikace se neustále snaží kontrolovat, jestli by něco dělat neměla. (Viz též informace u úrovně INFO)

Přijímaná a odesílaná data se typicky logují již úrovni INFO, protože jsou nezbytná pro dohledávání provozních problémů. Ale pokud jsou v úrovni INFO data nějak zkracována (např. se loguje maximálně 2000 znaků), pak v úrovni DEBUG může být vhodné do logu psát data celá. V takovém případě by měla být data zapisována do logu pouze celá, nikoliv jednou zkráceně a podruhé nezkráceně.

 

 

V zapsaném logu by mělo být na každém řádku uvedeno do které úrovně tento záznam spadá, tedy např:

 

2013-11-05 00:08:02,727 [7] DEBUG MXLineEMIConnector [linka] - EMI alert message was sent.

2013-11-05 03:02:33,392 [10] ERROR MXLineDbDriver [linka] - Cannot read from table MX_SMS_INQUEUE (line linka): A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.)

2013-11-05 03:03:44,883 [1] INFO  MXKernel [(null)] - MX kernel started with commandline: "C:\Program Files (x86)\DATASYS UMS\MobilChange\bin\MXKernel.exe" line linka