`v2.0.0`-Release <- Read this for performance problems
CommanderStorm opened this issue · 30 comments
This was originally a PR here, but has been transformed into an issue due to being pin-able
what has been done?
We are hard at work improving Uptime Kuma.
If you want to have a look at the full set of features for v2.0, have a look here.
Most notably this includes (a full migration guide will be made before the release, dont worry):
- better performance through external MariaDB, storing heartbeats in an aggregated form, full server-side pagination for important events
=> even though benchmarking is still out, we are confident that this pushes the prominent "limits" (highly hardware-dependent, not a limit imposed by us) ~500 Monitor or ~1.5GB DB-size
A large part of the focus in this release is on performance. We don't know if we are optimising for the right thing, see #4456 for a discussion on this topic.
Tip
If you are affected by the performance problems of v1, you need to reduce the amount of data you store.
The core problem is that Uptime Kuma in v1 has to do a table scan of the entire heartbeat table for some operations.
The solution boils down to having a lower amount of data => making Uptime Kuma less worried about reading those gigabytes of data.:
- reduce the retention and execute a manual cleanup under
/settings/monitor-history - Increase the time between checks
- pause or reduce the amount of monitors
- delete the specific history of less essential monitors (to "lower" their retention below the configured maximum)
- tightening the security via offering rootless docker images images #2086 #4052
- deprecated backup feature has been dropped (see #3892 (comment) for an explanation why)
- deprecated cacheable lookups (not the same as
nscd) have been dropped #3762 - A lot of bugfixes, some minor new features (see the milestone)
what is needed to get 2.0.0-beta.0 released
Note
We hope 2.0.0-beta.0 can be released in spring 2024, which doesn't include the e2e tests yet. During the beta test, we will try to work on implementing the e2e tests.
Tip
How can I get involved?
While most of the bugs noted below require reading some code
=> gaining some context about how the aggregated tables work, some work do not and are such better starting points:
- writing a synthetic benchmark which spawns some monitors and looks how the server handles it
- helping in writing e2e tests using playwright
- some features have not adopted to new aggregate tables yet
- Migrate existing heartbeat data into aggregate tables
- Clear stats (#4324)
- History retention
- Ping chart (#4264)
-
Heartbeat table keeps 24-48 hours data only (excepted for important events, it will keep longer for the event list)(Can be deferred) - Test and fix the Badges feature (originally introduced in #1119, a big headache for us right now because the new table schemas break this feature a lot) (#4850)
- Testing
- Document how the aggregated tables work for our contributors in our contribution guide
- Migration guide from
v1tov2(Wiki) louislam/uptime-kuma-wiki#53- New Docker tags
- Notify about breaking changes and write a migration guide
- Benchmark where the new performance limits are
- Write the changelog and Release
2.0.0-beta.0
is version already installable at the moment, or there are many things yet to be done to make it so and for a pre-release
@compgeniuses
Our installation guide only works for stable versions (it checks out a git tag to avoid users being on the wrong branch in npm run setup).
Pre-releases will be made once we don't have glaring bugs left, see my post above for which ones there are.
If you want to test-drive or contribute one of the areas named above, our contribution guide should have all the answers. If you are missing something for development, feel free to ping me.
We also have this way of testing PRs: https://github.com/louislam/uptime-kuma/wiki/Test-Pull-Requests
Uptime kuma supports API call
so we can use Rundeck to set Incidents on it and once it resolves we can stop the incident
is that possible?
This is an discussion issue. Please ask help-quesstions via the appropirate means to not spam everyone who subscribes to this thread
Uptime kuma supports API call
Currently, we don't have an official API. Please refer to my answer to you here #118 (comment)
How is it going?
I think you are asking about a status update: The checklist above is kept up to date in what needs to happen before 2.0.0-beta.0.
Is there something that we are missing in the post?
No I don't think so. But I am more interested in knowing if the beta is still estimated during the spring now?
We don't give out concrete deadlines and prioritise long-term team health over achieving short-term goals.
=> Maybe. See #noestimates why we don't give out more concrete timelines rather than "Spring" (=a flexgoal).
Being cheeky: If you want to move this along, you could consider contributing...
What is the best way to try this out? We deploy via Docker on Railway.app and we use it to monitor our services. It is pretty low-stakes environment and I am happy to risk running a preview version of Uptime Kuma to get access to the new features and 'test run' it. But since it is not available on Docker hub I am not sure how to get started
What is the best way to try this out?
U can do this by not using docker but by running in nodejs environment. Read the README
U can do this by not using docker but by running in nodejs environment. Read the README
Thanks - is it just the master branch? I couldn't find a specific branch or tag for v2.
Read the README
@Zaid-maker the path in our readme is designed to run a stable version as npm run setup checks out said version (=> preventing bugs). v2.0-dev is not stable.
In master, development happens for v2.0-dev.
We currently have NOT published a git/docker tag as we are NOT ready to have a public beta (see the checklist above)
You can:
- Test PRs via the path listed here
- help developing using the path laid out in our contribution guide
- subscribe to this issue or to releases to get notified of the beta once it releases
Note
If you want to use uptime kuma in any production environment, please refer to our installation guide.
We do not offer stability/semver guarantees for development versions such as v2.0-dev.
There will be a migration guide between the versions.
I would like to take care of testing activity
Backend tests are stored in test/backend-test and Frontend tests are stored in test/e2e AFAIK
Can you help me with lists of tests that are to be written and documentation/examples of how they are to be written and tested
I am currently quite busy with uni stuff (I have a thesis deadline on Saturday) and I will get back to you on what is necessary precisely and on the code examples:
From the api side, I think these things need a test case:
- the badges API does work
- some of the other apis likely also benefit from testing, but would need to look into them
I think the most beneficial would be a frontend end to end test of interacting with monitors:
- logging into the ui, adding a monitor
- seeing that the monitor does a ping
- enacting a maintenance period
- seeing that the monitor is in maintenance
- adding it to a status page
Fom the initialisation side (bit trickier):
- launching (fresh) via maridb works
- launching (fresh)
- migrating from one to the other works (don't think that we have yet looked into this)
From a monitor perspective (not related to v2.0, but to be complete):
Most of our monitors are currently untested. At least some of the bug reports are likely due to this.
My longer term plan is to use test containers to verify the monitors work as intended. I have currently not been able to finish the debugging effort of said PR (it is basically done, but one test case is not working. Will need to debug)
From the notification providers (not related to v2.0, but to be complete):
Our current testing strategy is to require screenshots of the relevant events by our contributors. I am unsure if we can test this better, but am open to ideas ^^
When do you this this'll be ready?
We don't give out concrete deadlines and prioritise long-term health over achieving short-term goals. In a volunteer run org, anything else would not be sustainable.
See #noestimates why we don't give out more concrete timelines rather than "Spring"/"Summer" (=a flexgoal).
Being cheeky: If you want to move this along, you could consider contributing ...
I'd like to know if it's possible to have v2 (or nightly docker versions) of this repo published in Docker Hub. If there's any technical constraint for that purpose, I might be able to contribute.
I'd like to know if it's possible to have v2 (or nightly docker versions) of this repo published in Docker Hub. If there's any technical constraint for that purpose, I might be able to contribute.
While a good idea, it may end up causing alot of support request that are unnecessary to the community due to incomplete build version.