4 ms·
Disagree on the "dynamically increase" logging. Log everything all the time. When you enable logging/debug you've just changed your resource profile. Presumably
by donavanm 14y ago
Disagree on the "dynamically increase" logging. Log everything all the time. When you enable logging/debug you've just changed your resource profile. Presumably your already in a precarious/high risk situation, don't add more change.
Storage is cheap to save your bits. If you need to save money record different granularities, discard old records, or use (good) sampling.
A system to dynamically/automatically capture something like oprofile/systemtap/dtrace can be handy. But on the converse I've seen it make a bad instance dead.
- peterwwillis 14y agoThe problem there is the sheer amount of logs puts strain on the network when logging remotely, and will destroy the box from i/o load locally. The more hardware you have, the cheaper you'll want to be. And unfortunately the engineers don't get to make the budgets ;-) If you have your meter admission up to par, you can throttle back on requests to the box while enabling specific logging. You can employ tricks like enable extra logging for only specific sessions, URIs, etc or only for a specific time period. It's not like you're going to profile your whole application while the site's almost down, but usually there may be a query or a subset of users or something that's abnormally slow.