Ho bisogno di qualche input per la memorizzazione delle informazioni di stdin, stdout, stderr per il debug

1

Sto lavorando con un sistema legacy che non è male, ma ho pensato di apportarvi alcuni miglioramenti, e volevo sollecitare il vostro feedback per aiutarmi a prendere buone decisioni. La piattaforma è Linix (diverse versioni di esso).

Il sistema ruota attorno all'esecuzione [a volte lunghi] di "lavori" - programmi a riga di comando. I lavori di solito riescono, ma a volte possono fallire, e quando lo fanno è molto importante diagnosticare cosa è andato storto in modo efficiente, e correggere i problemi sottostanti (se ce ne sono) e riavviare un lavoro.

Per questo motivo non utilizziamo software di terze parti perché abbiamo bisogno di un controllo completo sul processo. In questo momento le informazioni su un lavoro vengono salvate su disco come file: c'è un file per stdin, un file che memorizza il codice di uscita, un file per stdout e stderr combinato, e so anche esattamente come è stato avviato il processo - che cosa era il nome del comando e quali erano gli argomenti.

Ora ... pensavo di dividere le uscite stdout e stderr in file diversi, ma poi mi sono reso conto che quando sono combinati insieme, si può vedere l'ordine cronologico dei messaggi, eccetto che ora prende un giudizio umano per dire quale era output e che contiene gli errori. Portandolo ad un estremo estremo - perché non lanciare stdin nel mix? Potrebbe essere importante, a scopo di debug, quale sia stata la linea di input specifica che ha causato un errore. Idealmente il messaggio di errore sarebbe sufficientemente descrittivo da fornire un sacco di contesto, ma questo non sempre accade.

Sto cercando un modo pulito per organizzare questi dati in modo che la logica automatizzata possa essere utilizzata per aiutare gli esseri umani con la diagnostica degli errori. Con molti lavori che eseguono questi errori, accadono piuttosto spesso. Un esempio di qualcosa che potrei voler interrogare - quali sono state le ultime 20 righe di input che hanno preceduto la prima riga in stderr? Suppongo che l'esatta marca temporale possa essere utile, ma non così importante. Inoltre, poiché si utilizza un modulo di registrazione, spesso le righe di output contengono già timestamp, ma non sempre: non ho scritto ogni bit di questo sistema legacy. Posso apportare modifiche ad esso; Non voglio riscriverlo.

Potresti proporre un buon modo per massaggiare questi flussi (aggiungere forse una sorta di metadati) per organizzare le cose in modo pulito? Il requisito è che non si debba utilizzare molta potenza di calcolo o spazio su disco / ram. Sospetto che il mio problema non sia unico. Grazie in anticipo.

    
posta Job 19.01.2013 - 18:16
fonte

1 risposta

2

Quando ho dovuto fare questo, ho sempre usato un singolo file di log con i timbri "source-and-time".

Anche se questo può essere molto utile, c'è ancora il problema che STDOUT è normalmente bufferizzato, mentre STDERR normalmente non lo è. Ciò significa che guardando un log combinato di righe di output etichettate, le linee adiacenti potrebbero non essere mai avvenute l'una vicino all'altra nel tempo. Puoi annullare il buffer STDOUT , ma questo può introdurre un effetto Heisenberg in modo che il programma abbia esito positivo / negativo in modi diversi.

La mia soluzione è assicurarsi che ogni chiamata al registro STDERR scarichi sempre STDIN prima . Sì, questo ha ancora un effetto Heisenberg, ma normalmente non è male.

Riguardo a STDIN : puoi memorizzarli nello stesso file di registro comune e durante un'esecuzione di prova cerca la riga successiva contrassegnata con STDIN . Puoi anche usarlo per fare test di regressione in quel file di log da 2 esecuzioni dovrebbe essere equivalente (ignorando il tempo).

    
risposta data 19.01.2013 - 18:48
fonte

Leggi altre domande sui tag