Analisi empirica dei meccanismi di log in sistemi open-source

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea Analisi empirica dei meccanismi di log in sistemi open-source Anno Accademico 21/211 Relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Antonio Pecchia candidato Imperatrice Assunta 534/1657

Taluni nascono grandi. Altri alla grandezza giungono per gradi. (W. Shakespeare)

Indice Introduzione 5 Capitolo 1. Log Analysis 8 1.1 I logs 1 1.2 Il meccanismo di logging 1 1.3 Il formato dei logs 12 1.4 Contributo e problematiche della Log Analysis 13 1.5 Obiettivo della tesi 15 Capitolo 2. Progettazione ed implementazione di un tool per il parsing delle chiamate alle funzioni di log 16 2.1 Il tool di parsing 16 2.1.1 Scopo del tool 16 2.1.2 Modalità operative 18 2.2 Problematiche e soluzioni proposte 19 2.3 Considerazioni per la fase di progettazione 21 2.4 Validazione dei risultati prodotti 22 Capitolo 3. Descrizione e catalogazione dei sistemi open-source 24 3.1 Apache HTTP Web Server 25 3.2 Data Distribution Service 27 3.3 Cardamom Object Web 29 3.4 Corba TAO 31 3.5 Minix 33 3.6 MySQL 34 3.7 RTEMS 36 3.8 Criteri di catalogazione dei sistemi 37 Capitolo 4. Analisi sperimentale 39 4.1 Confronto del meccanismo di logging tra alcune release di uno stesso software 39 4.1.1 Confronto del logging tra alcune release di Apache 39 4.1.2 Confronto del logging tra alcune release del DDS 43 4.2 Confronto del meccanismo di logging tra differenti classi di sistemi 46 III

4.2.1 Confronto del logging tra sistemi di vari domini applicativi 46 4.2.2 Confronto del logging tra sistemi con diverse architetture a livello di S.O. 51 4.2.3 Confronto del logging tra sistemi scritti in differenti linguaggi di programmazione 58 4.2.4 Confronto del logging tra differenti tipologie di sistema: centralizzato e distribuito 64 Conclusioni e sviluppi futuri 7 Bibliografia 71 IV

Introduzione Con l'evoluzione dei sistemi di elaborazione sempre più settori (militari, finanziari, industriali, ecc.) affidano a sistemi automatici il controllo di delicate operazioni. Tale evoluzione ha portato la nascita di calcolatori sempre più funzionali e performanti ma non necessariamente più affidabili o esenti da clamorosi fallimenti. Ogni malfunzionamento può provocare danni più o meno gravi : per esempio, un errore di sviluppo nel campo della telefonia potrebbe comportare problemi di connessione, di ricezione mentre conseguenze più disastrose potrebbero verificarsi in scenari cosiddetti critici per i quali un fallimento nell'assolvere una o più funzioni ad essi richiesti comportano conseguenze di notevole gravità in termini di perdite economiche e/o danni a persone e/o ambiente : si pensi ad un errore in sistemi di controllo di traffico aereo. I fallimenti dei sistema possono essere legati a problemi hardware, generando errori solitamente transitori e facilmente individuabili, e/o a errori nel software, tipicamene più comuni. Questi ultimi sono legati a difetti presenti nella parte software del sistema, noti con il termine Software Faults. La loro usualità è legata alla crescita continua della complessità dei sistemi moderni : oggigiorno i Software Faults sono una delle principali cause di fallimento delle applicazioni. L ipotesi attuale è che non possono essere realizzati software privi di bugs. Ciononostante, soprattutto negli scenari critici, è necessario avere un alto grado di affidabilità del comportamento del sistema. Per questo motivo, sia durante la sua fase di 5

