[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian systemd maintainer resigns due to online bullying + risultati votazione DD



On 21/11/2014 21:40, Alessandro Pellizzari wrote:
Il Thu, 20 Nov 2014 22:37:40 +0100, Davide Prina ha scritto:

ma queste sono ricerche approssimative, che non ti permettono di trovare
sempre ed esattamente e solo quello che cerchi... questo se sai cosa
cercare. Se non lo sai le cose si complicano parecchio (es: vuoi vedere
se c'è l'indizio di qualche possibile problema futuro)

Se usi i tuoi occhi, è facile farsi sfuggire qualche informazione
"interessante", quando le righe da guardare sono davvero tante.

Scusate, non riesco a seguire tutto il thread, che sta diventando
parecchio lungo.

a chi lo dici, poi in questi giorni non ho molto tempo e alcune risposte non riesco neppure a leggerle :-(

Ma mi pare che si dimentichi qualcosa. I log, per la maggior parte del
tempo, vengono solo scritti.

vero, ma il loro unico scopo è quello di poter essere letti/analizzati :-)

Nel momento in cui ho un DDoS, o anche solo un periodo molto buono per la
mia webapp, mi può capitare che il server scriva qualche migliaio di
righe al secondo, anche per diversi minuti o ore di fila.

Con un log indicizzato, il processo di log mi porta via più risorse
(perché è in scrittura) di quante ne porti via l'app in sé, ammazzandomi
il server. Se invece si limita a scrivere righe alla fine di un file di
testo, il carico è praticamente nullo (soprattutto se uso un disco
dedicato).

questo lo dici perché ti è capitato? Non penso...
Ora visto che avete così tante domande perché non le chiedete direttamente ad esempio a quelli che hanno creato systemd, così avrete delle risposte più appropriate e un caso d'uso reale.

Quello che posso dire io è che:

1) puoi avere delle riche simili a questa:
Nov 23 08:51:33 NOMEMACCHINA kernel: [ 4732.582919] [UFW BLOCK] IN=eth1 OUT= MAC=50:e6:ba:10:2e:f1:01:0c:f6:ab:17:aa:08:00 SRC=215.92.8.5 DST=10.0.0.221 LEN=1500 TOS=0x00 PREC=0x00 TTL=54 ID=58079 DF PROTO=TCP SPT=80 DPT=37262 WINDOW=292 RES=0x00 ACK URGP=0

se usi un file di log testuale ti viene buttato su di esso tutto, naturalmente con cache che va a scrivere solo quando la cache è piena. Però ogni riga sono 258 byte, se ne ricevi anche solo 1.000 al secondo sono già circa 250 KByte al secondo... il che vuol dire che il tuo log viene scritto più volte ogni secondo. Solo questo può rallentarti il sistema.

se invece viene usato un log binario può essere che quei 258 byte vengano ridotti notevolmente perché se l'indirizzo di provenienza è lo stesso possono cambiare 2-3 parametri, se l'indirizzo è diverso ne possono cambiare 4-5. Questo vuol dire che l'informazione necessaria a registrare ogni singolo evento può essere ridotta drasticamente a 10-15 byte... quindi a parità di cache puoi avere 1/20 di scritture.
Poi, in teoria, è possibile fare anche meglio.

2) Poi, se io devo gestire un log binario indicizzato posso far sì che l'indicizzazione venga calcolata solo se il sistema è scarico o tramite nice o se c'è una richiesta di lettura del log...

L'analisi dei log può essere fatta in differita (per farmi un report
giornaliero) tramite script. E la volta che devo cercare qualcosa di
anomalo a una certa ora, averlo binario o testuale, cambia poco.
Ma se è binario e devo cercare qualcosa che non è previsto da chi ha
progettato la struttura dei log, la decodifica da binario per poi
passarlo
a grep o chi per esso è solo un peso in più.

un attimo, qui si sta dicendo che chi crea/gestisce i log li crea in binario e quindi è lui che è in grado di leggerli e di presentarteli.

Tra l'altro, un sistema tipo database potrebbe essere più efficiente, in
lettura, solo se gli eventi venissero codificati in qualche modo (tipo:
postfix codice 15, SMTP connection received codice 1, campo testuale per
il mittente e il destinatario).

infatti è quello che ipotizzavo anch'io

Ma allora ci mettiamo a codificare le centinaia di errori di ogni
programma? Poi finiamo con "l'applicazione 0x123456abc ha provocato un
errore 0x63bd467a" :P

se ogni applicazione definisce i tipi di errore che può generare hai risolto il problema :-)

Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
Database: http://www.postgresql.org
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook


Reply to: