Feat/riemann exporter #58
Conversation
Put in place Riemann exporter skeleton.
- Fix typo. - Fix construction.
Refactor run function to avoid nested code.
Event is sent to Riemann. It needs to be refactored because it is really raw. However it is working.
Add hostname crate to get system hostname.
Simplify usage of send_metric function.
- Allow &str and String type as Metric
- Allow to pass ttl, tag, description - Refactor to add some functions - Rename add_metric to set_metric
Add dependencies to protobuf to insert tags.
Add mem and cpu metrics.
Add new measures. Only processes are missing. Refactoring needed.
Refactor host and socket part. Avoid to set a default version.
Update code due to rebase on upstream.
Add option --qemu introduce by latest rebase.
Add power consumption on processes.
- Add vmname is -q or --qemu option is passed. - Factorize common code into utils.rs.
Add Riemann exporter documentation.
|
This is awesome, thanks a lot ! |
|
I'm trying the PR and this is great so far ! Thanks ! |
| @@ -18,6 +18,9 @@ clap = "2.33.3" | |||
| regex = "1" | |||
| procfs = "0.8.1" | |||
| actix-web = "3" | |||
| riemann_client = "0.7.0" | |||
There was a problem hiding this comment.
I never tried it but you also have https://github.com/sunng87/rustmann which supports stuff like mTLS.
There was a problem hiding this comment.
In your experience is this a must have or a nice to have for a riemann client ?
There was a problem hiding this comment.
Interesting because based on tokio as well, but maybe a bit early to use this client. As stated in the presentation.
A riemann client using tokio. This project is still in its early stage and API changes aggressively.
So we may run to adapt the code to the api changes. I think we can keep an eye on it and move as soon as the api is more stable and if it makes sens.
There was a problem hiding this comment.
In your experience is this a must have or a nice to have for a riemann client ?
it's not mandatory but I usually run all of my services using mTLS if I can.
But as @uggla said, the current lib may be enough for now.
There was a problem hiding this comment.
Thanks a lot for your feedbacks. Let's keep this one for now and keep an eye on rustmann :)
There was a problem hiding this comment.
Another option could be to add mTLS to the current riemann client using rustls. Seems not "too hard" although with security it is never as easy as it looks...
@bpetit, if it is ok for you, as soon as this PR will be merged, I will open a new one to do the proposed changes to reduce duplication. |
|
I've added prefixes to the PR as I solved the docs conflicts. I'd like to know if you find it relevant or not before I push. |
|
I pushed as I preferred to integrate that PR before others. We can open another PR as you suggested to change some details if needed. |
|
|
I've added
So they have the same name as the ones in the prometheus exporter (except for the one you mentionned in the docs). What do you think ? |
Yes of course. We have a base now and it's better to iterate and improve it.
I got it now. Yes sounds good. |
First "version" of Riemann exporter.
The implementation was done as a proof of concept. So I tried to do it minimizing the modifications to the existing files.
This is inspired and not so far from the Prometheus one.
As a result it works fine, but there are a lot of duplications in the code currently.
Future improvements could be to:
Sorry this PR is a bit large, but it mostly introduced new files, so it can probably be merged without being too worried about it.
Note, I have also fixed a couple of typos in Prometheus exporter.