-
Notifications
You must be signed in to change notification settings - Fork 570
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document how to enable/disable Debug Output on the fly #9981
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pls. rebase!
doc/15-troubleshooting.md
Outdated
However, in case of [a HA zone](06-distributed-monitoring.md#distributed-monitoring-scenarios-ha-master-agents) | ||
the feature gets enabled/disabled on both nodes once they're connected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is like any other configuration object, is it worth mentioning some HA specific details? If in doubt, I would rephrase it slightly different, as I can currently think of it as both masters need to be waiting to each other to be connected in order to get enabled the debuglog
on both sides.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is like any other configuration object, is it worth mentioning some HA specific details?
Given that feature's I/O impact, no. It's not as trivial as every other object.
I can currently think of it as both masters need to be waiting to each other to be connected in order to get enabled the
debuglog
on both sides.
Exactly! As long as the other master isn't connected, it doesn't write the debuglog.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly! As long as the other master isn't connected, it doesn't write the debuglog.
Seriously? How? Why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry.
As long as the other master isn't connected, it doesn't write the debuglog.
As long as the other master isn't connected, it doesn't start writing the debuglog too as it didn't get the runtime debug logger yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as the other master isn't connected, it doesn't start writing the debuglog too as it didn't get the runtime debug logger yet.
I'm not questioning that! I'm just confused, and maybe others will be too, by this one ... the feature gets enabled/disabled on both nodes once they're connected.
The one specific endpoint that receives the API request does not have to wait for anyone to enable/disable it.
doc/15-troubleshooting.md
Outdated
* Hence, the debug log is enabled exactly as long as desired | ||
|
||
However, in case of [a HA zone](06-distributed-monitoring.md#distributed-monitoring-scenarios-ha-master-agents) | ||
the feature gets enabled/disabled on both nodes once they're connected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚠️ Thing to consider
4071e2f
to
a1825f0
Compare
This is a good alternative to `icinga2 feature enable debuglog`: * Object creation/deletion via API happens immediately and requires no restart * Hence, the debug log is enabled exactly as long as desired
a1825f0
to
9eff386
Compare
This is a good alternative to
icinga2 feature enable debuglog
: