Verbose Logging Will Disturb your Sleep - Revision history

Kevlin: Verbose logging will disturb your sleep moved to Verbose Logging Will Disturb your Sleep

2009-07-05T22:00:29Z

Verbose logging will disturb your sleep moved to Verbose Logging Will Disturb your Sleep

←Older revision

Revision as of 22:00, 5 July 2009

Kevlin at 08:56, 22 November 2008

2008-11-22T08:56:45Z

←Older revision		Revision as of 08:56, 22 November 2008
Line 1:		Line 1:
-	When I encounter a system that has already been in development or production for a while, the first sign of real trouble is always a dirty log. You know what I'm talking about. When clicking a single link on a normal flow on a web page results in a deluge of messages in the only log that the system provides. Too much logging is as useless as none at all.	+	When I encounter a system that has already been in development or production for a while, the first sign of real trouble is always a dirty log. You know what I'm talking about. When clicking a single link on a normal flow on a web page results in a deluge of messages in the only log that the system provides. Too much logging can be as useless as none at all.

-	If your systems are like mine, when your job is done someone else's job is just starting. After the system has been developed, it will hopefully live a long and prosperous life serving customers. If you're lucky. How do you know if something goes wrong when the system is in production, and how will you deal with it?	+	If your systems are like mine, when your job is done someone else's job is just starting. After the system has been developed, it will hopefully live a long and prosperous life serving customers. If you're lucky. How will you know if something goes wrong when the system is in production, and how will you deal with it?

	Maybe someone monitors your system for you, or maybe you will monitor it yourself. Either way, the logs will be probably part of the monitoring. If something shows up and you have to be woken up to deal with it, you want to make sure there's a good reason for it. If my system is dying, I want to know. But if there's just a hiccup, I'd rather enjoy my beauty sleep.		Maybe someone monitors your system for you, or maybe you will monitor it yourself. Either way, the logs will be probably part of the monitoring. If something shows up and you have to be woken up to deal with it, you want to make sure there's a good reason for it. If my system is dying, I want to know. But if there's just a hiccup, I'd rather enjoy my beauty sleep.

-	For many systems, the first indication that something is wrong is a log message being written to some log. Mostly, this will be the error log. So do yourself a favor: Make sure from day one that if something is logged in the error log, you're willing to have someone call and wake you in the middle of the night about it. If you can simulate load on your system during system testing, looking at a noise-free error log is also a good first indication that your system is reasonably robust. Or ~~a first~~ warning if it's not.	+	For many systems, the first indication that something is wrong is a log message being written to some log. Mostly, this will be the error log. So do yourself a favor: Make sure from day one that if something is logged in the error log, you're willing to have someone call and wake you in the middle of the night about it. If you can simulate load on your system during system testing, looking at a noise-free error log is also a good first indication that your system is reasonably robust. Or an early warning if it's not.

-	~~For my~~ systems~~, the best indication that everything~~ is ~~all right~~, ~~is that the messages at~~ a ~~lower priority are ticking along happily~~. ~~I want about one INFO-level log message for every significant event for the application~~.	+	Distributed systems add another level of complexity. You have to decide how to deal with an external dependency failing. If your system is very distributed, this may be a common occurrence. Make sure your logging policy takes this into account.

-	~~Distributed systems add another level of complexity. You have to decide how to deal with an external dependency failing. If your system~~ is ~~very distributed, this may be~~ a ~~common occurrence~~. ~~Make sure your logging policy takes this into consideration~~.	+	In general, the best indication that everything is all right is that the messages at a lower priority are ticking along happily. I want about one INFO-level log message for every significant application event.

-	A cluttered log is an indication that the system will be hard to control once it reaches production. ~~Like with all problems:~~ If you don't expect anything to show up in the error log, it will be much easier to know what to do when something does show up.	+	A cluttered log is an indication that the system will be hard to control once it reaches production. If you don't expect anything to show up in the error log, it will be much easier to know what to do when something does show up.

Jhannes: Added a short sentence on distributed systems. Feels very detached

2008-11-15T21:06:33Z

