New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dev.icinga.com #9461] New Graphite schema #3090
Comments
Updated by tgelf on 2015-06-19 16:18:57 +00:00 NB: This would be the perfect occasion to also fix #8149 |
Updated by tgelf on 2015-06-19 16:19:11 +00:00
|
Updated by tgelf on 2015-06-19 16:21:03 +00:00 Forgot to mention: perfdata-label should NOT escape dots, this would allow for even deeper structures. |
Updated by mfriedrich on 2015-06-22 07:26:00 +00:00
TODOs:
|
Updated by dgoetz on 2015-06-22 11:50:09 +00:00 Can we also get range support for the thresholds like discussed in https://dev.icinga.org/issues/5043? Furthermore enable_send_thresholds and enable_send_metadata will be parameters for the writer? Can we get this in a way so you can add these options on a service or command base? |
Updated by mfriedrich on 2015-06-22 12:29:27 +00:00
|
Updated by mfriedrich on 2015-06-23 07:21:18 +00:00 dirk wrote:
I do see a similar use case as the {host,service}_format_template attributes - enable them on a global basis and have it either enabled or disabled. Obfuscating the service or checkcommand object types with additional parameters could lead into errors similar to "why does this service have these items, and others don't" which makes it impossible to determine from a graphite's point of view. If you still think this should taken into account, please discuss it in a separate issue. If such options get added, they could be added later on, not blocking this issue. |
Updated by mfriedrich on 2015-06-26 09:06:57 +00:00
|
Updated by gbeutner on 2015-06-30 06:54:08 +00:00
|
Updated by espenfjo on 2015-07-05 14:50:33 +00:00 It would be very nice if this could be some general cleanup of the perfdata structure. After looking into how best to create a logical structure for a tag based Graphing system (OpenTSDB and KairosDB) it feels like Icinga is lacking quite a bit. I was fiddling with adding several new variables which optionally could be set for each service/host.
This will create a metric with name "`ping`" in KairosDB with the following tags: tag | description ------------------~~|-----------------------------------------~~ host | Host name that is being probed source | Icinga instance probing the host protocol | Custom tag defined in the service, here set to ipv4 for the ping4 check. target | The \`ping4\` probe will create three different target tags: \`meta\`, \`rta\` and \`pl\`. \`rta\` and \`pl\` are the sub checks of the probe. \`meta\` is the internal check statistic mentioned above.I would think that, if generalised, one would be able to use a similar structure for every^Wmost graphing systems. |
Updated by mfriedrich on 2015-07-06 15:16:50 +00:00 Perfdata is just a specific value class being parsed from the string values a host/service check provides. There's not much one could do about structure here. I also do think that OpenTSDB and InfluxDB (or collectd) follow a different approach in their tree structure using tags, which is not necessarily the same as one would do in graphite. Which is why such discussions on trees should be kept in a separate issue, as each writer will prefer its own schema. |
Updated by mfriedrich on 2015-07-17 20:32:19 +00:00
|
Updated by mfriedrich on 2015-08-03 15:46:16 +00:00
|
Updated by mfriedrich on 2015-08-03 15:46:26 +00:00
|
Updated by mfriedrich on 2015-08-27 16:17:00 +00:00
|
Updated by mfriedrich on 2015-09-06 08:30:27 +00:00
|
Updated by mfriedrich on 2015-09-06 08:34:55 +00:00
In order to enable the old mode you'll need to add the following to your graphite.conf
|
Updated by mfriedrich on 2015-09-06 08:55:09 +00:00
I'm using this nice Docker container for tests.
|
Updated by mfriedrich on 2015-09-06 09:04:47 +00:00
New SchemaAgain, without legacy mode. Dashes are not escaped
Perfdata Labels not escaped
|
Updated by mfriedrich on 2015-09-06 09:25:03 +00:00
Applied in changeset b10cb8a. |
Updated by mfriedrich on 2015-09-07 14:17:31 +00:00
|
Updated by mfriedrich on 2015-09-30 12:43:25 +00:00
|
Updated by gbeutner on 2015-11-06 17:09:04 +00:00
|
This issue has been migrated from Redmine: https://dev.icinga.com/issues/9461
Created by tgelf on 2015-06-19 16:18:08 +00:00
Assignee: mfriedrich
Status: Resolved (closed on 2015-09-06 09:25:03 +00:00)
Target Version: 2.4.0
Last Update: 2015-11-06 17:09:04 +00:00 (in Redmine)
The current graphite writer implementation creates a pretty flat tree while enriching perfdata values with lots of additional data. Currently we encounter the following problems:
Data overhead
There is (much) more additional data than "real" performance data. For many people this means burning resources for data they don't need. This can be solved with additional config flags.
I would suggest to distinguish between enable_send_thresholds and enable_send_metadata in the Graphite writer config.
Template assignment
It would be great if we could ship default templates for various checks. This is currently hard to impossible as we have no chance to figure out what data to expect behind generated Graphite paths. The service name gives no hint, the command name is not available and all the extra data on the same level are noisy and hard to filter away in an efficient way.
I'd opt for a completely new default structure to solve this issue. To avoid trouble with existing trees I propose to use a completely new global prefix, icinga2 instead of icinga. Reason: people do not read changelogs. Who does not like the new structure will delete the new tree and continue to fill the legacy one by downgrading or toggling config knobs.
Proposed tree structure
Prefix for hosts:
Prefix for services:
Data should be written as follows:
With enable_send_thresholds = true (default should be false) Icinga would add
With enable_send_metadata = true (should also default to false) it would add
Cheers,
Thomas
Tests
Docker Container:
Attachments
Changesets
2015-06-19 16:34:04 +00:00 by (unknown) 0bcb0f5
2015-06-22 16:15:39 +00:00 by (unknown) 66a10d6
2015-08-03 16:03:34 +00:00 by (unknown) 04fccda
2015-08-03 16:03:34 +00:00 by (unknown) 489514e
2015-09-04 13:43:21 +00:00 by mfriedrich 6b3337c
2015-09-04 13:43:21 +00:00 by mfriedrich e687c51
2015-09-04 15:33:52 +00:00 by mfriedrich acfb8b2
2015-09-06 08:32:48 +00:00 by mfriedrich c37902f
2015-09-06 08:32:49 +00:00 by mfriedrich 5b3a47e
2015-09-06 08:32:49 +00:00 by mfriedrich b6a57f8
2015-09-06 08:32:49 +00:00 by mfriedrich 76a14ce
2015-09-06 09:10:49 +00:00 by mfriedrich b10cb8a
2015-10-20 06:06:25 +00:00 by (unknown) b77c9ed
Relations:
The text was updated successfully, but these errors were encountered: