Closed icinga-migration closed 9 years ago
Updated by tobiasvdk on 2015-06-17 14:45:44 +00:00
You could look at the OpenTSDB plugin. OpenTSDB also uses tags.
Updated by espenfjo on 2015-06-17 16:19:47 +00:00
You are right, KairosDB is actually a fork of OpenTSDB.
The OpenTSDB writer would although create metric names based on the service names which could be everything from "check_disk_/srv", "/srv" to "http". This would be very little flexible from a QOS/Graphing point of view.
Updated by mfriedrich on 2015-08-21 19:14:15 +00:00
Wouldn't it be more reasonable to patch OpenTsdbWriter to also support KairosDB? I use neither of them, so please discuss and provide a patch.
Updated by mfriedrich on 2015-09-17 08:26:34 +00:00
Any news on that topic?
Updated by mfriedrich on 2015-10-15 12:49:23 +00:00
No feedback received in almost a month.
This issue has been migrated from Redmine: https://dev.icinga.com/issues/9439
Created by espenfjo on 2015-06-17 11:10:30 +00:00
Assignee: (none) Status: Rejected (closed on 2015-10-15 12:49:23 +00:00) Target Version: (none) Last Update: 2015-10-15 12:49:23 +00:00 (in Redmine)
Hi, I am currently pondering on implementing a KairosDB performance writer in the samme manner as the GraphiteWriter. (KairosDB is a fast distributed scalable time series database written on top of Cassandra.)
I have some design problems that needs to be solved however.
Where Graphite stores data in a tree (icinga.$host.name$.$service.name$.metric) KairosDB only stores metric and applies "tags" to be able to distinguish between metric from various sources.
Eg the disk usage of "/srv" on "www1.example.org" would typically be stored with "disk_usage" as the metric, and the following tags: "host: www1.example.org", "target:/srv".
I am thinking that perhaps that the metric name should be set to $service.name$ if a variable (vars.kairosdb_metric_name?) isnt set?
Tags could be done with something like: 'vars.kairosdb_tags = ["host=$host.name$", "target=/srv", "tag3=foobar"]'?
I am not sure if the metric name should be "disk" and "usage" should be a tag or not tho..
I could also create magic and use the $service.name$ instead of the custom variables. Perhaps calling a service "diskusage/" and split on "**" to create tags and metric names, but that is probably something that is not advisable.
I hope someone could give me some input on these questions, and on if this is something that is wanted at all.