Re: Debian systemd maintainer resigns due to online bullying + risultati votazione DD
Il Sun, 23 Nov 2014 20:35:45 +0100, Davide Prina ha scritto:
> On 21/11/2014 21:40, Alessandro Pellizzari wrote:
>> 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.
> questo lo dici perché ti è capitato? Non penso...
Non in produzione, ma mi è capitato più volte in staging.
Una volta il tail -f in locale ha continuato a scrollare per 3 minuti
buoni dopo che la chiamata al webservice era finito. :)
> 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.
Il mio era un discorso generico riferito alla tua idea di indicizzare i
log durante la scrittura. Che non è sbagliata come idea, ma ha delle
controindicazioni la cui unica soluzione è mandare pacchetti udp a una
batteria di server per il logging
> 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.
Sì, ma è flessibile. Il tuo è un caso molto particolare di log
(iptables),
ma il formato dei log varia tantissimo.
Senza considerare che qualsiasi app può mandare un messaggio al syslog
tramite una syscall, specificando solo il level e il messaggio.
A quel punto il sistema di logging deve anche parsare il messaggio per
vedere se riesce a capire come encodarlo in binario.
L'alternativa sarebbe, con però modifiche sostanziali alle syscall per i
log, salvare i dati in un DB NoSQL tipo mongodb, redis o couchdb.
Ma allora a quel punto uso un server di log esterno. :)
> 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.
Non puoi rendere stateful un log. Ogni riga dovrebbe essere indipendente
dalle precedenti, a meno che non sia identica (e infatti syslog, se
arrivano n messaggi identici in meno di un secondo scrive "n identical
messages".
Se rendi stateful per messaggi non identici, basta che per qualsiasi
motivo manchi una riga o anche solo un byte e il log non ha più senso.
>> 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.
Sì, ok. Ma se il tool in oggetto non è in grado di darmi certe
informazioni (vuoi perché il log è creato dalla mia app o da un'app che
lui non conosce) devo farglielo decodificare e mandare in pipe a un mio
script che lo analizza. A quel punto non solo ho il carico del mio
script, ma anche quello della decodifica.
> se ogni applicazione definisce i tipi di errore che può generare hai
> risolto il problema :-)
Che è meno semplice di quanto possa apparire :)
Pensa alle app in Java (o in Python, Ruby o PHP) e ai loro backtrace.
Bye.
Reply to: