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