sviluppo hardware e software che dopo il suo rilascio, è essenziale che esso venga continuamente osservato ed esaminato. Tuttavia un sistema che funziona correttamente può contenere faults non attivi, detti dormienti. Una delle metodologie più diffuse per la correzione del sistema dai Sosftware Faults è il logging: un insieme di istruzioni per il rilevamento degli errori che si presentano all interfaccia del sistema quando uno o più Software Faults dormienti sono attivati dai fault trigger 1. Attraverso delle semplici chiamate a funzioni di una libreria specifica, inserite in punti specifici del codice sorgente, esse permettono di raccogliere le informazioni relative all evento in appositi file log. La Log Analysis consente di ricostruire la catena di propagazione del guasto (faulterror-failure). Tuttavia, come vedremo in seguito, questo pattern presenta un importante limite : si dimostra che un numero significativo di Software Faults provocano il failure del sistema senza la produzione di alcun event log. Lo scopo di questo elaborato è quello di fornire, mediante un analisi sperimentale di sistemi software, le informazioni necessarie per comprendere l evoluzione del meccanismo di logging tra varie release di uno stesso software e tra diverse tipologie di sistemi : quali costrutti sono stati preferiti ad altri, come è variata la quantità di chiamate ai logs, etc. Tali dati sono interessanti al fine di intuire le eventuali cause della scarsa copertura del meccanismo. Il lavoro è organizzato come segue : Nel capitolo 1 sono introdotti i concetti necessari alla comprensione della log analysis : definizione di log, meccanismi per la detection e collection dei dati, obiettivi e limitazioni della metodologia; Nel capitolo 2 viene illustrato nel dettaglio lo scopo di questa tesi e le tecniche di realizzazione adottate: chiarimenti sulla fase di analisi e progettazione del tool usato per il parsing delle chiamate alle funzioni di logs e sull indagine sperimentale delle 1 I fault trigger sono delle particolari condizioni di attivazione dei fault, quali un particolare stato del sistema, una determinata sequenza di input. Non sono semplici da evidenziare solo con il testing 6

strutture usate per la detection. È riportato un esempio a scopo dimostrativo; Nel capitolo 3 è fornita una breve discussione dei sistemi software open-source selezionati per lo studio. Al fine di realizzare dei confronti e delle statistiche significative i software sono stati scelti in modo da coprire differenti caratteristiche reali e classificati secondo particolari criteri di analisi; Nel capitolo 4 sono esposti i risultati sperimentali : attraverso l elaborazione dei risultati ottenuti dall indagine, supportata dal tool, viene analizzata la modalità di detection prima tra le diverse release di uno stesso software e poi tra le differenti categorie di cui prima. 7

Capitolo 1 Log Analysis Il fiorire di scenari applicativi sempre più nuovi e complessi, soprattutto in ambienti critici, porta alla necessità di realizzare sistemi software non solo più sofisticati e potenti ma soprattutto più affidabili. Un malfunzionamento in una critical application può provocare danni molto gravi non solo in termini economici ma anche ambientali o addirittura perdite di vite umane. Le cause per cui un sistema può portarsi in uno stato incoerente, e dunque fallire, sono molteplici e possono manifestarsi in ogni fase del suo ciclo di vita: guasto hardware, errori in fase di design, di manutenzione, etc. Nell ambito ingegneristico sono di particolare interesse i Software Faults, classificati come la principale causa dei fallimenti dei sistemi software. I Software Faults sono delle imperfezioni nel codice del sistema, anche noti con il termine bugs : quando si presentano con modalità deterministica si parla di hard faults, mentre si parla di elusive faults quando essi, per limitazioni temporali e tecnologiche, sfuggono ai controlli della fase di testing e si manifestano sotto determinate condizioni computazionali (fault trigger). La natura non deterministica di questo tipo di faults fa sì che ogni applicazione software sia caricata di difetti residui (residual faults). La conseguenza è che un qualsiasi sistema, anche apparentemente corretto, può contenere dei faults inattivi, detti dormienti. L attivazione di un fault, in seguito a particolari trigger, porta il sistema in uno stato di errore : la produzione non corretta del servizio verifica un

