Statistics Networked Database setup

Back

LBL Application Delivery Controller è un prodotto destinato ad ambienti mission-critical pertanto solo personale che ha effettuato il corso ed ha superato l’esame è autorizzato a certificare l’installazione e manutenzione dei prodotti in esercizio. Tutte le persone certificate sono dotate di patentino di riconoscimento rilasciato da noi.

LBL Application Delivery Controller gestisce la persistenza delle statistiche su Database Relazione in maniera Transazionale. Nella configurazione di default utilizza l’engine JavaDB Embedded fornito direttamente nella distribuzione Java (JDK). Oltre a JavaDB Embedded LBL Application Delivery Controller è stato progettato per utilizzare i più diffusi Database Relazionali Transazionali. Di seguito la lista completa dei Database supportati per la storicizzazione delle statistiche:

  1. Oracle
  2. MS SQLServer
  3. MySQL (InnoDB engine)
  4. Postgres
  5. JavaDB embedded (default)
  6. JavaDB Networked

Il modulo di persistenza delle statistiche è stato realizzato per poter essere disaccoppiato dal sistema di bilanciamento. Questa caratteristica permette la realizzazione di diverse architetture in base alle necessità di storicizzazione.

Nell’installazione di default queste funzionalità non sono immediatamente evidenti essendo state volutamente realizzate in modo da creare il minimo impatto nell’installazione di base.

Tipologie di storicizzazione delle statistiche

Ci sono fondamentalmente 2 tipologie di storicizzazione delle statistiche:

  1. Embedded
  2. Networked

Per Embedded si intende l’utilizzo esclusivo del Database di LBL Application Delivery Controller senza la possibilità di interagire durante il run-time con interrogazioni custom SQL. (N.B. E’ possibile passare dalla modalità embedded a networked in qualsiasi momento senza perdita di informazioni)

Per Networked si intende l’utilizzo di un DBMS tra quelli supportati attraverso la rete con l’utilizzo dei driver (JDBC) messi a disposizione dai singoli produttori. Con questa tipologia di storicizzazione è possibile interrogare il Database con proprie query SQL durante il run-time.

Architettura

L’architettura della storicizzazione statistica è stata studiata per avere il minimo impatto sull’elaborazione core (il bilanciamento di carico) dando nel contempo la massima flessibilità di configurazione e un’altissima scalabilità.

E’ basata su 3 livelli logici

Questi tre livelli logici da un punto di vista di “Process” di sistema operativo possono essere collassati nella modalità Embedded su 2 “Process”. Nella modalità Networked invece saranno al minimo 3 “Process” distinti.

Process di Sistema Operativo in modalità Embedded

Essendo questi servizi raggiungibili attraverso la rete le architetture possibili sono molteplici.

L’architettura preimpostata ha un bassissimo impatto sia nell’installazione sia nel mantenimento e ben si adatta a quelle realtà che hanno bisogno solo di alcuni dati estemporanei a verifica dell’operatività e che non hanno necessità di ulteriori elaborazioni statistiche o di consolidato.

Con l’architettura Embedded le statistiche rimangono all’interno delle singole Istanze e vengono gestite in automatico dal sistema mediatore (LBL Application Delivery Controller WebCacheBroker).

Nei parametri preimpostati il processo LBL Application Delivery Controller WebCacheBroker mantiene i dati nel Database Embedded per 2 giorni verificando nel contempo le occupazioni fisiche nel supporto di memorizzazione di massa. Nel caso queste dimensioni superino il GB (1GB) provvederà in automatico alla rigenerazione del DB evitando l’esaurimento delle risorse. Sia il limite dei 2 giorni che il limite di 1GB sono modificabili da parametri (vedi LBL S.A.A.I. Reference Guide).

Ovviamente essendo dei processi separati LBL Application Delivery Controller (il produttore delle statistiche) e LBL WebCacheBroker (il mediatore, Broker) e collegati attraverso la rete sarebbe comunque possibile delocalizzare la storicizzazione su terze macchine, sia nella stessa DMZ sia nel backend. Questa possibilità è sicuramente meglio sfruttata nella modalità di utilizzo di un Database Networked dove sarà possibile eseguire durante il run-time delle query SQL sui dati di traffico.

Nell’immagine di seguito una configurazione su 3 livelli completamente separata tra la produzione delle statistiche, la mediazione (broker) e la storicizzazione su DBMS.

E’ possibile raggiungere questo risultato per due distinte motivazioni, la prima è derivata dal disegno architetturale che nasce su tre distinti livelli, la seconda è derivata dalla separazione logica dei dati all’interno dello stesso DBMS. Con LBL Application Delivery Controller Standard HA e LBL Application Delivery Controller Enterprise HA è infatti possibile consolidare all’interno dello stesso DB e nelle stesse tabelle i dati provenienti da più Istanze LBL Application Delivery Controller.

Struttura del Database e creazione tabelle

La persistenza dei dati di traffico nel database statistico viene realizzata attraverso le seguenti tabelle:

  • SESSION_ACTIVITY
    • analisi dell’utilizzo delle sessioni
  • L7_HTTP_HTTPS
    • persistenza delle informazioni di traffico HTTP e HTTPS.
  • L4_TCP_TCPSSL
    • persistenza delle informazioni di traffico TCP e TCP come terminatore SSL
  • L4_DATAGRAM
    • persistenza delle informazioni di traffico UDP e MULTICAST
  • POOL_QUEUES_ACTIVITY
    • analisi dell’utilizzo dei pool di risoluzione delle richieste di servizio
  • INCOMING_QHIGHWATER_LEVEL
    • analisi dell’utilizzo del riempimento della coda delle connessioni entranti
  • WAF_EXEC
    • log delle regole eseguite con esito positivo dal Web Application Firewal
  • DDOS_EXEC
    • log degli attacchi DoS e DDoS
  • DAILY_ALERT
    • log delle notifiche provenienti da Attack Prophecy
  • GUIRT_MASTER
    • log master dell’esecuzione delle tracce GUI Reliability Tool
  • GUIRT_DETAIL
    • log di dettaglio dell’esecuzione degli step delle tracce GUI Reliability Tool

Gli schemi delle tabelle per singolo Database supportato sono contenuti nella directory (LBL_HOME)/legacyBin/DatabasesScript.

In questa directory possiamo trovare rispettivamente:

  • ORACLE_LBLDBTables.sql
    • ORACLE database table creation
  • SQLSERVER_LBLDBTables.sql
    • Microsoft SQL Server database table creation
  • MySQL_LBLDBTables.sql
    • Sun MySQL database table creation
  • POSTGRES_LBLDBTablesCreation.sql
    • Postgres database table creation
  • JavaDB_LBLDBTables
    • Java DB derby

A parte alcune differenze relative alla tipizzazione del formato dei campi, le tabelle , sui diversi database, contengono gli stessi dati. Nelle pagine a seguire verranno descritti dettagliatamente campo per campo i significati delle strutture per poter facilmente creare reports, statistiche, sistemi di fatturazione in base al traffico.

ATTENZIONE

La creazione del database e delle tabelle JavaDB (aka IBM cloudscape, Apache derby) avviene completamente in automatico sia per soluzione Embedded sia Networked.

Per tutti gli altri database fare riferimento agli script di creazione tabelle disponibili per ogni distinto database nella directory (LBL_HOME)/legacyBin/DatabasesScript.

Tabella SESSION_ACTIVITY

Tabella contenente gli snap ad intervalli di 10” dello stato delle sessioni di instradamento.

RECORD_TYPE Int 6 Tipo di record
VRRP_HOST_NAME varchar(4000) Nome dell’host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBER int Port number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico
END_POINTS_GROUPING varchar(4000) E’ il nome del gruppo di endpoint
DOMAIN_REQUEST varchar(4000) E’ il dominio associato alla sessione
COMMAND varchar(4000) EMPTY
URI_PATH_REQUEST varchar(4000) EMPTY
RESPONSE_CODE int 0
END_POINT_HOST_NAME varchar(4000) Nome dell’host dell’endpoint associato alla sessione
END_POINT_PORT_NUMBER int Port number dell’host dell’endpoint associato alla sessione
END_POINT_URI_PATH varchar(4000) E’ l’URIPath di contesto in elaborazione
USER_ID varchar(4000) Utilizzo futuro
CLIENT_ADDRESS varchar(4000) Il client address riporta l’indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

Se trasmissione a layer 7 HTTP/S ed e’ stata impostata la gestione dell’entity X-Forwarded-For (HEADER HTTP) attraverso il parametro xForwardedFor=”true” nel

listener in iproxy.xml il valore dell’intera catena IP sara’ trasferita.

Ovviamente LBL puo’ assicurare solo l’ultimo elemento della catena essendo gli altri elementi utili solo a scopo statistico essendo popolati da altri strumenti

di infrastruttura come ad esempio i proxy.

es.: 192.168.32.115,192.168.41.10,192.168.43.150

THIS_DATE date Data uniformata ad orario a 00:00:00
THIS_TIME time Ora con data uniformata a 01-01-1970
NUMBER_OF_ACTIVE_SESSIONS int E’ il numero di sessioni relative alla chiave di raggruppamento (in rosso)

Le chiavi utilizzate sono:

index K1_SESSION_ACTIVITY ON SESSION_ACTIVITY (THIS_DATE);

index K2_SESSION_ACTIVITY ON SESSION_ACTIVITY (THIS_TIME);

Tabella L7_HTTP_HTTPS

Questa tabella contiene il traffico del protocollo HTTP e HTTPS (SSL).

RECORD_TYPE Int 0=HTTP

1=HTTPS

Tipo di record
VRRP_HOST_NAME varchar(4000) Nome dell’host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBER int Port number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico
END_POINTS_GROUPING varchar(4000) E’ il nome del gruppo di endpoint
DOMAIN_REQUEST varchar(4000) E’ il dominio richiesto dal client
COMMAND varchar(4000) E’ il comando HTTP richiesto dal client (GET, POST, etc)
URI_PATH_REQUEST varchar(4000) Path riferito al dominio richiesto dal client. Questo valore riporta il risultato della richiesta dopo l’azione di rewriting se esistente. E’ l’effettiva richiesta che viene effettuata nel backend.
URI_PATH_REQUEST_ORG varchar(4000) Path originale riferito al dominio richiesto dal client prima di eventuali rewriting
CONTENT_TYPE_REQUEST varchar(4000) content type in request
CONTENT_TYPE_RESPONSE varchar(4000) content type in response
RESPONSE_CODE int Response CODE HTTP inviato dal server al client in risposta alla sua richiesta
END_POINT_HOST_NAME varchar(4000) Nome dell’host su cui è stata elaborata la richiesta di servzio
END_POINT_PORT_NUMBER int Port number dell’host su cui è stata elaborata la richiesta di servzio
END_POINT_URI_PATH varchar(4000) E’ l’URIPath di contesto su cui è stata elaborata la richiesta
USER_ID varchar(4000) La colonna contiene le informazioni dell’utente profilato e autenticato. Le informazioni sono una somma degli elementi caratteristici di una autenticazione BASIC (Basic Authentication) e della autorizzazione derivante da certificato digitale. Questa colonna contiene rispettivamente:

