Root Cause Analysis in Microservices Environment

Question

Root Cause Analysis in Microservices Environment

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

0

Questa domanda è il risultato di un dibattito interno che coinvolge i dipartimenti di R & D, DevOps e di automazione della società per cui lavoro. Ecco la sintesi del dibattito:

automation: Abbiamo bisogno dell'accesso SSH a tutti i contenitori durante e dopo i test per automatizzare (almeno parzialmente) RCA, se non lo facciamo, molti errori di test rimarranno inspiegabili e il dipartimento di automazione dovrà fare molto lavoro manuale per analizzare i test. Il tempo trascorso meglio a scrivere nuovi test / fornire una copertura di prova migliore.

R & D: Saremmo lieti di avere accesso SSH perché vogliamo essere in grado di eseguire il debug casualmente dell'applicazione dopo la sua distribuzione o, riconfigurarla allo scopo di testare utilizzando parametri di configurazione che non è necessario essere generalmente disponibili / documentati.

DevOps: Fornire l'accesso SSH è un rischio per la sicurezza (cosa succede se dimentichiamo e lo lasciamo in produzione?). Parti dell'applicazione distribuite nel cloud, quindi, anche se non ci sono dati effettivi in quella distribuzione, le risorse di elaborazione possono essere compromesse. Molti dei contenitori utilizzati nella distribuzione effettiva sono contenitori di terze parti privi di demone SSH, a volte senza alcun sistema operativo, quindi affrontali: non avrai accesso completo a tutti i contenitori che desideri.

Che cosa dici, un requisito di SSH è giustificato? DevOps dovrebbe fare uno sforzo, o dovrebbe l'automazione / R & D pensare a soluzioni alternative?

Se hai un'opinione, puoi eseguirne il backup con una fonte attendibile?

L'implementazione effettiva coinvolge una dozzina di istanze Amazon EC2 che eseguono il cluster Kubernetes con microservizi Scala principalmente combinati con servizi Amazon RDB, ELK, ecc. e alcune caselle Amazon EC2 non containerizzate dedicate a cose come Kafka / MQ ecc.

testing programming-practices microservices

posta wvxvw 14.03.2018 - 14:51

fonte

3 risposte

Leggi altre domande sui tag testing programming-practices microservices

Verifica della versione durante la lettura di strutture profondamente annidate Per un sito Web che utilizza la propria API, è standard per comunicare su HTTP?

score 2 · Answer 1

Devi massimizzare quantità di dati attendibili e opzioni di configurazione e ridurre a icona il numero di elementi a cui devi accedere per questi dati e configurazione.

Come raggiungerlo?

In primo luogo, analizza ciò di cui hai veramente bisogno:
- se hai bisogno di log dal meccanismo di creazione della macchina per fornire questi log senza accedere alla macchina stessa (ci sono molte soluzioni, ad esempio ELK che hai già menzionato)
- se è necessario modificare i parametri dell'applicazione / server / db, è necessario automatizzare questo processo ed estrarre questi parametri come parte della distribuzione automatizzata (presumo che si usi come strumento CI / CD)
- Se è necessario modificare i parametri frequentemente per scopi di test, considerare un ambiente separato per quello. In tal caso è possibile accedere alle macchine senza alcun rischio.

Probabilmente hai molti altri casi: la regola è identificare COSA di cui hai bisogno e COME puoi ottenerlo senza toccare le macchine. Non è solo un problema di sicurezza, ma anche il problema di manutenibilità se è necessario accedere a decine di macchine. La centralizzazione di registri, monitoraggio e configurazione è davvero vantaggiosa in questo caso e paga tutti i costi dell'automazione.

score 1 · Answer 2

DevOps, CI, The Cloud, Containers, VMs ecc. è tutto relativo all'estrazione del codice in esecuzione lontano dal metal box che lo esegue e che ha solo una CPU di potenza / storage / rete ecc. come utility.

Non puoi SSH in una casella quando non hai caselle.

Potresti non vivere ancora in questo mondo perfetto. Ma dovrebbe essere il tuo obiettivo. Ciò significa resistere a questo tipo di richieste / requisiti.

Vediamo i motivi delle richieste

automatizza (almeno parzialmente) RCA

Invece, esporre qualunque cosa stiano controllando una metrica o uno strumento di monitoraggio.

esegui il debug dell'applicazione dopo che è stata distribuita o, riconfigurandola allo scopo di testare

No no no. Crea una nuova versione e distribuiscila.

score 0 · Answer 3

Hai bisogno di un modo per strumentare e riassumere il tuo sistema nel suo insieme. La maggior parte delle storie di successo che hanno scoperto la causa principale in un'infrastruttura di microservizi avevano:

Microservizi strumentati
Transazioni tracciabili su microservizi
Un team dedicato all'analisi delle informazioni

Netflix e Spring hanno il supporto per microservizi che si adattano a questa esigenza abbastanza bene. Un riepilogo delle tecnologie da esaminare include:

Stack ELK: consente di consolidare tutti i log in un'unica posizione con una ricerca ad hoc avanzata
Zipkin: traccia la richiesta di un utente in tutti i microservizi, inclusi quelli asincroni
Netflix Eureka e Hystrix: rilevamento dei servizi e monitoraggio della salute

Ci sono alcuni articoli che parlano di suite di prodotti per gestire questo tipo di cose come:

Hai detto che hai a che fare con i servizi di Scala, e ho visto il supporto per Zipkin che puoi aggiungere.

Gli articoli sopra elencati sono quelli che la mia azienda utilizza, ma gli articoli menzionano prodotti che non abbiamo ancora esplorato. Si spera che ciò fornisca informazioni su come determinare le cause alla radice di natura più sistemica. Il video di AirBnB aveva una buona applicazione pratica che riguardava il tempo in cui uno dei loro servizi andava fuori controllo regolarmente, e il modo in cui ciò influiva sul sistema dei microservizi.