nomon: server resources monitoring & alerting for Cloudron
-
@potemkin_ai very nice! Is this an app or some server level monitor? Just wondering how it gets server level metrics being a Cloudron app.
As for the repo, all our packages are in GitLab. I think this might help you (and us) keep the licensing of the packaging separate from the app. You can license the app however you want but the app package has to be an open license for us to reliably package and publish it. Maybe you can develop upstream and add the package as a submodule or something like that.
-
Any reason not to use Apprise?
Not from my side, we utilize Shoutrrr library and enjoy services provided by that library
Does Apprise supports generic webhooks?
Nextcloud Talk is my ideal hub for chat & notifications.
I have no experience with Nextcloud Talk (although I do use it for other purposes) - why not Mattermost or any other full-scale messaging app?
-
@girish thank you!
Is this an app or some server level monitor? Just wondering how it gets server level metrics being a Cloudron app
We use psutil for golang and according to our tests it picks up the server's information from within the Docker - that was the first thing we tried.
I think this might help you (and us) keep the licensing of the packaging separate from the app.
We can specify that some specific, package-related, files are under Apache 2.0 license. We already have dual license template ready, so it's just a matter of changing a few lines.
all our packages are in GitLab
From what I understand, you package external software from within your GitLab. Am I right that what you want us to do, it's to publish yml file and some build things, but Docker image could be pushed from GitHub packages? If not, could you please, correct me there?
The only reason I would like to keep things at GitHub, it's that we invested into building workflow and it's all nicely automated after the new code push
-
@potemkin_ai Not sure what "full-scale" means. Nextcloud Talks does everything I need and nothing I don't.
Have implemented with 100+ companies, and almost zero training. People just logged in and got on with using.
Used Rocket-Chat for years. Very clear they have moved more to it being shareware for advertising. Many times distracted with bugs, constraints or unnecessary convolutions.
Mattermost and Element Apps I found both to be poorly designed and user experience. With an amount of reading documents and trial and error, I got to the point that I could use them, but couldn't explain them to those that don't have the time or experience to do anything beyond login and get on with using.
I've been around since HipChat before Atlassian bought them. Then Discord way before is was a widely known.
Nextcloud Talk is just so easy and users like it. Search works across all Nextcloud hosted content. Mobile apps that actually work, integrate well with mobile native features, interfaces feel native, as opposed to the clumsy interfaces of the others I tried. Voice & Video calls are production released and working well. All files shared are stored and searchable in the Files app and synced to any device connected to that. Alerts work nicely on all interfaces. No cost or 3rd-party gateway needed for Push notifications, unlike Rocket.Chat. It just has so many advantages that don't need yet another integration for a feature, that I can't imagine why I'd make life more complicated again.
Google, Teams & Slack. I get why they are used, and how they work with their own ecosystems. I just don't need them when already having a solution that just gets out of the way and makes using invisible, so focus is on the work through them, and the data generated in communications is liberated from needing to pay forever to host and access.
In short, my sole goal with any development is for each thing to be the last time I ever need to research and develop an area. The value is all in being an undistracted user, free to just get on with the work that these apps are merely interfaces to collaborate on.
I wanted to like other apps, but they just felt the opposite of "full-scale", and looked more like MVP prototypes to me.
You did ask
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
@marcusquinn not to go off-topic too much but have you ever had NC Talk not send notifications for new chat messages to users until they open the webpage or app (iOS)?
It happens often enough to all of my users to be considered unreliable, but then it fixes itself. It's a recurring on/off thing. Funny thing, the same thing happens with my self-hosted Element/Matrix. NC lives on my home server while Matrix is on a VPS, if that makes a difference.
-
@humptydumpty It's a good question. It's been a while since the most recent instance I setup, but I seem to remember I had to change an admin setting from the defaults to get notifications working.
I'm sure you know all apps nowadays have to ask for all permissions on first use, so sometimes the users deny those at first, but then forget that they are needed, and I don't think the app asks again, so you have to dig and set yourself.
I've also noticed sometimes there will be an event that I get repeat notifications for until I acknowledge them. Never bothered to dig into if that was a bug or feature.
Overall, I've found it to just work, and any issues to be settings, as opposed to bugs, but I guess environments are in constant flux so sometimes issues are created and solved before I got to the issue being an annoyance.
Also off topic, I do all I can to minimise disrupting notifications in my life, I just don't think they are healthy, as our minds are just as programmable as our systems. On the flip-side, chat for asynchronous multi-tasking working is only possible with notifications to keep attention and conversations within the same working day.
I will pay more attention to this, though, and revert if I notice it, as so much of what we do is needing examples to evidence and diagnose, eh.
-
@marcusquinn full-scale for me means threads, calls, rich formatting, notifications management. Guess it's everything that most people found confusing, indeed.
It seems like out experience matches: Rocket.Chat - extremely buggy; Element - specs are not complete, not yet ready for mass production use as team management; Mattermost - looks just right, but quite slow in some of the features and unpredictable with the prices (they managed to change the pricing overnight with no trace of that anywhere at all; twice).
Shall we go back to IRC or XMPP based chats?
-
@potemkin_ai
IRC for the win!I have a funny feeling that's not such an unlikely destination either, given the behaviour of big-tech with our attention.
As I pass through mid-life, I'm starting to think the attention-economy needs and antidote. Everything I do now is choosing once-and-for-all solutions, eliminating or automating as many maintenance needs as possible, and focusing on getting back to enjoying all the free time email was supposed to give from letter post.
-
@potemkin_ai said in nomon: server resources monitoring & alerting for Cloudron:
From what I understand, you package external software from within your GitLab.
Correct, we only want the packaging code to be in our gitlab. For example, you can take the example of recent ctfreak app. The app itself is developed elsewhere (it's closed source) but the packaging code is in our gitlab at https://git.cloudron.io/cloudron/ctfreak-app/ .
Am I right that what you want us to do, it's to publish yml file and some build things, but Docker image could be pushed from GitHub packages? If not, could you please, correct me there?
If you give us the initial Cloudron package for your app, we can take it from there. We don't automate package builds - instead we track upstream releases, make a build and test it. Practically none of the upstream projects I have seen have tests for Docker images. So, that style of publishing doesn't work for us. We have (cloudron specific) tests which test installation, update, configuration, restore, backup etc for every app release. It's quite rigorous and deployment related. It won't make much sense to have all this in your app repos anyway.
The docker image is in docker hub in our org - https://hub.docker.com/r/cloudron/ . This ensures "images" don't disappear (for whatever reason. maybe github goes down, you forgot to pay docker hub, upstream developer went berzerk and made everything private and things like that).
-
@girish thank you and apologies for the delay in getting back to you!
If you give us the initial Cloudron package for your app, we can take it from there.
Would gladly do!
We do have Cloudron manifest file, Dockerfile, and github action to build and push Dockerfile.Please, let me know if there any changes that we can do that would make it easier for you - would it be another push to your Dockerhub, change of license to some of the files, or anything else.
The project is under AGPL to make sure it's development is kept open source and we can license some specific files as Apache 2.0, if required.
The docker image is uploaded to GitHub packages to stay away from Dockerhub uncertainty, but it's not something we will keep tight for.As for the tests - I'm absolutely with you, but we didn't make it... Shall you create them, happy to add them to the main source tree, so that all of the pushes will be verified against them, if you like.
-
@potemkin_ai no worries, thanks. I think we have to think a bit on how to handle this. So far, we have inclined to package widely developed and used apps. This means that the app has users from the get go and it makes sense for us to spend time maintaining the package. In this case, I think you have written an app most likely for your own use. At the same time, you are packaging this only because you think it's probably useful for others as well... Ideas welcome on how to handle such apps
-
@girish thank you for the invitation to think together and direct answer, I understand the logic behind it and I would do the same.
I've been thinking about the options possible and so far I can see the following options:
- separation of platform and app store with adding the ability to subscribe to 3rd party app stores - doesn't seem plausible, as require quite a major rewrite and cooperation with (guess not so many) app-stores developers (think recent case with Redis & PostgreSQL Upgrades) + it's closer to CapRover approach, which feels to be different from yours
- keeping things as is + provide an ability for the users to attach 3rd party app. stores, letting app stores owners and users regulate things on they own - it could be free of charge for some reasons or paid, with billing handled on the app store side
Second approach feels more plausible, as it requires 'not that much' - extend existing apps sideload into a full-scale app store, with listing, install and updates from within the UI.
User access could be restricted by docker's build-in user & password functionality, optionally with IP address limitations.
On the app - it was indeed created from our specific use case, more specifically - lack of monitoring & alerting to the remote endpoints if there are not enough server resources of any kind. If Cloudron could deliver the notifications elsewhere (not only to the notifications dashboard on the interface) - that probably won't be required as such, but I understand it's not at the top of the backlog now, which is something I understand very well.
-
@potemkin_ai thanks for understanding. I think approach 1 is too complicated for us, we rather have one app store with 3rd party apps in it. But to make this happen, we need some development on the appstore side with auth and somehow making sure apps are visible only to specific cloudrons. I don't know when we can find for developing this feature.
-
@girish thanks for the feedback!
Another thing I see from the approach you mentioned, it's that you will have to moderate and manage AppStore and developers - it might be way too complicated for a small team and/or might not be self-sustainable for a big one...
Following up on the only mobile platform with many AppStores - Android - I believe you might want to provide an interface for developers to create their own AppStores or F-Droids or whatever.
-
Given that the Cloudron API already allows to install apps from other sources I think it would already be possible to build something like the f-Droid for Cloudron. like f-droid also only relies on the basic apk install method and not on appstore library listings via playstore.
-
@nebulon right, but that means that I have to:
- do a custom build of cloudron, without the dashboard
- develop and keep extending the dashboard
- maintain & support things
- create my own repository
- gain users
If we speak that Cloudron become a platform, then, I believe, cloudron shall stop developing apps and create everything for the developers to package the apps for you. Few examples could be provided for free, but your main income and way of doing things shall be shifted to get money from appstore and/or licensing your platform to other customers.
I can't see that happening for Cloudron, as nobody cares about the platform and getting proper very careful apps selection and packaging is what, most probably, is driving customers and the cash flow. And if I would be you I wouldn't dare to 'fix' what doesn't seem to be broken.
At the same time, this model could be limiting - you have an ever growing backlog of the apps to be packaged and that is a potential lost business opportunity here (in a good way; business as a service to the people where profit is a way to keep things sustainable and getting better).
I'm not saying I know how to do right - even though it's most probably the way it sound, but I feel the pain and I believe that there must be a good solution, hence keep looking.
My personal stake is that the best way to open the gate - it's to let users to add third party appstores that will act and behave like a first class citizens: they will appear on the appstore dashboard, updates will be rolling, etc.
The only clash I can see there - it's a possibility of the apps or services overlap, but I can see a reasonable agreements that could serve well for both parties. -
@potemkin_ai To be fair, if anyone has packaged an app to Cloudron guidelines, including unit tests, then submission for inclusion in the App Store is fairly trivial.
The bottleneck isn't the allowance or possibility, but the reliance on Cloudron devs to quality control and add unit tests.
Take care of that, as you would likely also want to with your alternative ideas exploration, and you'd have an app App Store ready, already.
The negotiation is only needed when considering changing the platform itself, which is likely always better know by its creators, so pretty good to have their frequent engagement in the debates.
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
@marcusquinn it's not packaging, it's support that matters. And without proper incentives, I don't believe there will be anyone willing to get into that.
-
Fascinating conversation. We are looking for Cloudron monitoring @potemkin_ai ourselves.
Ideally you would keep it simple and self-contained enough that it doesn't need access to third-party app stores. In terms of the notifications, it would make sense to build a very simple API which would allow the external services (Rocket.Chat, Mattermost) to pick up nomon's notifications. You could include a sandbox for push notifications along with templates for the major services, and guidance on how to use it.
KIS and focused would be my choice for such an app.
The problem with many open-source people is that we want to cover every need and every possibility and leave every door open. To be everything for everybody doesn't work in the physical world, and to be honest it doesn't work well in the virtual world.