failure. La rilevazione dell errore e le opportune tecniche di ripristino riportano il sistema ad operare in maniera corretta. In Figura 1 è riportata la catena di propagazione faulterror-failure. La distinzione tra errore e fallimento deriva dalla considerazione che in un sistema complesso l errore può essere confinato ad uno o più componenti senza raggiungere l interfaccia di servizio del sistema, mentre si ha un failure per la propagazione dell errore verso l interfaccia del sistema alterando la correttezza del servizio. È chiaro che l errore deve raggiungere l interfaccia in un tempo ragionavole, altrimenti viene classificato come errore latente. Fault, error e failure sono legati da una precisa relazione definita in letteratura come patologia del guasto. Poichè il fallimento di un componente può rappresentare un guasto esterno per un altro componente, la catena è ricorsiva. Figura 1 Catena di propagazione dell errore I Fallimenti Software rappresentano l incubo dell Information Age. Oltre agli errori ʺ tradizionaliʺ, quali le eccezioni e le computazioni errate, alcuni software faults sviluppati possono essere la causa dell invecchiamento del software : fenomeno in cui progressivamente le condizioni di errore maturate conducono o alla degradazione delle performance o a fallimenti transitori, o ad entrambi. Esempi sono la memoria piena, threads sospesi, corruzione dei dati, frammentazione dello spazio di memorizzazione. 9

A causa dell evoluzione di questi sistemi software, soprattutto in molteplici applicazioni critiche, è necessario che essi godino di un elevato grado di affidabilità. Le tecniche per aumentare il grado di dependability di un sistema sono diverse e si differenziano per il modo con cui si relazionano all occorrenza di un fault. La scelta della particolare strategia da adottare è legata alla natura del sistema e al grado di sicurezza che si vuole raggiungere. La log analysis è una delle tecniche a disposizione degli sviluppatori per misurare in maniera diretta la dependability di sistemi software complessi. 1.1 I logs I file di log sono dei file testuali in cui applicazioni, componenti o moduli di sistema memorizzano le informazioni delle operazioni compiute durante la fase operativa del sistema quando si rileva l attivazione di un software fault che ha portato l esecuzione ad uno stato di fallimento (es. se violata un asserzione di una variabile) o di avaria (es. se si riceve un servizio non corretto). Possono essere usati per molteplici scopi ma principalmente intesi per caratterizzare l affidabilità dei sistemi operazionali. Sono realizzati da manodopera umana, organizzati in record contenenti principalmente un timestamp, la descrizione sintetica dell evento, dello stato del sistema, una severity 2, l hostname, il pid del processo che ha generato l errore e possono mostrarsi come avvisi generici, notifiche di stati di errore, etc. Es. July 27 12:46 testlogs[1552] : Attenzione a questo evento! Il formato dell'entry di log è del tutto arbitrario, solitamente rivolto alla comprensione umana: il processo di logging è strettamente legato alla soggettività del singolo sviluppatore, per cui capita spesso che i formati dei logs differiscano sensibilmente anche tra varie sezioni dello stesso software. 1.2 Il meccanismo di logging Il meccanismo di logging è dunque una metodologia che si occupa della detection degli 2 Severity: grado di gravità scelto in un range predefinito 1

