OpenStack, Logstash and Elasticsearch: living on the edge

As part of my work for Bigfoot, I deployed a system to gather application logs and metering data coming from an OpenStack installation into Elasticsearch, for data analysis and processing. This post is based on OpenStack Icehouse.

Ceilometer to Elasticsearch

Ceilometer promises to gather metering data from the OpenStack cloud and aggregate it into a database, where it can be accessed by monitoring and billing software. In reality getting some data is very easy, but getting all the data is very hard, and in some cases, impossible.

Some OpenStack projects integrate the metering functionality and send their samples (VM CPU usage, disk, network, etc.) via RabbitMQ to a central agent. Other do not integrate Ceilometer (why? I don’t know) and the administrator has to run periodically a separate script/daemon to gather the information and send it out. The lack of documentation in this area is almost complete, I found out about “neutron-metering-agent” and “cinder-volume-usage-audit” by chance and doing Google searches for them, right now, results in nothing that explains what they are and how to use them.

Once the data is gathered, Ceilometer wants to store it into a database. MongoDB is highly suggested, but it does not work together with Sahara, another OpenStack project. The issue ticket has been opened almost a year ago, and it is still open.

Mysql is not up to the task, a week of data causes the database to grow to a few tens of gigabytes. The script provided by Ceilometer to delete old data then tries to load everything in memory, hits swap and all hope is lost. I let it run for a week trying to delete one day of data, then I decided to try something else.

Ceilometer can send the data in msgpack format via UDP to an external collector. I removed the central agent and the database and pointed Ceilometer to Logstash. Connecting Logstash to Elasticsearch is very easy and now I can do something useful with the data. It works quite well, and here is how I did it:

First, the Ceilometer pipeline.yaml:

sources:
  - name: bigfoot_source
    interval: 60
    meters:
        - "*"
    sinks:
        - bigfoot_sink
sinks:
  - name: bigfoot_sink
    transformers: 
    publishers:
      - udp://<logstash ip>:<logstash port>

This file has to be copied to all OpenStack hosts running Ceilometer agents (even on the Swift Proxy that does not have a standalone agent). Logstash needs an input:

input {
  udp {
    port => <some port>
    codec => msgpack
    type => ceilometer
  }
}

and some filters:

filter {
  if [type] == "ceilometer" and [counter_name] == "bandwidth" {
    date {
      match => [ "timestamp", "YYY-MM-dd HH:mm:ss.SSSSSS" ]
      remove_field => "timestamp"
      timezone => "UTC"
    }
  }
  if [type] == "ceilometer" and [counter_name] == "volume" {
    date {
      match => [ "timestamp", "YYY-MM-dd HH:mm:ss.SSSSSS" ]
      remove_field => "timestamp"
      timezone => "UTC"
    }
    date {
      match =>["[resource_metadata][created_at]","YYY-MM-dd HH:mm:ss"]
      remove_field => "[resource_metadata][created_at]"
      target => "[resource_metadata][created_at_parsed]"
      timezone => "UTC"
    }
  }
  if [type] == "ceilometer" and [counter_name] == "volume.size" {
    date {
      match => [ "timestamp", "YYY-MM-dd HH:mm:ss.SSSSSS" ]
      remove_field => "timestamp"
      timezone => "UTC"
    }
    date {
      match =>["[resource_metadata][created_at]","YYY-MM-dd HH:mm:ss"]
      remove_field => "[resource_metadata][created_at]"
      target => "[resource_metadata][created_at_parsed]"
      timezone => "UTC"
    }
  }
}

These filters are needed because date formats in Ceilometer messages are inconsistent. Without these filters Elasticsearch will try to parse them and fail, discarding the messages. Perhaps there are other messages with this problem, but the only way to find them is wait for a parser exception in Elasticsearch logs.

I think this configuration is much more scalable, flexible and useful to the end user than the standard Ceilometer way, with its database and custom API for which there are no consumers.

Application logs

Managing an OpenStack deployment is hard. It is a complex distributed system, composed of many processes running on different physical machines. Each process logs to a different file, on the machine it is running on. A general lack of documentation and inconsistent use of log levels across OpenStack projects means that trying to investigate an issue is a tedious and time consuming job. Processes need to be restarted with debugging enabled, and a few important lines get lost among tons of other stuff.

