Some questions about the project and vision

[capttrousers]

⚠️ Please verify that this bug has NOT been raised before.

• I checked and didn't find similar issue

🛡️ Security Policy

• I agree to have read this project Security Policy

📝 Describe your problem

I've been using Uptime Kuma for a week to monitor some docker containers and svcs on my raspberry pis, it's working great, really well done project.

I've been diving into the source code a bit and have some questions:

• What is the intended use cases/how to guides for plugins? I see the plugins dir created in the data_dir but not sure how to go about creating one, or what I could do with that.
• For Push based monitors, what's the intended usage of the PING param? I've been using it for tracking the duration of certain api calls in a batch service, and putting different msg's for each task in the batch job but I'm thinking there might be a discussion to be had about this kind of pure metric monitoring. Would love to chat more about this part.
• For Push based monitors, it looks like the Duration prop is calculated by the datediff between current and last push event? I dont quite understand how that plays with the heartbeat check interval that's set for Push based monitors. Is the check interval for Push monitors just basically defining the window that you'd expect to receive at least one push event?
• For the Details page for a monitor, what are your thoughts on allowing a "show all" toggle, to show all events, not just the important heartbeats?
• On the Details page, what's the distinction between clearing Events vs Heartbeats? Looking at the source code, it seems like clearing events just nulls out the properties but keeps the records, whereas clear Heartbeats deletes the records? Not clear what the first one would be used for?
• I saw the Project roadmap page shows supporting Mysql/Mariadb in addition to sqlite, I saw the redbean library also supports those rdbms options, so is that a difficult lift? If not, I'd be willing to try to tackle that over the next few weeks. One use case I'd like to try to support, possibly with plugins, is defining some custom charts for various metrics and embedding them in the Details pane or maybe a top level Status page. There are a few charting services I'm planning to checkout: Superset or Perses, but Im not clear on the path forward here yet. But having the db be connectable like mariadb would be great to help test something like that out.

Thanks again for all your work on this, it's really impressive.

📝 Error Message(s) or Log

No response

🐻 Uptime-Kuma Version

1.21.3

💻 Operating System and Arch

rasbian bullseye, but running uptime-kuma via docker

🌐 Browser

Firefox 108

🐋 Docker Version

Client: Docker Engine - Community Version: 23.0.4 API version: 1.42 Go version: go1.19.8 Git commit: f480fb1 Built: Fri Apr 14 10:32:04 2023 OS/Arch: linux/arm Context: default Server: Docker Engine - Community Engine: Version: 23.0.4 API version: 1.42 (minimum version 1.12) Go version: go1.19.8 Git commit: cbce331 Built: Fri Apr 14 10:32:04 2023 OS/Arch: linux/arm Experimental: false containerd: Version: 1.6.20 GitCommit: 2806fc1057397dbaeefbea0e4e17bddfbd388f38 runc: Version: 1.1.5 GitCommit: v1.1.5-0-gf19387a docker-init: Version: 0.19.0 GitCommit: de40ad0

🟩 NodeJS Version

No response

[capttrousers]

Some other Qs I forgot to add:

• what is the purpose of this line
• I've seen some feature requests about monitoring other system things like cpu/memory/disk space. There's a nice simple tool called glances That I've tested for this use case but uptime-kuma is much nicer to look at it, so curious what your thoughts are on supporting something like that, to consolidate more monitoring within the single tool? Maybe this is another good use case for the plugins system? But I couldnt find docs on the plugins. Or even monitoring memory/CPU usage of docker containers with monitors?

[CommanderStorm]

These are a lot of questions for one issue. I tried to answer them as much as I can.

On the topic of plugins:

There are multiple proposals in issues. Until now there has been #1787
This is a feature in the ideas section of the Roadmap.
I don't quite know what Louis vision is on this topic, but one plugin is available at https://uptime.kuma.pet/c/plugins.json

Push-based monitors

I am not qualifed to answer this question.

"show all"

This does not fit in the help section. Please open another issue in the correct section.

clearing events vs heartbeats

Heartbeats include more metadata (f.ex. ping-duration) which you might not want to delete. There are however cases where an event happened after you want a clean slate (f.ex. a lot of DNS errors after adding too many monitors without the caching enabled).

database

I don't understand what you mean.
See #1139 for the current status of mariadb.

what is the purpose of this line

This line does not have any value afaik. A PR to remove it would be appreciated.

monitoring system usage

I think this would not be a good use case for an uptime monitor. (maybe a plugin?)
I think there are better tools for this (namely the Grafana stack or other promising contenders in the observability space)
This could be an expansion goal, but currently there would need to be a lot of work.

[chakflying]

Regarding how push monitors work, you can read about the logic of operation here: #1428. Your basic understanding is correct.

[github-actions]

We are clearing up our old issues and your ticket has been open for 3 months with no activity. Remove stale label or comment or this will be closed in 2 days.

[github-actions]

This issue was closed because it has been stalled for 2 days with no activity.