Logging

[darktrick544]

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.

[Keefer S]

Seen this too many times to count. Unbelievably frustrating at times.

[agolddog]

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. ;-)

[Matt Bond]

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

[MikeCO10]

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.

[decaffeinatedMonkey]

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. 🤣

[Daniel Anderson 2021]

the same way as one could say any data in a file is a database: a huge stretch of the imagination! :-D

[Calin Negru]

spying on poor people, how cruel, that`s an interesting logging use case.

[MSBassSinger]

Disclaimer: I make no claim this is the best for everyone. But it works for me on desktop apps, backend apps, Azure, etc. I have plans to make it open-source sometime this year. I use it often. Your mileage may differ. But it is easy to use, has several useful options. If this post doesn’t look right, I am making it from a mobile browser. NuGet Gallery | Jeff.Jones.JLogger 1.1.2[^] Demo GitHub - MSBassSinger/JLogger_Demo: Demo of how to use the JLogger NuGet package[^]

[Gary Wheeler]

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;

[Calin Negru]

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)

[MSBassSinger]

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.

[MSBassSinger]

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 see

[Shmoken99]

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.