To try to simplify this situation I used again Logstash+Elasticsearch to gather all the application logs coming from OpenStack. To work at its best and provide meaningful searches (all messages from a certain Python module, all messages with exception traces), I decided to use a Python logging module that would translate the Python log objects into Logstash (json) dictionaries. This way the structure is conserved and not lost in syslog-like text translation.

Doing that is fairly simple, with a few caveats. First you will need to install python-logstash (my version reduces the number of fields that get discarded).

Then add this file to the configuration directory of the project you want to get the logs from (for example /etc/neutron/logging.conf):

[loggers]
keys=root

[handlers]
keys=stream

[formatters]
keys=

[logger_root]
level=INFO
handlers=stream

[handler_stream]
class=logstash.UDPLogstashHandler
args=(<logstash server>, <logstash port>, 'pythonlog', None, False, 1)

And finally add this option to Neutron’s config file (it is the same for the other projects):

log_config_append=/etc/neutron/logging.conf

Configuring logstash is easy, just add this:

input {
  udp {
    codec => "json"
    port => <some port>
    type => "pythonlog"
    buffer_size => 16384
  }
}

Now, the caveats:

  • this will disable completely any other logging option you set in the configuration files (debug, verbose, log_dir, …). Disregard what the documentation says about the fact the logging conguration will be appended, it does not, it overrides anything else and because of how the python logging system is made, there is nothing that can be done. If you use that option, all logging configuration has to reside in the logging.conf file.
  • The configuration above discard all logs with a level lower than INFO. DEBUG level is needed to investigate issues, but the volume of logs coming from a full OpenStack install at DEBUG level is just too big and imposes useless load.
  • Depending on the size and the load of your deployment, you may need to scale up both logstash and elasticsearch.

Agende nel 2014

Sono sempre alla ricerca di modi per organizzarmi meglio e periodicamente parto per delle quest, alla ricerca della soluzione definitiva ai miei problemi. Oggi riassumo i risultati delle mie ricerche sui modi migliori per organizzare una agenda di cose da fare.

I miei requisiti sono semplici, almeno all’apparenza:

  1. Client offline Android e PC (windows), sincronizzazione automatica
  2. I dati devono risiedere sul mio server
  3. Integrazione con la rubrica (compleanni, liste di persone presenti alle riunioni)
  4. Integrazione con un gestore di “attività/task”. Mi riferisco ai task inclusi nella specifica del protocollo caldav (i VTODO nella definizione dell’RFC 2445).

Sinceramente, non penso di chiedere la Luna. Il punto 1 dovrebbe essere piuttosto diffuso vista la quantità di telefoni Android e PC Windows in circolazione.Il punto 2 dovrebbe interessare a chiunque abbia o un minimo di riguardo per la propria privacy, o voglia tenere i dati della propria attività lavorativa sotto il proprio controllo e non cederlo a terzi.
Il punto 3 è questione di integrazione tra servizi esistenti, niente di nuovo da inventare. Outlook con Exchange lo fa già molto bene da tanto tempo, ad esempio.
Il punto 4, i task: mi piacerebbe poter tenere una lista delle cose che ho in mente di fare. Alcune hanno delle scadenze e altre no. Quelle che hanno scadenza dovrebbero apparire nell’agenda. Di nuovo, integrazione tra servizi, niente di nuovo.

Dopo innumerevoli ricerche, ripensamenti, installazioni e software in prova sono giunto alla conclusione che c’è parecchia strada da fare. Vediamo un po’.

Server

Per fare sincronizzazione facile ed affidabile ci vuole un server. La soluzione più promettente in quanto standardizzata e aperta sembra essere caldav. Ci sono vari server, uno che ho provato è baïkal, che mi sembra faccia il suo lavoro egregiamente ed è facile da installare. Un altro è radicale, ma è implementato in Python e quindi non è facile da installare su un web server in hosting. In realtà faccio uso del server SabreDAV fornito dal mio provider di posta, a cui hanno aggiunto un’interfaccia web.

Il lato server è il più facile, ci sono varie soluzioni, tutte buone.

Client Android

