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. /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: WebSocket: | |
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 | |
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 = 'YYYY-MM-DD HH24:MI:SS'"
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 >))) "