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
fix(cli): log cache full when on debug level #3085
Conversation
Help fixing kopia#3059
I was wondering, how about to set it to warning level instead of debug level ? As a Kopia user, I would like to know if the cache is full, leading to an increase cost of bandwidth, and an increased time to achieve the maintenance. |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #3085 +/- ##
==========================================
+ Coverage 75.37% 75.40% +0.03%
==========================================
Files 459 459
Lines 36408 36451 +43
==========================================
+ Hits 27442 27486 +44
- Misses 7044 7047 +3
+ Partials 1922 1918 -4
☔ View full report in Codecov by Sentry. |
@arouene Please address the linter issues. Thanks. |
Done, thanks ! |
if clock.Now().Sub(c.lastCacheWarning) > time.Minute { | ||
c.lastCacheWarning = clock.Now() | ||
|
||
log(ctx).Warnf("Cache is full, unable to add %v into cache.", key) |
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.
We should make this Debug
down the road.
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.
This can be pretty noisy, even once per minute. Some workflows take several hours.
If the cache is full, are not we making the situation worse by filling up the logs ??
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.
@Shrekster yes, we should
- reduce the frequency
- add counters
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 discussed this partly offline. I think the write rate could be reduced, but even better I'd propose we just log once and then mute.
If we can settle on logging this once then this doesn't even need to be a debug log and that could be more useful upfront than having to turn on debug logs on a second run.
The alternate question to "how much logging is bad logging?" is maybe "what frequency is useful ?"
IMO once is ok for this becuase logging this the second time is only telling me that nothing got expired, but what debugging info do I get from it ? If cache was full once and the perf was crappy then that probably explains it.
Is the second log going to add more info ? Yes!
Does that more info help ? I don't know... doesn't seem like 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.
@Shrekster PTAL at #3193
…nutes Addresses concernes about too many messages in the logs (kopia#3085)
Instead log the cache description, which provides information about the types of contents being cached. Followup to kopia#3085 :
Simple debug log addition to help diagnose of duplicate downloading of blobs.
fixes #3059