Se autorizzazione con certificato digitale il Subject con un valore aggiuntivo riportante il Serial Number del certificato es.:

“CN=clientname, OU=clientlob, O=clientcompany, L=clientcountry, ST=clientdistrict, C=IT, SERIAL=1282479557”

Se basic authentication

“BASIC=usr1”

Nel caso siano presenti entrambe le credenziali il valore risultante sara’ :

“BASIC=usr1, CN=clientname, OU=clientlob, O=clientcompany, L=clientcountry, ST=clientdistrict, C=IT, SERIAL=1282479557”

CLIENT_ADDRESS varchar(4000) Il client address riporta l’indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

Se trasmissione a layer 7 HTTP/S ed e’ stata impostata la gestione dell’entity X-Forwarded-For (HEADER HTTP) attraverso il parametro xForwardedFor=”true” nel

listener in iproxy.xml il valore dell’intera catena IP sara’ trasferita.

Ovviamente LBL puo’ assicurare solo l’ultimo elemento della catena essendo gli altri elementi utili solo a scopo statistico essendo popolati da altri strumenti

di infrastruttura come ad esempio i proxy.

es.: 192.168.32.115,192.168.41.10,192.168.43.150

USER_AGENT varchar(4000) Valore User-agent nell’HTTP HEADER
COOKIES varchar(4000) Valore Cookie nell’HTTP HEADER
REFERER varchar(4000) Valore Referer nell’HTTP HEADER
URI_PARAMETERS varchar(4000) Valore con parametri e/o query string.

I parametri, definiti nella URL dal carattere ; e le query string definite daò carattere ? vengono normalizzate in una unico valore separato da &. es.:

/aaa/bbb;c1=aaa&c2=bbb?q1=ccc&q2=dddd

VALORE IN URI_PARAMETERS

c1=aaa&c2=bbb&q1=ccc&q2=dddd

PROTOCOL_VERSION varchar(4000) HTTP/1.0

HTTP/1.1

INCOMING_ADDRESS varchar(4000) Indirizzo locale in cui è stata accettata la connessione
INCOMING_PORT_NUMBER int Porta locale in cui è stata accettata la connessione
THIS_DATE date Data uniformata ad orario a 00:00:00
THIS_TIME time Ora con data uniformata a 01-01-1970
COUNTER bigint Numero di operazioni sommate in questo record (se non sono stati modificati i default è il numero di operazioni effettuate nella sua finestra temporale negli ultimi 10”)
RESPONSE_TIME bigint E’ il response time del servizio richiesto (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER). Valore espresso in nanosecondi.
LAP_TIME_A bigint Tempo compreso tra la fine della lettura dell’HEADER del client e l’inizio della connessione verso l’endpoint (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER). Valore espresso in nanosecondi.
LAP_TIME_B bigint Tempo di connessione all’endpoint (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER). Valore espresso in nanosecondi.
LAP_TIME_C bigint Tempo tra la connessione avvenuta all’endpoint e l’inizio della lettura dell’HEADER di risposta. Se il client invia il body è il tempo di trasmissione del body dal client all’endpoint.(Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER) . Valore espresso in nanosecondi.
LAP_TIME_D bigint Tempo di lettura dell’Header dell’endpoint (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER). Valore espresso in nanosecondi.
LAP_TIME_E bigint Tempo tra la fine della lettura dell’Header e la fine dei dati in risposta (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER). Valore espresso in nanosecondi.
HEADER_LENGTH_FROM_CLIENT bigint E’ la lunghezza dell’HEADER di richiesta dei client verso gli endpoint (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER)
BYTES_SENT_FROM_CLIENT bigint Totale trasferito compresa l’HEADER dal client verso gli endpoint (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER)
HEADER_LENGTH_FROM_END_POINT bigint E’ la lunghezza dell’HEADER di risposta degli endpoint verso i client (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER)
BYTES_SENT_FROM_END_POINT bigint Totale trasferito compresa l’HEADER dagli endpoint verso i client (Questo valore è relativo al traffico degli ultimi 10”. Per avere un valore medio è necessario dividerlo per il COUNTER) relative alla chiave di raggruppamento (in rosso)
SESSIONID varchar(100) È un identificatore univoco (hash) generato dall’insieme indirizzo del client + referer
REFERRING_DOMAIN varchar(300) Host name da cui è partita la richiesta
BROWSER varchar(100) Nome del browser o del client che ha effettuato la richiesta
BROWSER_REL varchar(100) Release del browser o del client che ha effettuato la richiesta
OS varchar(100) Sistema operativo da cui è pervenuta la richiesta
OS_REL varchar(100) Release del sistema operativo da cui è pervenuta la richiesta
DEVICE varchar(100) Costruttore del device da cui è pervenuta la richiesta
COUNTRY_CODE varchar(100) Sigla dello stato da cui è pervenuta la richiesta
COUNTRY_DES varchar(350) Descrizione dello stato da cui è pervenuta la richiesta
INTERNET_ADDRESS varchar(350) È l’indirizzo del client derivato dal socket se non esiste XFF. Se esiste XFF è il secondo della catena XFF.