Qui inizia il calvario. Android non supporta caldav. Ci sono app a pagamento o gratuite (beta) che fanno la sincronizzazione (ma non la fanno dei task per qualche motivo a me ignoto). Questo già mi sembra un po’ tanto grave in un sistema operativo che fa di un punto di forza il suo essere aperto e libero.
Una volta che l’agenda è sincronizzata (ma non i task/attività, ripeto) ci sono varie app, alcune anche molto carine e ben fatte. Uso Business Calendar Pro, che ha dei bei widget, ma c’è anche SolCalendar.

Businness Calendar ha un supporto parziale per gli inviti ai meeting che arrivano da un calendario Google. Dico parziale perché appare la domanda “vuoi partecipare a questo meeting?”, ma poi non mi sembra che accada alcunché, qualunque sia la riposta.

Esiste una app, chiamata Birthday Adapter, che riempie un calendario a scelta coi compleanni presi dalla rubrica di Android. È utile, ma è un tapullo. Gli eventi sono visibili solo sul cellulare ed è ancora un altro servizio che deve girare su un dispositivo a batteria quando invece potrebbe essere fatto lato server ed essere condiviso su tutti i dispositivi.

Per i task c’è Mirakel. Che vuole una versione con patch della app per sincronizzare caldav. È tutto molto beta. Oppure c’è una app della stessa persona che fa caldav-sync, la app a pagamento per la sincronizzazione, ma è limitata e non fa cose fondamentali come i task ricorrenti (tipo qualcosa che si ripete una volta a settimana).

Client Windows

C’è Thunderbird con l’addon lightning. Poverino, fa il suo dovere e ha qualche bachetto. Zero sincronizzazione con la rubrica, che comunque in Thunderbird non si sincronizza. Non trova da solo tutti i calendari in un account e bisogna aggiungerli uno alla volta manualmente.
In alternativa c’è eM client. Che è un client di posta più moderno, ma che non solo vuole una licenza, ma aggiunge veramente pochissimo (una rubrica che si sincronizza) a quello che fa Thunderbird. Non sono a conoscenza di altri software, forse ci sono dei port di software Linux, come Evolution, ma nella mia esperienza è raro che tali progetti di porting funzionino decentemente e siano supportati bene.

Personalizzazioni

Ho sviluppato uno script che scarica un calendario condiviso e lo ripubblica all’interno di un calendario privato. Serve ad accentrare in un punto unico (il mio server) tutti i calendari di cui ho bisogno. Ad esempio uso un calendario pubblico di festività francesi e lo importo sul mio server, a questo modo ho quegli eventi su tutti i miei dispositivi automaticamente.Ho intenzione di estendere la cosa anche per i compleanni, basta leggere dalla rubrica condivisa e creare degli eventi in un calendario apposta.

Conclusioni

Manca del tutto un sistema di organizzazione personale, per singoli individui. Un sistema che racchiuda rubrica, calendario, posta e task manager, usando tecnologie e software esistenti e già diffusi, senza reinventare la ruota. La maggior parte delle componenti esiste già, mancano un po’ di pezzetti qui e là ed un po’ di colla per tenere insieme il tutto e dargli un aspetto decoroso. Ad averci il tempo potrebbe essere anche un progetto interessante, ma per ora purtroppo, si va avanti a script o si fa senza.

Curiosità

Durante la mia quest ho incontrato siti interessanti:

SocketCAN documentation update

I’m updating the Linux kernel SocketCAN documentation by sending patches to the can.txt file distributed with the sources. I had to translate an old LaTeX file from German to English to implement some stuff at work related to the BCM subsystem and I took the opportunity to contribute back the translations.

The BCM system is very useful and I think that with some English documentation it will get used a lot more. It provides a lot of services that are usually implemented by hand for each Linux application that uses CAN, such as timed frame send, receive filters and RTR management. For sure we will be sending out next week the first unit of a new product that integrates BCM and works flawlessly. We implemented the logic behind the communication, without having to care about timing and timeouts, since everything is handled by the kernel.

There is a page where I keep track of the patches and the status of the project.

OLS – Ottawa Linux Symposium

