|
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.
|
|
|
|
|
As far as design or process, this is my general pattern for logging. Of course, I also consider if any one or more of the steps is needed or not, or whether there is value in logging in any particular code block.
1 - On methods, use try-catch, and optionally, finally. Part of it is to ensure I log exceptions, and part of it is to destroy objects I create, given the GC may be slow to actually destroy the instance. The GC thing is a preference I have and a whole other discusssion.
2 - My logger gets the module and method names, as well as the line number so I can isolate where the problem occurred. It also captures the machine and usernames.
3 - My logger checks for inner exception instances to be sure to get all the exception messages.
4 - My log, when in a file, is tab delimited so it can be opened in Excel (or some other reader that handles columns). That aids in isolating specific repeating problems and doing analysis. The log to a SQL database table is easily queried from the same columns.
5 - My logging uses a bitset (flagged Enum) to categorize the log type. A bit comparison is used before logging so that if a particular log type is not "turned on", the call to the log is not made and that function overhead is not incurred. That also allows me to define what types to log in a config file, which can be changed at runtime to increase or decrease logging.
6 - My logger uses a queue approach, so that log entries are made to the queue (very fast, non-blocking, works great in multithreaded environments where there could be thousands of log entries from multiple parallel tasks). A separate task unwinds the FIFO queue to the written log or database (whichever is chosen). On shutdown, the queue is emptied before the logger shuts down.
7 - The logger creates a set of initial entries that capture system state, such as RAM, ethernet ports, disk space, OS and .NET info, etc. That has proven to be useful in figuring out problems related to the environment.
8 - I can include performance measurement for each method, and the code for it does not execute unless the performance bit is turned on in the log type bitset. Same for auditing flow in the log.
9 - I can optionally have a log entry send an email.
10 - If there is a practical need, I can add user-defined columns to my log (file or DB).
11 - I use the Exception.Data collection to store name-value pairs of runtime values that are useful in understanding the state at the time of the exception, and then logged. More than once, I have seen a value captured that immediately told me what the problem was (usually some missing validation on the front end).
Every developer is different in how they do things, and why. My approach has been refined over the decades to minimize the time spent during QA and during the post-production support part of the SDLC. If a given approach works for you, then it is the right approach.
|
|
|
|
|
Wasteful flip - or twist portcullis? (10)
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Profligate ?
Edit
Anagram of flip or and gate (portcullis)
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
modified 4-Jul-22 4:34am.
|
|
|
|
|
I liked that one - you are up tomorrow! 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yes nice clue
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