Le chiavi utilizzate sono:

index K1_L7_HTTP_HTTPS ON L7_HTTP_HTTPS (THIS_DATE);

index K2_L7_HTTP_HTTPS ON L7_HTTP_HTTPS (THIS_TIME);

Tabella L4_TCP_TCPSSL

Come per la tabella precedente questa tabella contiene i dati di traffico relativo alle attività del connettore TCP e TCP come terminatore SSL. La struttura iniziale è molto simile a quella HTTP/S per differenziarsi poi sui dati di traffico

RECORD_TYPE Int 2=TCP

3=SSL

Tipo di record
VRRP_HOST_NAME varchar(4000) Nome dell’host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBER int Port number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico
END_POINTS_GROUPING varchar(4000) E’ il nome del gruppo di endpoint
DOMAIN_REQUEST varchar(4000) Se WebSocket è l’host richiesto a layer 7
COMMAND varchar(4000) Identifica il flusso dei dati:

CLIENT_FLOW dal client verso gli endpoint

ENDPOINT_FLOW dagli endpoint verso i client

WebSocket:

WSCLIENT_FLOW dal client verso gli endpoint

WSENDPOINT_FLOW dagli endpoint verso i client

URI_PATH_REQUEST varchar(4000) Se WebSocket è l’URIPath richiesto a layer 7
RESPONSE_CODE int 0
END_POINT_HOST_NAME varchar(4000) Nome dell’host su cui è stata elaborata la richiesta di servzio
END_POINT_PORT_NUMBER int Port number dell’host su cui è stata elaborata la richiesta di servzio
END_POINT_URI_PATH varchar(4000) Se WebSocket è l’URIPath richiesto a layer 7
USER_ID varchar(4000) If a SSL client authentication contains the Subject and the additional values of the certificate bearing the Serial Number eg.:

“CN=clientname, OU=clientlob, O=clientcompany, L=clientcountry, ST=clientdistrict, C=IT, SERIAL=1282479557”

CLIENT_ADDRESS varchar(4000) Il client address riporta l’indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

COOKIES varchar(4000) Valore univoco associato alla connessione. Questo valore viene popolato con il valore LBLCOLOR per identificare la singola connessione a layer 4. Per l’attivazione del popolamento di questo valore è necessario impostare il parametro distinguishSingleConnection=”true” nel paragrafo <bind> del file parametri iproxy.xml

Se WebSocket contiene i cookie della connessione layer 7 HTTP/S

INCOMING_ADDRESS varchar(4000) Indirizzo locale in cui è stata accettata la connessione
INCOMING_PORT_NUMBER int Porta locale in cui è stata accettata la connessione
THIS_DATE date Data uniformata ad orario a 00:00:00
THIS_TIME time Ora con data uniformata a 01-01-1970
COUNTER bigint Numero di operazioni sommate in questo record (se non sono stati modificati i default è il numero di operazioni effettuate nella sua finestra temporale negli ultimi 10”)
BYTES_FORWARDED bigint E’ il numero di bytes scambiati in base al flusso (client>endpoint oppure endpoint>client) relative alla chiave di raggruppamento (in rosso)
START_ADV_TIME bigint E’ il momento in cui viene rilevato il primo buffer/carattere espresso in nanosecondi
END_ADV_TIME bigint E’ il momento in cui viene eseguito il flush dell’ultimo buffer dello stream espresso in nanosecondi
TOTAL_ADV_TIME bigint E’ il tempo totale di forwarding dell’informazione (END_ADV_TIME – START_ADV_TIME) espresso in nanosecondi

Le chiavi utilizzate sono:

index K1_L4_TCP_TCPSSL ON L4_TCP_TCPSSL (THIS_DATE);

index K2_L4_TCP_TCPSSL ON L4_TCP_TCPSSL (THIS_TIME);

Tabella L4_DATAGRAM

Come per la tabella precedente questa tabella contiene i dati di traffico relativo alle attività del connettore TCP e TCP come terminatore SSL. La struttura iniziale è molto simile a quella HTTP/S per differenziarsi poi sui dati di traffico

RECORD_TYPE Int 10=UDP

11=MULTICAST

Tipo di record
VRRP_HOST_NAME varchar(4000) Nome dell’host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBER int Port number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico
END_POINTS_GROUPING varchar(4000) E’ il nome del gruppo di endpoint
DOMAIN_REQUEST varchar(4000) EMPTY
COMMAND varchar(4000) Identifica il flusso dei dati

CLIENT_FLOW dal client verso gli endpoint

ENDPOINT_FLOW dagli endpoint verso i client

URI_PATH_REQUEST varchar(4000) EMPTY
RESPONSE_CODE int 0
END_POINT_HOST_NAME varchar(4000) Nome dell’host su cui è stata elaborata la richiesta di servzio
END_POINT_PORT_NUMBER int Port number dell’host su cui è stata elaborata la richiesta di servzio
END_POINT_URI_PATH varchar(4000) EMPTY
USER_ID varchar(4000) Utilizzo futuro
CLIENT_ADDRESS varchar(4000) Il client address riporta l’indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