Sono tornato da qualche giorno dal Canada ed è tempo di fare un po’ il sunto di quello quello che ho visto. Era il mio primo viaggio oltreoceano ed è stata un’esperienza molto molto interessante. Per cominciare devo dare atto all’Air France, ho volato bene, con ottimi pasti e belle hostess, tutto in orario e nessun problema di bagagli o coincidenze.

La conferenza si è svolta per quattro giorni presso l’Ottawa Conference Centre, da mercoledì a sabato, con orari molto prolungati, dalle 9 (o 10) fino alle 20, con diverse pause. Un giorno siamo arrivati alle 21 grazie ad un incontro non previsto su Linux Embedded. Non sto a contare i party che si sono svolti due o tre sere e che si sono prolungati fino a notte fonda, con birra a fiumi e (purtroppo roba da mangiare abbastanza scadente).

Un dato di fatto è che lo sviluppo di linux è gestito sempre di più da dipendenti di grandi aziende come IBM, Intel, HP, Freescale e Red Hat. Queste aziende sviluppano più del 50% delle modifiche fatte ad ogni release del kernel. Finché in cima c’è Torvalds e Morton, che non lavorano per nessuna grossa compagnia, non c’è nulla da temere, in quanto sono loro che decidono cosa va bene e cosa no e hanno un buon potere di controllo. La situazione attuale, in effetti, è ottimale: le aziende ci mettono la manodopera e gli obiettivi concreti (e ci fanno parecchi soldi) e la Comunità ci mette il potere di controllo, l’innovazione e quel po’ di chaos necessario all’avanzamento del progetto sul lungo periodo. Finché questa situazione di equilibrio permane, Linux continuerà a crescere ai livelli attuali, mangiando fette di mercato un po’ a tutti gli altri.

Tra le altre cose interessanti che ho sentito (ma ci sono in giro per la rete delle cronache molto più dettagliate di questa) c’è il fatto che finalmente qualcuno presso Red Hat ha deciso di mettere mano al gran casino che è l’audio su Linux: tra esound, alsa, oss, jack, arts e altri non ci si capisce più nulla, e soprattutto cercare di fare una chiamata voip mentre si ascolta della musica è praticamente impossibile a causa dei conflitti di volumi e mixing tra le varie librerie.

Infine ci sono novità interessanti nel campo del USB senza fili (un bluetooth con gli steroidi) e del read ahead, per rendere ancora più furbe le letture da disco fisso. Alcune notizie interessanti ci sono state per l’embedded. Parecchia gente sta lavorando con Linux su sistemi piccoli, portatili e facili da usare. C’è molto lavoro in corso nel campo del risparmio energetico e nella gestione furba dei dispositivi tipici dei sistemi embedded (memoria flash, batterie, piccoli lcd).

In ogni caso, evviva il Canada ;-)

Cocoa programming

Oggi ho speso buona parte della giornata tentando di scrivere un visualizzatore di immagini per Mac Os X che potesse:

  1. leggere le immagini da una directory
  2. ignorare i file non leggibili/non immagini
  3. visualizzarle a pieno schermo con/senza ridimensionamento
  4. passare all’immagine successiva o precedente nella stessa directory premendo un solo tasto (spazio)
  5. tornare indietro di un’immagine premendo backspace
  6. canellare un’immagine premendo canc

Nient’altro, niente thumbnail, niente zoom intelligente, niente funzioni di editing. Ho spesso a che fare con directory remote con centinaia di foto e non voglio aspettare ore prima di poter iniziare a controllarle.

Inutile dire che ho rinunciato (per ora!) all’impresa. Dovrei imparare seriamente l’Objective C per iniziare a capirci qualcosa, in ogni caso ho trovato Cocoa molto macchinoso e la documentazione generica (tutorial, introduzioni) troppo vaga. Il tutorial consigliato da tutti è praticamente inutile, è troppo semplice e non spiega perché si fanno le cose in un certo modo. Un esempio su tutti è NSBrowser, un widget per visualizzare dati strutturati ad albero. Il codice d’esempio rasenta il delirio solo per visualizzare un albero di directory perché si perde a settare font, sottolineature e colori vari.
La documentazione non dice assolutamente come si fa a riempire un NSBrowser nuovo, dice solo che una volta pieno è bellissimo.
Speravo che i binding Python<->Cocoa potessero salvarmi, ma sono abbastanza inutilizzabili per chi non conosce l’Objective C.