Added a short sentence on distributed systems. Feels very detached

←Older revision		Revision as of 21:06, 15 November 2008
Line 8:		Line 8:

	For my systems, the best indication that everything is all right, is that the messages at a lower priority are ticking along happily. I want about one INFO-level log message for every significant event for the application.		For my systems, the best indication that everything is all right, is that the messages at a lower priority are ticking along happily. I want about one INFO-level log message for every significant event for the application.
		+
		+	Distributed systems add another level of complexity. You have to decide how to deal with an external dependency failing. If your system is very distributed, this may be a common occurrence. Make sure your logging policy takes this into consideration.

	A cluttered log is an indication that the system will be hard to control once it reaches production. Like with all problems: If you don't expect anything to show up in the error log, it will be much easier to know what to do when something does show up.		A cluttered log is an indication that the system will be hard to control once it reaches production. Like with all problems: If you don't expect anything to show up in the error log, it will be much easier to know what to do when something does show up.

Jhannes: Improved language

2008-10-31T20:34:10Z

Improved language

←Older revision		Revision as of 20:34, 31 October 2008
Line 5:		Line 5:
	Maybe someone monitors your system for you, or maybe you will monitor it yourself. Either way, the logs will be probably part of the monitoring. If something shows up and you have to be woken up to deal with it, you want to make sure there's a good reason for it. If my system is dying, I want to know. But if there's just a hiccup, I'd rather enjoy my beauty sleep.		Maybe someone monitors your system for you, or maybe you will monitor it yourself. Either way, the logs will be probably part of the monitoring. If something shows up and you have to be woken up to deal with it, you want to make sure there's a good reason for it. If my system is dying, I want to know. But if there's just a hiccup, I'd rather enjoy my beauty sleep.

-	For many systems, the first indication that something is wrong is ~~because~~ a log message ~~of the correct level has been~~ written to a log. Mostly, this will be the error log. So do yourself a favor: Make sure from day one that if something is logged in the error log, you're willing to have someone call and wake you in the middle of the night about it. If you can simulate load on your system during system testing, looking at a ~~well~~-~~kept~~ error log is also a good first indication that your system is reasonably robust. Or a first warning if it's not.	+	For many systems, the first indication that something is wrong is a log message being written to some log. Mostly, this will be the error log. So do yourself a favor: Make sure from day one that if something is logged in the error log, you're willing to have someone call and wake you in the middle of the night about it. If you can simulate load on your system during system testing, looking at a noise-free error log is also a good first indication that your system is reasonably robust. Or a first warning if it's not.

	For my systems, the best indication that everything is all right, is that the messages at a lower priority are ticking along happily. I want about one INFO-level log message for every significant event for the application.		For my systems, the best indication that everything is all right, is that the messages at a lower priority are ticking along happily. I want about one INFO-level log message for every significant event for the application.

Kevlin at 16:10, 31 October 2008

2008-10-31T16:10:20Z

←Older revision		Revision as of 16:10, 31 October 2008
Line 1:		Line 1:
	When I encounter a system that has already been in development or production for a while, the first sign of real trouble is always a dirty log. You know what I'm talking about. When clicking a single link on a normal flow on a web page results in a deluge of messages in the only log that the system provides. Too much logging is as useless as none at all.		When I encounter a system that has already been in development or production for a while, the first sign of real trouble is always a dirty log. You know what I'm talking about. When clicking a single link on a normal flow on a web page results in a deluge of messages in the only log that the system provides. Too much logging is as useless as none at all.

-	If your systems are like mine, when your job is done, someone else's job is just starting. After the system has been developed, it will hopefully live a long and prosperous life serving customers. If you're lucky. How do you know if something goes wrong when the system is in production, and how will you deal with it?	+	If your systems are like mine, when your job is done someone else's job is just starting. After the system has been developed, it will hopefully live a long and prosperous life serving customers. If you're lucky. How do you know if something goes wrong when the system is in production, and how will you deal with it?

