mesos input plugin

[asdfsx]

Hope telegraf will support mesos one day. Prometheus has already have a mess_exporter.

[tripledes]

@asdfsx If what you need is to query mesos for metrics, I guess for now you could use httpjson plugin.

I'm working on a slightly more elaborated plugin for mesos, currently I've already got some code to fetch metrics from mesos master, at this stage it's not very different from what httpjson can do although I'm trying to group related metrics so they can be blacklisted from configuration.

As soon as I have a decent version, I'll submit a PR.

[asdfsx]

@tripledes THX ! I almost forget httjson..... and good to hear you're working on the mesos plugin~~~!

[sparrc]

thanks @tripledes, looking forward to the PR 👍

[tripledes]

Hi, I've got a POC for the plugin, currently it's able to query a mesos master which is not that different from what httpjson can do, although I've added a possibility to remove sets of metrics.

I would like to have opinions regarding both the code and the functionality, what would be better to remove based on sets or allow the user to remove hand picked metrics by name? The former feels more prone to problems in the future if Mesos removes/adds/whatever changes to the API, the later can be cumbersome to handle in the configuration file although this option would make the plugin more generic thus both Mesos masters and slave could be queried and removed specific metrics.

Also, would it be a good idea to use goroutines for speeding up the plugin when several masters are defined?

Here: https://github.com/zooplus/telegraf/tree/mesos/plugins/inputs/mesos

Thanks!

[asdfsx]

@tripledes excellent work!!! And Are you trying to collect whole mesos cluster's metrics using one telegraph?

[sparrc]

@tripledes yes to the using goroutines, you can see the ping plugin as an example of how to structure that: https://github.com/zooplus/telegraf/blob/mesos/plugins/inputs/ping/ping.go

For the "blacklist", I would suggest reversing that to "collect_metrics", and have it default to a list of all the categories that can be collected. That way users can just comment out the ones they don't care about.

[tripledes]

Hi,

thanks for the comments much appreciated.

@asdfsx what would be your use case? I mean I think I can do discovery through the Master's API, but not sure whether everything can be discovered or whether that's would be the desired behaviour, IIRC the elasticsearch plugin does something similar.

On the other hand, I imagine Mesos slave might be something ephemeral for some people so I was wondering what would make more sense, auto-discover or run telegraf with a Mesos slave specific plugin.

@sparrc Thanks for the tips, I'll have a look later this evening. 👍

[asdfsx]

I might run telegraph on each mesos slave, so that I can collect more information from the host.

[tripledes]

@asdfsx that was my impression, so not sure whether the auto-discovery thing would be that useful, but can be introduced later as new feature.

I've pushed some changes, now it uses goroutines and I'm refactoring the whitelisting feature (previously blacklisting). I hope it'll ready for a PR soon.

Again, any comment/idea will be much appreciated.

[asdfsx]

I agree with that auto-discovery can be introduced as a feature later!

[tripledes]

Sorry for the delay, I feel like it should be ready (I've performed some tests, looked fine), I've got one question before opening a PR.

• I've renamed it to mesos_master as there will be more Mesos plugins coming, e.g. slaves, frameworks and they might share some methods...Is the naming fine? Or should they live in different packages?

As always, any comment/idea would be much appreciated.

[sparrc]

@tripledes any reason those other metrics shouldn't just be options on the mesos plugin?

[tripledes]

@sparrc now that you mention it, not really. So it would look like:

masters = []
slaves = []
framework1 = []
…

Is that what you meant?

[sparrc]

yes, something like that, for starters it could just have the masters=[] option, and the rest can come as they're implemented

[tripledes]

Sure thing, I'll change it tomorrow and submit the PR.

Thanks.

[sparrc]

@tripledes how difficult is it to get the list of slaves from the master? Is that something that you could query the master for?

[tripledes]

@sparrc from what I remember, it'd be a Get() to another endpoint, parse the response and query the slaves' metrics endpoints, so nothing dramatic.

It can also be done for the frameworks although I'd need to double check the API.

[sparrc]

I imagine that some users may have slaves & frameworks that come and go, so that might be a better option than having to statically configure the IPs of those? (you can correct me if I'm wrong, I'm far from a mesos expert 😉)

But like you mentioned earlier, that doesn't need to be in the initial PR.

[tripledes]

@sparrc I can see both use cases, I can imagine some would like to run telegraf side by side with the slaves I guess, so being able to query independent components can be useful as well. Although I agree, that discovering the Mesos platform through the master can ease the setup, specially nowadays that everything seems to be ephemeral 👍

[asdfsx]

@tripledes Agree with that discovering the Mesos platform through the master can ease the setup. But I'm a little worried about with this. If the cluster is small, I can query all metrics from one host. But when the cluster is huge, and we want to collect metrics from each slave, the host may be under lots of pressure, would that be a problem? May be I think too much. May be the pressure won't be too much.

[tripledes]

@asdfsx Agreed. Although I would offer both options cause for users starting to play with Mesos, auto discovery can be handy, but anyway, I'll start with the more static approach. :)

[sparrc]

closed by #682

[asdfsx]

@tripledes I just create a mesos slave plugin. since I haven't write golang code for a long time! I just copy all of your code, and just modify some of them!
And I really don't know whether it's useful, maybe just like you said depends on the use case.
here it is: https://github.com/asdfsx/telegraf-1/tree/master/plugins/inputs/mesoslave.

[tripledes]

@asdfsx great work! I had a different idea in mind thought, to avoid duplication, looking at your code, there are just some small differences between a master and a slave. For another project (related to mesos) what I did is to implement a small interface called Mesos and based on configuration I had two different objects (structs) Master and Slave, both implementing the Mesos interface. Pretty much the code was shared by both objects and only something like 2 methods were actually different.

That might be a bit too much here, so what I would propose is to abstract common methods to a single file, e.g. mesos_common.go, have mesos_master.go and mesos_slave.go that would be the actual plugins with their own methods.

@sparrc any thoughts on this?

[sparrc]

+1 to @tripledes approach

[asdfsx]

+1 to @tripledes approach too!!!
The only difference is the block function which describe the mesos api.
So I've also think about merge 2 plugins into 1.
And @tripledes , how does the new plugin register into telegraf? use only one name 'mesos'? and save metrics from 'slave' and 'master' into one table?

[asdfsx]

@tripledes I create a new plugin, include master & slave:
take a look
https://github.com/asdfsx/telegraf-1/tree/master/plugins/inputs/mesos2