Protocol Proxy: Specifiche Implementative
Requisiti Generali - controllare pagina standard e convenzioni
Ogni microservizio deve rispettare gli standard della piattaforma
Ogni proxy deve soddisfare i requisiti suggeriti dal 12 factors manifest
Esposizione di un endpoint
/status
per l'healthcheck: esso deve essere restituire 200 se il sistema è "healthy" e 503 in caso si presentino un problemi di connessione con kafkaEsposizione delle metriche mediante l'endpoint
/metrics
con Prometheus utilizzando la convenzione da loro suggeritaTerminazione pulita del servizio (timeout di 15 secondi)
Esposizione di un endpoint
/docs
per la consultazione della documentazione delle API esposte dal servizio secondo lo standard OpenAPIIntegrazione con Sentry per l'error reporting
Il sistema di logging deve rispettare il formato Apache e descrivere nei tre livelli debug, error e info. Ogni log, quando possibile, deve loggare il
remote_id
e l'id
del documento processatoIl README deve seguire le linee guida della pubblicazione del software open source
il nome del progetto e del servizio devono essere nella seguente forma : "Protocol Proxy <Nome del Protocollo Specifico>"
Inserire il file
.gitlab-ci.yml
riportando in esso questa pipeline
Metriche in dettaglio
Il Protocol Proxy deve esporre le seguenti metriche:
Metrica | Labels | Descrizione |
---|---|---|
| cluster, env, app_name | la metrica deve misurare gli errori di validazione sull'evento letto (es. il |
| cluster, env, method, app_name, status_code | la metrica deve monitorare le chiamate http indicandone lo status code |
| cluster, env, app_name | la metrica deve misurare solo gli eventi per cui il proxy ha una configurazione e che sono stati processati con successo |
| cluster, env, app_name | la metrica deve misurare gli eventi validi di cui però è fallito il processing per qualsiasi motivo (escluso il caso in cui non esiste una configurazione per esso) |
| cluster, env, app_name | la metrica deve misurare gli eventi validi di cui però è fallito il processing a causa di un errore sul provider |
| cluster, env, app_name | la metrica deve misurare gli eventi validi di cui però è fallito il processing per errori interni al codice |
| cluster, env, app_name | istogramma che mostra la distribuzione di latenza delle risposte del provider |
Requisiti normativi
Avere una specifica in formato OpenAPI v3
Rispettare la Linee Guida di interoperabilità: in particolare per quanto riguarda
il formato dei dati (4.2)
raccomandazioni sul naming (4.3) optando per la scelta di
snake_case
per i nomi degli attributilogging (4.4)
risultare valido nel validatore ufficiale OA3
Documentazione API di Esempio - Swagger
Specifiche funzionali
Il servizio deve essere multi tentant e multi servizio: deve quindi essere in grado di gestire le confiugurazioni per più tenant a cui possono essere attribuiti più servizi con il corrente sistema di protocollazione.
Ogni richiesta sia essa appartenente alla fase 1 o alla fase 2 descritte nella sezione "workflow sistema di protocollazione" devono essere trattate in maniera atomica.
Lo storage deve essere compatibile con Aws s3, Azure e local file system.
Configurazione del microservizio (variabili d'ambiente)
Il servizio deve essere configurabile attraverso le seguenti variabili d'ambiente.
Se le varibili senza valore di default non vengono settate, il servizio deve notificare la mancata impostazione attraverso un log di livello error e terminare in maniera pulita la propria esecuzione.
Nome | Default | Descrizione |
---|---|---|
| local | Indica l'ambiente di sviluppo (locale, dev, prod, ecc.) utilizzato da Sentry. |
| true | ... |
| false | ... |
| nessun valore | Endpoint per il monitoraggio di Sentry. |
| kafka:9092 | Lista di lunghezza variabile i cui elementi devono essere separati da virgola. lista degli Indirizzi dei broker Kafka per connettersi al cluster. |
| <nome_del_servizio> | Consumer group per Kafka. |
| documents | Identifica il topic da cui consumare gli eventi Kafka. |
| documents | Identifica il topic a cui inviare gli eventi Kafka. |
| nessun valore | topic in cui produrre gli eventi consumati dal meccanismo di retry |
| 0.0.0.0:8080 | Indica l'indirizzo e la porta utilizzati per l'healthcheck. |
| 5m | ... |
| 10m | ... |
| local | Tipo di storage dei pagamenti: s3, azure, local |
| nessun valore | Indirizzo di accesso allo storage. |
| nessun valore | Chiave di accesso allo storage. |
| nessun valore | Chiave segreta di accesso allo storage. |
| nessun valore | Location del cloud storage |
| nessun valore | Nome dello storage |
| "/data/" | Basepath dello storage |
| nessun valore | Chiave dello storage AZURE |
| nessun valore | Password dello storage AZURE |
| /data/ | |
| nessun valore | utente autenticazione per recuperare il token dalla piattaforma |
| nessun valore | password autenticazione per recuperare il token dalla piattaforma |
Test
Protocol Proxy Tests Checklist
Se si sta facendo il deploy di un nuovo microservizio per la prima volta o si sta aggiungendo una nuova API o una nuova pagina a una interfaccia esistente, è necessario aggiungere alcuni controlli di qualità minima prima del rilascio.
Controlli
Test flusso standard
Inserire la configurazione del tenant
Inserire la configurazione del servizio
Inserire un esempio di documento non protocollato nel topic documents e verificare che venga correttamente protocollato
Inserire un esempio di documento protocollato nel topic documents e verificare che venga ignorato
Inserire un esempio di documento non protocollato nel topic documents per cui non esiste una configurazione di tenant e/o di servizio e verificare che venga ignorato
Test flusso di errore
Modificare la configurazione del servizio in modo che sia errata (mettendo ad esempio credenziali errate)
Inserire un esempio di documento non protocollato nel topic documents e verificare che, a seguito del fallimento, venga prodotto un evento nel topic di retry
Correggere la configurazione del servizio
Inserire il documento prodotto nel topic di retry all'interno del topic documents e verificare che venga correttamente protocollato
Last updated