|
Oh yes I am talking about the VB6 time in the 90's.
Since .net I didn't have much contact with visual basic. All companies I worked for since then all switched to C#, so I can't tell whether it is still used today.
|
|
|
|
|
We have multiple schemes, some do it via file logging and some use kafka broker to log and then it can be visualized using Kibana
|
|
|
|
|
You have to track for unusual activities, warning and error in your logs and send email to administrator to investigate. Most companies dun track their logs, that's why many intruders can stay undetected on their servers for many years.
|
|
|
|
|
Quote: Errors? My applications don't produce errors!
Klingon software is always on the offensive; there is no need of logs when your users have been exterminated.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Klingon Programmer — Software Development
Quote: By filing this bug you have questioned my family honour. Prepare to die!
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
We developed our own logging system containing the standard levels from debug to fatal.
The logging System is cross-plattform and logs to a local logging database (ios, android, windows).
Each log level has a retention time (verbose/debug 24 hours, info, warn 96 hours, error 168 hours, fatal forever). a client-side cleanup job that runs every 1000 log lines does a background delete of all outdated entries, thus making the db log more or less a ring buffer.
It is purely appender-based, and for the windows platform we have local log appenders, eventlog appender (windows eventlog, logs only errors and fatals) as well as a serverappender, which logs errors and fatals to a central serverside log database so the monitoring system can catch them.
For debugging we have console appender, file appender, etc.
Each appender has its own log level, so we can set up the eventlog appender to level "error", which means, it will only trigger for log events of error or above, while the console appender runs on debug level. standard production setting for the appenders is "info".
|
|
|
|
|
We use NLog for file logging and we created an email to help desk for any untrapped exceptions.
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
I write log in my own log file..as simple as TXT file, I don't want tabulation, colors, style in my log.. I just need error line ! 
Find More .Net development tips at : .NET Tips
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
Same here. Small programs, use Mailsend to send to PHB. 
User: Technical term used by developers. See Idiot.
|
|
|
|
|
File (using log4net), Elmah(?), Windows log, database, email, Application Insights...
I've seen them all (sometimes in the same application), no one really knows what to use.
And, of course, no one really knows what to log (at my previous employer we had to log EVERYTHING, which of course became unreadable...).
|
|
|
|
|
"And, of course, no one really knows what to log (at my previous employer we had to log EVERYTHING, which of course became unreadable...)."
Not always unreadable.
That's where log levels and a database log which can be filtered, wins over a plain file logging.
Key is also a structured way of writing your logs. We even have defined formatting rules for log lines. How and where variable values have to printed, what's in quotes and what not, what is in [brackets], how lists have to be logged, etc.
We even do code reviews over the log lines.
Nothing can crush your error investigation more than an unstructured pile of "lines" where everybody writes in the log what's in his mind in a specific moment.
The log is the most important thing in finding errors. This is nothing that "has to be done also", but more something that needs BIG attention and effort to keep it in structure. You win in the long run, when errors occur in production and you need to find their source...
If the structure of the log is clear you can also write crawlers that do a pattern matching and find unusual constellations, fully automated with a low rate of false positives.
You need a very performant db layer with background write that can handle high log density, but the debug level may spam. you only know that you needed a specific log line AFTER the error occurred, so you have a chance to trace back to the origin.
|
|
|
|
|
Let me clear that up.
EVERYTHING was logged in max. 10 MB flat text files in a multi-threaded environment (and keep a max. of 10 files before overwriting the first).
Good luck 
I complained about it a couple of times and even left out logging altogether (except error logging, of course).
We never needed those logs and when we did we didn't because we didn't feel like going through all those log files
|
|
|
|
|
Well "everything" is a term you need to define. It does not exist in my universe. The closest would be a log line for every code line "reached line 314", "reached line 315", ... which makes no sense as there could not be any code beside the log lines themselves.
The main problem is the rolling file architecture and no filter options.
In verbose mode we log up to 50 lines per second, depends on what the app does at a specific moment.
still... in a database log system with smart filters and a STABLE STRUCTURE of your log lines, we find errors in minutes (if not in seconds as we have written a log viewer application that applies multi-column-multi-term-regex filters and we can save those filters as templates).
So we have a set of ~15 filters that cover our most common error scenarios and states the app might have (online mode, offline mode, connection breaks, invalid id's, etc etc).
We go through the filters and within a minute we have a clear picture of what happened.
Oh, our log size is normally between one and three MILLIONS log lines.
No problem.
|
|
|
|
|
We had to log every first and last line of a function, including all input and output parameters.
We had two or three 10 MB files per day, so not a lot.
And still it was pretty much impossible to find anything of value.
Notice that if we had 10 files and two to three files a day, we couldn't search back farther than about 3 to 4 days ago.
Always fun when the software went into a loop, that was usually good for 7 files in a few minutes...
It was really just logging because "we have to log something."
At least we had a separate error log, so that worked (most of the time).
Before that I worked at a company who logged everything to the database.
We had a separate log for exceptions, functional events, and tracing.
We could filter, group, etc. Much easier to find and fix bugs as they happen or long after that.
|
|
|
|
|
"Entering xyz" is what we do too, at least for methods (in java, we do not log getter/setter).
This is the verbose level, retained for about 2 hours in the log.
Enough time for admin team, if the monitoring system raises an alert to snapshot the log and find the codepath, that is active.
Loggin method entries is nothing unusual as far as I can tell.
I personally don't see much sense in logging the exits, except for functions that return a value, but even in those cases we log the return value from the calling method, not inside the executing method, for a simple reason: There are MANY threads active, even with the threadId in the log, the log is easier to follow with lines like "(Methodname) received [HANDLE_INVALID] from [getWindowHandle]. Creating new window." than from an anonymous "Returning [HANDLE_INVALID]" out of a method that runs 50 times a second." (Just an example).
If you can't find anything in those logs, think about their structure.
In our production systems we have no other chance than those logs to find out whats going on, with 10k users online. The log density is extremely high.
But I can understand that writing logs can get boring very easily very fast. But we see it as part of our code quality. The structure of the log is extremely important for monitoring, so we have to keep the patterns straight with not much room for grammar. Some keywords, some values - everything for the monitor 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