errori, dovuti all attivazione di Software Faults durante la fase operativa, e della collection delle informazioni relative all evento e allo stato del sistema al momento del rilevamento all interno dei logs. È necessario tener presente che una piattaforma dedicata al logging deve consentire allo sviluppatore di creare messaggi con invocazioni non complesse e permetterne la memorizzazione sul disco in un formato prestabilito, garantendo in tal modo la permanenza dei dati anche in caso di caduta del nodo o comunicazioni 3. Il meccanismo di logging richiede uno studio preliminare del sistema e del suo ambiente sia per identificare le tecniche adeguate al contesto sia per decidere se accompagnarle o meno con un componente ad hoc per il monitoraggio. La registrazione delle informazioni avviene per mezzo di chiamate proprie di una libreria di registrazione nel codice sorgente del programma in punti specifici. Di seguito è riportato un esempio della chiamata a log estrapolata dal file sorgente PublisherImpl.ccp del Middleware DDS 1.. È a cura del programmatore inserire correttamente le chiamate di registrazione all'interno del codice sorgente. I logs risultanti possono essere resi leggibili agli utenti o alle macchine a seconda della loro progettazione e alla loro finalità. if (enabled_ == false) { ACE_ERROR ((LM_ERROR, ACE_TEXT("(%P %t) ERROR: PublisherImpl::lookup_datawriter, ") ACE_TEXT(" Entity is not enabled. \n"))); return ::DDS::DataWriter::_nil (); } Chiamata dʼattivazione estratta dal file sorgente PublisherImpl.cpp di DDS 1. (372-378) Sistemi noti basati sul meccanismo di logging sono Unix Syslong 4 e Microsoft. Syslong è un protocollo particolarmente diffuso in ambiente Unix/Linux, prevede che i messaggi di log non siano localmente memorizzati bensì instradati, attraverso la rete, verso applicazioni di monitoraggio. Definisce tre tipologie di entries : 3 I log possono essere memorizzati su database relazionali o su file 4 Con il termine Syslong (System Log) si indica un protocollo appartenente alla suite dei protocolli Internet 11

1) Originator che rappresenta il codice del messaggio ; 2) Relay usato per l instradamento ; 3) Collector che si occupa dell analisi e del monitoraggio. A differenza degli altri protocolli, esso non rappresenta uno standard rigidamente definito. Il suo semplice funzionamento può essere così schematizzato : - il client invia un certo messaggio di testo al server, comunemente definito come syslong daemon o syslong server ; - il server può gestire messaggi provenienti da una variegata tipologia di macchine (computer, stampanti, ecc.) e può limitarsi a registrare l'evento per avere un archivio centrale di avvenimenti oppure reagire a particolari livelli di severità chiamando programmi, inviando e-mail, etc. La Microsoft, invece, mette a disposizione una sofisticata piattaforma per fare logging distribuito realizzata con tools per l analisi di logs propietari, la Windows Event Log. Gli amministratori di sistemi Windows possono scegliere di inoltrare i logs ai vari sistemi nella rete di lavoro includendo un singolo log server con il compito di collezionare i logs proveninenti da tutte le macchine. Utilizza il Microsoft Event Log protocol : ogni host Windows esegue un Event Log provider, accessibile dal codice usando particolari chiamate di sistema. In presenza di una new entry, quindi quando un error è loggato, il provider automaticamente la scrive sul file log locale oppure la inoltra verso hosts remoti specifici a seconda della configurazione. 1.3 Formato dei logs Come anticipato nel paragrafo 1.1, la mancanza di uno standard per la struttura dei messaggi di log è causa di elevati livelli di eterogenità tra di loro. Ad esempio : I logging frameworks di Apache usano un formato di log personalizzato la cui sintassi è stata stabilita da un pugglable di componenti. È adatto per l adozione di un formato di linguaggio comune ; Syslong impone che i messaggi abbiano una struttura molto semplice : organizzati in record contenti una severity e una facility, seguiti da campi quali timestamp, hostname 12

