21–30 of 108 posts
The only gripe I have with it is the approach to security, i.e. the lack of user accounts (even one). So you have to either block the stats by IP (who is doing it these days?) or use other workarounds like proxying by Nginx etc.
All these graphs are never really actionable and are only of interest for a short period of time and you won't be looking at it after a while because they don't mean anything unless you know where and when the problem is. A sever admin wants "Incident" panel that only shows anomaly components at the top coupled with adjustable alerting mechanism and not just a dump of all the data there is blindly. There are so many…
This is one of the things i am focusing on most - how to package and then surface up "anomaly events" to the user that the user can then quickly digest and decide if they are or are not something that could represent an "incident". So human in the loop sort of ML to help assist and lower the cognitive load of all the charts.
We have a first step on this ladder via the python based anomalies collector that you could play around with to see if any use: https://learn.netdata.cloud/docs/agent/collectors/python.d.p...
That will give two summary aggregation type charts based on anomaly scores built off all the system.* charts by default (but can be configured however you want) - so, at each second, an anomaly probability for each chart and an anomaly flag if the model thinks that chart looked anomalous at that time.
We are also working on some other related projects to build on this capability out more and do it at the edge, in C++ or Go as opposed to Python, (or via a parent node) as cheap as possible so minimal, ideally negligible, impact on the agent itself. We should have some more features related to this in coming months as we are just trying to dogfood them internally a little first.
Anyone interested i'd love to hear some more feedback here or in this community megathread here: https://community.netdata.cloud/t/anomalies-collector-feedba... or just email me at analytics-ml-team@netdata.cloud
All these graphs are never really actionable and are only of interest for a short period of time and you won't be looking at it after a while because they don't mean anything unless you know where and when the problem is. A sever admin wants "Incident" panel that only shows anomaly components at the top coupled with adjustable alerting mechanism and not just a dump of all the data there is blindly. There are so many…
I for one deeply enjoy interacting with my Netdata dashboard whenever I want to deep dive into my servers resources and behaviors. For me it fits a purpose and if I ever were to run a company that hosted things, I would want it and I would want to pay for it. I am a huge fan and a long time homelab user of Netdata.
https://news.ycombinator.com/item?id=11388196
https://news.ycombinator.com/item?id=17773874
https://news.ycombinator.com/item?id=26886792
(For commentary, I'm not being snarky.)
Earlier quoted context omitted.
Using Netdata Cloud is a great way not to spend any time with that and access the Agent's dashboard through Netdata Cloud. We use WSS and MQTT, so it's super secure and lightweight. The data are streamed from the Agent directly to your browser via the cloud. Relevant docs: https://learn.netdata.cloud/docs/configure/secure-nodes#disa...
So the only convenient way to have security is to use the cloud version? Got it.
I wouldn't formulate it that way, it's just a bit annoying for me to see this trend of not having even tiny bit of security built in and having to do extra work just to protect the dashboard. Just one admin account and a random generated password would be fine.
The only gripe I have with it is the approach to security, i.e. the lack of user accounts (even one). So you have to either block the stats by IP (who is doing it these days?) or use other workarounds like proxying by Nginx etc.
Workarounds like proxying by nginx is not a workaround, it's the industry standard way of managing access to services. It's both more convenient and more secure, a rare combination. More convenient because you can use your companies pre-existing authentication to authenticate the requests, and more secure because you're not having to manage separate passwords and user accounts.
Is it any good? ;)