Progetto e sviluppo di un sistema di rilevamento di anomalie su sistemi informatici basato sui log

Universit`a degli Studi di Trieste
DIPARTIMENTO DI INGEGNERIA E ARCHITETTURA
Corso di Laurea in Ingegneria Elettronica e Informatica, curriculum Applicazioni Informatiche
Progetto e Realizzazione di un Sistema di Rilevamento di
Anomalie su Sistemi Informatici Basato sui Log
Candidato:
Michael Fuser
Relatore:
Prof. Eric Medvet
Correlatore:
Dott. Alex Dagri
Anno Accademico 2019-2020

Ai miei genitori e ai miei nonni

Sommario
Il crescente sviluppo tecnologico a cui stiamo assistendo porta con sè moli
di dati che diventano sempre più imponenti. Se questi dati devono essere
analizzati da gruppi di persone con l'obiettivo di rilevare anomalie al loro
interno, è chiaro che questo compito diventi sempre più insostenibile. Nasce
perciò la necessità di progettare e realizzare un sistema automatico di ano-
maly detection che possa aancare l'uomo in questo impegnativo lavoro. Il
punto di partenza sono i le di log che vengono generati da un'applicazio-
ne, il punto di arrivo la segnalazione di problemi in un determinato giorno.
I passi che vengono eettuati in questo percorso sono il raggruppamento
di log entry in gruppi omogenei e il calcolo delle statistiche per ogni gior-
no e per ogni gruppo, quindi l'apprendimento del comportamento normale
dell'applicazione ricavato dalle statistiche calcolate. In tal modo si può ef-
fettuare una previsione sul giorno desiderato. Inne l'addestramento di un
modello che avendo a disposizione dati reali e dati predetti, assieme alla co-
noscenza pregressa delle anomalie, impari a distinguere autonomamente il
comportamento normale da quello anomalo.
Inoltre se c'è la necessità di operare su più installazioni dell'applicazione,
non è necessario ripetere la procedura ma basta fornire in input i le cor-
rispondenti ed il sistema riesce a gestire il tutto imparando un modello per
ogni installazione e fornendo una risposta per ognuna.
I risultati ottenuti dimostrano che una simile procedura può essere adot-
tata con buone probabilià di successo, attestandosi ad una precisione media
del 91% nella segnalazione di anomalie, e ad un tasso medio di solo il 14%
di mancata segnalazione di problemi.

Indice
1 Introduzione 1
2 Lavori Correlati 3
3 Approccio Adottato 5
3.1 Anonimizzazione dei log . . . . . . . . . . . . . . . . . . . . . 8
3.2 Clustering dei Log . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Preprocessing dei Log . . . . . . . . . . . . . . . . . . 13
3.3 Apprendimento del Comportamento . . . . . . . . . . . . . . 14
3.3.1 Serie Temporali . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Modello di Classicazione Supervisionato . . . . . . . . . . . 19
3.5 Indici di Performance . . . . . . . . . . . . . . . . . . . . . . . 24
4 Risultati 27
5 Sviluppi Futuri 36
6 Conclusioni 38
Bibliograa 39
iii

Elenco delle gure
4.1 Confronto tra F1 Score dei Modelli. . . . . . . . . . . . . . . . 33
4.2 Curva Precision Recall modello ottimo. . . . . . . . . . . . . . 34
iv

Elenco delle tabelle
4.1 Legenda alternative modelli . . . . . . . . . . . . . . . . . . . 30
4.2 F1 Score Modelli con Baseline 1 . . . . . . . . . . . . . . . . . 30
4.3 F1 Score Modelli con Random Forest . . . . . . . . . . . . . . 31
4.4 F1 Score Modelli con Linear Regression . . . . . . . . . . . . 31
4.5 F1 Score Modelli con SVM . . . . . . . . . . . . . . . . . . . 32
v

Capitolo 1
Introduzione
Al giorno d'oggi i sistemi informatici caratterizzano praticamente qualsiasi
realtà, dalle grandi organizzazioni al singolo cittadino, dal settore econo-
mico a quello manifatturiero, e specialmente quello informatico. Proprio
in questo settore si colloca Cybertec SRL, azienda leader in soluzioni soft-
ware ad elevate prestazioni nell'ambito della pianicazione della produzione
e ottimizzazione della Supply Chain, con conseguente riduzione dei costi,
massimizzazione della produttività e aumento del livello di servizio. In ot-
tica di quest'ultimo obiettivo svolge un'attività particolarmente importante
il support team, composto da esperti di assistenza col compito di aiutare
i clienti alle prese con malfunzionamenti software o anomalie del prodotto
venduto da Cybertec, CyberPlan Web. CyberPlan Web è un software ac-
cessibile via web, del quale per ogni cliente esistono una o più installazioni
(denite istanze). Uno dei compiti principali del team di support è quello di
cercare di risolvere problemi sollevati dai clienti, cosa che può avvenire o tra-
mite segnalazione telefonica o tramite apertura di un ticket, che evidenzia il
problema, su un portale dedicato. La dicoltà del task sta nell'andare a ve-
ricare se eettivamente la questione dipenda da un problema di CyberPlan
Web piuttosto che da tematiche a loro interne, e nel primo caso identicare
la causa scatenante per risolverla o richidere l'intervento del team di svilup-
po. Tuttavia, il crescente numero di clienti che si adano a Cybertec e il
continuo aumento delle moli di dati processati, rende il lavoro sempre più
complesso e progressivamente non gestibile. Quello che manca infatti in Cy-
bertec è uno strumento automatico e scalabile che possa aiutare gli esperti
di assistenza ad individuare se e su quali installazioni ci sono state anoma-
1

CAPITOLO 1. INTRODUZIONE 2
lie, idealmente evidenziando anche la motivazione del problema. Una tale
proprietà potrebbe garantire rilevamento e risoluzione in tempi più rapidi.
Ciò che caratterizza ogni installazione di CyberPlan Web è il fatto che
ogni qual volta accade un evento essa genera dei messaggi di log: stringhe
uni- o multi-linea elencate in ordine cronologico e salvate dinamicamente in
un le o più, quando è superata la dimensione massima di 10 MB. Con
evento si intende o un'operazione da parte dell'utente es. login, esecuzione
script o un'azione automatica backup, job schedulati. Ogni messaggio
è detto log entry.
Proprio a partire da questi le di log, attraverso l'analisi delle singole en-
try, le persone del team support cercano le soluzioni ai problemi che gli sono
stati segnalati, o in generale eettuano una analisi a campione per vericare
il funzionamento corretto delle installazioni. L'ambito in cui si può interve-
nire con un sistema automatico è dunque l'anomaly detection a partire dai
le di log. In eetti, avendo a disposizione una serie di le di periodi prece-
denti, nei quali è nota la normalità o anomalia di specici giorni, è possibile
istruire un sistema che autonomamente faccia queste distinzioni sull'ultimo
giorno. Così facendo, non solo i membri del team support aumenterebbero
la produttività, ma ci si muoverebbe sempre di più verso quella che è de-
nita manutenzione predittiva, ovvero la capacità di risolvere i problemi del
software prima ancora che provochino disagi all'utente.

Capitolo 2
Lavori Correlati
In letteratura è stato spesso arontato il problema dell'anomaly detection,
utile sia per garantire qualità e continuità del servizio oerto, sia per la
prevenzione di eventuali attacchi informatici; una tra le strategie più diuse
è quella di partire dall'analisi dai le di log.
Inizialmente l'analisi di questi le veniva svolta da sviluppatori od opera-
tori manualmente, che andavano a ricercare all'interno del singolo le quale
fosse la causa dell'anomalia, ma la crescente mole di dati dei sistemi moderni
rende sempre meno percorribile questa strada, sia in termini di tempo che di
risorse disponibili. Ecco che per ridurre tempi e sforzi si è iniziato a pensare
a strumenti automatici per il rilevamento dai log. Innanzitutto vi sono di-
stinzioni su come vengono trattate le log entry: Landauer e al. (2018) decide
per essibilità di utilizzare i raw logs, depurati solamente del timestamp o di
caratteri speciali; altri, come He e al. (2016) e Xu e al. (2009), utilizzano le
entry solo dopo averne estratto un pattern; altri ancora, come Andreasson
e C. (2015), aggirano il problema dell'identicazione del pattern utilizzando
distanze tra stringhe e n-grammi. Anche il tipo di anomalia che viene ri-
cercato non è sempre lo stesso ma esistono diverse sfumature: inizialmente
si possono andare a cercare le singole righe di log diverse da tutte le altre,
denite outliers; per questo scopo è suciente rappresentare le log entry in
uno spazio multidimensionale e utilizzare tecniche di riduzione di dimensioni,
come sostenuto da Juvonen e al. (2015).
Se invece il task fosse più complesso, come trovare anomalie sulle fre-
quenze o sulle sequenze di log, la necessità di raggruppare le entries in clu-
ster diventa necessaria. Esistono molti esempi di questo approccio: C'è chi
3

CAPITOLO 2. LAVORI CORRELATI 4
come Thaler e al. (2017) utilizza reti neurali per la formazione dei gruppi,
chi usa metriche basate sul numero di parole comuni nel messaggio, come
Zou e al. (2016) e Gurumdimma e al. (2015), e chi invece calcola distanze
basate sui singoli caratteri (Ren e al. (2018), Wurzenberger e al. (2017)).
Per quanto riguarda le anomalie sulle frequenze di messaggi, un approccio
interessante è quello di He e al. (2016), che fa uso di una matrice che con-
teggia gli eventi e determina se vi siano deviazioni dal normale numero di
occorrenze dei gruppi; relativamente alle sequenze anomale di messaggi un
esempio può essere il lavoro di Lin e al. (2016), che utilizza gli ID dei processi
per raggruppare entries appartenenti allo stessa sequenza.
Una buona parte di ricerche focalizza anche l'attenzione sull'analisi delle
serie temporali per il rilevamento di anomalie, come fatto da Du e Cao (2015),
che ricercano comportamenti inusuali creando serie temporali a partire dalle
frequenze degli eventi. Anche Landauer e al. (2018) si avvale dello studio
delle serie temporali per studiare l'evoluzione dei cluster nel tempo, utiliz-
zando un modello autoregressivo a media mobile; stesso modello che viene
utilizzato anche in prodotti commerciali come il software Datadog (Pomel e
al. (2010)), un servizio di monitoraggio basato anche sull'analisi dei singole
log entry e delle sequenze.
Complessivamente, il sistema di rilevamento di anomalie proposto in que-
sta tesi dierisce dai lavori sopra citati per una serie di motivi. Primo, non
mira alla individuazione degli outliers ma eettua una decisione su una -
nesta temporale di 24 ore (prevedendo comportamento normale o anomalo
per l'ultimo giorno); inoltre per comprendere a fondo il comportamento del-
l'applicazione sfrutta l'azione combinata di clustering e serie temporali; il
tutto per garantire maggiore robustezza al sistema. Inoltre non si limita ad
indviduare anomalie per un singolo sistema informatico ma può prendere in
input dati di più applicazioni e trattarli adattandosi al singolo caso, fornendo
in output anomalie per tutte le installazioni di input. Altro aspetto che dif-
ferenzia questo sistema dalla maggior parte di quelli sopra elencati è il fatto
che non solo si può denire un giorno come anomalo, ma si può anche fornire
indicazione di quale sia il cluster che ha causato l'anomalia; questo rende
sicuramente più facile e veloce andare ad intervenire per risolvere il proble-
ma, ipoteticamente anche prevenedo una segnalazione da parte del cliente.
Per questi motivi si ritiene che questo approccio sia un valido contributo allo
stato dell'arte corrente in ambito di anomaly detection.

Capitolo 3
Approccio Adottato
L'obiettivo che si pressa il sistema è quello di eseguire anomaly detection
sul comportamento delle installazioni dell'applicazione, sulla base dei le di
log di CyberPlan Web. I le hanno le seguenti caratteristiche:
ˆ sono formati da log entry che coprono un arco temporale di almeno 28
giorni
ˆ descrivono il comportamento dell'applicazione per quel periodo tem-
porale
Il comportamento per tutti i giorni eccetto l'ultimo è considerato normale.
Il comportamento nell'ultimo giorno può essere normale o anomalo: in fase
di training l'informazione è nota, in fase di applicazione è il modello a sug-
gerire la risposta. Inoltre, i le possono appartenere ad applicazioni diverse
e coprono durate e periodi temporali diversi.
Una log entry è rappresentata come un'unica stringa, che al suo interno
però contiene quattro informazioni:
ˆ Timestamp: indica quando è stato scritto il messaggio di log
ˆ Level: segnala il livello di gravità del messaggio(INFO, WARN, ER-
ROR,...)
ˆ Type: indica la tipologia di evento che ha scatenato la generazione
delle log entry (Auth, Backup,...)
ˆ Message: riporta una breve descrizione dell'evento accaduto
5

CAPITOLO 3. APPROCCIO ADOTTATO 6
Un esempio di log entry è il seguente:
[2020-07-30T06:53:55.025Z] info: [Script] Successfully
executed statement {user:386abf5616fd17c48edfa5e4e7bfbd4d,
id:7d8b9cd8-67d3-42ab-9301-f994af6173ca}
A partire da questo dataset si vuole arrivare ad avere una risposta sullo
stato delle installazioni nelle giornate considerate; per fare ciò, data la com-
plessità strutturale della soluzione, il modello è stato suddiviso in tre step
(più uno step 0). Innanzitutto i cosiddetti raw logs, ovvero i le singole righe
del le così come sono stampate, non possono essere utilizzati direttamen-
te, perché contengono dati sensibili dei clienti. Una operazione preliminare
(step 0) è perciò quella dell'anonimizzazione dei le, che permette di ot-
tenere gli stessi le ma con i dati sensibili sostituiti da un corrispondente
hash (sezione 3.1). Una volta anonimizzati, ci si chiede come possano esse-
re utilizzati questi le: non essendo lo scopo quello di identicare outliers
bensì anomalie giornaliere, pare evidente la necessità di un raggruppamento,
detto clustering, di entries con periodicità giornaliera (step 1) e il conseguen-
te calcolo di statistiche quotidiane. Dalle statistiche è possibile imparare il
comportamento normale dell'installazione (step 2), e dunque predire quello
dell'ultimo giorno, nel caso di normalità. Avendo a disposizione predizione e
valore attuale per l'ultimo giorno, e conoscendone a priori lo stato, si adde-
stra un modello che impara a classicare nuovi campioni con stato anomalo
o normale (step 3).
La prima fase è dunque quella del clustering delle entries, ovvero suddi-
visione in gruppi in base a dei criteri di distanza. Trattandosi di dati non
strutturati, l'operazione di partenza prevede l'individuazione di una serie di
feature da fornire all'algoritmo di clustering; in prima approssimazione, si
può prendere come unica feature la stringa rappresentante l'intera log entry.
Tuttavia, conoscendo la struttura delle entries, si può procedere all'estra-
zione di feature più sosticate, come il tipo e il messaggio, e raggruppare
in base a queste; per quanto riguarda il messaggio però, si sa che questo è
caratterizzato da una parte che si può denire ssa, rappresentante l'evento
descritto, e una parte parametrica, che contiene indicazioni come l'utente o
lo script che ha causato la generazione del messaggio. Sembra quindi sensato
sottoporre i messaggi ad una operazione di preprocessing per la rimozione

delle parti variabili con conseguente estrazione del pattern; nel computo del-
le feature allora è considerato anche il messaggio preprocessato. Queste ed
altre alternative sono spiegate nel dettaglio nella sezione 3.2.
Indipendentemente dal modello scelto per il raggruppamento, si può pro-
cedere con la seconda fase, di apprendimento del comportamento normale
dell'applicazione. A partire dai cluster complessivi ottenuti, quello che si
può fare è andare a guardare le dimensioni dei cluster contando solo le en-
try giorno per giorno; questa statistica viene quindi usata per imparare il
comportamento normale dell'applicazione no al penultimo giorno, ed esse-
re perciò in grado di eettuare una previsione di comportamento normale
sull'ultima giornata. Un primo modo per ricavare questa caratteristica è
quello di prendere i valori del conteggio di ogni cluster giorno per giorno
e calcolarne la media: in tal modo si avrà una stima del numero medio di
occorrenze per quel cluster, e questo sarà il valore atteso per l'ultimo giorno.
Un'altra strada percorribile è invece quella di utilizzare le serie temporali per
ricavare il comportamento dell'applicazione; una media infatti non riesce a
tener conto di trend o stagionalità sui dati, cosa che invece riesce utilizzando
una serie temporale. Anche al modello che impara la serie si possono fornire
diverse feature, e nel caso specico sono prese in considerazione da un lato
le statistiche dei giorni no al penultimo, dall'altro queste più le variabili
cosiddette esogene, che corrispondono alle occorrenze di tutti gli altri cluster
proprio per il giorno da predire, l'ultimo. Col primo metodo si dà solamente
importanza al cluster considerato, col secondo si dà anche importanza alle
relazioni che questo cluster può avere con gli altri individuati nel sistema.
Anche in questo caso tutte le opzioni elencate sono trattate in seguito, alla
sezione 3.3.
Inne, predetti i valori per i tutti i cluster per l'ultimo giorno, ricavati i
valori reali delle statistiche dell'ultimo giorno dai le di input e noto a priori
lo stato dell'applicazione, è possibile passare alla terza fase della costruzione
del sistema: il training di un modello supervisionato che prende in input un
insieme di feature e in output predice il comportamento per l'ultimo gior-
no: anomalo o normale. Come per le fasi precedenti, non ci si è limitati a
considerare una sola opzione ma sono state vagliate diverse possibilità: la
prima, che fornisce come feature valori predetti e attuali di tutti i cluster;
un'altra che utilizza come feature il valore assoluto della dierenza norma-
lizzata tra valore predetto e attuale per ogni cluster; un'ultima che considera

valore assoluto della dierenza diviso per la deviazione standard, normaliz-
zata. Oltre alla scelta delle feature adatte ci si occupa anche della scelta del
miglior modello di apprendimento. Le alternative sono trattate nel dettaglio
alla sezione 3.4.
Terminata la denizione del modello, viene analizzato quale sia il miglior
indice di performance per valutare i risultati (sezione 3.5). Nel capitolo dei
risultati, cap. 4, sono comparate le prestazioni di tutte le combinazioni di
modelli considerati, e viene indicato quale sia quello più performante e scelto
come modello nale.
Si procede quindi alla descrizione delle singole fasi in maniera più appro-
fondita.
3.1 Anonimizzazione dei log
Si è detto che, data la natura riservata di alcune informazioni all'interno dei
le, è necessaria una operazione di anonimizzazione di questi parametri.
Il procedimento consiste in primis nell'andare ad individuare i dati sen-
sibili contenuti nei le: per poter avere una lista completa di tutte le infor-
mazioni da anonimizzare sono stati analizzati più le nella versione originale
ed è stato richiesto supporto al team di assistenza, che si trova spesso a do-
ver lavorare con i suddetti le. Terminata l'analisi i dati sensibili sono stati
riconosciuti nei seguenti 3:
ˆ username
ˆ indirizzi IP
ˆ URL
Una volta identicate queste tre classi, si è passati all'individuazione di
tutte le istanze presenti all'interno di tutti i le: questa operazione è resa
possibile dalle espressioni regolari, ovvero sequenze di simboli che identicano
insiemi di stringhe. Un esempio di espressione regolare, che va selezionare
tutti gli username e in tutte le forme presenti preceduti e seguiti da apici,
da doppi apici, da spazi bianchi, da due punti, eccetera è il seguente:
([uU]ser(name)??:?.?['])(.+?)(['])

La totalità delle stringhe selezionate è stata dunque sostituita da un
corrispondente versione hashed. Un hash è una funzione non invertibile
che mappa una stringa di lunghezza arbitraria in una stringa di lunghezza
predenita. Esistono numerosi algoritmi che realizzano funzioni hash con
particolari proprietà che dipendono dall'applicazione.
Una funzione hash ha le seguenti proprietà:
1. resistenza alla preimmagine: è computazionalmente intrattabile la ri-
cerca di una stringa in input che dia un hash uguale a un dato hash;
2. resistenza alla seconda preimmagine: è computazionalmente intratta-
bile la ricerca di una stringa in input che dia un hash uguale a quello
di una data stringa;
3. resistenza alle collisioni: è computazionalmente intrattabile la ricerca
di una coppia di stringhe in input che diano lo stesso hash.
Nel caso specico è stata utilizzata la funzione hash MD5: essa produce
in output una stringa di 128bit. Terminata la sostituzione dei dati sensibili
col rispettivo hash, ciò che si ottiene sono dei le per il resto identici a
quelli di partenza, ma dai quali è ragionevole pensare non si possano estrarre
informazioni compromettenti per il cliente in tempi ragionevoli.
3.2 Clustering dei Log
Come detto, il punto di partenza nella formulazione del modello nale è il
clustering delle log entry. Con questo si intende un insieme di tecniche di
analisi multivariata dei dati volte alla selezione e raggruppamento di elementi
omogenei in un insieme di dati, basandosi su misure relative alla somiglianza
tra elementi. Molto spesso questa somiglianza è intesa in termini di distanza
in uno spazio multidimensionale.
Esistono diverse classicazioni di clustering, una delle quali è basata sul
tipo di algoritmo utilizzato per dividere lo spazio:
ˆ clustering partizionale: viene creata una partizione delle osservazioni
minimizzando una certa funzione di costo;
ˆ clustering gerarchico: produce una rappresentazione dei cluster non
piatta ma ad albero;

ˆ clustering density-based: il raggruppamento avviene analizzando l'in-
torno di ogni punto nello spazio;
Ci si chiede dunque quale sia la strategia più corretta da adottare nel
caso di raggruppamento di messaggi di log.
Per quanto riguarda gli algoritmi di clustering partizionale, questi soli-
tamente individuano k punti di partenza nella generazione dei cluster, detti
centroidi, e procedono alla formazione dei gruppi assegnando il singolo punto
al centroide più vicino. Questo signica che innanzitutto il numero di cluster
deve essere noto a priori, e che questi algoritmi centroid-based non possiedo-
no la nozione di outlier, ovvero tutti i punti saranno assegnati ad un cluster
(senza eventualmente crearne uno nuovo) anche se non appartengono a nes-
suno. Chiaramente nel campo dell'anomaly detection, cioè il caso in esame,
questo potrebbe rappresentare un grave problema. Inoltre questi algoritmi
funzionano bene quando la distanza utlizzata è quella classica, ovvero quella
euclidea, mentre peggiorano le prestazioni nei casi di altre metriche
1.
Un esempio è l'algoritmo K-Means.
Relativamente agli algoritmi di clustering gerarchico ciò che si può dire
è che mirano a denire una gerarchia tra cluster, in modo da avere i gruppi
principali e all'interno di ogni gruppo avere una ulteriore suddivisione; que-
sti algoritmi funzionano bene sia con distanza euclidea sia con altri tipi di
distanza (Manhattan, Mahalanobis).
Un esempio è l'algoritmo Agglomerative Clustering.
Gli algoritmi density-based funzionano molto bene in ambienti con poche
dimensioni, e in eetti in questo caso orono grande controllo per raggruppa-
mento e interpretazione dei cluster. Essi operano identicando zone dense
di punti, permettendo di avere un numero di gruppi arbitrario e di numero-
sità arbitraria. In tal modo è anche possibile l'identicazione di outliers o
cluster di outliers.
Un esempio è l'algoritmo DBSCAN.
Per capire quale tipologia di clustering utilizzare, è fondamentale cono-
scere i dati che hanno a disposizione. Avendo a che fare con stringhe, sembra
evidente la necessità di utilizzare una metrica custom per il calcolo delle di-
stanze. Inoltre il numero di cluster non è noto a priori, e nel caso di presenza
di outliers vorremmo che questi non nissero in mezzo ad altri gruppi. Inne
1
vedi https://stats.stackexchange.com/questions/81481/why-does-k-means-clustering-
algorithm-use-only-euclidean-distance-metric

non sembra necessaria un suddivisione dei cluster ad albero, e in partenza
è presente una sola dimensione (la stringa corrispondente alla log entry).
Viene utilizzato dunque clustering density-based, nello specico l'algoritmo
DBSCAN, sia per il fatto che, a dierenza di K-Means o Agglomerative Clu-
stering non richiede che il numero di cluster venga specicato a priori, sia
perché si è nel caso di bassa dimensionalità ed è nota la possibilità di cluster
con dimensioni molto diverse.
Nello specico all'algoritmo DBSCAN si può fornire in input l'informa-
zione che le distanze sono calcolate in maniera personalizzata e che quindi
non eettuerà esso il calcolo con metrica euclidea o altro e che riceverà
in input una distance matrix: essa è la matrice delle distanze tra tutti gli
elementi, calcolata a priori. L'algoritmo quindi conoscendo tutte le distanze
riesce a formulare una proposta di raggruppamento.
I parametri che sono forniti a DBSCAN sono i seguenti:
ε: massima distanza tra due campioni per essere considerati vicini
min samples: numero minimo di campioni vicini ad un punto per
considerarlo come capace di generare un cluster
metric: la metrica per il calcolo delle distanze
Per quanto riguarda la metrica, il valore fornito è precomputed, e nel
momento in cui si va ad addestrare il modello il l'input è la sopra citata
distance matrix, matrice di distanze già calcolate. Persiste però il problema
di come calcolare le distanze tra due stringhe: in letteratura sono presenti
numerose alternative, molte delle quali testate proprio su messaggi di log da
Wurzenberger e al. (2017), che identica come metrica più adatta la distanza
di Levenshtein
2. Tuttavia data la natura non strutturata e variegata dei
messaggi di log, si è scelto di prendere in considerazione la edit distance ma
normalizzata alla massima lunghezza tra due stringhe x e y
normalized_edit(x, y) =
edit(x, y)
maxi∈(x,y)length(i)
2
La distanza di Levenshtein, o edit distance, tra due stringhe A e B è il numero mi-
nimo di modiche elementari che consentono di trasformare la A nella B. Per modica
elementare si intende la cancellazione di un carattere, l'inserimento di un carattere o la
sostituzione di un carattere con un altro.

per avere sempre valori tra 0 e 1, in modo da mitigare gli eetti che ve-
drebbero due stringhe molto corte ma totalmente diverse avere distanza an-
che minore di due stringhe molto più lunghe e con un numero superiore di
caratteri in comune.
Nell'andare a calcolare la matrice delle distanze tra log entry come unica
grande stringa, ci si è accorti della dicoltà di proseguire verso questa strada:
il numero di messaggi, dell'ordine di grandezza minimo delle centinaia di
migliaia, non permette il completo riempimento della matrice delle distanze.
La memoria RAM richiesta infatti è di gran lunga superiore a quella in
dotazione a tutto il personale di Cybertec.
mem = 105
× 105
× 64 b = 80 GB
Dovendo cercare alternative per la prosecuzione del lavoro, si è ragiona-
to sulla natura dei messaggi di log: non essendo come frasi del linguaggio
parlato ma proposizioni in gran parte ripetute, si è osservato come in realtà
ai ni del clustering siano necessari solo i messaggi diversi tra loro. Due
messaggi identici infatti avranno distanza 0 e saranno raggruppati assieme.
Inoltre, in letteratura sono frequenti operazioni di preprocessing sui log per
estrazione di un pattern: i messaggi infatti i possono essere scomposti in due
parti, ovvero pattern e parametri. Il pattern denisce l'evento, i parame-
tri ciò che ha causato l'evento o le sue caratteristiche. Si è optato dunque
di andare verso questa direzione: estrazione di un pattern e clustering solo
tra pattern estratti dierenti. Ecco che quindi, con questi accorgimenti, si
ottiene il primo modello di clustering sulle entry.
Volendo però vagliare più alternative possibili per poi scegliere quella
più conveniente, è stata considerata la struttura delle log entry: è vero che
sono dati non strutturati ma al loro interno contengono svariate informa-
zioni che si possono estrarre. Come evidenziato nel capitolo 1, ogni entry è
una concatenazione di stringhe tra cui messaggio, tipo e livello; il secondo
modello considerato utilizza come feature una combinazione dei primi due.
Per quanto riguarda il livello infatti, si è notato che messaggi appartenenti
allo stesso ambito niscono spesso in livelli diversi, e che il livello error non
viene di norma utilizzato come segnalazione di un comportamento anomalo.
Con queste premesse, si ritiene che i due aspetti più caratterizzanti di una
entry, e alla base del secondo modello, siano tipo e pattern estratto dal mes-

saggio. In questo caso la distanza è calcolata come combinazione lineare tra
due distanze: quella tra messaggi preprocessati edit distance normalizzata
e quella tra i tipi 0 se dieriscono, 1 se coincidono.
3.2.1 Preprocessing dei Log
Una operazione preliminare introdotta è un preprocessing che cerchi di estrar-
re il pattern dai messaggi, così da calcolare la distanza come combinazione
lineare tra tipo e pattern del messaggio. A tal proposito si può utilizzare
l'algoritmo DRAIN, introdotto per la prima volta da Zheng e al. (2017);
questo algoritmo prende in input una sequenza di stringhe tra le quali rie-
sce ad individuare le strutture ricorrenti e sostituire quelle variabili con una
wildcard, *. Il meccanismo alla base di DRAIN consiste nel creare un
cosiddetto parse tree, suddiviso in tre strati:
ˆ la radice
ˆ i nodi interni
ˆ le foglie
Radice e nodi interni codicano regole per guidare il processo di ricerca di
pattern; ogni path di ricerca termina con delle foglie, contenenti una lista di
gruppi di log; all'interno di queste liste troviamo i pattern estratti dall'algo-
ritmo. La particolarità di DRAIN sta nel fatto che per motivi prestazionali
la profondità delle foglie è la stessa ed è ssata a priori. Il risultato di questo
step è una riduzione del numero totale di messaggi dierenti. Messaggi di
log di questo tipo infatti
A) Local client TtjgFUuO1Te3Pv2OAAFm connected, user
a1834f6162bcbe1d57509c4acde03d5a, ip
7844cc1f60c5dce7eeea287e5aef7a27
B) Local client C4Z7wYtk96YRAPgMAAFl connected, user
386abf5616fd17c48edfa5e4e7bfbd4d, ip
7844cc1f60c5dce7eeea287e5aef7a27
vengono ricondotti a questo
C) Local client * connected, user *, ip *

A livello pratico questo si traduce in una distanza 0 tra A e B, ovvero che
niranno sicuramente nello stesso cluster. In realtà A e B potebbero a tutti
gli eetti essere considerati lo stesso messaggio C, motivo per il quale ai ni
del raggruppamento si deduce che non è obbligatorio utilizzare tutti i log, ma
solamente tutti le log entry diverse. Da qui la possibilità in fase di clustering
di calcolo della distance matrix, che in seguito al preprocessing risulterà
avere dimensioni gestibili dai computer utilizzati. A seconda dei parametri
con cui è inizializzato l'algoritmo DRAIN possono essere individuati numeri
dierenti di pattern, che risulteranno in numeri dierenti di messaggi distinti;
I parametri che sono forniti all'algoritmo DRAIN sono i seguenti:
1. depth: profondità dei nodi foglia dell'albero
2. similarity threshold: soglia di somiglianza oltre la quale un'entry viene
associato ad un gruppo esistente
Come nel caso dell'algoritmo di clustering, anche in questa circostanza
sono testati più valori per ognuno dei parametri per stabilire i migliori in
relazione al risultato nale.
Qualunque sia l'opzione di clustering scelta tra quelle elencate, ciò che si
ottiene per ogni le è una lista di labels, ciascuna associata al messaggio di
log corrispondente e rappresentante il gruppo di appartenenza della entry.
3.3 Apprendimento del Comportamento
A partire dai gruppi identicati tramite clustering quello che si vuole fare è
apprendere il comportamento normale dell'applicazione; quando si parla di
comportamento si intende il numero di eventi di vario tipo che accadono ogni
giorno, che può venire rappresentato come la numerosità delle occorrenze
giornaliere per ogni cluster. L'obiettivo di questa fase sarà, per ogni le,
imparare il comportamento per tutti i giorni tranne l'ultimo, e con le nozioni
apprese andare a predire il numero di elementi per l'ultimo giorno.
Parallelamente, sempre per ogni le, è possibile ricavare le statistiche
reali dell'ultimo giorno. Il risultato sarà avere da un lato le previsioni e
dall'altro i valori reali, che serviranno per la prossima fase.
Un primo modello di apprendimento basato sul passato può essere rap-
presentato dal calcolo della media: avendo a disposizione almeno 28 giorni di

statistiche per ogni gruppo, si è pensato di calcolare il valor medio di tra que-
sti dati. Per uniformità di notazione si assume che i le coprano uno stesso
intervallo temporale, così che N sia l'ultimo giorno per tutti. Relativamente
ad ogni le si ha
µj =
N−1
k=0
akj
dove akj è il numero di occorrenze del cluster j per il giorno k, e µj il
valor medio del cluster j; i giorni vanno da 0 a N − 1.
Da qui
forecastj = µj
la previsione del giorno N per il cluster j in ogni le sarà esattamente il valor
medio tra tutti i giorni precedenti.
All'applicazione di questa strategia però si può obiettare che in questo
modo valori più e meno recenti avrebbero lo stesso peso nella determinazione
del valore predetto: ecco che si potrebbe pensare ad una media pesata con
peso inversamente proporzionale alla distanza temporale dall'ultimo giorno.
Ma ancora questo non riuscirebbe a tenere conto di eventuali trend, ci-
clicità o stagionalità nei dati, motivo per il quale sembra ragionevole andare
ad esplorare l'alternativa delle serie temporali.
3.3.1 Serie Temporali
Un secondo modello perciò, alternativo al primo, è quello di ricavare il com-
portamento normale dell'applicazione grazie allo studio delle serie temporali.
Uno dei modelli più utilizzati, di cui fa uso anche il software Datadog, che
si occupa di log analysis, outlier e anomaly detection, è il modello SARI-
MA(X). Prima di parlare di questo modello è necessario introdurre la sua
versione base, e ancor prima fare una panoramica sulle serie storiche.
Una serie storica (o temporale) è la registrazione cronologica, non ne-
cessariamente con campionamento uniforme, di osservazioni sperimentali di
una variabile. Da questa serie di dati si vuole estrarre informazione per la
caratterizzazione del fenomeno in osservazione e per la previsione di valori
futuri. Indicando con Y il fenomeno, si indica con Yn un'osservazione al
tempo n, con n che varia tra 1 e N dove N è il numero complessivo degli
intervalli considerati. L'ipotesi più semplice che si può fare sulla serie è che
sia stazionaria, ovvero che la sua distribuzione di probabilità congiunta non

cambi se viene traslata nel tempo; in altre parole parametri come media e
varianza non cambiano nel tempo.
In tal caso è possibile utilizzare un modello ARMA per caratterizzare
completamente la serie ed essere in grado di eettuare previsioni. Molte
volte però le serie non sono stazionarie per la presenza al loro interno di
diverse componenti:
ˆ Trend: componente che varia lentamente nel tempo e determina il
livello della serie
ˆ Stagionalità: una o più componenti periodiche, ovvero che si ripresen-
tano uguali o quasi a distanza ssa nel tempo
In questi casi è abbastanza comune per non perdere i vantaggi assicurati
dalla stazionarietà (come la facilità di previsione), cercare di trasformare
la serie originale in una serie stazionaria: questo obiettivo viene raggiunto
con estensioni del modello ARMA, denite rispettivamente ARIMA in
presenza di trend e SARIMA per trend e stagionalità.
La versione base, il modello ARMA (Auto Regressive Moving Average)
fornisce per una serie stazionaria istante per istante il valore di uscita basan-
dosi su valori precedenti sia di input che di output. Groebner e al. (2017) ha
stimato che il modello, inizialmente impreciso per mancanza di dati passa-
ti, raggiunge una stabilità oltre la quale non modica il suo apprendimento
con un numero di campioni non inferiore al periodo di quattro settimane, se
ciò che si vuole prevedere è il singolo giorno; da qui il vincolo iniziale sulla
durata rappresentata dai le di almeno 28 giorni.
Una generalizzazione del modello ARMA è ARIMA, che appartiene alla
famiglia dei processi lineari non stazionari; la I infatti sta per Integrated,
ed è associata al fatto di eseguire dierenze di d-esimo ordine ai dati con
trend per renderli stazionari. Spesso ARIMA viene presentato come ARI-
MA(p,d,q), questo perché quelli sono i tre parametri che caratterizzano to-
talmente il modello e la serie temporale in esame. Il signicato dei parametri
è il seguente:
1. p: il numero di osservazioni precedenti incluse nel modello
2. d: il numero di dierenze richieste per rendere la serie stazionaria
3. q: la grandezza della nestra di media mobile

Un'ulteriore estensione del modello è SARIMA, dove la S sta per Seaso-
nal, che permette di trattare serie temporali con trend, non stazionarie, e con
eventuali stagionalità al loro interno. La prima alternativa nello studio del
comportamento del sistema è rappresentata proprio dal modello SARIMA.
In questo caso per la previsione del valore desiderato, per ogni cluster ven-
gono forniti in input solo i valori precedenti di numero di occorrenze di quel
cluster, ovvero siamo nel caso di serie temporali univariate. Inoltre ai tre
precedenti si aggiungono altri quattro parametri, tanto che spesso si trova
indicato SARIMA(p,d,q)(P,D,Q)m:
1. P: ordine del termine di autoregressione stagionale
2. D: ordine di dierenza stagioale
3. Q: ordine del termine di media temporale stagionale
4. m: numero di time steps per il singolo periodo stagionale
Se per la stagionalità il parametro m deve essere fornito a priori (m=12
per stagionalità annuale se lo step è mensile, m=7 per settimanale se lo
step è giornaliero), per tutti e sei gli altri parametri è suciente indicare
un range plausibile di appartenenza e il modello vaglia tutte le possibilità
e opta per i parametri che vanno a minimizzare una parametro noto come
AIC. L'AIC (Akaike Information Criterion) fornisce una misura della qualità
della stima di un modello tenendo conto sia della bontà che della complessità
del modello; generalmente più basso è l'AIC e migliore è il modello.
In conclusione dunque per addestrare il modello si applica SARIMA che
impara dalla serie temporale di input autoregolando sei dei sette parametri,
e inne si fa la previsione per l'ultimo giorno.
Esiste un'altra alternativa a SARIMA, che vale la pena prendere in con-
siderazione: prima si è parlato di serie temporale univariata, ma in realtà
per ogni giorno del quale si ha a disposizione la statistica di un cluster, si
ha anche a disposizione le statistiche di tutti gli altri cluster, e una cosa
plausibile è che le numerosità di alcuni siano correlate alle numerosità di
altri. Sembra interessante allora testare il modello con una serie temporale
multivariata: in questo caso di parla di SARIMAX, ovvero SARIMA with
eXogenous variables.

Chiaramente non è detto che la variabile da predire dipenda numerica-
mente da tutte le altre, ma anzi l'aggiunta di informazioni errate e/o ridon-
danti potrebbe rallentare o addirittura peggiorare il modello. Si può quindi
ragionevolmente andare a cercare la correlazione tra le numerosità dei clu-
ster e in fase di applicazione del modello utilizzare solo le statistiche dei
cluster che hanno una relazione di dipendenza con quello in esame. Que-
sta operazione prende il nome di feature selection e viene eseguita per ogni
gruppo.
Nel caso specico per eseguire feature selection viene utilizzato il p-value
e vericata o rigettata la cosiddetta null hypothesis. Null hypothesis è una
dichiarazione generale che non ci sono relazioni tra due fenomeni misurati;
il contrario, alternative hypothesis, aerma che la variabile indipendente in-
uenza la variabile dipendente, ragion per cui la null hypothesis deve essere
rigettata. Il p-value aiuta a determinare il signicato dei risultati riguardo
la null hypothesis: è compreso tra 0 e 1 e più piccolo è, più forte è l'evidenza
che bisogna rigettare la null hypothesis a favore della alternative hypothesis,
ovvero esiste relazione tra le variabili considerate.
In particolare
ˆ Un p-value 0.05 è statisticamente signicativo. Indica grande evi-
denza contro la null hypothesis, essendoci meno del 5% di probabilità
che sia corretta.
ˆ Un p-value 0.05 non è statisticamente signicativo e indica forte
evidenza di null hypothesis.
L'input di quest'ultimo modello sarà allora composto dalla serie di stati-
stiche del cluster da prevedere per i giorni [1,N-1], e dalla serie di statistiche
nell'ultimo giorno N dei soli cluster con p-value minore della soglia 0.05, che
potebbero aiutare nella comprensione del comportamento.
La fase di apprendimento dello status normale termina con la predizio-
ne per ogni cluster del numero di occorrenze nell'ultimo giorno N. De-
nite tutte le opzioni per ottenere questo output, è possibile procedere con
l'implementazione dell'ultima parte del modello, il modello di classicazione
supervisionato.

3.4 Modello di Classicazione Supervisionato
Quello che si pregge di ottenere quest'ultima fase è un modello addestrato
al riconoscimento di anomalie e comportamento normale; per fare ciò, viene
utilizzato un modello di classicazione supervisionato.
L'apprendimento supervisionato è una tecnica di machine learning che
mira ad istruire un sistema informatico in modo da consentirgli di elaborare
automaticamente previsioni sui valori di uscita di un sistema rispetto ad un
input. La fase di addestramento avviene sulla base di una serie di esempi
ideali, costituiti da coppie di input e di output.
Esso si dierenzia dall'apprendimento non supervisionato perché a que-
st'ultimo in fase di training sono forniti solo esempi non annotati, in quanto
le classi non sono note a priori ma devono essere apprese automaticamen-
te. Un esempio di quest'ultimo è proprio il clustering utilizzato ad inizio
capitolo.
L'apprendimento automatico in base alla forma dell'output fornito può
essere diviso in due categorie:
ˆ classicazione: l'output è discreto
ˆ regressione: l'output ha un dominio continuo
Nel caso in esame quello che si vuole fare è classicare la giornata come
anomala o normale: è un problema di classicazione binaria.
Chiaramente a priori non si può avere indicazione di quali siano le migliori
feature, perciò la strada percorribile è quella di provare più combinazioni e
ricavare quelle più redditizie.
Gli esempi, formati da coppie input-output, che vengono forniti al mo-
dello per l'addestramento sono ricavati dai le (un esempio per ogni le).
Quello che segue riguarda il singolo esempio.
L'output è rappresentato da 0 o 1, normale o anomalo, ed è noto in
partenza.
L'input invece può essere di vari tipi, a seconda delle feature che vengono
selezionate per l'apprendimento.
Una prima alternativa di input che può essere fornito al modello è il
seguente:
ˆ
∀j
forecastj
Forecastj

ˆ
∀j
actualj
Actualj
ˆ giorno della settimana d ∈ [0, 6]
avendo denito forecastj come la previsione per l'ultimo giorno per il cluster
j e Forecastj come il massimo tra tutte le previsioni per l'ultimo giorno per
il cluster j. Analogamente actualj è il valore attuale per l'ultimo giorno per
il cluster j e Actualj il massimo tra i valori attuali per l'ultimo giorno e
cluster j.
I primi sono predetti al termine della fase di apprendimento del compor-
tamento (sez. 3.3); i secondi calcolati dall'ultimo giorno dei le di input;
il terzo inserito perché sembra evidente che quelle che sono le statistiche di
un giorno festivo possono non essere le stesse di un giorno feriale, e questo
potrebbe aiutare nelle previsioni. La normalizzazione è guidata dal fatto che
vorremmo che tutte le feature avessero lo stesso peso: se prendessimo i valori
non normalizzati invece avremmo valori dell'ordine di grandezza delle unità
e altri delle migliaia, altri delle centinaia.
Un accorgimento che può essere adottato come alternativa è quello di for-
nire per ogni gruppo invece dei due valori attuale e predetto, la loro dierenza
normalizzata.
Le feature allora sarebbero
ˆ
∀j
forecastj − actualj
Gapj
con forecastj e actualj come sopra e Gapj la massima dierenza tra predetto
e attuale per il cluster j, considerando ogni le i.
∀j, Gapj = maxi{forecastij − actualij}
In realtà questa formulazione non tiene conto della condenza con la
quale è stato predetto un valore: nel caso di cluster con numerosità sempre
costante, una dierenza normalizzata di 1 dovrebbe avere importanza mag-
giore di una dierenza normalizzata di 1 nel caso di cluster con numerosità
fortemente variabile. Ma non solo: anche per lo stesso cluster ci potrebbero

essere giorni della settimana in cui le occorrenze hanno valore costante, e altri
in cui le occorrenze sono molto più variabili. Da qui l'intuizione di dividere
la dierenza per la deviazione standard; non quella del cluster, ma quella del
cluster nello specico giorno della settimana, e conseguente normalizzazione.
Un'ultima opzione di feature allora può essere questa:
ˆ
∀j
forecastj−actualj
stdjd
StdGapjd
avendo denito stdjd come la deviazione standard del cluster j nel giorno del-
la settimana d, e StdGapjd il massimo valore per il cluster j della dierenza
tra attuale e predetto normalizzato alla deviazione standard, considerando
ogni le i.
∀j, d StdGapjd = maxi
forecastij − actualij
stdijd
Finora si è parlato dell'algoritmo di apprendimento come una scatola
nera che impara un modello; questo da sequenze input-output riesce a predire
l'output quando gli viene fornito solo l'input. In realtà esistono moltissimi
classicatori supervisionati, motivo per il quale in questa trattazione si è
scelto di ridurre l'analisi ai seguenti tre:
ˆ Random Forest
ˆ Regressione Lineare
ˆ SVM
Il Random Forest è un classicatore ottenuto dall'aggregazione tramite
bagging
3 di alberi di decisione.
Un albero di decisione è un modello predittivo, nel quale ogni nodo in-
terno rappresenta una variabile, un arco verso un nodo glio rappresenta
un possibile valore per quella proprietà e una foglia il valore predetto per la
variabile obiettivo a partire dai valori delle altre proprietà, che nell'albero è
3
Nel bagging più modelli dello stesso tipo vengono addestrati su dataset diversi,
ciascuno ottenuto dal dataset iniziale tramite campionamento casuale con rimpiazzo

rappresentato dal cammino dal nodo radice al nodo foglia. Normalmente un
albero di decisione viene costruito utilizzando tecniche di apprendimento a
partire dall'insieme dei dati iniziali (il dataset), il quale può essere diviso in
due sottoinsiemi: il training set sulla base del quale si crea la struttura del-
l'albero e il test set che viene utilizzato per testare l'accuratezza del modello
predittivo così creato.
Le foreste casuali si pongono come soluzione che minimizza l'overtting
del training set rispetto agli alberi di decisione.
La regressione lineare rappresenta un metodo di stima del valore atteso
condizionato di una variabile dipendente Y , dati i valori di altre variabili
indipendenti, X1,...,Xk. Il modello di regressione lineare è il seguente:
Yi = β0 + β1Xi + ui
dove β0 + β1X è detta retta di regressione e ui l'errore statistico.
L'algoritmo Support-Vector Machines (SVM) è basato sull'idea di trovare
un iperpiano
4 che divida al meglio i dati in due classi. I Support Vector
sono i punti dati più vicini all'iperpiano: se vengono rimossi o modicati
alterano la posizione dell'iperpiano divisorio. Il margine invece è denito
come la distanza tra i vettori di supporto di due classi dierenti; a metà di
questa distanza è tracciato l'iperpiano. Inizialmente l'algoritmo SVM è stato
proposto per costruire un classicatore lineare, ma non sempre ci si trova ad
avere a che fare con dataset lineari: per questa ragione è stato ideato un
uso alternativo per SVM, il metodo kernel. Esso si approccia al problema
mappando i dati di uno spazio multidimensionale trasformandoli nella forma
richiesta in un insieme di punti dello spazio euclideo.
In generale il kernel è denito come
K(x, y) = f(x), f(y)
dove K è la funzione di kernel, x e y sono vettori di input a dimensione p. f è
usato per mappare l'input dallo spazio p-dimensionale a uno q-dimensionale
di più alto livello, mentre , indica il prodotto scalare.
4
per classicazione con solo due dimensioni spaziali esso è una linea, con tre dimensioni
è un piano, con più dimensioni è denito genericamente iperpiano

Nel caso specico le SVM saranno utilizzate con il kernel RBF (Radial
Basis Function), detto anche kernel gaussiano.
K(xi, yj) = e(−γ xi−yj
2
)
Il kernel RBF contiene il parametro γ: un piccolo valore di γ fa sì che il
modello si comporti come un SVM lineare, mentre un grande valore rende il
modello fortemente inuenzato dagli esempi dei Support Vector.
Indipendentemente dal modello utilizzato, esso produce una regola che
consente di elaborare previsioni per future unità di cui sono stati osservati
solo i valori delle variabili indipendenti. Le previsioni sono dei punteggi che
misurano il grado di condenza con cui le osservazioni appartengono ad una
certa classe, che, per convenzione, si assume essere quella di maggior inte-
resse. Per alcuni modelli, come quello in esame, la previsione rappresenta
una stima della probabilità P di appartenenza ed è contenuta nell'interval-
lo più ristretto [0, 1]. Si stabilisce la categoria prevista Y introducendo
un'opportuna soglia di classicazione th reale tale che l'output fornito sia
discreto:
Y =



1 se P th
0 altrimenti
(3.1)
La scelta più naturale per la soglia è 0.5; tuttavia la classe positiva è
quella di maggior interesse e anche scarsamente rappresentata come nume-
rosità rispetto alla classe normale. In tal caso il modello potrebbe eettuare
molte più previsioni errate sulla classe minoritaria piuttosto che su quella
prevalente e di minor interesse. Per non dover condizionare la valutazione di
un modello ad un unico valore della soglia che è oltretutto problematico da
denire, una valida alternativa sarà quella di testare in maniera automatica
più soglie e selezionare quella che garantisce maggiori probabilità di successo.
Tutte le alternative di feature e modelli introdotti in questo capitolo
saranno testate per determinare il miglior modello possibile. La scelta del
criterio col quale decidere viene giusticata nella sezione seguente.

3.5 Indici di Performance
Dopo aver elencato più alternative per ogni fase, giunge il momento di va-
lutare quale tra tutte le combinazioni sia la più conveniente, ma per fare
questo serve denire il giusto o i giusti indici di performance per il problema
in questione. Questo capitolo si occupa della giusticazione della scelta di
tale indice.
Innanzitutto si può avere indicazione di ciò che si ha predetto corretta-
mente e ciò che si ha predetto erroneamente con la matrice di confusione:
essa non è propriamente un indice di performance ma quasi tutti gli indici
sono basati su ciò che è contenuto al suo interno.
1. True Positives (TP): quando la classe attuale è Anomalia e la predetta
è Anomalia
2. True Negatives (TN): quando la classe attuale è Normale e la predetta
è Normale
3. False Positives (FP): quando la classe attuale è Normale e la predetta
è Anomalia
4. False Negatives(FN): quando la classe attuale è Anomalia e la predetta
è Normale
A partire da queste quattro casistiche, si possono denire diversi indici. Pri-
ma delle denizione degli indici è necessario aver chiaro quello che si vuole
dal sistema, ovvero se i casi sopra elencati hanno tutti lo stesso peso. Si-
curamente il fatto di classicare un giorno normale come tale è importante,
ma sembra molto più importante riuscire ad identicare un giorno anoma-
lo come tale; non identicare un'anomalia infatti comporterebbe perdita di
servizio per l'utente, di tempo nell'andare a ricercarla eventualmente in un
secondo momento, nonchè perdite economiche. Si può aermare dunque che
si cercheranno indici di performance che danno più peso a TP e FN piuttosto
che a TN e FP.
Il primo indice della lista è l'accuratezza,
accuracy =
TP + TN
TP + FP + FN + TN
denita come il numero di predizioni corrette eettuate dal modello su tutte
le predizioni. L'accuratezza attribuisce lo stesso peso alle due classi, e si

deve utilizzare quando le classi nei dati sono circa bilanciate (es. 60/40); è
sconsigliato utilizzarla in caso contrario, che è proprio il caso in esame, dove
le anomalie sono in numero nettamente inferiore ai comportamenti normali,
e dove gli ultimi sono di scarso interesse.
Un secondo indice è rappresentato dalla specicità,
specificity =
TN
TN + FP
misura che dice la proporzione di comportamenti eettivamente normali che
sono stati predetti come normali. Anche questo indice interessa relativamen-
te nel caso specico dato che la previsione di corretta normalità è secondaria
al rilevamento di comportamenti anomali.
Alla specicità si contrappone la sensitività o recall,
recall =
TP
TP + FN
che ci indica quante anomalie abbiamo mancato, ovvero quante ne abbiamo
individuate in relazione al totale. Indice sicuramente da tenere in conside-
razione, ma con un difetto: non riesce ad evidenziare quanto precisi siamo
stati nella predizione delle anomalie. Se ci fossero 5 anomalie e ne fossero
state previste 40, tra cui anche le 5 reali, sarebbe
recall =
5
5 + 0
= 1
ovvero il 100% di recall.
Data questa lacuna spesso la recall è aancata dalla precisione,
precision =
TP
TP + FP
che ci indica quante tra le predizioni di anomalia, fossero realmente delle
anomalie; una misura indicativa della bontà del sistema, anch'essa con una
limitazione: ci dà informazioni sulle anomalie che abbiamo predetto, ma non
riesce a cogliere la sfumatura di quelle che abbiamo mancato. Se ci fossero 20
anomalie e ne fossero state predette solamente 2, ma quelle fossero veramente
anomalie, sarebbe
precision =
2
2 + 0
= 1
ovvero il 100% di precisione.

Solitamente questi due indici sono usati assieme, dato che riescono a da-
re una buona caratterizzazione del sistema, in termini di quanti casi positivi
sono stati individuati e quanti invece sono stati mancati. Spesso infatti si
rappresentano questi due indici in un graco, con recall in ascissa e precision
in ordinata, e si studia la loro evoluzione al variare della soglia di classica-
zione. Tuttavia risulta scomodo basarsi su due indici contemporaneamente,
se ad esempio si vogliono confrontare più modelli; come se non bastasse,
anche una media aritmetica tra i due risulterebbe fuorviante: un sistema
che prevede sempre e solo comportamento anomalo, ovvero un classcato-
re pessimo, risulterebbe in 100% di recall, una percentuale molto bassa di
precisione (es. 3%), ma una media di 51%, superiore ad un random classier.
Quello che si può fare è allora utilizzare un indice di performance che sia
unico e che venga penalizzato se una delle due tra precision e recall fosse
piuttosto bassa. Questo è l'ultimo indice ad essere presentato e sarà anche
quello utilizzato per capire la bontà del sistema.
F1 Score = 2 ×
precision × recall
precision + recall
F1 Score è la media armonica tra precisione e recall; la media armonica
tra due indici X e Y converge alla media aritmetica degli indici se questi
sono uguali, ma nel momento in cui sono diversi è più simile al valore più
basso tra i 2. Nel caso indicato prima di recall al 100% e precision al 3%,
sarebbe
F1 Score = 2 ×
3 × 100
3 + 100
= 5%
indice di performance che mette in luce la scarsità di un modello, quello
che predice sempre anomalo, che con la media aritmetica non sarebbe stata
colta.
Di seguito verranno perciò valutate e confrontate tramite tabelle le varie
combinazioni di modelli risultanti dai diversi approcci per ogni fase, e verrà
eletto il modello migliore proprio sulla base del più alto F1 Score ottenuto.

Capitolo 4
Risultati
Prima di passare alla visualizzazione dei risultati sperimentali è bene fare
una premessa. Essa riguarda l'approccio: ogni fase è stata trattata inizial-
mente in maniera indipendente dalle altre, andando a soddisfare i requisiti
del singolo step e cercando di ottimizzare la soluzione in merito al singo-
lo problema; una volta esplorate le alternative possibili per una fase, si è
proceduto all'analisi e soddisfacimento dei requisiti della fase successiva. La
giusticazione di questo approccio denito a cascata, piuttosto che dell'uti-
lizzo di una metodologia agile che n dal principio producesse un prototipo
banale ma funzionante del sistema, è glia delle condizioni iniziali del
dataset. All'inizio del progetto infatti il dataset per come era stato concepito
non era disponibile, e solo un meticoloso lavoro di ricerca parallelo allo svi-
luppo del sistema ha permesso di ottenere i dati nella forma desiderata. Per
assemblare dei le di log che al loro interno incorporassero comportamenti
normali del sistema per tutti i giorni, mentre per l'ultimo presentassero al-
cuni comportamento normale, altri anomalo, e che questa informazione fosse
nota, sono state svolte le seguenti attività:
ˆ controllo di segnalazioni di anomalie o malfunzionamenti da parte di
clienti
ˆ verica di aperture di ticket per assistenza da parte di clienti
ˆ richieste pareri dal team di support
Le informazioni combinate derivate da questo hanno permesso la crea-
zione del dataset così come serviva l'input del sistema progettato. Il dataset
27

CAPITOLO 4. RISULTATI 28
o in generale i dataset, se riferiti a più installazioni risultanti sono
piuttosto sbilanciati, avendo un tasso medio di anomalie
Tavg =
#ultimi giorni anomali
#file
= 0.14
Con Ti invece si intende il tasso di anomalie della singola installazione i.
Accanto alla valutazione del modello è bene trovare una o più baseline che
possano permettere di confrontare il risultato ottenuto, in modo da capire
se il lavoro svolto abbia eettivamente valore. Quella che si può denire
Baseline0 riguarda il caso di un regressore privo di intelligenza: normalmente
si sceglie il random classier come limite inferiore, tuttavia data la natura
sbilanciata del dataset (le con l'ultimo giorno anomalo sono il 14%) un
classicatore che prevede 0 o 1 con la stessa probabilità non sembra adatto
e porterebbe a delle oscillazioni eccessive sul risultato. Si è scelto dunque
un caso più stabile e adatto: essendo l'obiettivo quello di individuare le
anomalie, Baseline0 è un classicatore che prevede 1 con probabilità 1. A
tal proposito per ogni installazione si avrà quanto segue:
RecallB0 = 1
PrecisionB0 = p(Y = 1) = Ti
F1 ScoreB0 = 2 ×
Ti
1 + Ti
Volendo individuare anche un caso di classicatore non banale, si è pro-
ceduto alla denizione di quella che si può denire Baseline1. Essa e denita
come segue:
ˆ Clustering come il modello proposto
ˆ Apprendimento del comportamento come il modello proposto
ˆ Classicazione non con modello supervisionato ma basata sull'inter-
pretazione dei valori normalizzati delle feature. In particolare il valore
normalizzato è identicato come probabilità di appartenenza alla classe
Anomalia, e viene trattato esattamente come sono trattati gli output
dei modelli di classicazione: vengono binarizzati testando automati-
camente varie soglie e viene scelto il valore della soglia per il quale è
massimo l'F1 Score. Per avere un'unica probabilità e non una per ogni

cluster, quello che si fa è prendere come probabilità il massimo tra que-
sti valori. In eetti, anche un solo cluster può provocare un'anomalia,
e sarebbe più grave causare un Falso Negativo piuttosto che un Falso
Positivo.
Introdotte queste alternative che permetteranno il confronto nale, è pos-
sibile indagare quale tra i modelli proposti precedentemente sia il migliore.
Per eettuare un confronto il più oggettivo possibile, tutti i parametri del
sistema sono stati impostati al loro valore di default.
Per la progettazione e lo sviluppo del sistema è stata utilizzato l'ambiente
Jupyter Lab, editor di testo per il linguaggio Python, su di una workstation
DELL Precision T3620, con processore Intel i7-6700, CPU a 3.4 GHz 4Core
e 32 GB di RAM.
Vengono quindi presentate le tabelle che riassumono le performance, nelle
quali i valori delle celle sono occupati, come argomentato in sezione 3.5, da
F1 Score. Per la precisione l'indice è ottenuto come media di m = k ×t = 50
valori, calcolati utilizzando la tecnica di k-fold cross validation. La cross-
validation è una procedura di ricampionamento utilizzata per valutare la
bontà di un modello di machine learning; essa ha un solo parametro k che
si riferisce al numero di split che devono essere eettuati del dataset. Una
volta diviso il dataset in k parti, a turno k-1 sono utilizzate come train
set e la rimanente come test set; è utile perché fornisce generalmente una
stima di abilità del modello andando a compensare eventuali situazioni di
overtting
1. Nel nostro caso k=5 e la procedura è ripetuta per t = 10 volte,
da cui m = 50.
Per brevità di rappresentazione sono stati assegnati dei codici alle imple-
mentazioni delle fasi, riportati in tabella 4.1. Un modello generico M sarà
denito come una sequenza di tre alternative, una per ciascuna fase.
I risultati presentati di seguito sono relativi ad una sola installazione; nel
caso di installazioni multiple, sarebbero forniti risultati per ciascuna di esse.
Per quanto riguarda Baseline0 non c'è bisogno di tabelle: l'espressione di F1
Score è denita sopra ed è costante:
F1 ScoreB0 = 0.32
1
Si parla di overtting quando un modello statistico molto complesso si adatta ai dati
osservati perché ha un numero eccessivo di parametri rispetto al numero di osservazioni.

A Clustering
con pattern del messaggio A1
con tipo e pattern del messaggio A2
B
Apprendimento
comportamento
con media statistiche B1
con serie univariata B2
con serie multivariata B3
C
Feature in input al modello
e a Baseline1
actual,predicted,day C1
actual-predicted,day C2
(actual-predicted)/std,day C3
Tabella 4.1: Legenda alternative modelli
Per i modelli seguenti, i valori nali di F1 sono riportati come media ± std.
Relativamente a Baseline1 sono stati valutati come probabilità di Anomalia
i valori ottenuti da tutti e tre i tipi di normalizzazione introdotti per la fase
C. I risultati sono presentati in tabella 4.2
C1 C2 C3
A1
B1 0.32 0.43 0.39
B2 0.32 0.44 0.38
B3 0.32 0.46 0.55
A2
B1 0.32 0.43 0.37
B2 0.32 0.43 0.42
B3 0.32 0.55 0.48
Tabella 4.2: F1 Score Modelli con Baseline 1
Come si può notare, nel caso di modello che utilizzi le feature C1, il
risultato è scarso ed è esattamente uguale a quello di Baseline0, ovvero equi-
valente a predire sempre anomalia. Chiaramente in un caso concreto un
modello del genere sarebbe inutilizzabile. I modelli che meglio funzionano
per Baseline1 sono M1 = [A1,B3,C3] e M2 = [A2,B3,C2]. Anche il modello
M3 = [A2,B3,C3] ottiene un risultato non molto distante. Il miglior valore
risulta
F1 ScoreB1 = 0.55 ± 0.04
con un incremento del 71.8% del risultato rispetto a Baseline0.
I risultati sul sistema che utilizza i modelli di classicazione supervisio-
nati, sono presentati di seguito, nelle tabelle 4.3, 4.4 e 4.5.

C1 C2 C3
A1
B1 0.65 0.73 0.69
B2 0.64 0.79 0.83
B3 0.77 0.64 0.78
A2
B1 0.65 0.70 0.68
B2 0.65 0.82 0.81
B3 0.80 0.75 0.85
Tabella 4.3: F1 Score Modelli con Random Forest
Per quanto riguarda il Random Forest, il valore più alto lo si ottiene col
modello M1 = [A2, B3, C3], anche se hanno prestazioni simili i modelli M2
= [A1,B2,C3] e M3 = [A2,B2,C2]. Il migliore è
F1 ScoreRF = 0.85 ± 0.05
con un incremento del 54.5% rispetto a Baseline1 e del 165% rispetto a
Baseline0.
C1 C2 C3
A1
B1 0.52 0.62 0.66
B2 0.58 0.77 0.77
B3 0.65 0.59 0.67
A2
B1 0.66 0.68 0.68
B2 0.52 0.79 0.80
B3 0.54 0.62 0.70
Tabella 4.4: F1 Score Modelli con Linear Regression
In merito alla regressione lineare, il valore più alto lo si ottiene col modello
M1 = [A2, B2, C3], ma una valida alternativa potrebbe essere il modelloM2
= [A2,B2,C2]. Il migliore è
F1 ScoreLR = 0.80 ± 0.06

Baseline0.
C1 C2 C3
A1
B1 0.54 0.65 0.65
B2 0.60 0.78 0.78
B3 0.54 0.60 0.68
A2
B1 0.64 0.66 0.68
B2 0.68 0.81 0.81
B3 0.52 0.61 0.70
Tabella 4.5: F1 Score Modelli con SVM
Inne per quanto riguarda il modello SVM, il valore più alto lo si ottiene
col modello M1 = [A2, B2, C2] o M2 = [A2,B2,C3]. Il migliore è
F1 ScoreSV M = 0.81 ± 0.06
Baseline0.
In generale, una caratteristica che si nota per tutti e 3 i modelli super-
visionati considerati è che il miglioramento dei risultati delle singole fasi ha
inciso sul miglioramento del risultato nale: infatti per tutti i migliori mo-
delli non sono state utilizzate le soluzioni di partenza per quanto riguarda
l'apprendimento del comportamento del sistema e la denizione delle feature
da fornire in input al modello supervisionato (ovvero B1 e C1 non portano
a risultati buoni come le loro alternative).
Per quanto riguarda la scelta del modello da utilizzare tra Baseline1 o
modelli supervisionati SVM, Linear Regression o Random Forest, si può af-
fermare che indipendentemente dalla scelta di alternative seguite, in generale
Random Forest raggiunge punteggi più alti, oltre che il punteggio più alto
in assoluto, come si può osservare in gura 4.1.
Sintetizzando quello che emerge dai graci e dalle tabelle precedenti, si
può constatare che il modello selezionato sarà quello che utilizza per il cluste-
ring le feature messaggio preprocessato e tipo (A2), impara il comportamento
con serie temporali multivariate (B3), usa come modello di classicazione il
Random Forest fornendo a questo come feature quelle identicate da C3.
Precedentemente si è detto che per il confronto tra modelli i parametri
sono stati impostati ai loro valori di default; ora che il miglior modello è sta-

Baseline1 Linear Regression SVM Random Forest
Model
0.3
0.4
0.5
0.6
0.7
0.8
F1Score
Max F1 Score = 0.85
Figura 4.1: Confronto tra F1 Score dei Modelli.
to selezionato, sembra opportuno procedere con un'operazione di parameter
tuning, eettuata su questo sistema nale.
I parametri sono i seguenti:
ˆ ε: in fase di clustering, massima distanza tra due campioni per essere
considerati vicini. Il valore di default è ε=0.3
ˆ min_samples: in fase di clustering, il numero minimo di campioni vi-
cini ad un punto per considerare quest'ultimo come capace di generare
un cluster. ll valore di default è min_samples=5
ˆ st: in fase di preprocessing delle log entry, soglia oltre la quale un
messaggio viene associato ad un gruppo esistente. Il valore di default
è st=0.3

ˆ depth: in fase di preprocessing delle log entry, profondità dei nodi foglia
dell'albero. il valore di default è depth=2
ˆ weight: in fase di clustering, il peso che deve essere assegnato al mes-
saggio nel calcolo della distanza (al tipo è assegnato 1-weigth). Il valore
di default è weigth=0.5
Il risultato nale è ottenuto con un valore dei parametri e = 0.33,
min_samples = 1, st = 0.4, depth = 2, weight = 0.5.
In gura 4.2 si trova una rappresentazione della curva Precision-Recall
per uno dei casi di cross validation; è stata scelta quella più rappresentativa
del valore medio.
0.0 0.2 0.4 0.6 0.8 1.0
Recall
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1.0
Precision
Best F1Score=0.875, th=0.233
Baseline1
Random Forest
Best F1 Baseline1
Best F1 Random Forest
Figura 4.2: Curva Precision Recall modello ottimo.
Il massimo valore di F1 Score è ottenuto dalla curva Precision-Recall in
corrispondenza della soglia th.
th = 0.23

F1 Score = 0.87 ± 0.05
Potrebbe essere che, dopo aver presentato il sistema al team support e
questo inizi ad usarlo, si presenti la necessità di aggiungere un vincolo sulle
prestazioni.
Un esempio potrebbe essere il seguente:
Le anomalie non segnalate devono essere al massimo il 10% del totale
→ Minima Recall = 0.9
In tal caso può essere che alla soglia identicata dal modello come quella
che massimizza F1 Score corrisponda una soluzione ora non valida. A questo
punto è suciente inserire il vincolo al sistema e quest'ultimo ricalcola il
miglior F1 Score con Recall minima 0.9.
Tuttavia quello che prima poteva essere il modello migliore, frutto della
combinazione delle tre fasi, non sia più il modello ottimo: il sistema in ogni
caso vaglia ogni possibilità ed è quindi in grado non solo di variare la soglia
per adattarsi al nuovo vincolo, ma di cambiare anche modelli se necessario,
a dimostrazione della sua grande robustezza e essibilità.

Capitolo 5
Sviluppi Futuri
Giunti al termine della realizzazione del sistema, è stata fatta una consi-
derazione sulla sua applicabilità e sulle funzionalità che potrebbero essere
aggiunte.
Innanzitutto il sistema presenta una strategia che può essere riproposta
anche fuori dal contesto dei log les. In questo lavoro sono stati utilizzati i
messaggi di log in quanto un ottimo strumento per il rilevamento di anomalie
nei sistemi informatici, ma rimane il carattere generale del procedimento:
ˆ Raggruppamento degli oggetti in esame
ˆ Apprendimento del comportamenteo del sistema in esame, a partire
dai gruppi di oggetti
ˆ Addestramento di un modello che predice il comportamento basandosi
su esempi noti
In particolare nel contesto di CyberPlan Web sarebbe interessante apportare
qualche modica al sistema per adattarlo a prevedere anomalie nelle opera-
zioni di import dei settings, cosa che tornerebbe utile al team di integrazione;
o ad un livello ancora più alto il rilevamento nel campo dei parametri MRP
1.
Per quanto riguarda nuove funzionalità invece, un spunto sarebbe quello
dell'anomaly detection sulle sequenze di log entry, oltre che sulle frequenze.
1
Il Material Requirements Planning (detto anche pianicazione dei fabbisogni di ma-
teriali e abbreviato in MRP) è una tecnica che calcola i fabbisogni netti dei materiali e
pianica gli ordini di produzione e di acquisto, tenendo conto della domanda del mercato,
della distinta base, dei lead time di produzione e di acquisto e delle giacenze dei magazzini.
36

CAPITOLO 5. SVILUPPI FUTURI 37
In tal senso dal preprocessing delle entry si potrebbe estrarre oltre al pattern
anche un parametro, come il nome utente, ed imparare le interazioni del
singolo utente col sistema. Ad esempio con il seguente scenario
l'utente A eettua solitamente nell'ordine le operazioni X Y Z
l'utente B eettua solitamente nell'ordine le operazioni Y Y Z Z
sarebbe interessante segnalare se A esegue la sequenza Y Y Z Z, e viceversa
per B.
Data l'assenza attuale di un sistema automatico per il rilevamento di
anomalie in Cybertec, inizialmente la strada seguita è quella di segnalare
se l'ultimo giorno risulti anomalo o no; in futuro il sistema potrebbe anche
essere modicato per operare real-time nell'ottica del miglioramento della
manutenzione predittiva. In fase di denizione è anche la tematica dell'in-
dicazione di quale cluster abbia avuto il maggior impatto sulla segnalazione
anomala.
Altri eventuali sviluppi futuri potrebbero venire considerati in un secondo
momento.

Capitolo 6
Conclusioni
Complessivamente nell'implementazione del sistema sono state riscontrate e
superate diverse criticità. Tra queste troviamo, come evidenziato preceden-
temente, il reperimento del dataset nella forma necessaria, che ha richiesto
un duro lavoro, come anche il fatto di avere a che fare con moli di dati mai
sperimentate prima. Questo è risultato in alcune dicoltà operative (vedi la
mancanza di memoria RAM) che mi hanno spinto e stimolato a cercare una
soluzione per portare a termine il lavoro iniziato.
I risultati sperimentali ottenuti sono in linea con le previsioni e le spe-
ranze maturate prima di iniziare il lavoro, e questo è un motivo di orgoglio
personale e sperabilmente anche del personale di Cybertec, che ha deciso di
accogliermi e supportarmi in questa sda, e del relatore che ha supervisionato
tutto fornendomi preziosi consigli.
Ci sono anche funzionalità che purtroppo per questioni di tempo non sono
state arontate, ma che potrebbero comunque essere implementate in un
secondo momento nel caso in cui il sistema trovasse applicazione in maniera
concreta in azienda.
Trovo che questa esperienza sia stata per me importante sia da un punto
di vista formativo, dato che mi ha permesso di imparare nuovi linguaggi come
Python e permesso di toccare con mano quella che è una realtà aziendale,
che dal punto di vista umano, avendomi permesso di relazionarmi e prendere
consigli con e da personale qualicato. In denitiva sono molto soddisfatto
del lavoro svolto e curioso di scoprire quello che ancora posso imparare.
38

Bibliograa
Andreasson, J. e Geijer C. (2015). Log-based anomaly detection for system
surveillance. url: https://odr.chalmers.se/handle/20.500.12380/
219089.
Du, S. e J. Cao (2015). Behavioral anomaly detection approach based on log
monitoring. url: https://ieeexplore.ieee.org/abstract/document/
7365981.
Groebner, D. e al. (2017). Business statistics. Pearson.
Gurumdimma, N. e al. (2015). Towards detecting patterns in failure logs of
large-scale distributed systems. url: https://ieeexplore.ieee.org/
abstract/document/7284426.
He, S. e al. (2016). Experience report: System log analysis for anomaly de-
tection. url: https://ieeexplore.ieee.org/abstract/document/
7774521.
Juvonen, A. e al. (2015). Online anomaly detection using dimensionality re-
duction techniques for http log analysis. url: https://www.sciencedirect.
com/science/article/abs/pii/S1389128615002650.
Landauer, M. e al. (2018). Dynamic log le analysis: An unsupervised clu-
ster evolution approach for anomaly detection. url: https : / / www .
sciencedirect.com/science/article/pii/S0167404818306333.
Lin, Q. e al. (2016). Log clustering based problem identication for onli-
ne service systems. url: https://ieeexplore.ieee.org/abstract/
document/7883294.
Pomel, O. e al. (2010). Datadog. url: https://www.datadoghq.com.
Ren, R. e al. (2018). Deep convolutional neural networks for log event classi-
cation on distributed cluster systems. url: https://ieeexplore.ieee.
org/abstract/document/8622611.
39

BIBLIOGRAFIA 40
Thaler, S. e al. (2017). Towards a neural language model for signature extrac-
tion from forensic logs. url: https://ieeexplore.ieee.org/abstract/
document/7916497.
Wurzenberger, M. e al. (2017). Incremental clustering for semi-supervised
anomaly detection applied on log data. url: https://dl.acm.org/doi/
abs/10.1145/3098954.3098973.
Xu, W. e al. (2009). Detecting large-scale system problems by mining console
logs. url: https://dl.acm.org/doi/abs/10.1145/1629575.1629587.
Zheng, Z. e al. (2017). Drain: an online log parsing approachwith xed depth
tree. url: https://ieeexplore.ieee.org/document/8029742.
Zou, D.-Q. e al. (2016). Uilog: Improving log-based fault diagnosis by log ana-
lysis. url: https://link.springer.com/article/10.1007/s11390-
016-1678-7.

Progetto e sviluppo di un sistema di rilevamento di anomalie su sistemi informatici basato sui log

Recommended

Recommended

More Related Content

Similar to Progetto e sviluppo di un sistema di rilevamento di anomalie su sistemi informatici basato sui log

Similar to Progetto e sviluppo di un sistema di rilevamento di anomalie su sistemi informatici basato sui log (20)

Progetto e sviluppo di un sistema di rilevamento di anomalie su sistemi informatici basato sui log