Qual è il punto di registrazione? [chiuso]

I had added some logging statements to our integration testing package, to find out what part of it was taking so long (many hours) to finish.

Our QA manager looked at these statements and said "Why do we need these? We never had logging before, why should we have it now?"

Sono necessari perché "il codice impiega così tanto tempo (molte ore) per finire" e stai cercando di scoprire perché .

• Se questo è generalmente percepito come un problema di prestazioni, il responsabile della qualità non ha svolto il proprio lavoro lasciandolo degradare a questo scarso livello di throughput.

• Se non viene percepito come un problema di prestazioni (e è una possibilità), il responsabile della qualità dovrebbe chiedersi perché stai lavorando su questo < em> a tutti , non mettere in discussione come stai affrontando il problema.

OK, sarebbe una discussione diversa se suggerissero di entrare in un framework di strumenti "standard" invece di eseguire il proprio log, ma non penso che sia il caso qui.

Non dici cosa stai loggando. Nella mia esperienza, il logging è una soluzione subottimale per la maggior parte delle cose, perché quello che succede è che il log è aggiunto e mai rimosso. Poi viene aggiunto altro e non viene mai rimosso, e presto ci sono così tanti registri che se vuoi registrare qualcosa non riesci a trovarlo nell'output di registrazione. Quindi comprendo decisamente il desiderio di mantenere la registrazione minima.

Stai semplicemente registrando i tempi? O stai registrando cose come "Entered function foo ()", "Entered function bar ()", "Exited function bar ()"? Le registrazioni dei log sono quelle che vorresti registrare se hai intenzione di accedere, anche se ci sono modi migliori.

I problemi relativi alla registrazione delle prestazioni sono:

1. Scrivere il codice temporale delle prestazioni è spesso più complicato di quanto sembri. Semplicemente calcolando il tempo all'inizio di un'operazione e alla fine e prendendo la differenza ignora il fatto che altri processi sul sistema possono rallentare il processo di profilazione dando letture fuorvianti
2. La registrazione può influire sulle prestazioni di ciò che stai testando, quindi la registrazione delle prestazioni potrebbe finire per darti risultati non validi

Ci sono altri strumenti per la profilazione (conosciuti come profiler!) che evitano i problemi di cui sopra. Dovresti utilizzare questi strumenti piuttosto che scrivere da soli o aggiungere la registrazione nella maggior parte dei casi. Possono darti dettagli più dettagliati (a volte ti dicono anche le istruzioni esatte che impiegano più tempo) e possono automaticamente differenziare il tempo trascorso nel tuo processo rispetto ad altri processi di sistema. Possono ancora influire sulle prestazioni della tua applicazione o sistema, ma probabilmente è inferiore al tuo codice di registrazione.

(Ho una congettura che) Nel build di rilascio per un sacco di firmware incorporato, potrebbe avere senso disattivare la registrazione o mettere in discussione l'utilità della registrazione se il costo del debug del codice è superiore a quello dell'hardware, oppure il costo di archiviazione dei log può aumentare sostanzialmente il costo totale del prodotto.

Per lo più, non ho sentito perché abbiamo bisogno di registri ma ho sentito un sacco di "oh abbiamo registri !?" la gente che testava il prodotto non era a conoscenza di questo aspetto.

Per triage il problema, ho chiesto loro di esaminare i log e dirmi cosa sta succedendo.

L'usecase comune per la registrazione è / era raccogliere informazioni sullo stato :

a) Fornire informazioni sullo stato di un'applicazione in termini di errori

b) Fornire informazioni processuali su un sistema in termini di ciò che il sistema sta facendo mentre non si arresta in modo anomalo o forse le informazioni di sincronizzazione

Una sottoclasse di (b) è il cosiddetto "debug di stampa". Nel caso in cui la tua applicazione si comporti in modi imprevisti, potresti "stampare" informazioni sullo stato e cercare di dare un senso a questo.

Detto questo: il modo naturale per ottenere informazioni sulla tua scatola nera: l'applicazione in esecuzione, sta scrivendo informazioni di registrazione (in genere sui file). Ci sono pacchetti per ogni lingua disponibile o anche intere applicazioni ( logstash , fluentd ecc.) dedicato a quel lavoro: raccogliere informazioni dai sistemi in esecuzione.

Quindi la risposta alla domanda valida:

"Why do we need these? We never had logging before, why should we have it now?"

Sarebbe:

to find out what part of it was taking so long (many hours) to finish

La domanda di follow-up dovrebbe essere:

Is there another way to get this timing information?

E la risposta è: Sì. Monitoraggio

Esempi: AppDynamics , Nuova reliquia

Inoltre:

I had added some logging statements to our integration testing package

Sembra puzzolente. I tuoi test dovrebbero essere veloci in primo luogo. Ma forse hai un problema in produzione senza saperlo.