What about support for *BSD systems as well?

[gred7]

Hi, I really like netdata running on Linux, but some of our servers run BSD systems. I would appreciate, if it will be possible to run on BSDs too. Looking at the code, you just need to remove or put under "#ifdef" some linux-specific code.

[ktsaou]

The linux specific code will disable by itself if it does not find the information it needs.
The problem is that we have to write all the system data collectors for BSD...

I need help guys... I cannot do this alone...

#112 #601 #187

[gred7]

I would rather think of integrating the whole thing with collectd.
this way, collectd would take metrics and them put into netdata, and
then netdata will only serve the graphs.
the question is: does netdata provide an api for pushing metrics?
thank you.

On 07.10.16 10:00, Costa Tsaousis wrote:

The linux specific code will disable by itself if it does not find the
information it needs.
The problem is that we have to write all the system data collectors
for BSD...

I need help guys... I cannot do this alone...

#112 #112 #601
#601 #187
#187

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1083 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACx1xee-pE9VKNoCyuEh4t0c3XgU11egks5qxe4ngaJpZM4KQs9z.

[ktsaou]

I would rather think of integrating the whole thing with collectd.
this way, collectd would take metrics and them put into netdata, and
then netdata will only serve the graphs.
the question is: does netdata provide an api for pushing metrics?
thank you.

That would be really nice.

collectd collects independent metrics. To have them in netdata, you have to group them in charts and provide a few additional metadata (if it incremental or absolute, multipliers and divisors to have them in the proper units, a title and units of the charts, the chart type, etc).

So, the best way would be to write a netdata plugin and communicate to collectd via a unix socket: https://collectd.org/documentation/manpages/collectd-unixsock.5.shtml

[gred7]

Are there any docs for that?
Also, I've been looking into possibility to port netdata as is to OpenBSD and found that there are too much linux specific code and the worst thing is it is spread among all files. That makes porting effort enormous.
I would propose you to reorganize code a bit, and have all system specific code as functions, grouped in one or two files, say linux.c. me, or someone else then would write another such file, with same functions implemented, called 'openbsd.c', etc.

[ktsaou]

Are there any docs for that?

Check https://github.com/firehol/netdata/wiki/External-Plugins

Also, I've been looking into possibility to port netdata as is to OpenBSD and found that there are too much linux specific code and the worst thing is it is spread among all files. That makes porting effort enormous.
I would propose you to reorganize code a bit, and have all system specific code as functions, grouped in one or two files, say linux.c. me, or someone else then would write another such file, with same functions implemented, called 'openbsd.c', etc.

I think it is not like that.

There are 2 internal plugins and multiple external ones.

1. The internal plugins are proc and cgroups. These are linux specific and will be disabled by themselves if they cannot find any relative information. My suggestion is to just ignore them. It is impossible to normalize the charts across all platforms. If you attempt it, you will end up with a lot less charts to show, with misleading information in many cases.

   This is the proc plugin that orchestrates all /proc related info: https://github.com/firehol/netdata/blob/master/src/plugin_proc.c You can copy this and provide the basis for another system.

   This is the cgroup plugin: https://github.com/firehol/netdata/blob/453e1d01fd32ce5ff1948e202669f9d71a827d47/src/sys_fs_cgroup.c#L1410-L1480 - You can ingore it.

2. The external ones are not linux specific.

So, you can either provide a new internal or external plugin to handle BSD system data collection.

The only break point you are going to have is libuuid dependency. Fortunately, there are only 2 calls that are needed (parse a GUID, generate a GUID), so these can be easily replaced with something else.

[ktsaou]

Keep in mind that the whole idea of netdata is speed. In Linux the architecture of netdata allows it to collect several thousands of metrics, per second, with minimal CPU utilization. To accomplish this, netdata adapts everything to the system it finds. For example, during normal data collection, it does not execute any memory allocations or file and socket management operations. It has all buffers already adapted, all files and connections it needs open, and just focuses on the repeating task of collecting the values required.

For a different system, possibly a different infrastructure is needed. procfile.c is the key mechanism that provides this adaptation for Linux. For BSD a different abstraction layer may be needed that will allow the data collection plugins to focus on the collected values at a higher level.

[ktsaou]

netdata now supports FreeBSD and as of today Mac OS X (although with limited charts).

Cleaning up day. I am closing this, but if you have a suggestion/issue, please post and I'll re-open it.