Task #520
closedVolitelný způsob logování pro klientskou knihovnu
Added by Pavel Kácha over 12 years ago. Updated about 12 years ago.
0%
Description
Kromě stderr i syslog - nutné navrhnout a vytvořit konfigurační volby (facility).
Related issues
Updated by Pavel Kácha over 12 years ago
- Due date set to 08/08/2012
- Assignee set to Jan Soukal
Nejprve tedy návrh. Bude vhodné i zvážit, zda nebude stačit jen jedna nějak přetížená direktiva.
Updated by Jan Soukal over 12 years ago
Logování¶
Standard error¶
- Logování na stderr zachovat implicitně.
- Výpis pouze při chybném ukončení klientské funkce (error hláška obsahující důvod chybného ukončení klienta. Rozšířené logování do Syslogu)
Syslog¶
- Implicitně vypnuto
- Řešit podobně jako logování u serveru (např. write2log())
Konfigurace¶
- Nastavení logování v konfiguráku, např.:
$ALLOW_SYSLOG = 1;
- Postačují úrovně 'error' a 'info' (taky možno nastavovat přes konfigurák, ale není to nutné)
- Dynamické požadavky na logování (např. další volby předané při volání klientské funkci) nejsou nutné
Facility¶
- Implicitně (při instalaci) "local7" - stejně jako u serveru
- V konfiguráku lze pak facility změnit, dle potřeby
$FACILITY = "local7";
TODO: Zbyva doplnit "logovací" fci (např. zmiňováná write2log()), která se postará jak o stderr tak i o zápis do Syslogu
Updated by Pavel Kácha over 12 years ago
Výpis pouze při chybném ukončení klientské funkce (error hláška obsahující důvod chybného ukončení klienta. Rozšířené logování do Syslogu)
Tomu úplně nerozumím. Co myslíš rozšířeným logováním? Že do syslogu půjde něco víc, než na stderr?
$ALLOW_SYSLOG = 1; $FACILITY = "local7";
Uživatel může chtít logovat do syslogu, a nelogovat na stderr (protože mu leze do výstupu jeho volající aplikace). Navíc časem můžeme chtít přidat i logování do jiného souboru, bez syslogu. Chtělo by to, aby konfigurace byla rozšiřitelná. Možnosti:
$LOG_STDERR = 1;
$LOG_SYSLOG = 1;
$FACILITY = "local7";
a třeba časem:
$LOG_FILE = 1;
$LOG_NAME= "/tmp/warden-errors.log"
Varianta je i využít jednu přetíženou direktivu (jmenné prostory jsou různé):
$LOG = [2, "local7", "/tmp/warden-errors.log", "/var/chroot/watch/warden-errors.log"];
s tím, že číslo je deskriptor (2=stderr), známé jméno facility znamená syslog, cesta znamená soubor.
Názory, pro, proti?
Updated by Pavel Kácha over 12 years ago
- Due date changed from 08/08/2012 to 08/22/2012
Updated by Jan Soukal over 12 years ago
Pavel Kácha wrote:
Výpis pouze při chybném ukončení klientské funkce (error hláška obsahující důvod chybného ukončení klienta. Rozšířené logování do Syslogu)
Tomu úplně nerozumím. Co myslíš rozšířeným logováním? Že do syslogu půjde něco víc, než na stderr?
V podstate ano. Resili jsme to s Tomem a vychazeli z predpokladu, ze na STDERR by mel jit asi jen error, ktery zhodil aplikaci. Prave proto (jak pises nize), aby se to nemotalo do volajici aplikace. Kdezto do Syslogu muze uzivatel chtit i rozsirujici informace (warningy, info, nekriticke chyby). Koneckoncu i my bychom to takto mohli chtit vyuzit v ramci backtracingu chyb (#522).
$ALLOW_SYSLOG = 1; $FACILITY = "local7";
Uživatel může chtít logovat do syslogu, a nelogovat na stderr (protože mu leze do výstupu jeho volající aplikace). Navíc časem můžeme chtít přidat i logování do jiného souboru, bez syslogu. Chtělo by to, aby konfigurace byla rozšiřitelná.
Uvazujeme-li v kontextu verze 2.1 (potazmo i budoucich) takto rozsahle (konfigurovatelne) vyuziti logovani, pak souhlasim.
Možnosti:
$LOG_STDERR = 1;
$LOG_SYSLOG = 1;
$FACILITY = "local7";a třeba časem:
$LOG_FILE = 1;
$LOG_NAME= "/tmp/warden-errors.log"
Ale co kdyz bude chtit uzivatel logovat napr. do vice souboru? (Recnicka otazka, priklonil bych se spise k variante nize.)
Varianta je i využít jednu přetíženou direktivu (jmenné prostory jsou různé):
$LOG = [2, "local7", "/tmp/warden-errors.log", "/var/chroot/watch/warden-errors.log"];
s tím, že číslo je deskriptor (2=stderr), známé jméno facility znamená syslog, cesta znamená soubor.
Pokud se vydame cestou konfigurovatelneho logovani, tak jsem pro variantu s pretizenou direktivou, jak jsi ji popsal. Nejsem si ale uplne jisty tim, ze neco takoveho aktualne (a v blizke budoucnosti) potrebujeme.
Pokud muzeme zit s jakymsi "zakladnim" logovanim chyb, pak bych sel cestou nejmensiho odporu:
$LOG_STDERR = 1; #kdo nechce STDERR, nastavi 0 $LOG_SYSLOG = 1; $LOG_FACILITY = "local7";
Updated by Pavel Kácha over 12 years ago
- Status changed from New to Feedback
Máš pravdu, přílišná obecnost je drahá. Uděláme to podle Tvého posledního návrhu. I přesto ještě - byl bych pro cíle logování sjednotit alespoň pomocí například:
$LOG_STDERR = 1; #kdo nechce STDERR, nastavi 0 $LOG_STDERR_VERBOSE = 0; # 0 = základní, jako v současné době $LOG_SYSLOG = 1; $LOG_SYSLOG_FACILITY = "local7"; $LOG_SYSLOG_VERBOSE = 1; # 1 = debug, s backtrackem, etc.
V testovacích setupech lidi nemusí vůbec mít syslog, ale rádi by se třeba dozvěděli i rozšířený debug. Je to takle ještě vcelku jednoduché, a kód se k oběma logovacím cílům může chovat stejně. Co myslíš?
Updated by Pavel Kácha over 12 years ago
- Due date changed from 08/22/2012 to 08/29/2012
A ať nezdržujeme dalšími latencemi - jestli nejsi zásadně proti, pust se do toho.
Updated by Jan Soukal over 12 years ago
Pavel Kácha wrote:
A ať nezdržujeme dalšími latencemi - jestli nejsi zásadně proti, pust se do toho.
Pracuju na tom. Vzhledem k tomu, ze se de facto tento ukol spojil v jedno s #522, komentare pridavam tam.
Updated by Jan Soukal about 12 years ago
- Status changed from Feedback to Resolved
Updated by Pavel Kácha about 12 years ago
- Status changed from Resolved to Closed