INCOMING_ADDRESS varchar(4000) Indirizzo locale in cui è stata accettata la connessione
INCOMING_PORT_NUMBER int Porta locale in cui è stata accettata la connessione
THIS_DATE date Data uniformata ad orario a 00:00:00
THIS_TIME time Ora con data uniformata a 01-01-1970
COUNTER bigint Numero di operazioni sommate in questo record (se non sono stati modificati i default è il numero di operazioni effettuate nella sua finestra temporale negli ultimi 10”)
BYTES_FORWARDED bigint E’ il numero di bytes scambiati

Le chiavi utilizzate sono:

index K1_L4_DATAGRAM ON L4_DATAGRAM (THIS_DATE);

index K2_L4_DATAGRAM ON L4_DATAGRAM (THIS_TIME);

Tabella POOL_QUEUES_ACTIVITY

Questa tabella contiene a snap di 10” lo stato di attività dei risolutori di protocollo. La sua interpretazione non può essere utilizzabile come sommatoria delle attività della giornata ma come dato statistico istantaneo nel momento relativo alla data e all’ora riportate sui records. Con questi snap è possibile tracciare su un asse temporale lo stato di attività e quindi i picchi di utilizzazione con uno slice di 10”.

Questa tabella contiene due tipi di snap, uno relativo allo stato di attività dei risolutori di protocollo e l’altro relativo allo stato di “committed” dei risolutori di protocollo.

RECORD_TYPE Int 4=ACTIVITY

5=COMMITTED

Tipo di record
VRRP_HOST_NAME varchar(4000) Nome dell’host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBER int Port number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico
END_POINTS_GROUPING varchar(4000) E’ il nome del gruppo di endpoint
DOMAIN_REQUEST varchar(4000) E’ il dominio in elaborazione sul risolutore
COMMAND varchar(4000) EMPTY
URI_PATH_REQUEST varchar(4000) EMPTY
RESPONSE_CODE int 0
END_POINT_HOST_NAME varchar(4000) Nome dell’host su cui è stata elaborata la richiesta di servzio
END_POINT_PORT_NUMBER int Port number dell’host su cui è stata elaborata la richiesta di servzio
END_POINT_URI_PATH varchar(4000) E’ l’URIPath di contesto in elaborazione
USER_ID varchar(4000) Utilizzo futuro
CLIENT_ADDRESS varchar(4000) Il client address riporta l’indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

Se trasmissione a layer 7 HTTP/S ed e’ stata impostata la gestione dell’entity X-Forwarded-For (HEADER HTTP) attraverso il parametro xForwardedFor=”true” nel

listener in iproxy.xml il valore dell’intera catena IP sara’ trasferita.

Ovviamente LBL puo’ assicurare solo l’ultimo elemento della catena essendo gli altri elementi utili solo a scopo statistico essendo popolati da altri strumenti

di infrastruttura come ad esempio i proxy.

es.: 192.168.32.115,192.168.41.10,192.168.43.150

THIS_DATE date Data uniformata ad orario a 00:00:00
THIS_TIME time Ora con data uniformata a 01-01-1970
NUMBER_OF_BUSY_CONSUMER int E’ il numero di consumatori in attività nell’istante THIS_DATE e THIS_TIME relative alla chiave di raggruppamento (in rosso)

Le chiavi utilizzate sono:

index K1_POOL_QUEUES_ACTIVITY ON POOL_QUEUES_ACTIVITY (THIS_DATE);

index K2_POOL_QUEUES_ACTIVITY ON POOL_QUEUES_ACTIVITY (THIS_TIME);

Tabella INCOMING_QHIGHWATER_LEVEL

E’ la tabella che registra a snap di 10” il livello di riempimento della coda delle richieste di connessione entranti. Questa tabella è importante perché in relazione al numero di risolutori di protocollo è l’indicatore di un possibile attacco DoS o di risorse insufficienti per elaborare il carico di richieste.

RECORD_TYPE Int 7 Tipo di record
VRRP_HOST_NAME varchar(4000) Nome dell’host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBER int Port number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico
THIS_DATE date Data uniformata ad orario a 00:00:00
THIS_TIME time Ora con data uniformata a 01-01-1970
HIGH_WATER int E’ il numero di richieste di connessione all’interno della coda prima in attesa di essere elaborate
HIGH_WATER_LEVEL float E’ il fattore di calcolo derivato da:

(100*HIGH_WATER)/ACT_SESSIONS

HIGH_WATER_WARNING_LEVEL float E’ la soglia in % superata la quale viene spedito un messaggio di avvertimento
HIGH_WATER_DANGER_LEVEL float E’ la soglia in % superata la quale viene spedito un messaggio di pericolo
ACT_SESSIONS int E’ l’attuale disponibilità di risolutori di protocollo
MAX_CONCURRENT_SESSIONS int E’ il numero massimo di risolutori di protocollo

Le chiavi utilizzate sono:

index K1_INCOMING_QUEUE_HL ON INCOMING_QHIGHWATER_LEVEL (THIS_DATE);

index K2_INCOMING_QUEUE_HL ON INCOMING_QHIGHWATER_LEVEL (THIS_TIME);

Tabella SYSLOG_EVENT