-	Maybe someone monitors your system for you, or maybe you will monitor it yourself. Either way, the logs will be probably part of the monitoring. If something shows up and you have to ~~wake~~ up to deal with it, you want to make sure there's a good reason for it. If my system is dying, I want to know it. But if there's just a hiccup, I'd rather enjoy my beauty sleep.	+	Maybe someone monitors your system for you, or maybe you will monitor it yourself. Either way, the logs will be probably part of the monitoring. If something shows up and you have to be woken up to deal with it, you want to make sure there's a good reason for it. If my system is dying, I want to know. But if there's just a hiccup, I'd rather enjoy my beauty sleep.

-	For many systems, the first indication that something is wrong is because a log message of the correct level has been written to a log. Mostly, this will be the error log. So do yourself a favor: Make sure from day one that if something is logged the error log, you're willing to have someone call and wake you in the middle of the night about it. If you can simulate load on your system during system testing, looking at a well-kept error log is also a good first indication that your system is reasonably robust. Or a first warning if it's not.	+	For many systems, the first indication that something is wrong is because a log message of the correct level has been written to a log. Mostly, this will be the error log. So do yourself a favor: Make sure from day one that if something is logged in the error log, you're willing to have someone call and wake you in the middle of the night about it. If you can simulate load on your system during system testing, looking at a well-kept error log is also a good first indication that your system is reasonably robust. Or a first warning if it's not.

	For my systems, the best indication that everything is all right, is that the messages at a lower priority are ticking along happily. I want about one INFO-level log message for every significant event for the application.		For my systems, the best indication that everything is all right, is that the messages at a lower priority are ticking along happily. I want about one INFO-level log message for every significant event for the application.
Line 15:		Line 15:
	By [[Johannes Brodwall]]		By [[Johannes Brodwall]]

-	This work is licensed under a	+	This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
-	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]	+



	Back to [[97 Things Every Programmer Should Know]] home page		Back to [[97 Things Every Programmer Should Know]] home page

Jhannes: Fixed phrasing

2008-10-30T20:56:08Z

Fixed phrasing

←Older revision		Revision as of 20:56, 30 October 2008
Line 3:		Line 3:
	If your systems are like mine, when your job is done, someone else's job is just starting. After the system has been developed, it will hopefully live a long and prosperous life serving customers. If you're lucky. How do you know if something goes wrong when the system is in production, and how will you deal with it?		If your systems are like mine, when your job is done, someone else's job is just starting. After the system has been developed, it will hopefully live a long and prosperous life serving customers. If you're lucky. How do you know if something goes wrong when the system is in production, and how will you deal with it?

-	Maybe someone monitors your system for you, or maybe you will monitor it yourself. Either way, ~~what~~ the ~~system~~ logs ~~is going to~~ be ~~critical~~ to ~~know when~~ you want to ~~be woken up in the middle of the night~~.	+	Maybe someone monitors your system for you, or maybe you will monitor it yourself. Either way, the logs will be probably part of the monitoring. If something shows up and you have to wake up to deal with it, you want to make sure there's a good reason for it. If my system is dying, I want to know it. But if there's just a hiccup, I'd rather enjoy my beauty sleep.

	For many systems, the first indication that something is wrong is because a log message of the correct level has been written to a log. Mostly, this will be the error log. So do yourself a favor: Make sure from day one that if something is logged the error log, you're willing to have someone call and wake you in the middle of the night about it. If you can simulate load on your system during system testing, looking at a well-kept error log is also a good first indication that your system is reasonably robust. Or a first warning if it's not.		For many systems, the first indication that something is wrong is because a log message of the correct level has been written to a log. Mostly, this will be the error log. So do yourself a favor: Make sure from day one that if something is logged the error log, you're willing to have someone call and wake you in the middle of the night about it. If you can simulate load on your system during system testing, looking at a well-kept error log is also a good first indication that your system is reasonably robust. Or a first warning if it's not.

Jhannes at 15:57, 28 October 2008

2008-10-28T15:57:00Z

