Updated by bsheqa on 2016-08-01 15:53:21 +00:00

It looks like metadata is only being sent if there are also valide perfdata.
Best would be to make metadata independent from perfdata, like the GraphiteWriter does is. Would this be possible? Maybe by just letting the fields/tags for perfdata blank where they are not available?

Updated by nglp on 2016-10-05 08:09:30 +00:00

We have an issue like this, our case:

Any check or host without valid performance data (or none performance data) doesnt write metadata on influxdb

It can be reproduced doing simple steps

• Add new host, with ip without conectivity
• You"ll see it doesnt write any metadata until has any valid performance data

Same with services, you can try with simple script with an exit 0 (or 2) inside

Our version is r2.5.3-1

https://monitoring-portal.org/index.php?thread/37570-icinga2-influxdb-checks-without-performance-data-not-writting-metadata/

Updated by spjmurray on 2016-10-06 09:27:08 +00:00

Looks like an easy enough fix. I shall have it done shortly...

Updated by spjmurray on 2016-10-06 10:24:51 +00:00

• File added 0001-InfluxDB-Always-Write-Out-Metadata.patch

From e58433c71af91c635cbba516ab0fc6ce3a51d79f Mon Sep 17 00:00:00 2001
From: Simon Murray <[email protected]>
Date: Thu, 6 Oct 2016 10:49:00 +0100
Subject: [PATCH] InfluxDB: Always Write Out Metadata

Previously the logic would just bail out if no performance data was associated with a
check, the problem being that check metadata was skipped too. This rearranges the code
to dump out performance metrics if they exist, then dump out metadata if requested. This
also fixes an issue whereby metadata was being sent for every performance data in the
check result, rather than just once, so we save a bit of bandwidth as a result.

refs: #12276

Updated by spjmurray on 2016-10-06 10:27:31 +00:00

As you can see meta-data is only written out once per check now and doesn"t have a metric name (as it"s not guaranteed to have one when no performance data is present).

[2016-10-06 11:19:17 +0100] debug/InfluxdbWriter: Add to metric list:"apt,domain=angel.net,fqdn=ns.angel.net,hostname=ns,service=apt,metric=available_upgrades value=43 1475749157".
[2016-10-06 11:19:17 +0100] debug/InfluxdbWriter: Add to metric list:"apt,domain=angel.net,fqdn=ns.angel.net,hostname=ns,service=apt,metric=critical_updates value=0 1475749157".
[2016-10-06 11:19:17 +0100] debug/InfluxdbWriter: Add to metric list:"apt,domain=angel.net,fqdn=ns.angel.net,hostname=ns,service=apt acknowledgement=0i,current_attempt=1i,downtime_depth=0i,execution_time=1.295918,latency=0.000870,max_check_attempts=5i,reachable=true,state=1i,state_type=1i 1475749157".

Updated by nglp on 2016-10-10 13:20:32 +00:00

spjmurray wrote:

As you can see meta-data is only written out once per check now and doesn"t have a metric name (as it"s not guaranteed to have one when no performance data is present).

[...]

Thank you mate, this will be implemented on next releases?

Updated by spjmurray on 2016-10-10 16:33:24 +00:00

Depends how long it takes to send a bribe of cookies to Germany... I"ll give Gunnar a poke tomorrow and get the ball rolling, short answer: probably

Updated by nglp on 2016-11-02 10:16:58 +00:00

spjmurray wrote:

From e58433c71af91c635cbba516ab0fc6ce3a51d79f Mon Sep 17 00:00:00 2001
From: Simon Murray <[email protected]>
Date: Thu, 6 Oct 2016 10:49:00 +0100
Subject: [PATCH] InfluxDB: Always Write Out Metadata

Previously the logic would just bail out if no performance data was associated with a
check, the problem being that check metadata was skipped too. This rearranges the code
to dump out performance metrics if they exist, then dump out metadata if requested. This
also fixes an issue whereby metadata was being sent for every performance data in the
check result, rather than just once, so we save a bit of bandwidth as a result.

refs: #12276

Hi again,

I really need this, so i tried to patch it on v.2.5.3 but im getting an error on compilation when it tries to compile that module with that patch code. Can you provide me the ccp or version with you compiled it sucesfully?

Thank you

Updated by spjmurray on 2016-11-04 12:30:13 +00:00

Given it was written 17th September on master I can only assume it"s intended to be patched onto 2.5.4 or later. I"ve rebased onto the current upstream head and it still applies and compile cleanly. Hopefully this is some help
Si

Updated by spjmurray on 2016-11-04 12:42:39 +00:00

@dnsmichi - can someone have a look at this please?

Updated by mfriedrich on 2016-11-09 15:11:08 +00:00

• Status changed from New to Assigned
• Assigned to set to mfriedrich
• Target Version set to 2.6.0

Been on vacation lately.

Updated by spjmurray on 2016-11-09 15:15:02 +00:00

• Status changed from Assigned to Resolved
• Done % changed from 0 to 100

Applied in changeset 2c37a00.