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