dell originator, il nome dell applicazione. Tuttavia, alla semplicità della struttura si oppone una libertà di sintassi, che contribuisce al problema dell eterogeneità dei dati. Una severity rappresenta un grado d importanza del messaggio ai scopi di analisi, una facility è usata per gruppi di messaggi provenienti da un certo tipo di sorgenti, quali kernel, mail daemon. Se combinati tra loro, secondo la legge P=F*8+S, definiscono il valore di priorità del log. Mycrosoft impone per i Windows Event Log un formato code-oriented : i logs non sono scritti in file testuali ma memorizzati in un database nel loro formato originale e privi di ogni forma di serializzazione. Il formato è definito seguendo frammenti di codice C e prevede il salvataggio di due differenti timestamp : uno che indica il tempo in cui il messaggio è stato registrato e l altro il tempo in cui è stato scritto nel log. 1.4 Contributo e problematiche della Log Analysis La Log Analysis, schematizzata in Figura 2, permette attraverso una registrazione cronologica dei file log di: stabilire le correlazioni tra malfunzionamenti e determinate condizioni di carico di lavoro ; identificare le cause all origine di errori e comportamenti indesiderati ed imprevisti ; fornire analisi ed interpretazioni statistiche sui fallimenti e sulle conseguenti riparazioni dei guasti. Figura 2 Log Analysis Può essere utilizzata dagli sviluppatori per ricostruire la catena fault-error-failure, scoprire i faults (prima dormienti e in seguito attivati) e correggerli, dagli amministratori per 13

ottenere delle statistiche sull utilizzo del sistema. Tuttavia, nello scenario descritto non si è tenuto conto dei limiti del meccanismo di logging : la rilevazione di un fallimento è a carico di un operatore umano e dipende fortemente dal fatto che il modulo o l'applicazione tenga traccia o meno del particolare evento che ha generato il failure : il software può contenere dei faults che sfuggono anche al controllo di basso-livello e quindi restare totalmente inclassificati, in tal caso si parlerà di faults non loggati ; non esiste uno standard dedicato alla scrittura dei logs e ciò comporta problemi legati alla loro etereogenità che coinvolge sia il formato sia i contenuti ; i logs possono contenere informazioni fuorvianti, essere incompleti e ridondanti. L eterogeneità del formato è fortemente legata alla complessità del codice del sistema. I problemi legati a questo aspetto possono essere risolti convertendo tutte le entries in un formato comune mentre c'è poco da fare per quelli legati alla varietà dei contenuti. Un aspetto più critico dei limiti del logging riguarda la scarsa copertura dei logs rispetto a quei software faults che, una volta attivati, danno luogo ad errori che generano il bug del sistema rimanendo totalmente inclassificati. Questa difetto spesso è legato alla mancanta consapevolezza della presenza di fenomeni di propagazione degli errori, fonte di un numero elevato di eventi apparentementi non correlati nei logs. Una valutazione dell affidabilità della piattaforma di Windows NT la Log Analysis ha evidenziato che ben il 58% delle cause di failures non sono classificate, mentre uno studio sulla JVM mostra che, pur essendo dotata di un sosfisticato meccanismo di gestione delle eccezioni, non risultano segnalati nei logs il 45% dei casi di fallimento. Questi valori evidenziano una significativa percentuale di difetti strutturali non rilevatati dal meccanismo di logging. Sebbene siano stati realizzati numerosi studi per il perfezionamento delle tecniche per la detection e sulla ricerca di metodologie più innovative per garantire lo sviluppo e la diffusione di sistemi con un più alto livello di dependability, contribuendo alla realizzazione di tools automatici per la generazione e l'analisi (post e/o real time) degli 14

