Netscaler logging deserves its own level of hell. You're given 15 undocumented logging levels, with the suggestion not to leave it running longer than necessary, and that level 11 should be enough for anybody.
The Five Levels of Logging
51–60 of 61 posts
Re: The Five Levels of Logging
#52I increasingly feel that there should be two separate logs, one for the user with the Error/Warning/Info information (what the user wanted to be done and how well it went) and the other for the developer with the Debug/Trace information (capture key information about what the program was doing, especially on the interface - what files it was looking for, what database calls it did etc.). I always get complaints from…
This is a very common pattern on Node.js... look into the package debug, it's structured to work as a dev help and can be enabled/disabled per part. So you only enable it for the bit you are debugging and unrelated info gets filtered out.
Re: The Five Levels of Logging
#53> Connecting to server:4242 as "user":"hunter2" as an example of DEBUG logging is very wrong. Passwords should not end up in your logs, ever.
What password? All I see is * * * * * * *.
Hah. Context for others: http://bash.org/?244321
Re: The Five Levels of Logging
#54Earlier quoted context omitted.
What about FATAL errors which prevent the entire program from continuing?
Error and fatal are the same thing. If an operation fails and cannot be recovered, that's an error. There is no meaningful difference between an operation failing and the entire program failing. Or, from another perspective, keeping the program running is just another operation that can have fatal or non-fatal errors.
That depends on the nature of the program. We use error and critical for server software. If there is a protocol violation on a particular connection, log an error and drop the connection, but otherwise continues. If the `accept` system call fails that's critical and the program shuts down. Depending on what we're doing there may be other critical operations, but some software doesn't have any.
Re: The Five Levels of Logging
#55Talking about logging got me a rejection at Google. The very kind 22 year old interviewing me asked what my thoughts on commenting code was and I said most every time it's used as an excuse to show off a piece of overly clever code, so normally I discourage it in favor of logging, as they are code comments you can use in production. I realize now that was my first graybeard moment.
Re: The Five Levels of Logging
#56I increasingly feel that there should be two separate logs, one for the user with the Error/Warning/Info information (what the user wanted to be done and how well it went) and the other for the developer with the Debug/Trace information (capture key information about what the program was doing, especially on the interface - what files it was looking for, what database calls it did etc.). I always get complaints from…
An "audit log" or "branch log", what business decisions were made, and a "debug log", what params drove said decision
Re: The Five Levels of Logging
#57I've always preferred levels of logging rather than these arbitrary names (what's the difference between trace and debug, and which one is lower level?). Give me three levels of logging, 1, 2, and 3, and then warning, and error. Maybe allow to mix and match them, if this makes sense (the typical nomenclature makes them all mutually exclusive, which is dumb). There are your five levels.
Depending on your Coding Culture, you order them based on "priority" (FATAL would have priority over all others, and therefore numbered as 1), or "importance" (FATAL would be most important, and therefore numbered 5.) Alternatively, each is a flag in a number so that they can be combined, with FATAL being 1 or 16 depending on priority vs. importance. I would argue that the names do indeed suffice to tell you their "l…
Curiously, in the days of OpenVMS this was called 'severity' level and was a global system concept [0] related to status code of execution.
Info, Warning, and Error are degrees of Success or Fatal/Severe.
The status would then be logged in a structured manner that shows a facility code, serverity, message.
Re: The Five Levels of Logging
#58I support these 5 levels of logging, but given the discussion below I also would like to highlight a lesson from an SRE talk I once attended[citation needed] that really there are only three levels of alert: 1. DEBUG - Look at this when debugging, otherwise no one will ever see it. 2. TICKET - Open a ticket and have someone on your team look at this when it gets to the top of your queue. 3. PAGER - Drop what you're d…
That may work for an application, but there are many errors that occur while using a library that are expected/handled etc by the application. Perhaps separate logs can help.
Re: The Five Levels of Logging
#59Info: What is the program up to. Occasional messages that indicate it is alive and doing what is expected. Warn: Problems that you know about and wish would not happen, but do anyways. A service call has failed, unexpected input that violates the contract of the method, etc. You may be handling these conditions gracefully and/or returning an error to the caller, but still want to know when they happen. Usually you sh…
IMHO the difference between Warn and Error is that Warn is recoverable while Error is not.
What does recoverable mean though?
If the server process handles it without crashing, is that a recovery?
A more general distinction IMO is the one presented in the article: an Error is something that should not have happened. A Warning is something that maybe should not have happened.
Re: The Five Levels of Logging
#60Talking about logging got me a rejection at Google. The very kind 22 year old interviewing me asked what my thoughts on commenting code was and I said most every time it's used as an excuse to show off a piece of overly clever code, so normally I discourage it in favor of logging, as they are code comments you can use in production. I realize now that was my first graybeard moment.
Without diving too far down the comment rabbit hole (complex but efficient algorithms, external references, legal retirements, backwards compatibilty), that's not true though.
A comment is attached to code. A log is attached to an event.
Conflating those will either give you very bad logs or very bad comments.