←Older revision		Revision as of 15:57, 28 October 2008
Line 1:		Line 1:
	When I encounter a system that has already been in development or production for a while, the first sign of real trouble is always a dirty log. You know what I'm talking about. When clicking a single link on a normal flow on a web page results in a deluge of messages in the only log that the system provides. Too much logging is as useless as none at all.		When I encounter a system that has already been in development or production for a while, the first sign of real trouble is always a dirty log. You know what I'm talking about. When clicking a single link on a normal flow on a web page results in a deluge of messages in the only log that the system provides. Too much logging is as useless as none at all.

-	If your systems are like mine, when your job is done, someone else's job is just starting. After the system has been developed, it will hopefully live a long and ~~full~~ life serving customers. If you're lucky. How do you know if something goes wrong when the system is in production, and how will you deal with it?	+	If your systems are like mine, when your job is done, someone else's job is just starting. After the system has been developed, it will hopefully live a long and prosperous life serving customers. If you're lucky. How do you know if something goes wrong when the system is in production, and how will you deal with it?

	Maybe someone monitors your system for you, or maybe you will monitor it yourself. Either way, what the system logs is going to be critical to know when you want to be woken up in the middle of the night.		Maybe someone monitors your system for you, or maybe you will monitor it yourself. Either way, what the system logs is going to be critical to know when you want to be woken up in the middle of the night.

-	For many systems, the first indication that something is wrong is because a log message of the correct level has been written to a log. Mostly, this will be the error log. So do yourself a favor: Make sure from day one that ~~nothing comes in~~ the error log ~~that~~ you're ~~not~~ willing to have someone call and wake you in the middle of the night about. If you can simulate load on your system during system testing, looking at a well-kept error log is also a good first indication that your system is reasonably robust. Or a first warning if it's not.	+	For many systems, the first indication that something is wrong is because a log message of the correct level has been written to a log. Mostly, this will be the error log. So do yourself a favor: Make sure from day one that if something is logged the error log, you're willing to have someone call and wake you in the middle of the night about it. If you can simulate load on your system during system testing, looking at a well-kept error log is also a good first indication that your system is reasonably robust. Or a first warning if it's not.

	For my systems, the best indication that everything is all right, is that the messages at a lower priority are ticking along happily. I want about one INFO-level log message for every significant event for the application.		For my systems, the best indication that everything is all right, is that the messages at a lower priority are ticking along happily. I want about one INFO-level log message for every significant event for the application.

-	A cluttered log is an indication that	+	A cluttered log is an indication that the system will be hard to control once it reaches production. Like with all problems: If you don't expect anything to show up in the error log, it will be much easier to know what to do when something does show up.

Jhannes: New page: When I encounter a system that has already been in development or production for a while, the first sign of real trouble is always a dirty log. You know what I'm talking about. When clicki...

2008-10-27T18:10:13Z

New page: When I encounter a system that has already been in development or production for a while, the first sign of real trouble is always a dirty log. You know what I'm talking about. When clicki...

New page

When I encounter a system that has already been in development or production for a while, the first sign of real trouble is always a dirty log. You know what I'm talking about. When clicking a single link on a normal flow on a web page results in a deluge of messages in the only log that the system provides. Too much logging is as useless as none at all.

If your systems are like mine, when your job is done, someone else's job is just starting. After the system has been developed, it will hopefully live a long and full life serving customers. If you're lucky. How do you know if something goes wrong when the system is in production, and how will you deal with it?

Maybe someone monitors your system for you, or maybe you will monitor it yourself. Either way, what the system logs is going to be critical to know when you want to be woken up in the middle of the night.

For many systems, the first indication that something is wrong is because a log message of the correct level has been written to a log. Mostly, this will be the error log. So do yourself a favor: Make sure from day one that nothing comes in the error log that you're not willing to have someone call and wake you in the middle of the night about. If you can simulate load on your system during system testing, looking at a well-kept error log is also a good first indication that your system is reasonably robust. Or a first warning if it's not.

For my systems, the best indication that everything is all right, is that the messages at a lower priority are ticking along happily. I want about one INFO-level log message for every significant event for the application.

A cluttered log is an indication that

By [[Johannes Brodwall]]

This work is licensed under a
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

Back to [[97 Things Every Programmer Should Know]] home page