eventi di log da fornire poi agli ingegneri del software sia per le nuove applicazioni sia per le applicazioni legacy 5, quale la fault injection oppure la Field Failure Data Analysis (FFDA), risulta ancora poco consistente il contributo nelle ricerche per il superamento di queste limitazioni. 1.5 Obiettivo della tesi Lo scopo del presente elaborato è quello di fornire una valutazione quantativa della metodologia di logging, mediante un analisi sperimentale della modalità con cui è realizzata in un set di software open-source utilizzati in Critical Application. L indagine è compiuta con l ausilio di un tool per il parsing delle chiamate alle funzioni di log (vedi Capitolo 2). Sono sottoposti ad analisi differenti release di uno stesso software, più specificamente si fa riferimento a varie release del Server Apache e del Middleware DDS, e differenti sistemi software scelti in modo da coprire una serie di caratteristiche determinate sulla base di specifici criteri : stile di programmazione (object-oriented e procedure-oriented), dominio applicativo applicativo (mission e business critical), organizzazione a livello di sistema operativo (processo server, middleware, sistema operativo), architettura (centralizzato e distribuito). I sistemi open-source che meglio rispecchiano queste caratteristiche sono : Apache Web Server, MySQL, Corba TAO, Data Distribution Service, RTEMS, Minix e Cardamom Object Web, illustrati nel capitolo 3. Una valutazione empirica delle strutture utilizzate per la detection, suddivisa secondo le tipologie di cui prima, permette di studiare il trend di logging in vari contesti al fine di fornire informazioni utili alla comprensione della scarsa copertura dei logs. 5 Un Sistema legacy è un sistema informativo esistente da anni, di valore per il business da esso supportato, che è stato ereditato dall ambiente elaborativo attuale 15

Capitolo 2 Progettazione ed implementazione di un tool per il parsing delle chiamate alle funzioni di log In questo capitolo sarà illustrata la strumentazione adotta per la realizzazione dell analisi sperimentale della modalità di logging nei sistemi open-source: si realizza un tool di supporto, scritto in linguaggio Bash del Sistema Operativo Linux con l ausilio delle espressioni regolari, con lo scopo di filtrare i codici sorgenti dei sistemi da esaminare, di isolare le chiamate alle funzioni di log e di ʺ catturareʺ la struttura di controllo utilizzata per la detection degli errors. Poichè per ogni sistema il logging è realizzato mediante chiamate proprie di una particolare libreria di registrazione nel codice sorgente, per poterle individuare è stato necessario uno studio preliminare dei file sorgenti per ciascuno di essi. I risultati ottenuti dal tool sono stati poi elaborati per la valutazione del trend di logging tra le release di uno stesso software e tra le differenti classi considerate. 2.1 Il tool di parsing 2.1.1 Scopo del tool Lo script per il parsing delle chiamate ai log, denominato file_log.sh, è stato scritto in modo da renderlo valido per questo studio e per eventuali studi futuri. In altre parole, è stato realizzato in modo da risultare indipendente dai particolari software esaminati in questo contesto. Ricevuti in ingresso, nel medesimo ordine, la cartella dei file sorgenti del software sottoposto ad esame, il file di testo contenente la lista delle corrispondenti funzioni di log e

il numero di righe che le precedono, lo scopo del tool è quello di fornire in output : o la stima della quantità di codice dei sorgenti : Loc ; o la porzione di codice esaminato : Loc ANALIZZATE ; o l aliquota di codice dedicato al logging, ovvero il numero di chiamate a log : LOG ; o la catalogazione e il conteggio di tutte le strutture di controllo individuate, utilizzate per la detection degli errors : IF, ELSE, SWITCH, IFDEFINE, CATCH e OTHER ; gli IF sono a loro volta classificati in IF con 1 condizione, IF con 2 e IF con un numero di condizioni maggiori di 2, suddivise in base alle condizioni logiche ; o la classificazione e l enumerazione di tutte le possibili operazioni coinvolte nelle clausole dei costrutti IF : =,, <, >, e ; o la schedatura e il calcolo di ciascuno dei possibili valori coinvolti nelle condizioni degli IF : notevoli «NULL,, 1, -1, TRUE, FALSE» e di default «VALUE». I risultati ottenuti in questo step sono oggetto di studio nelle fasi successive dell analisi, esposte nel Capitolo 4. In Figura 3 è riportato un esempio di analisi del sosftware Apache v. 2.2.19. 17

