ktsaou

Hi, netdata supports both big and little endian machines. You should probably disable the apache plugin, or configure your apache to run without an access log file. You can size the netdata database and disable unwanted plugins. Generally, netdata will run just fine with very limited memory. We have also given special attention to have netdata running with predictable memory. For example, while data collecting, netdata does not allocate any memory at all. So, its memory consumption should be just fixed. Netdata does not write to disks while it runs. So, this should not be a problem.

Fixed the ratio: 100% at 480MHz is 40% at 1200MHz, not 35%

Keep in mind that this is a key requirement for a monitoring system. It would be tragic to see CPU utilization 40% instead of 100% on a system that has thermal issues and the processor does not actually scale.

Nightly is probably better for this, otherwise it will slow down all PRs.

yes of course. Netdata reports whatever the kernel reports. We almost never change the metrics artificially. But we report both CPU utilization % and CPU frequency. The reason is simple: assuming that the CPU will scale, is wrong. The processor may not increase its speed for a number of reasons, including thermal protection, scaling governor policy and user settings. If everything works as expected, CPU frequency will be increased by the kernel long before utilization hits 10% or 20%. So, if scaling works, you will never see 100% on a CPU running at 480MHz when it can go up to 1200MHz. But if we did this artificially, it would be possible to see 40% on a CPU that could go up to 1200MHz, but for some reason runs constantly at 480MHz with 100% utilization. This situation would be totally unacceptable and with the current netdata cannot happen. We don't provide them, just because travis does not support these architectures. We are open for help thought. If you can make a PR integrating netdata CI to a third party service that can build such binary files, we would be glad to provide them.

Hi, I am the founder of netdata. I just wanted to contribute to this discussion, that netdata can perfectly run on extremely weak devices, of any architecture, if you pay attention to a couple of settings that affect its resource consumption. The first is the data collection frequency. The default is "per second" (`update every = 1), which may be quite expensive in CPU resources for very weak devices. Configuring netdata with `update every = 2` will cut its CPU resources utilization in half, while still maintaining a very high granularity compared to any other solution. For extremely weak devices this setting can be set to 5 or even more. For example, on my tests on RPi 1b, setting it to 5 seconds provides the best results. Memory footprint can also be controlled using the `history` setting. This defaults to 3600 data collection points. If you set `update every = 5`, setting also `history = 720` will still provide 1 hour of data, but netdata will need just 1/5 of the memory. Also, netdata has configurable data collection modules. Most notably, `apps.plugin` should be disabled completely on very weak devices. This is as expensive as the netdata daemon itself. Last, keep in mind that you should examine the netdata resources usage while netdata does not have any viewers on its dashboard. This is the "permanent impact" of netdata on the target system. If there are viewers, the netdata daemon will use additional resources to serve them. But this only happens while you view the dashboard. The data collection frequency also affects the resources required by viewers, since the dashboards query the server with the same frequency data are collected. If you need help to configure netdata properly for weak IoT devices, I would be glad to help. Thank you!