L'evoluzione dell'analisi dei log

Di analisi e di cose for real se n'è viste ben poche. Mi spiace ammetterlo ma questo talk, per come l'ho percepito io, m'è sembrato una marketta bella e buona.

Mi tocca concordare con dlondero. Speaker sicuramente preparati; che - a quanto è sembrato - hanno avuto a che fare con parecchi tipi di database NoSQL (utili se non altro le citazioni ai tool usati). Sarebbe stato però bello se le competenze acquisite dagli speaker si fossero trasformate in trasferimento di conocenza per la platea, anzichè in una carellata di "abbiamo fatto questo; poi questo, e anche questo": Con qualche - ancor più frustrante: "ecco, questo l'abbiamo fatto noi; ma non lo rilasciamo Open Source". La parte FOR REAL è completamente mancata, soprattutto relativamente all'analisi dei Log, su cui almeno un cenno mi aspettavo, considerato il titolo del talk. Anche a causa di un timing non proprio perfetto - che ha causato un aumento di ritmo alla fine della presentazione (forse sulle parti più interessanti?) - oltre che di qualche affermazione per lo meno discutibile ("speriamo XML muoia; tutto si può fare con JSON...") si è - per quanto mi riguarda - trattato dell'intervento più deludente della giornata. Sono sicuro il potenziale degli speaker ci sia; ma che si debba cercare di tenere maggiormente in considerazione le attese e le aspettative della platea, più che essere visibilmente bramosi di elencare i propri successi professionali.

Accetto le critiche e vorrei fare un paio di chiarimenti, poichè spesso ci sono delle incomprensioni.
Il nostro obiettivo era fornire delle idee e soluzioni per "vere" che abbiamo incontrato/sviluppato e sono in produzione con una serie di "consigli" su come sopravvivere all'integrazione di prodotti NoSql.
Se riguardi le slide (titoli "self note" e ricette Problemi/Soluzioni alla fine) vedrai una serie di problemi e soluzioni, che ti aiutano a scalare e evitare tranelli nella gestione dei dati.
Il nostro concetto di trasferimento di informazioni era mirato a fare capire che le soluzione NoSQl non sempre sono la soluzioni ai problemi e tal volta come altri speaker hanno detto più volte "la soluzione NoSQL te la sposi". Ciò implica che occorre avere profonda conoscenza di tali strumenti perché:
- sono carenti ("Some base functionalities, but a lot of missing features")
- le necessità di sviluppo/utilizzo nella pratica spesso si discostano da quelli dalla vision di chi li ha progettati ("There are divergent choices between developers and the company’s needs")
- quante volte gli altri speakers hanno detto che non solo la soluzione a tutto ("There’s no any “Best NoSQL Solution” at all")

