DB Networked setup

Note prima dell' installazione

Oplon 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 Oplon.

Oplon Application Delivery Controller gestisce la persistenza delle statistiche su Database Relazione in maniera Transazionale. Nella configurazione di default utilizza l'images engine JavaDB Embedded fornito direttamente nella distribuzione Java (JDK). Oltre a JavaDB Embedded Oplon 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:

Postgres
Oracle
MS SQLServer
MariaDB (InnoDB engine)
JavaDB embedded (default)
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:

Embedded
Networked

Per Embedded si intende l'utilizzo esclusivo del Database di Oplon 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 (Oplon Application Delivery Controller WebCacheBroker).

Nei parametri preimpostati il processo Oplon 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 Oplon S.A.A.I. Reference Guide).

Ovviamente essendo dei processi separati Oplon Application Delivery Controller (il produttore delle statistiche) e Oplon 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 Oplon Application Delivery Controller Standard HA e Oplon Application Delivery Controller Enterprise HA è infatti possibile consolidare all'interno dello stesso DB e nelle stesse tabelle i dati provenienti da più Istanze Oplon 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.

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 OPLON 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_L7_HTTP_HTTPS ON L7_HTTP_HTTPS (THIS_DATE);

index K2_L7_HTTP_HTTPS ON L7_HTTP_HTTPS (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 OPLON 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

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 OPLON 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 Oplon 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 OPLON 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	Se alla traccia in esecuzione è stata assegnata una lista “csv” di sostituzione è il numero della riga della lista in esecuzione.
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

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="jdbc:postgresql:"
DBName="//\_\_\_hostname\_\_\_:\_\_\_portnumber\_\_\_/\_\_\_dbname\_\_\_"
DBLogin="postgres"
DBPassword="adminadmin"
DBDateFormat="yyyy-MM-dd"
DBTimeFormat="HH:mm:ss"

Modifica profondità temporale di storicizzazione

Oplon 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 >))) "