Come progettare il monitoraggio degli errori per i lavori batch con passaggi multipli e diversi?

Question

Come progettare il monitoraggio degli errori per i lavori batch con passaggi multipli e diversi?

#1 da (3 voti)

3

Sto lavorando a un software per integrare un negozio di e-commerce e l'ERP aziendale. Tutti i passaggi di integrazione vengono eseguiti come un processo batch unico, ogni 5 minuti. Le cose stanno funzionando in fase di produzione, ma sono alle prese con il modo di progettare meglio il sottosistema che ci avvisa (sviluppatori e personale IT) che si sta verificando un errore di integrazione.

Essenzialmente, il software integra tutti i nuovi clienti, le nuove fatture, azioni, prodotti e così via. Per semplificare le cose, il processo è stato sviluppato per essere eseguito come una sequenza seriale. Esempio: integrare prima i clienti e dopo le fatture, quindi non possiamo avere fatture senza dati dei clienti. Quando qualcosa non va a buon fine (il nostro provider di e-commerce tenta di integrare alcuni dati non validi su un cliente specifico o semplicemente non funziona), l'intero processo fallisce e segnala a Nagios (un sistema di monitoraggio e allerta) avvisarci.

Sto cambiando il design in modo che un problema specifico con una singola unità non fermi il processo, ma il problema è la progettazione di allerta che l'integrazione di quella specifica unità è fallita, e non è necessario manipolare i log per trovare cosa sta succedendo.

Ho riflettuto su alcuni modi, ma mi piacerebbe sapere se c'è un modo migliore per affrontare questo problema:

Invia un'e-mail all'IT con una descrizione semplificata del problema, con alcuni dati (esempio: numero di fattura), in modo che possano aprire un ticket di emissione con il fornitore di e-commerce. Il problema è che il processo viene provato ad ogni elaborazione in batch, quindi dovremmo avere un modo per inviare solo una e-mail per ogni problema.
Invia il problema a un sistema centralizzato (da sviluppare) tramite API e mostra una pagina web che elenca i problemi attuali. Ci dovrebbe essere un modo per, di nuovo, gestire gli errori duplicati e rimuovere gli errori risolti dall'elenco dopo che sono stati risolti e le unità integrate.

Sono davvero bloccato a questo progetto e vorrei sapere se esiste un altro modo migliore per gestire le incoerenze dei dati di tali lavori batch, anche se richiede lo sviluppo di alcune "infrastrutture" per semplificarci.

error-handling integration monitoring

posta user149702 02.12.2015 - 22:55

fonte

1 risposta

Leggi altre domande sui tag error-handling integration monitoring

Pattern builder: separazione della costruzione dalla rappresentazione Come modellare una risorsa ordinabile nel database sql? [chiuso]

score 3 · Accepted Answer

The problem is the design of alerting that the integration of that specific unit failed.

Fai un passo indietro dalla soluzione tecnica e pensaci prima da una prospettiva di business.

Quali tipi di errori dovrebbero accadere? Segui ogni passaggio di integrazione e elenca le cose che possono andare storte. Raggruppa questi livelli in diversi livelli di gravità. Ad esempio, questi possono essere minori (ad esempio, il sistema ricollegato dopo una breve disconnessione), moderato (ad esempio un record è stato scaricato perché non valido) o maggiore (ad esempio il sistema è inattivo).

Potresti aver bisogno di intelligenza qui. Ad esempio, problemi di gravità inferiore (ad esempio conversione dei dati) potrebbero indicare un errore più grave (ad esempio, se un intero file di input non è valido).

Chi deve rispondere? Diversi errori possono essere corretti da persone diverse in momenti diversi della giornata. Avrai anche bisogno di backup nel caso in cui la persona designata non sia disponibile (ad es. Malata) o occupata (ad esempio occupandosi di un altro problema).

Le risposte a queste domande determinano il mezzo migliore. Probabilmente gli errori meno importanti possono essere archiviati per una revisione successiva. Probabilmente gli errori di conversione dei dati sono meglio fascicolati e indirizzati alla rinfusa. Gli errori gravi devono essere comunicati urgentemente agli utenti, ma potresti volere utilizzare un messaggio diverso durante la notte (ad es. SMS) rispetto al giorno (ad es. E-mail o messaggio Slack).

Non vuoi che i problemi di gravità inferiore inondino gli utenti . Questo li allena solo a ignorare gli errori. Rende più difficile trovare la causa principale.

Prendi in considerazione anche altri requisiti. Avete accordi sul livello di servizio? Il numero di fallimenti può contribuire a questo. Gestisci cosa segnala i tipi di guasti e il tempo impiegato per risolverli? Le persone vengono pagate in più per occuparsi di problemi fuori orario?

I've thought about some ways, but I would like to know if there is some better way to tackle this.

La buona notizia sono molti sistemi là fuori che fanno già questo genere di cose. Ad esempio, la maggior parte dei server syslog ha un motore di regole che può prendere i vari messaggi da origini diverse (ogni passaggio di integrazione) quindi eseguire uno script se le condizioni sono soddisfatte (ad esempio, inviare un messaggio di posta elettronica o SMS). Questo separa il modo in cui i sistemi segnalano errori (ad es. Tramite syslog), le regole che determinano se le azioni vengono intraprese (utilizzando il motore delle regole) e quali sono quelle azioni (gli script).