Add RAM warning

[jimaek]

Check the available memory when starting and ensure its enough to have working auto updates. I think 400mb?

If there's too little, output a warning to the user, something like:
WARNING: Not enough memory to run auto updates. This probe will stop working once a new version is released. Please increase the available memory to at least X.

Maybe worth doing the same in the dashboard.

[jimaek]

I think we need to do the same for disk space too. Check the container has enough free space to download and execute an update.

[alexey-yarmosh]

Warnings are already logged, but only when update is available. Min memory is 250MB, disk space - 1GB.

Warning on the dashboard should be helpful.

[jimaek]

Maybe a bigger warning in size then? To make sure people notice it when trying to run a probe on extremely limited hardware. A guy wasn't sure while updates fail on many probes .

Also are you sure 250 is enough to run an update?

[MartinKolarik]

What do you mean by "updates fail on many probes"? Based on what? 250MB is enough even for a node.js update; a regular update needs considerably less.

I would recommend people give the probe at least 450 MB for normal operation, and 1 GB disk space, and we could document that as a recommendation, check at startup, and log a friendly message (less urgent than the ones that are already logged in the "outdated" state)... but is isn't as urgent as "the probe will fail on next update otherwise".

[jimaek]

What do you mean by "updates fail on many probes"?

I meant what I said, updates failed on my probes.

Based on what? 250MB is enough even for a node.js update; a regular update needs considerably less.

Based on a chat with a user running multiple probes. I saw a similar behaviour on some probes running on really bad VMs.

You dont have to doubt every word I say.

250MB is enough even for a node.js update; a regular update needs considerably less.

Maybe so, I did not say to use 450 as a strict number:

"Check the available memory when starting and ensure its enough to have working auto updates"

What's the argument in this case? The task seems pretty clear, check how much memory is needed to run a full code and node.js update. If we already have that logic then double check the values are correct.

Use that value with a buffer and add a big warning in the logs to ensure people actually notice it when they first run the probe and not when it quitly fails.

Ideally at a warning in the dashboard.

[MartinKolarik]

No argument at all, just clarifying what needs to be done in addition to the existing checks. We already check and log for outdated node.js versions, so we'll add a check at startup with the same values but a different message, plus document in readme. Dashboard warning is somewhat independent from this, but can be added too.

I meant what I said, updates failed on my probes.
Based on a chat with a user running multiple probes. I saw a similar behaviour on some probes running on really bad VMs.
You dont have to doubt every word I say.

This is not about doubting what you say; it's about understanding the background here. We tested updates, including a node.js upgrade, with as little as 200 MB. Currently, the smallest probes have 240 MB, so at first sight, this shouldn't be a problem. I also don't recall a specific case where we'd lose too many probes after a release. But if you knew about such cases, the logs would also contain the exact step at which the probes crashed, which would certainly be useful.

[jimaek]

If I had the logs I would definetely add them. The issue came up when a user reported it after trying to run the probe on small VM instances. He said it was fixed after he increased the RAM but he guessed as he didn't notice any warnings.
I tried checking a few of my own probes and saw some suck as "outdated" too. But was not able to login to the VMs, maybe due to full disks (do we generate errors non-stop or something?) so I had to reset them.
Another user was also trying to run them on extremely little disk space, so I rememberd him and added that comment as well.

Thats why this task is about testing the logic and not fixing a specific issue as I'm not sure myself if and where the issue exists.

[MartinKolarik]

Ok, we should also add a check in the entrypoint script just before an update is performed to require 200 MB of disk space as a minimum.

[MartinKolarik]

So to summarize:

• Check on startup regardless of the update status. Same values as for node, log if lower.
• Check in entrypoint.sh before downloading, skip if disk space < 200 MB. Similarly, log a big warning.

As for the dash message, I'd probably move it under jsdelivr/globalping-dash#161 as we only collect the values once at startup at the moment, and it would be confusing if we kept showing the warning after the user already made changes (especially cleaning disk space may not require a restart). It'll make more sense once we collect real-time metrics.