|
Don't you just wish you could have a loonie for every time bullet point 3 has happened?
Shoot, I could have wound up chasing Elon Musk in the Forbes 500.
|
|
|
|
|
I know, right? And you stare and you stare, and you run every test and scenario and it's simply, positively, absolutely impossible.
And blip. Another log entry pops up.
cheers
Chris Maunder
|
|
|
|
|
Seen this too many times to count. Unbelievably frustrating at times.
|
|
|
|
|
We've had similar situations in so many oddball scenarios I added a dynamic counter window to our tracing app. Rather than watching for an event to go flying by(*), it's easier to see the count increment.
(*) Our product is multicomputer, multiprocess, and multithreaded. Our logging records hundreds or even thousands of events per second, depending on what the thing is doing.
Software Zen: delete this;
|
|
|
|
|
Agree. Huge topic of discussion. Lots of requirements, lots of conditions, and even more requirements.
Start with first order requirements, such as source, frequency, etc.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Sorry not much to add. Chris said it all.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Quote: Huge topic of discussion
at least there is agreement it`s an interesting topic, I think one could say that any recording in a digital format with a date attached is a type of log.
|
|
|
|
|
the same way as one could say any data in a file is a database: a huge stretch of the imagination!
|
|
|
|
|
Yes; for (3), the best I can do is a "Logic error" message.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Every prepared statement that is about to run, the parameters to the statement, the number of rows returned with how long it took.
|
|
|
|
|
Just be aware of sensitive parameter values.
|
|
|
|
|
sounds like a constructive advice thanks
|
|
|
|
|
I use logs to keep track of users so I can say "I told you not to do that!"
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
spying on poor people, how cruel, that`s an interesting logging use case.
modified 6-Jul-22 11:06am.
|
|
|
|
|
I'm communicating with external devices so I log the communication, both what gets transferred & what settings are used for sending/receiving (yup, they're separate, my professional life's weird albeit cool). I don't log the internal workings outside of few debug cases as those get stabilized by unit tests.
I also output a bit of general program info on start. Version, copyright (of course, that's the most important part of all this), relevant environment variables if applicable.
|
|
|
|
|
I have worked on lots of simulators, telescope and sensor control hardware. These desktop applications operate as processes, so progress through their various tasks is logged, as well as important choices that the software makes throughout the process, and substantive I/O values and events. Naturally unexpected events are logged too, as well as meta-info about software modules and hardware devices. Plus whatever extras we need to track down difficult problems.
Often the goal is to provide the user with the right amount of info to help them solve problems themselves without overwhelming them with cryptic detail, but make the detail available when we need to step in. For example, putting in full file paths saves us a lot of tech support calls when the user cannot find their results, or have a typo in their configuration file. Always include the complete software version (and licensed feature level) that produced the log, too.
The rest of the time a log is a useful history of what data as produced, and how.
- Owen -
|
|
|
|
|
I use a singleton, CLogEntry, so I can make 1 line log entries anyplace or time.
Here, someone copied a folder from one place to another:
CLogEntry.MakeLogEntry(CDefines.TYPE_FOLDER, pFolderInfo.nID, CDefines.LOG_ACTION_COPIED, pFileInfo.m_szTitle);
It adds a date and user ID stamp when it write to the table. So any place something notable happens, I can pop in a single line call and save the info.
|
|
|
|
|
I'll add this. Like a lot of things in development, it's tough to do well.
At a minimum, exceptions must be logged. But, that often doesn't help diagnose the problem ("Hey, we got a NullReference somewhere in this block of code.")
It's often helpful to log something about the context of the exception--maybe the inputs to a method, maybe some other details--to make logging more useful. I suspect it's the same for your functional logging.
Of course, be careful to allow for nulls when constructing the message, or you've multiplied your problem.
|
|
|
|
|
The main program I work on is a COTS desktop application. Our logging works, but I don't think it's up to modern standards. We log...
* Every exception as an Error, even if it doesn't display to the user.
* Every answer to a question in a UI prompt as Info, just because Users like to say "I didn't do that!" when they did.
* Every UI warning as a Warning, so we know if it happened.
* For time sensitive processes, every entry and exit of a method as Debug, but wrapped in a compiler directive so this only happens on non-release builds. This way we know were the bottlenecks are when testing.
* Every new piece of functionality gets Debug logging at important steps in the logic, so when it breaks we know where it broke and what values were being used.
Support has the capability to turn on debug logging on production systems so we can get more details. Also, the log file names are timestamped and rotate to another file if they get too big. We use SmartInspect to do the logging. We wrote our own wrapper around it to simplify its use.
Unfortunately, our logs are stored locally. Our Support team has to fetch them as issues arise. I would love to have the logs sent to a web service we control, but Management/PM's never give me the time to implement this.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Our desktop apps have small user bases, <100. Back in the day, we logged a variety of interactions due to speed and stability of DB/Servers. Today, I'll go with logs are good for a fireplace too . The apps are running five nines+, even on remotes, with better exception handling and DB performance. We were creating logs that no one literally ever looked at, and the once in a blue moon issue was a windows error that was beyond a rabbit hole.
We still log some queries server side, but I can't remember the last time we've looked at one.
|
|
|
|
|
We log the world. Everything is turned on, from inputs into top level API methods and the outputs too. Is it too much logging? Yes... But it's saved us a ton of time and headaches in finding root causes.
We also log passwords in plain text. 🤣
|
|
|
|
|
|
Quote: backend apps
If you ask me that`s not a proper use of the word 'app'. App is something user oriented, backend software is something developer oriented (the exception)
|
|
|
|
|
App is shorthand for “software application”. It refers to any executable, regardless of where it runs. The word was in use before mobile devices and the web existed.
Azure has function apps - no UI.
Windows has service apps - no UI.
Unix and Linux have daemons - no UI.
All are apps.
|
|
|
|
|
Aside from the logging for troubleshooting consider the log to be of some use to the customer/user:
Log users' decisions by username and time for later witch hunt investigation.
Create clear, user actionable error messages so the customer can fix their own problems without having to get you out of bed call you.
|
|
|
|