Tutto dipende dalla posizione nel famoso grafico che è stato più volte mostrato da Lana. Noi (io, Flavio e gli altri miei compagni di lavoro) per costrizioni e tempi siamo dopo la delusione: siamo nel punto in cui facciamo funzionare le cose, abbiamo vivisezionato i tools (io elasticsearch, Flavio mongodb), abbiamo appreso i pregi delle architetture ed i loro difetti, come "le cose funzionano".
Non capisco la frase "ecco, questo l'abbiamo fatto noi; ma non lo rilasciamo Open Source", visto che abbiamo presentato per prima cosa i progetti che noi stessi abbiamo rilasciato per la comunità e che sono usati da molti. Esistono diversi motivi per cui invece altro codice non è stato rilasciato alla comunità quali:
- materiale copyright delle azienda (spetta al proprietario dell'azienda la decisione e non a noi: lui ci paga gli stipendi)
- io parlo frequentemente con Shay Banon: l'autore di ElasticSearch e certe feature che abbiamo implementato in azienda sono rischiose per gli "utonti" che userebbero il sistema (ElasticSearch è basato su Lucene: sai ciò che implica).
- altre sono talmente custom che altri non se ne farebbero niente (legate troppo alle strutture dati aziendali LDAP, Databases, ...)
Il nostro spirito è sempre di poter condividere con la comunità se no non avremmo mai condiviso così tanti progetti su mongodb e ES. Se gestisci progetti su codice opensource sai l'importanza sulla mantenibilità e come essa passi dallo sharare il codice.

Sulla parte dei log, abbiamo preferito parlare dell'architettura, delle lezioni imparate, di come approcciarsi al mondo NoSQL; piuttosto che mostrarti come interpretiamo un log di Apache. Abbiamo avuto un approccio più sul mostrare come poterlo fare a livello di tools, che sul come farlo fisicamente il codice.

Il tempo è stato tiranno, forse sarebbe stato necessario fare due talk.

Per quanto riguarda XML vs JSON, nella gestione dei dati, il mondo va verso il JSON per vari fattori: compatezza, idempotenza con XML, performance in parsing/writing. Negli anni precedenti, c'era il processo che tutti i dati erano strutturati, XML, ora JSON e YAML è evoluzione. Senza dubbio a parte vari settori (Semantica), XML può essere usato idempotente a JSON: e viene usato JSON, lo dimostrano il fatto che tutti i nuovi sistemi NoSQL usano JSON come base. I dati sono JSON.

Purtroppo hai perfettamente ragione sul fatto che sul "cercare di tenere maggiormente in considerazione le attese e le aspettative della platea", ma non conoscevamo le aspettative della platea e ci aspettavamo che fossero a conoscenza degli argomenti trattati ed avessero un minimo di esperienza in questi ambienti (parte in cima ed almeno in discesa della curva della delusione).
Spero che le soluzioni ed il nostro talk sia servito almeno a far capire che "There’s no any “Best NoSQL Solution” at all".

La cosa che mi è sembrata strana è che nessuno mi abbia mai chiesto niente di elasticsearch (http://www.elasticsearch.org/) ma magari se la curiosità ti stuzzica visita il siti http://blog.mozilla.com/data/2010/12/30/flume-hive-and-realtime-indexing-via-elasticsearch-2/ e il risultato http://glow.mozilla.org/
Per le architetture e la loro scalabilità: http://highscalability.com/

MongoDB map/reduce: http://stackoverflow.com/questions/2794377/mongodb-whats-the-point-of-using-mapreduce-without-parallelism
L'attuale stato è che se chiedi a 10gen ti consigliano di evitare il map/reduce se hai tanti dati. Io personalmente ho provato a sostituire V8 a spidermonkey, ma senza risultati. Nessuno nei talk ha parlato di ciò e di come tenendosi gli indici in memoria le macchine devono essere carozzate di memoria e tante! (Una configurazione safe sono 9 macchine 3x3 con shard).

Scusami per la risposta lunga e se hai bisogno di chiarimenti sono a tua disposizione.

Personalmente, concordo pienamente con entrambi. Con questo voglio dire che pur essendo vero che il talk è sembrato una marketta è anche vero che il suo scopo principale non era quello. Come ha detto Alberto, mostrare l'architettura piuttosto che l'intero flusso (e mi riferisco anche alla semplicità della slide in cui si tenta di mostrarlo) nasce dal fatto che i logs essendo così diversi tra di loro non permettono una spiegazione generale sul processamento/interpretazione che gli raggruppi.

D'altra parte vorrei anche far notare che l'utilizzo di mongodb come ha ben precisato Gabriele nel suo talk e come ha anche citato Alberto nel suo commento, richiede a tutti i costi un refactoring degli applicativi nonché di tutta l'architettura e modelli ed è per questo (ancora una volta) che vengono citate le soluzione interne (e mi riferisco a quelle create in azienda e rilasciate Open Source) che sono state utilizzate dentro l'architettura (stack interno di sfoftware e librerie) con le quali siamo riusciti ad evitare questa necessità di refactoring adottando la soluzione consigliata anche da Salvatore che è quella di modificare il layer di estrazione dati e far si che soddisfi quello business.

Veramente mi dispiace la strada che ha preso il talk e sopratutto l’impressione che ha lasciato in tutti dato che la mancanza di tempo (per errore nostro) ci ha penalizzati ed ha fatto si che la parte più tecnica (intendo dire quella che spiegava più in dettaglio il come e perché delle soluzioni adottate) no sia stata portata avanti nella maniera giusta e pur sapendo che questa non è la soluzione a ciò che è successo metto a disposizione il mio indirizzo email e contatto skype dove potete contattarmi liberamente per chiedere qualsiasi informazione riguardante a ciò che è mancato o vi aspettavate del talk (risponderò tutto ciò che il mio contratto permetta).

Ad ogni modo, colgo anche l’occasione per proporre un nuovo evento, meeting, “pirlo” (aperitivo) in cui potremmo discutere approfonditamente su i dettagli delle architetture destinate a gestire grossi moli di dati senza tralasciare la possibilità di ricerca e facile accesso ad essi.

flaper87 su skype
flaper87 chiocciola flaper87 punto org

P.S: Ho create un gruppo[0] anche su convore per discutere su nosql e le soluzioni esistenti per problemi reali basate su nosql

[0] https://convore.com/nosql-it/

Mi ha coinvolto veramente poco.

Non credo sia stata una marketta ( perlomeno non spinta... ) ma mi sono trovato in estremo disaccordo con alcune frasi pronunciate, che al solito scatenano la guerra di religione verso la quale un talk non dovrebbe mai andare: credo sia uno dei punti di partenza per ogni speaker.

Gabriele Lana esordisce parlando di "un martello e tutti chiodi" e in questo talk JSON viene paventato come il formato definitivo... Se tutti i sistemi NoSQL usano JSON *non* vuol dire che esso sia la soluzione a *qualsiasi* problema.

Di for real, peraltro, abbiamo visto poco o nulla, per cui il talk mi ha lasciato l'amaro in bocca.

Sfortunato Percoco che ha dovuto condensare la sua parte in pochissimi minuti: probabilmente, dovendo parlare nello specifico di Mongo, la sua parte sarebbe stata un plus.

Non so quanta esperienza avessero gli speaker in tema conferenziero, magari si e' semplicemente pagata la tensione della conferenza: anche se il talk, in definitiva, non mi e' piaciuto, non me la sento di liquidarlo malamente, ci puo' stare.