Feature #593
open
split log for facts, reports and everything else
Description
The foreman log should be split into three. The continuous stream of reports and facts makes looking at the log nearly impossible.
Updated by Paul Kelly over 12 years ago
- Status changed from New to Ready For Testing
Updated by Paul Kelly over 12 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset 5e7454fc1f73ebb599cf7dc96faa22836eebd11c.
Updated by Ohad Levy over 12 years ago
it would have been nice if we also included the ENC requests too ;)
Updated by Ohad Levy over 12 years ago
on second though, why would you split ENC, facts and reports logs? its probably better to have them all in a one seperate log.
that would be something like users logs and hosts/puppet related logs
Updated by Ohad Levy over 12 years ago
- Status changed from Closed to Assigned
Sorry, I've reverted the commit, as after playing with it, it makes little sense for facts and reports to different logs.
sometime you want to debug them, and the order etc is important.
what do you think of the suggestion above?
Updated by Ohad Levy over 12 years ago
- Status changed from Assigned to Closed
Applied in changeset 387b0b0c54a9b9c31b3727ebc1e8ec984e3d5c55.
Updated by Paul Kelly over 12 years ago
- Status changed from Closed to Need more information
The points that you make are fine. I assume that you mean the reports, facts and enc logs going into a development-input.log and the remainder going into the development.log.
As you say it is sometime advantageous to see all the logs in one location so we should make this configurable via a setting. For day to day monitoring of large installations the split log approach would be better in my opinion.
Updated by Ohad Levy over 12 years ago
Paul Kelly wrote:
The points that you make are fine. I assume that you mean the reports, facts and enc logs going into a development-input.log and the remainder going into the development.log.
I guess so.
As you say it is sometime advantageous to see all the logs in one location so we should make this configurable via a setting. For day to day monitoring of large installations the split log approach would be better in my opinion.
I agree, while I would argue there is a difference between a user action (such as creating a new host) vs automated actions (such as puppet reports).
Is that enough?
Updated by Ohad Levy about 12 years ago
- Status changed from Need more information to Feedback
- Target version deleted (
1.0)
Thinking on this further,
I would probably would split to:
- events that are generated by puppet (ENC, facts, reports).
- API events
- events that are UI driven (all the rest)
What do you think? any idea on how to implement per controller action instead of per model?
Updated by Anonymous almost 7 years ago
- Status changed from Feedback to Needs design