Questa tabella raccoglie tutti i messaggi provenienti da tutti i processi LBL®S.A.A.I.. In ambienti complessi è quindi un utile strumento che, se centralizzato, può essere utilizzato come sistema per rilevare eventuali anomalie di funzionamento.

RECORD_TYPE Int 12 Tipo di record
VRRP_HOST_NAME varchar(4000) E’ una stringa separata da @ contenente:

host name@monitor management url@server process name@absolute log dir@date YYYYMMDD@hostname_logfileSuffix

VRRP_PORT_NUMBER int
COOKIES varchar(4000) E’ un valore identificativo del messaggio sempre differente ed univoco per sistema es.: ID=”16231623”
INCOMING_ADDRESS varchar(4000) Host name
THIS_DATE date Data uniformata ad orario a 00:00:00
THIS_TIME time Ora con data uniformata a 01-01-1970
REPETITIONS bigint Numero di ripetizioni dello stesso messaggio
TIME_SEQUENCE bigint Sequenza temporale evento
SEVERITY varchar(4000) ERROR | WARNING | DEBUG | FATAL
JAVA_REL varchar(4000) Release java
LBL_REL varchar(4000) Relelase LBL
MESSAGE_GRP varchar(4000) Nome dell’unita di elaborazione che ha generato il messaggio
HOST_ID varchar(4000) Nome dell’host che ha generato il messaggio
MESSAGE varchar(4000) Messaggio
MONITOR_MNG_URL varchar(4000)
MONITOR_PROCESS_NAME varchar(4000)

Le chiavi utilizzate sono:

index K1_SYSLOG_EVENT ON SYSLOG_EVENT (THIS_DATE);

index K2_SYSLOG_EVENT ON SYSLOG_EVENT (THIS_TIME);

NOTE: At the start of the Monitor, the column is set with MONITOR_MNG_URL ** UNDEFINED ** because he still has not been started in-house theater management. Immediately after the start this column will correctly report the value of management eg.: https://192.168.46.109:54443/WebRegister

NOTE1: For the Monitor process the MONITOR_PROCESS_NAME is set with **MONITOR**

Tabella WAF_EXEC

Se Web Application Firewall installato, questa tabella raccoglie il log di tutte le regole eseguite con esito positivo durante il passaggio dei dati.

RECORD_TYPE Int 14 Tipo di record
VRRP_HOST_NAME varchar(350) Nome dell’host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBER int Port number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico
DOMAIN_REQUEST varchar(3500) Se WebSocket è l’host richiesto a layer 7
CLIENT_ADDRESS varchar(3500) Il client address riporta l’indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

THIS_DATE date Data uniformata ad orario a 00:00:00
THIS_TIME time Ora con data uniformata a 01-01-1970
COUNTER int Numero di operazioni sommate in questo record (se non sono stati modificati i default è il numero di operazioni effettuate nella sua finestra temporale negli ultimi 10”)
RULE_ID varchar(100) nome univoco della regola
REQUEST_ID varchar(100)
ENABLE varchar(100) Tipo di abilitazione della regola:

on, off, detect

SCORE int Peso della regola
ACTION varchar(100) Tipo di azione intrapresa:

drop, blacklist_ip …

DESCRIPTION varchar(3500) Descrizione della regola
EXECUTION_QUEUE varchar(100) runtime / near time
CATEGORY varchar(100) Categoria della regola:

Input; Bruteforce; Probing; Info leakage; Authentication; Linked site…

Le chiavi utilizzate sono:

create index K1_WAF_EXEC ON WAF_EXEC (THIS_DATE);

create index K2_WAF_EXEC ON WAF_EXEC (THIS_TIME);

Tabella DDOS_EXEC

Se Web Application Firewall installato, questa tabella raccoglie il log di tutte le regole eseguite con esito positivo durante il passaggio dei dati.

RECORD_TYPE Int 15 Tipo di record
VRRP_HOST_NAME varchar(350) Nome dell’host del servzio VRRP. Questo valore associato al VRRP_PORT_NUMBER, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico. Se Platform Edition vedere Reference Guide parametro uniqueContextID in iproxy.xml
VRRP_PORT_NUMBER int Port number del servzio VRRP. Questo valore associato al VRRP_HOST_NAME, definiscono l’istanza di bilanciamento per il consolidamento dei dati di traffico
DOMAIN_REQUEST varchar(3500) Se WebSocket è l’host richiesto a layer 7
INCOMING_ADDRESS varchar(3500) Indirizzo locale in cui è stata accettata la connessione
CLIENT_ADDRESS varchar(3500) Il client address riporta l’indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

THIS_DATE date Data uniformata ad orario a 00:00:00
THIS_TIME time Ora con data uniformata a 01-01-1970
COUNTER int Numero di operazioni sommate in questo record (se non sono stati modificati i default è il numero di operazioni effettuate nella sua finestra temporale negli ultimi 10”)
TUNNELS int nome univoco della regola
QUARANTINE_TIME bigint Tempo di quarantena
QUARANTINE_START_TIME datetime Inizio quarantena
QUARANTINE_END_TIME datetime Fine quarantena
COUNTRY_CODE varchar(100) Country code dell’attacco
COUNTRY varchar(100) Country estesa
SUBNET int 1 se attacco proveniente da una subnet; 0 se proveniente da singolo IP
DETECT int 1 se rilevato senza azione (detect only); 0 se eseguita azione di mitigazione

Le chiavi utilizzate sono:

create index K1_DDOS_EXEC ON DDOS_EXEC (THIS_DATE);

create index K2_DDOS_EXEC ON DDOS_EXEC (THIS_TIME);

Tabella DAILY_ALERT

Se Web Application Firewall e Attack Prophecy installati, questa tabella raccoglie le notifiche giornaliere di Attack Prophecy.

THIS_DATE date Data uniformata ad orario a 00:00:00
CLIENT_ADDRESS varchar(100) Il client address riporta l’indirizzo del client che ha richiesto il servizio.

es.: 192.168.43.150

COUNTRY_CODE varchar(100) Country code dell’attacco
COUNTRY_DES varchar(350) Country estesa
AS_CODE varchar(100) Codice autonomous system
AS_DESC varchar(350) Descrizione autonomous system
CATEGORY varchar(100) Categoria della regola:

Input; Bruteforce; Probing; Info leakage; Authentication; Linked site…

ALERT_NUM int Numero di alerts

Le chiavi utilizzate sono:

create index K1_DAILY_ALERT ON DAILY_ALERT (THIS_DATE);

Tabella GUIRT_MASTER <->> GUIRT_DETAIL

Le due tabelle GUIRT_MASTER e GUIRT_DETAIL vengono popolate dal modulo GUI Reliability Tool durante l’esecuzione. Queste due tabelle sono correlate in uno a molti (<->>) attraverso il join PLAY-ID.

GUIRT_MASTER
PLAY_ID bigint Id univoco di esecuzione della traccia (Join con PLAY_ID di GUIRT_DETAIL)
HOST_ID varchar(512) Identificativo del nodo LBL GDG (Where)
PROCESS_NAME varchar(512) Nome del modulo (es.: G10_LBLGUIPlayer)
TRACK_ID varchar(512) Nome della traccia assegnato nel form di caricamento del player
START_TIME datetime Data ora di inizio esecuzione della traccia
END_TIME datetime Data ora di fine esecuzione della traccia
ERROR int 0 la traccia non è terminata con errore, 1 la traccia è terminata con errore
GUIRT_DETAIL
PLAY_ID bigint Id univoco di esecuzione della traccia (Join con PLAY_ID di GUIRT_MASTER)
TIME_SEQ bigint È la sequenza temporale dello step. NOTA: Gli step possono essere eseguiti in maniera condizionale e quindi la cronologia del numero dello step può essere diversa dalla sequenza.
STYPE int Tipo di step:

0=process step, 1=text test 2=image test, 3=end step

ERROR int 0 la traccia non è terminata con errore, 1 la traccia è terminata con errore. NOTA: Può succedere che uno step rilevi un errore che però viene corretto da un salto condizionale. In questo caso lo step avrà come ERROR 1 mentra la traccia avrà come ERROR 0
ORIGINAL_SEQ int Data ora di inizio esecuzione della traccia
ROW_NUM int Data ora di fine esecuzione della traccia
ROW_COMPUTETIME bigint Tempo impiegato dal sistema per eseguire l’operazione (esempio tempo di compare image o di ricerca di un testo)
ROW_TIME bigint Tempo totale lordo impiegato per eseguire lo step in millisecondi. Questo tempo comprende il tempo di calcolo ROW_COMPUTETIME che deve essere scorporato se si vuole stimare il tempo netto di attesa
MESSAGE varchar(2000) Messaggio totale
RECORDED varchar(2000) Caricato solo se errore. Se test di tipo TEXT contiene il valore registrato da comparare. Se test di tipo immagine contiene il nome del file con l’immagine registrata per comparazione.
PICKED varchar(2000) Caricato solo se errore. Se test di tipo TEXT contiene il valore rilevato. Se test di tipo immagine contiene il nome del file con l’immagine rilevata.

NOTA: Alla rilevazione dell’errore, vengono spedite al sistema 3 immagini: immagine registrata, immagine rilevata e snap del desktop.

Esempio di selezione con Join GUIRT_MASTER e GUIRT_DETAIL per rilevare tutti gli step di confronto immagine che hanno riscontrato un errore di confronto.

SELECT * from GUIRT_MASTER m

LEFT JOIN GUIRT_DETAIL d ON m.PLAY_ID = d.PLAY_ID

WHERE d.STYPE<>3 and m.ERROR=1 and d.ERROR=1 and STYPE=2

ORDER BY m.START_TIME, m.PLAY_ID, d.TIME_SEQ;

Le immagini vengono trasferite verso il broker che provvede a memorizzarle nella diurectory: (LBL_HOME)/ GUIRTImages/

Il nome del file è composto dal PLAY_ID, sequenza temporale, tipo di immagine: picked, recorded, desktop.

882208199_1534915217334_picked.png

882208199_1534915217334_recorded.png

882208199_1534915217380_desktop.png

ATTENZIONE

GUIRT richiede l’attivazione di Traffic Monetizer con l’utilizzo dell’interceptor di trattamento dei dati in tempo reale.

Il modulo è rilasciato per i seguenti Database: MySQL, Oracle, MS SQL Server.

Stop del modulo

Prima di modificare i parametri eseguire lo stop del modulo interessato.

Modules>Statistic brokers>Choose the module>Edit

Espandere il pannello General start parameters>Impostare Module start da automatic a manual


