Separating logs: "replay" from "debug"

[bradanlane]

This came up early on and we chose to defer it. Is it time to separate debug logging from log recording?

We are approach the point of stable releases and shifting from significant development to more support and bug fixes (and tweaking). We may even be considering RO for day-to-day users.

Now (or soon) may be a good time to separate recording data from error logs.

Additionally, there is some logging to stratux.log that is "reporting" in nature. This may be useful in a recording situation but verbose in a day-to-day user runtime. We could move it elsewhere, tie it to a "-v" option, tie it to a WebUI setting option, or leave it.

[cyoung]

Do you mean globalSettings.DEBUG (only used for traffic source right now)? Or moving some of the things that are printed in stratux.log like CPU temperature every 30 seconds to a "debug" log class?

[bradanlane]

I was making two points at the same time. (A bad habit of mine.)

Currently "DEBUG" turns on all the logs.

I am suggesting there be a setting for all of the "replay logs" which is separate from debugging and error handling.

My second point was that the "every 30 seconds" reports are also not real debugging. It's valuable and good reporting.

[cyoung]

The ReplayLog setting is used for replay logging and only replay logging, so that part is separate now. The replay log facility does not log errors, nor should it. The main idea of this feature is to save log files that can replicate the "primary" inputs that stratux processes, not any intermediate results or outputs.

The DEBUG setting isn't really as the name implies, really it only turns on the traffic source display and nothing more. The setting should probably be renamed.

Besides replay logs and the stratux.log messages, what should we reclassify?

[bradanlane]

I'd say, when "logging" is turned off (whatever UI we use for it) then all logging should be off with the exception of real errors.

1. So, we can have a UI setting for the recording feature (aka replay).
2. We can choose something in the UI for enabling informational content.

Is this making sense ?

[ScraboTower]

Does all this writing whatever type of log to the SD card not impact performance ? I assume that first logging data is held in memory then occasionally flushed to disk - surely then the cpu has to perform some I/O operations , causing a slight lag ...? I/O is expensive.

[bradanlane]

With the current code, Tthe only "bleed through" I see is: even with replay turned off, informational messages are logged to stratux.log every 30 seconds.

We can either tie this informational logging to the "replay setting" or have some other UI. I'd suggest, for now, when replay is turned off, we also turn off the informational reports every 30 seconds.

What do others think?

[bradanlane]

Can we tie the "status every 30 seconds" to either the "replay" toggle or some form of verbose debugging? A clean running Stratux only generates startup status in the logs and then actual errors. Under normal operations I would not want any of the logs to be growing".

[cyoung]

Yeah, we could move it to another logfile that just logs all of the system stats in CSV format. Even when trying to track down issues with the stratux.log status messages this current format is unwieldy. Any suggestions for contents of a "system status" log? Above what is printed every 30 seconds now.

[bradanlane]

I like the CSV idea.

The current "stats" are a good place to start. I think current UAT message rate, ES message rate, current tower count, current satellite count, etc.

Are you still interested in gathering tower locations ? If so, having that is CSV is a good idea.