-
Notifications
You must be signed in to change notification settings - Fork 897
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
Move graph refresh internals logging to debug #16442
Conversation
05b9d4b
to
670b776
Compare
Checked commit agrare@670b776 with ruby 2.3.3, rubocop 0.47.1, and haml-lint 0.20.0 |
"created=#{inventory_collection.created_records.count}, "\ | ||
"updated=#{inventory_collection.updated_records.count}, "\ | ||
"deleted=#{inventory_collection.deleted_records.count} *************") | ||
_log.debug("Processing #{inventory_collection}, "\ |
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 would keep at least this one on info? That should help us to see how many&how long, in a case of perf issues.
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.
which goes with (not enough logging for old refresh made it hard to pinpoint the source of issue)
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 think some of these are useful but not sure if they all are, for instance a single refresh of an openshift provider gave us 45 of just these created/updated/deleted
lines. I think these are great for top level objects (Container, ContainerGroup, ContainerImage) but maybe not ContainerEnvVar, CustomAttribute? @Fryguy WDYT?
in a case of perf issues.
This is when we'd turn debug on and re-collect the logs IMO
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.
If it's ok to expect that people will run debug first, then I am fine with it. :-) I just know it was biting us a lot, that old refresh has no logging for figuring out where is the perf problem.
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.
Yeah I think if we can configurably log info for certain collections I'd love to see ContainerGroup, ContainerImage, Vm, Host, etc...
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.
Ok, seems it's normal to ask for debug logs in a case of problems, so we can leave it all debug.
Move graph refresh internals logging to debug (cherry picked from commit 1a73cd2)
Gaprindashvili backport details:
|
Perhaps just Benchmark.realtime_block-based timing could be a useful compromise (optionally with per-collection block) OTOH, as Doc Brown said about graph refresh, "Where we're going, we don't need timings" 🏎️ 🔥 ;-) |
👍 agreed this would be nice. I thought we had this at some point where the key was the inventory_collection name but I don't see it (maybe it was just a dream who knows) |
Move all logging except for the top level Saving... messages to debug.
When loglevel is info this is what will be logged from ManagerRefresh:
Fixes: #16374