Eseguire il save dei parametri ed attendere che il modulo sia in stato di Stopped:

Upload librerie di connessione database

Per caricare le librerie del database eseguire:

Files> External libraries>Import> Scegliere il modulo>Browse>Confirm

Alla conferma la libreria verrà caricata nel nodo selezionato. Se servissero più file di libreria ripetere l’operazione per tutti i file.

Associazione della libreria al modulo

Per associare la libreria del database al modulo che si connette al database eseguire:

Modules>Statistic brokers>Choose the module>Edit

Scegliere il pannello del Sistema operativo interessato e modificare il class path con la/e libreria del database. In questo esempio con la libreria MySQL.

Connessione al DB

Per impostare i parametri di connessione al DB, dipendenti dalla tipologia del DB eseguire:


Modules>Statistic brokers>Choose the module>Edit


Espandere il pannello Webcache basic parameter ed impostare i parametri in dipendenza al DB utilizzato.

La lista dei parametri in dipendenza del DB è di seguito riportata.

DERBY EMBEDDED(es. library: derby.jar derbyclient.jar derbytools.jar)
=====================================================================
DBDriver=”org.apache.derby.jdbc.EmbeddedDriver”
DBProtocol=”jdbc:derby:”
DBName=”lib/LBLDBStatistics”
DBDateFormat=”yyyy-MM-dd”
DBTimeFormat=”HH:mm:ss”
DERBY NETWORKED (es. library: derby.jar derbyclient.jar derbytools.jar)
=====================================================================
DBDriver=”org.apache.derby.jdbc.ClientDriver”
DBProtocol=”jdbc:derby:”
DBName=”//___hostname___:___portnumber___/____directoryDBName___”
DBDateFormat=”yyyy-MM-dd”
DBTimeFormat=”HH:mm:ss”
MySQL (es. library: mysql-connector-java-5.1.10-bin.jar)
=====================================================================
DBDriver=”com.mysql.jdbc.Driver”
DBProtocol=”jdbc:mysql:”
DBName=”//___hostname___:___portnumber___/___dbname___”
DBLogin=”root”
DBPassword=”adminadmin”
DBDateFormat=”yyyy-MM-dd 00:00:00″
DBTimeFormat=”1970-01-01 HH:mm:ss”
DBTimeIsDate=”true”
DBVarcharLimit=”3500″
SQLSERVER (es. library: sqljdbc.jar)
=====================================================================
DBDriver=”com.microsoft.sqlserver.jdbc.SQLServerDriver”
DBProtocol=”jdbc:sqlserver:”
DBName=”//___hostname___:___portnumber___;Database=___dbname___”
DBLogin=”sa”
DBPassword=”adminadmin”
DBDateFormat=”yyyy-dd-MM 00:00:00″
DBTimeFormat=”1970-01-01 HH:mm:ss”
ORACLE (es. library: ojdbc6)
=====================================================================
DBDriver=”oracle.jdbc.driver.OracleDriver”
DBProtocol=”jdbc:oracle:”
DBName=”thin:@___hostname___:___portnumber___:___dbname___”
DBLogin=”system”
DBPassword=”adminadmin”
DBDateFormat=”yyyy-MM-dd 00:00:00″
DBTimeFormat=”1970-01-01 HH:mm:ss”
DBSetDateFormat=”ALTER SESSION set NLS_DATE_FORMAT = &apos;YYYY-MM-DD HH24:MI:SS&apos;”
POSTGRES (es. library: postgresql-8.4-701.jdbc4.jar)
=====================================================================
DBDriver=”org.postgresql.Driver”
DBProtocol=”dbc:postgresql:”
DBName=”//___hostname___:___portnumber___/___dbname___”
DBLogin=”postgres”
DBPassword=”adminadmin”
DBDateFormat=”yyyy-MM-dd”
DBTimeFormat=”HH:mm:ss”

Modifica profondità temporale di storicizzazione


LBL®Application Delivery Controller per parametrizzazione di default storicizza i dati con una profondità temporale di 2 giorni. Per modificare questo comportamento è sufficiente impostare il parametro DBMaxHistoryDays. Se questo parametro viene impostato con un valore minore od uguale a 0 (zero) le statistiche non verranno mai cancellate. È possibile anche impostare profondità temporali diversificate per le diverse tabelle del database.

Verifica dei parametri

Dopo aver eseguito il save provare ad avviare il modulo manualmente

Modules>Statistic brokers>Choose the module>Start

Modules>Statistic brokers>Choose the module>See details


Modules>Statistic brokers>Choose the module>Actions>View logs


Modules>Statistic brokers>Choose the module>Actions>View logs>View log


Cercare nel log “DB Statistics initialization done!”

Ripristinare l’esecuzione automatica…

Modules>Statistic brokers>Choose the module>Edit

Espandere il pannello General start parameters>Set Module start da manual a automatic




Eseguire il save dei parametri ed attendere che il modulo sia in stato di Running

ORACLE RAC: Connection string

Per Oracle RAC la stringa di connessione al database statistico deve essere impostata in modo che possa raggiungere i listeners sulle diverse istanze. A tal proposito di seguito un esempio di stringa di connessione con listeners attestati su due hosts rispettivamente: db1 e db2.

DBName=”thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=<db1>)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=<db2>)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=<nome_servizio>)))”

Sei interessato alle nostre soluzioni?