Per ora continuerò ad usare gqview sotto X11, è il meglio ed è la dimostrazione che il software open source è in grado di dare la polvere a software blasonati e costosi (graphicconverter, iview), ma praticamente inutilizzabili o surclassati da iPhoto.
Una menzione d’onore a cocoviewx, sarebbe perfetto se non morisse così facilmente e se caricasse le immagini solo prima di visualizzarle.

Galleria fotografica

Ho appena finito di uploadare la nuova galleria fotografica, l’ho scritta in questi ultimi giorni, dopo essermi stufato di quella vecchia. Ho speso parecchio tempo a costruire un buon formato sul disco per l’organizzazione delle foto e alla fine sono arrivato ad una doppia struttura. Le foto sono organizzate in directory per anno e mese, così se decido di cambiare la grafica o la categoria non perdo i bookmark e i motori di ricerca. L’organizzazione sta in un albero di directory separato, con una serie di file di testo che elencano le fotografie appartenenti a ciascuna suddivisione.
Ho usato solo XHTML e CSS, ma non ho ancora verificato se valida sul sito del w3c. Devo anche rifare tutte le thumbnail, in modo che abbiano le stesse dimensioni.

La giornata del sistemista

Oggi ho passato la giornata a a giocare al piccolo sistemista. Tenendo iTunes in background con una radio online di sola musica anni ’80 e lavorando via ssh sul server casalingo ho giocato un po’ con tethereal e subversion, ottenendo delle cose abbastanza utili.

Stamattina tethereal. Fino ad oggi usavo tcpdump e uno scriptino bash per recuperare le informazioni su certi pacchetti che mi interessano, però la soluzione non era ottimale perché catturava poche informazioni su troppi pacchetti, dato che tcpdump non ha filtri per protocolli ad alto livello.
Con tethereal posso catturare solo i pacchetti che mi interessano in un certo periodo di tempo e metterne il dump in un file (in formato pcap). Uno script chiamato da cron, ad intervalli regolari, uccide il processo di cattura, esegue di nuovo tethereal sul file di cattura con parametri differenti (per fargli risolvere gli indirizzi IP) passando l’output ad un programmino in Python per estrarre solo le informazioni interessanti. Alla fine mi manda il tutto via mail e rimette in esecuzione il processo di cattura su un file vuoto. Quei simpaticoni di Echelon a confronto sono dei pivellini.

Il pomeriggio, invece, l’ho passato a litigarmi con subversion, apache2, mod_ssl e mod_auth_pam, però alla fine ne ho avuto ragione…
La configurazione che mi ero posto come obiettivo era:

  1. area pubblica in sola lettura
  2. autenticazione per poter modificare il repository

Avevo già l’autenticazione grazie a svn+ssh, ma dove sto facendo la tesi escono su Internet solo con un proxy (anche se ogni tanto si esce tranquilli con un NAT, dipende dalle maree e da certi riti sull’altare che hanno in terrazzo, credo) e volevo anche poter fornire accesso al ‘grande pubblico’, in particolare per il driver sis900.

L’unico tipo di autenticazione su http che funziona con mod_auth_pam (non volevo avere ancora un’altra password diversa) è ‘Basic’, con la password che viaggia in chiaro per mezzo mondo. La soluzione è stata usare mod_ssl. Non ci sono alternative se non criptare l’intera connessione, anche se l’unica cosa che vuoi tenere segreta è la password. Bah.

Mi sono creato la mia CA fasulla e l’ho usata per firmare il mio certificato fasullo anche lui e ora ho la mia brava connessione su https, alla faccia di tutti quelli che dicono che non si può avere SSL insieme ai virtual host di Apache (certo, non si può se si fanno le cose sul serio, con dei certificati veri, ma se uno fa finta di non vedere un paio di warning all’avvio di apache, problemi non ce ne sono…). Ora su https magari ci metto pure su un webmail, così posso leggermi la posta anche quando il sistemista in ditta si dimentica di fare i sacrifici agli dei.

Alla fine pure mod_auth_pam ha iniziato a funzionare senza particolari problemi (occhio che su Debian bisogna attivarlo con “AuthPAM_Enabled on”, anche se nella documentazione sul sito dice che quello è il valore di default).

Ora devo solo attivare un po’ di controllo di accesso sui singoli repository, attraverso un altro modulo dav_svn_<qualcosa>.

Appena c’è qualche cosa di significativo visibile all’esterno posto un link.

Tesi 2, la vendetta

Dopo aver abbandonato una tesi sulla bioinformatica a favore di un’argomento più promettente, in particolare quanto a prospettive lavorative, sembra che finalmente lunedì potrò iniziare.
Dovrò lavorare allo sviluppo di un sistema di comunicazioni wireless con routing dinamico e idealmente senza infrastruttura fissa da utilizzare in ambiente portuale.
Il tutto dovrebbe offrire un’interfaccia generica per permettere a qualunque tipo di applicazione di lavorare in modo trasparente, si va dal semplice scambio di dati sulle merci spostate al VoIP. Ovviamente ci sono anche degli studi di affidabilità e velocità da fare sugli algoritmi attualmente esistenti.
Il tutto si baserà su Linux, che è il sistema che già usano nella ditta presso cui vado a fare il tirocinio.
La mia intenzione è di tenere qui un diario degli avanzamenti, vedremo se ciò mi sarà possibile…

La mia opinione sulla questione BitKeeper

Qualche giorno fa si è scatenato l’ennesimo thread infinito su linux-kernel@vger.kernel.org sul problema che BitMover (la ditta dietro al prodotto BitKeeper) non fornisce abbastanza informazioni per ricostruire completamente la storia dei sorgenti del kernel di Linux. Io non credo che questo sia un problema reale, le patch su ftp.kernel.org hanno una granularità sufficiente per la maggior parte degli usi che mi vengono in mente.
Il problema che vedo io riguarda i piccoli sviluppatori, come me. Per noi è diventato estremamente difficile seguire lo sviluppo del piccolo pezzetto di kernel di cui ci vogliamo occupare senza utilizzare BitKeeper. Qualche mese fa mi sono trovato delle modifiche (perfettamente giuste e legittime) al driver che mantengo già incluse nella release stabile, mentre le mie povere patch faticavano a passare i molti filtri. Ho dovuto rifare le mie patch perchè non si applicavano più…
Non ha alcun senso che per mantenere un driver di 50KB io debba mantenere un albero cvs (o svn o bk) di diverse centinaia di MB contenente tutta la storia possibile. Attualmente uso una soluzione fatta in casa, quasi totalmente automatizzata che mi permette di fornire patch che si applicano all’ultimo snapshot di Torvalds. Internamente uso Subversion per mantenere la storia delle modifiche ai sorgenti. E’ un buon prodotto, decisamente migliore di cvs e più intuitivo di arch (e forse anche più avanti nello sviluppo).

Quindi il mio problema non è che la gente usi BitKeeper, a loro fa comodo, a me no. Il problema è che BitKeeper consente a chi lo usa una via rapida e veloce per includere modifiche senza che ci sia un reale controllo da parte della comunità. Si sono formate due categorie, quelli che usano BitKeeper e tutti gli altri, con questi ultimi che si sbattono con scriptini e casini vari perché non possono (o non vogliono) usare un programma che ha una licenza alquanto discutibile.
Dato che la maggior parte dei piccoli sviluppatori lo fa per hobby, più gli rendi le cose difficili e meno avranno voglia di continuare il lavoro.

Le nuove librerie di Enlightenment 0.17

Sto provando ad usare in questi giorni le Enlightenment Foundation Libraries (EFL) per scrivere un paio di programmini, tanto per farmene un’idea. Sono rimasto piacevolmente sorpreso, le librerie sono facilissime da usare, sono stabili e c’è già abbastanza documentazione per iniziare ad usarle senza perdere troppo tempo.
Per disegnare grafica in una finestra di X sono velocissime, mentre se si ha bisogno di usare dei widget, è meglio usare qualcosa come QT o GTK, per ora.
I widget di Enlightenment sono ancora in pesante sviluppo. Quanto al window manager e17, non ci conterei in tempi brevi…