SORGENTI: http_main.c, http_config.c, http_log.c FUNZIONI: ap_log_error n=3 TOOL ===================== ====Report =========================== LS SORGENTI 16276 LS ANALIZZATE 632 LOG 132 ELSE(std) 1 SWITCH 4 IFD 17 CATCH OTHER 19 TOT IF 71 -> IF 1-Cond: 66 ** IF 2-Cond: 4 ** IF >= 3-Cond: 1 IF 2-Cond-> IF 1-Op/AND: 4 ** IF 1-Op/OR: IF 3-Cond-> IF 2-Op/AND: ** IF 2-Op/OR: 1 ** IF 2-Op/AND-OR: -------------------------------------------------------------------- == -!= - < - > - <= - >= NULL 4 - (4) - 1-7 - - - (8) -1 - - - - - () +1 - - - - - () VALUE 4-36 - 3-1 - - (44) TRUE 13 - (13) FALSE 1 - (1) Figura 3 Esempio: Analisi del software Apache 2.2.19 2.1.2 Modalità operative Il funzionamento dello strumento di parsing può essere schematizzato in tre fasi: 1) Isolamento delle chiamate alle funzioni di log ; 2) Stima della percentuale della quota di codice dedicata al logging rispetto a quella dei sorgenti ; 3) Identificazione delle strutture di controllo per la detection. La fase di isolamento è adempita mediante : a) Copia di tutti i sorgenti, ricevuti come primo parametro di input, in un unico file di 18

testo 6. È importante tener presente che essi non sono altro che dei file scritti in un certo linguaggio di programmazione e quindi contenenti commenti che possono inquinare l analisi. Per questo motivo, tale operazione è anticipata da una di decommentazione. Il file testuale così ottenuto è denominato file_error.txt ; b) Trascrizione : fissato un n, si copia per ciascuna funzione di log (memorizzata nella lista e fornita al tool come secondo parametro d ingresso) una quantità di codice che precede la chiamata di log di un numero n di righe nel file di testo file_log_error.txt. Tale file è utilizzato per individuare le strutture utilizzate per il rilevamento di errori. La fase di stima è realizzata attraverso il conteggio delle : righe filtrate dei sorgenti, memorizzate nel file file_error.txt ; righe estrapolate per l individuazione delle strutture di controllo e salvate nel file_log_errog.txt ; chiamate a funzioni di log presenti nel file_error.txt. 2.2 Problematiche e soluzioni proposte Le difficoltà incontrate nella progettazione dello script sono state: farsì che esso fosse indipendente dalla tipologia del sistema; la scelta del numero di righe da prelevare per la cattura delle strutture di detection. La soluzione proposta per il primo punto è stata quella di fornire i sorgenti da analizzare come parametri d ingresso. In particolare, per ogni sistema è necessario raccogliere tutti i sorgenti da esaminare in una directory e fornirla al tool come primo input. A questo punto nasce il problema legato all eterogeneità delle funzioni di log tra i vari sistemi. Un idea consiste nel memorizzare in una lista tutte le chiamate individuate e fornirla come secondo input. Per quanto riguarda la scelta del numero di righe da prelevare per l individuazione delle strutture di controllo si è pensato di rendere tale valore arbitrario e modificabile per altre esigenze di analisi e per questo sarà fornito in input, rappresentando quindi il terzo 6 Esempio alcuni dei sorgenti del software Apache sono : http_config.c, http_request.c, http_main.c 19

