Logging
-
camping or trip chairs and tents are my favorites.
If you are camping by car, then yes. But on a bike, A tent is a necessity (and the rest of the space is free for food and beer) ;)
"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!
-
We do a lot of ETL work. Each ETL task takes a different amount of time. We use the logs to calculate the average time for each task to aid in scheduling the next run -- and thereby perform the historically longest-running tasks first. Similarly, we track record counts and signal an error if a record count falls outside the expected range ( +/- some factor).
Thanks Piebaldconsult I had to check online the ETL abbreviation for its meaning. That`s field I wasn`t familiar with.
-
Could some of you guys share a bit about your projects that use logging (not as a debugging process component but as a normal way of application functioning) and the type of things you throw in your logs. I would like to find out about all types of software that does some type of logging, everything ranging from desktop apps to servers. Thanks
This is such an insanely huge topic of discussion. Here's what we do: - Every exception thrown in our code gets logged - When we fix a bug that's due to odd input or conditions we generally log the odd condition up to the point where it's common enough we feel we have a handle on it's many guises - When there's a spot where the code simply cannot, ever, in a million years be reached, and it's reached, we log it. - When there are failures of external services we might log them in order to work out what conditions will cause it to fail so we can work on preemptively not causing those conditions - When conditions in our app become extreme (eg serious user load, serious queue back-ups etc) we log them Some of these logs are for debugging, some for planning, some of these logs are used to trigger alerts, and some for our own amusement.
cheers Chris Maunder
-
This is such an insanely huge topic of discussion. Here's what we do: - Every exception thrown in our code gets logged - When we fix a bug that's due to odd input or conditions we generally log the odd condition up to the point where it's common enough we feel we have a handle on it's many guises - When there's a spot where the code simply cannot, ever, in a million years be reached, and it's reached, we log it. - When there are failures of external services we might log them in order to work out what conditions will cause it to fail so we can work on preemptively not causing those conditions - When conditions in our app become extreme (eg serious user load, serious queue back-ups etc) we log them Some of these logs are for debugging, some for planning, some of these logs are used to trigger alerts, and some for our own amusement.
cheers Chris Maunder
Don't you just wish you could have a loonie for every time bullet point 3 has happened? Shoot, I could have wound up chasing Elon Musk in the Forbes 500. :laugh:
-
Don't you just wish you could have a loonie for every time bullet point 3 has happened? Shoot, I could have wound up chasing Elon Musk in the Forbes 500. :laugh:
I know, right? And you stare and you stare, and you run every test and scenario and it's simply, positively, absolutely impossible. And *blip*. Another log entry pops up.
cheers Chris Maunder
-
This is such an insanely huge topic of discussion. Here's what we do: - Every exception thrown in our code gets logged - When we fix a bug that's due to odd input or conditions we generally log the odd condition up to the point where it's common enough we feel we have a handle on it's many guises - When there's a spot where the code simply cannot, ever, in a million years be reached, and it's reached, we log it. - When there are failures of external services we might log them in order to work out what conditions will cause it to fail so we can work on preemptively not causing those conditions - When conditions in our app become extreme (eg serious user load, serious queue back-ups etc) we log them Some of these logs are for debugging, some for planning, some of these logs are used to trigger alerts, and some for our own amusement.
cheers Chris Maunder
-
Agree. Huge topic of discussion. Lots of requirements, lots of conditions, and even more requirements. Start with first order requirements, such as source, frequency, etc.
"A little time, a little trouble, your better day" Badfinger
-
Agree. Huge topic of discussion. Lots of requirements, lots of conditions, and even more requirements. Start with first order requirements, such as source, frequency, etc.
"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.
-
Could some of you guys share a bit about your projects that use logging (not as a debugging process component but as a normal way of application functioning) and the type of things you throw in your logs. I would like to find out about all types of software that does some type of logging, everything ranging from desktop apps to servers. Thanks
-
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.
-
Could some of you guys share a bit about your projects that use logging (not as a debugging process component but as a normal way of application functioning) and the type of things you throw in your logs. I would like to find out about all types of software that does some type of logging, everything ranging from desktop apps to servers. 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
-
This is such an insanely huge topic of discussion. Here's what we do: - Every exception thrown in our code gets logged - When we fix a bug that's due to odd input or conditions we generally log the odd condition up to the point where it's common enough we feel we have a handle on it's many guises - When there's a spot where the code simply cannot, ever, in a million years be reached, and it's reached, we log it. - When there are failures of external services we might log them in order to work out what conditions will cause it to fail so we can work on preemptively not causing those conditions - When conditions in our app become extreme (eg serious user load, serious queue back-ups etc) we log them Some of these logs are for debugging, some for planning, some of these logs are used to trigger alerts, and some for our own amusement.
cheers Chris Maunder
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
-
Could some of you guys share a bit about your projects that use logging (not as a debugging process component but as a normal way of application functioning) and the type of things you throw in your logs. I would like to find out about all types of software that does some type of logging, everything ranging from desktop apps to servers. Thanks
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.
-
Every prepared statement that is about to run, the parameters to the statement, the number of rows returned with how long it took.
sounds like a constructive advice thanks
-
Could some of you guys share a bit about your projects that use logging (not as a debugging process component but as a normal way of application functioning) and the type of things you throw in your logs. I would like to find out about all types of software that does some type of logging, everything ranging from desktop apps to servers. Thanks
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 -
-
Could some of you guys share a bit about your projects that use logging (not as a debugging process component but as a normal way of application functioning) and the type of things you throw in your logs. I would like to find out about all types of software that does some type of logging, everything ranging from desktop apps to servers. Thanks
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 know, right? And you stare and you stare, and you run every test and scenario and it's simply, positively, absolutely impossible. And *blip*. Another log entry pops up.
cheers Chris Maunder
-
Could some of you guys share a bit about your projects that use logging (not as a debugging process component but as a normal way of application functioning) and the type of things you throw in your logs. I would like to find out about all types of software that does some type of logging, everything ranging from desktop apps to servers. Thanks
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. ;-)
-
Could some of you guys share a bit about your projects that use logging (not as a debugging process component but as a normal way of application functioning) and the type of things you throw in your logs. I would like to find out about all types of software that does some type of logging, everything ranging from desktop apps to servers. Thanks
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
-
Could some of you guys share a bit about your projects that use logging (not as a debugging process component but as a normal way of application functioning) and the type of things you throw in your logs. I would like to find out about all types of software that does some type of logging, everything ranging from desktop apps to servers. Thanks
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.
