Acquisizione di avvisi quando l'elaborazione batch viene ignorata

3

Il mio cliente ha un processo che itera su un numero di azioni che possono o non possono essere applicate a un portafoglio di utenti. Molto spesso, l'elaborazione di un'azione può abbandonare e passare all'azione o al portafoglio successivo senza interrompere il processo (cioè l'elaborazione diretta).

A volte la decisione che porta alla riduzione dell'elaborazione dell'azione viene scritta nel registro e talvolta no. Anche quando lo è, questo è normalmente scritto deliberatamente a livello Informazioni piuttosto che Errore o Avviso . C'è una buona ragione per questo: Errori e Avvisi sono anche rilevati da altre regole di elaborazione e vengono generati ticket automatici. Se lasciassimo che accadesse, saremmo inondati di biglietti, molti dei quali non sarebbero necessari.

Il problema è che a volte un utente non chiede irragionevolmente perché non è stata eseguita un'azione sul proprio portafoglio e di solito non chiedono fino a pochi giorni o settimane dopo che l'elaborazione è avvenuta a partire da quando i log sono stati spesso purgato.

Ho suggerito che dovremmo introdurre un sistema più robusto per catturare questi problemi nel momento in cui accadono e abbiamo pensato a quanto segue:

  • Semplicemente migliora la verbosità della registrazione. Bello e facile ma non aiuta con il problema di eliminazione del log e non crea problemi più ovvio.
  • Aggiungi un processo separato per analizzare e analizzare i registri, selezionando su tali questioni. Il vantaggio è che non è necessario alcun o minimo cambiamento di codice, ma potrebbe non essere molto evidente che questo processo è in esecuzione o esiste e potrebbe essere compromesso se i messaggi di registrazione sono cambiati causando la mancata corrispondenza del modello. Potrebbe essere un problema di manutenzione.
  • Modificare il codice per acquisire i messaggi separatamente in una tabella di database. Più robusto e ovvio nel codice, ma il cambiamento è più grande e il design della nuova tabella di database potrebbe diventare una sfida (cioè dovrebbe essere solo un campo di testo libero con un indice di data-ora o qualcosa di più strutturato. più complicato se è necessaria la parametrizzazione - e forse XML blob?

Altri aspetti che guidano il design sono: quanto è facile usare queste informazioni? (potremmo presentarlo all'utente stesso per impedire che ci chiamino in primo luogo?) Abbiamo bisogno di creare un'interfaccia per vederlo / monitorarlo? Possiamo cercare rapidamente i dati e accedere ai dettagli per il problema specifico in questione?

Se qualcuno ha qualche esperienza nel creare (o meglio ancora imbullonare) tale funzionalità, sarei molto interessato a sentire esperienze ecc.

Il tech stak che stiamo usando è C ++ (backend) + semplice database SQL e Javascript / web front end.

Tuttavia, non sono così preoccupato per le soluzioni tecnologiche come la soluzione è (a) Più efficace per il minimo sforzo, (b) più mantenibile e (c) aggiunge più valore in termini di ridurre il tempo trascorso girando intorno all'inchiesta biglietti.

    
posta Component 10 27.02.2017 - 18:57
fonte

1 risposta

3

Direi che questo richiede un nuovo servizio che non è mescolato con la registrazione poiché sembra essere un altro motivo. Se si desidera mantenere la registrazione, è possibile lanciare una soluzione ad alta velocità per questo problema, ad esempio lo stack ELK. Ciò consentirebbe di memorizzare quasi tutti i log pur essendo molto ricercabili, ma ha lo svantaggio di essere più manutenzione.

    
risposta data 27.02.2017 - 19:11
fonte

Leggi altre domande sui tag