Project

General

Profile

Actions

Task #520

closed

Volitelný způsob logování pro klientskou knihovnu

Added by Pavel Kácha about 12 years ago. Updated almost 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Jan Soukal
Category:
-
Target version:
Start date:
07/30/2012
Due date:
08/29/2012
% Done:

0%

Estimated time:

Description

Kromě stderr i syslog - nutné navrhnout a vytvořit konfigurační volby (facility).


Related issues

Related to Warden - Task #522: Log/backtrace při chybě klientské knihovnyClosedJan Soukal08/13/201208/29/2012

Actions
Actions #1

Updated by Pavel Kácha about 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.

Actions #2

Updated by Jan Soukal about 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

Actions #3

Updated by Pavel Kácha about 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?

Actions #4

Updated by Pavel Kácha about 12 years ago

  • Due date changed from 08/08/2012 to 08/22/2012
Actions #5

Updated by Jan Soukal about 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";

Actions #6

Updated by Pavel Kácha about 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íš?

Actions #7

Updated by Pavel Kácha about 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.

Actions #8

Updated by Jan Soukal about 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.

Actions #9

Updated by Jan Soukal almost 12 years ago

  • Status changed from Feedback to Resolved
Actions #10

Updated by Pavel Kácha almost 12 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF