ROX-25642: Make the database monitoring interval configurable
Description
It does not make sense to fetch e.g. table sizes every minute, since they usually glow slowly. At the same time for testing environment it makes sense to have high resolution monitoring. To get the best of both worlds, make the monitoring interval configurable.
User-facing documentation
- [x] CHANGELOG is updated OR update is not needed
- [x] documentation PR is created and is linked above OR is not needed
Testing and quality
- [ ] the change is production ready: the change is GA or otherwise the functionality is gated by a feature flag
- [ ] CI results are inspected
Automated testing
- [ ] added unit tests
- [ ] added e2e tests
- [ ] added regression tests
- [ ] added compatibility tests
- [ ] modified existing tests
How I validated my change
Not validated yet.
Images are ready for the commit at 80d165d.
To use with deploy scripts, first export MAIN_IMAGE_TAG=4.6.x-647-g80d165d4c7.
Codecov Report
Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
Project coverage is 48.25%. Comparing base (
752268f) to head (80d165d). Report is 1296 commits behind head on master.
| Files with missing lines | Patch % | Lines |
|---|---|---|
| central/globaldb/postgres.go | 0.00% | 1 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## master #12900 +/- ##
==========================================
- Coverage 48.25% 48.25% -0.01%
==========================================
Files 2441 2441
Lines 175511 175511
==========================================
- Hits 84701 84700 -1
Misses 83992 83992
- Partials 6818 6819 +1
| Flag | Coverage Δ | |
|---|---|---|
| go-unit-tests | 48.30% <0.00%> (-0.01%) |
:arrow_down: |
Flags with carried forward coverage won't be shown. Click here to find out more.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
One question. Do we want to collect these on startup as well? Would it be valuable to do them initially on an upgrade to ensure we have stats on new version?
Do we want to collect these on startup as well? Would it be valuable to do them initially on an upgrade to ensure we have stats on new version?
Yes, that's a good point. It makes sense to do an initial stats collection, then proceed with the schedule.
@erthalion: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:
| Test name | Commit | Details | Required | Rerun command |
|---|---|---|---|---|
| ci/prow/gke-ui-e2e-tests | 80d165d4c751b2ba7618b03484092878002a69df | link | true | /test gke-ui-e2e-tests |
Full PR test history. Your PR dashboard.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.