New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
General steps I took to migrate my v1 Kuma to beta v2.
Took down the v1 instance on the fly and downloaded the kuma.db from there using the sftp shell.
Created a simple v2 instance on Docker from scratch.
Created a MariaDB DB on my database server.
Finished initial setup(only filled the DB details on the setup-database page and stopped the container), I didn't create the user as I will essentially migrate everything from the v1 sqlite.
Opened DBeaver (I know people prefer CLI, but I have been using DBeaver for years, it just makes it easier to manage different DBMS).
Opened the SQLite DB in profile 1 and the new MariaDB DB on profile 2.
Create a new task to export the database to a database, select tables, and it will guide you through mapping and whatnot, change the configuration of the task like threads, etc. And finally, click proceed, and it will start the migration from SQLite to MariaDB. It will take time, depending on your chosen configuration and DB size. (There might be some issues with some tables; you can skip or manually input the data in those tables. The main tables that need to be migrated are groups, heartbeat, monitor*, settings, and user.
Once the data has been pushed, restart the container, and you have the v2 instance up and running with your v1 data migrated over.
There's another way as well that might not trigger the errors during database migration, which is simply upgrade to v2 on v1 and let it alter the tables on the SQLite DB, and use the altered DB for DBeaver's database-to-database migration. Since I haven't used this, I can't say for certain that you won't be presented with any errors during database push.
Things to note: I made like 3 backups of the "data" directory before moving forward. My v1 instance was on fly.io's free hobby plan, and v2 is on Netcup Pico. I haven't seen any performance degradation on either of those with 1s checks on crucial monitors(roughly around 12) and the remaining on 5s checks. I killed the container when I was pushing data. I didn't enter any env since Kuma will still ask you to set up the database during first boot and will create db-config.json based on your input. Data migration takes time, especially more so if you are only pushing data with a single thread like I do(for various reasons).
Do people set up another uptime kuma to monitor their first uptime kuma?
Of course, this is called redundancy.
I use updown.io to monitor Uptime Kuma. Just that single check, then everything else is in Uptime Kuma.
Statusnook running on my homelab and uptimerobot takes care of it for me. Thinking of deploying something on CF workers to monitor kuma and beszel for me.
this one looks interesting there was something like this if I remember right also an uptime monitor based on GitHub actions but it was 5m intervals if I remember right
found it : https://github.com/lyc8503/UptimeFlare [Cloudflare workers one ]
GitHub actions one: https://github.com/upptime/upptime [its 5mins though]
SQLite requires some special concerns when doing many concurrent writes such as using correct pools and BEGIN CONCURRENT statements and running in WAL or WAL2 mode. I have not looked at the code of Uptime Kuma so I'm not saying they are doing it wrong, but yeah, lots of writes to SQLite requires some understanding about how things should be done.
Could probably be fixed with some tweaking, but why bother if running MariaDB solves it.
was for me, just ran it few days ago on a fresh ARM VPS with ubuntu
Minimal image or full?
minimal
Uptime kuma can't handle a lot of monitors it will be buggy as soon you do that.
How much is a lot please?
v2 seems to be able to handle more than 100 just fine.
I'd say around 80-100 it would start getting a little slow and the more you add the more slow and problems you will get but this can be avoided with the new version
Good!
I migrated from v1 to v2, still using SQLite. It's massively better!!! The migration took a couple of hours but that might be down to the crappy disk type I'm using in GCP more than anything else.
For the first time in a while the UI doesn't lock up whilst I'm trying to perform basic tasks. Being able to rely on this should save me a few dollars.
Hey Vito, we'll add version 2, right when it's out of beta. Since we support apps long-term, we can't add beta versions.
I'm also waiting for new features, like real DB support. SQLite is a real bottleneck right now.
Id love to get the compose file. Thnx
Doesn't this still use SQLite by default? Since you haven't specified the environment variables to point it to MariaDB: https://github.com/louislam/uptime-kuma/wiki/Environment-Variables#mariadb-environment-variables
Thanking you, gonna throw this on my Oracle free tier.
Nope. I think they changed it in v2. So, now it creates db-config.json where it specifies DB backend. I am not sure how it know that mariadb is installed but it worked in my case.
Ah, I'm just silly. Of course there's a setup step via the web UI where you can choose to use MariaDB.
In your setup I would suggest to change the Uptime Kuma image to use
louislam/uptime-kuma:beta-slimversion though. The non-slim beta has MariaDB embedded into the same image (and supposedly adds 300-400 MB to the image size).If you're running MariaDB in a separate container (which is recommended anyway), you don't need to use the non-slim beta.
Damn, thanks! I completely missed that there are two version: full and slim. Full image is 1.7Gb, slim is just 540Mb.