paramentro d ingresso. Tuttavia, nella nostra indagine la scelta di tale valore è il risultato di una serie di test : per ciascun sistema di elaborazione sono stati provati diversi valori fino a trovare quello che è risultato più idoneo. Sono state prelevate n righe antecedenti alle funzioni e memorizzate in un file testuale. Attraverso un ispezione di quest ultimo si è verificato qual era il valore che permettesse di catturare una quantità di strutture tale da ritenere l analisi attendibile. Le prove sono state realizzate con n=1, n=5, n=4, n=3 e n=2. Per n=1 è stata registrata un abbondanza di informazioni superflue che avrebbe reso lo studio inattendibile. Già scegliendo n=4, tale entità è risultata alquanto accettabile. Con n=3 si è verificato che in alcuni casi i costrutti venivano persi (ad esempio perchè le chiamate di logs sono anticipate da una serie di operazioni, quali il refresh di una variabile). La porzione di informazioni perse rispetto alla quota di chiamate analizzate è risultata tale da essere trascurabile. Analogamente per la razione di dati superflui. Con n=2, invece, il numero di costrutti persi è stato tale da rendere la nostra analisi incerta. In questo caso di studio i sistemi saranno analizzati con n=3. Sono riportati alcuni esempi dei pezzi di codici estrapolati con n=3: if (!reported && (active_threads == ap_threads_per_child)) { reported = 1; ap_log_error(aplog_mark, APLOG_NOERRNO APLOG_ERR, server_conf, "Server ran out of threads to serve requests. Consider " "raising the ThreadsPerChild setting"); Chiamata dʼattivazione estratta dai sorgenti di Apache 1.3.41 (http main.c, 616-6111) if (hostname.c_str()[] == ) { ctx.reporterror("hostname required on nodeid %d since it will " "act as server.", id1); Chiamata dʼattivazione estratta dai sorgenti di MySQL (393-397) if(path == strlen(path) == ){ ERROR_SET(fatal, NDBD_EXIT_INVALID_CONFIG, "Invalid configuration fetched. Configuration does not contain valid ", param_string); } Chiamata dʼattivazione estratta dai sorgenti di MySQL (Configuration.cpp 368-373) 2

A questo punto ci si aspetta che il file_log_error.txt abbia un numero di righe pari a n log* n (nel nostro caso n log*3), mentre invece non risulta così : sebbene in un quantità molto ridotta alcuni costrutti attivano in maniera sequenziale due o più logs. Quest'osservazione può essere utile nel caso in cui si voglia studiare la complessità del corpo dei costrutti di controllo. 2.3 Considerazioni per la fase di progettazione Come già anticipato nel Cap. 2.1.1, parte del compito del tool consiste nella catalogazione e nel conteggio di tutte le strutture utilizzate per il logging : IF, ELSE, CASE, IFDEFINE, CATCH e OTHER nel quale sono raccolti per default tutte quelle non elencate. La scelta di conteggiare anche i CATCH deriva dal fatto che i file sorgenti dei sistemi possono essere scritti in linguaggi che prevedono la gestione delle eccezioni per mezzo di blocchi try-catch (es. C++, Java). Per i costrutti IF, poichè essi sono i principali costrutti di controllo utilizzati nel meccanismo di logging, da come sarà anche illustrato nel capitolo successivo, viene effettuata un ulteriore catalogazione : IF composti da una condizione, IF composti da due condizioni e IF con un numero di condizioni maggiore di 2. Si è scelto di enumerare le condizioni limitatamente a n>2 (con n=n di condizioni) in quanto il numero di clausole così composte è molto ridotto, e quindi un ulteriore scomposizione non avrebbe fornito alcun contributo utile ai fini dell analisi. Per gli IF composti da 2 o più clausole sono stimate le possibili condizioni: IF con 1 AND, IF con 1 OR per quelli composti da 2 condizioni, IF con 2 AND, con 2 OR oppure con 1AND/ 1OR per gli IF con n>2. Un secondo passo della scomposizione degli IF consiste nell esaminare la struttura delle clausole : è eseguita la schedatura e il calcolo di ciascuna delle operazioni fattibili e dei i possibili valori coinvolti. Le operazioni possibili sono quelle di confronto : uguaglianza, disuguaglianza e monotonia lasca e stretta. Per quanto riguarda invece i possibili valori coinvolti, essendo questi una quantità infinita, è stato scelto di raggrupparli in tre categorie : quelli notevoli NULL,, 1 e -1 perchè usati normalmente non solo in operazioni di confronto ma anche in operazioni quali il set/reset di variabili, 21