Skip to content
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 #11483] Numbers are not properly formatted in runtime macro strings #4077

Closed
icinga-migration opened this issue Mar 31, 2016 · 10 comments
Labels
bug Something isn't working
Milestone

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/11483

Created by sys_x on 2016-03-31 07:48:01 +00:00

Assignee: gbeutner
Status: Resolved (closed on 2016-06-21 06:25:06 +00:00)
Target Version: 2.5.0
Last Update: 2016-06-21 10:40:22 +00:00 (in Redmine)

Icinga Version: 2.4.4
Backport?: Not yet backported
Include in Changelog: 1

Hey there,

i would like to use the runtime macros for services in the object NotificationCommand Environment
like last_check, last_state_change, last_state_ok, and so on.

But in my E-Mail notification i will get timestamps like "1.45933e+09".

Tried the following macros an get a wrong timestamps like "1.45941e+09"

  • next_check
  • last_hard_state_change
  • last_state_ok
  • last_state_critical
  • last_state_unknown
  • flapping_last_change

but the macro last_state_change works fine.

Reference:
https://monitoring-portal.org/index.php?thread/35670-runtime-macro-last-state-ok/#post227026

Maybe the same problem exists with host runtime macros. Didnt try it.

I use the Snapshot v2.4.4-258-g97bd4c2

Attachments

Changesets

2016-06-16 13:14:35 +00:00 by gbeutner bc6f7d7

Fix incorrect formatting for some macro values

fixes #11483

2016-06-16 13:32:29 +00:00 by gbeutner 039461e

Fix unit tests for Convert::ToString

refs #11483

2016-06-16 15:39:59 +00:00 by mfriedrich b4c56e5

Remove duplicate last_check runtime macro

Already available as {host,service}.last_check attribute.

refs #11483

2016-06-21 06:23:31 +00:00 by gbeutner b5a38f6

Fix compatibility issue with the $icinga.timet$ macro

fixes #11483

2016-06-21 09:29:12 +00:00 by gbeutner e3f1c1e

Make sure timestamps are formatted as integers in macro strings

refs #11483

2016-07-05 11:17:18 +00:00 by mfriedrich c73e4d3

Fix Downtime validation function signature

refs #11483
@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-03-31 09:45:11 +00:00

  • Subject changed from Wrong runtime macro format to Numbers are not properly formatted in runtime macro strings
  • Category set to libicinga
  • Status changed from New to Assigned
  • Assigned to set to mfriedrich

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-04-01 11:48:07 +00:00

Simple test case:

object Host "11483-host" {
  check_command = "dummy"
  check_interval = 10s
  retry_interval = 5s

  vars.dummy_state = 2
  vars.dummy_text = {{
     "Next check: " + macro("$host.next_check$") + " Last check: " + macro("$host.last_check$")
  }}
}

@icinga-migration
Copy link
Author

Updated by sys_x on 2016-04-04 06:15:15 +00:00

Tried the test case:

The output of the macro "host.next_check" isnt formatted.
The Macro "host.last_check" works fine.

Output:

CRITICAL: Next check: 1.45975e+09 Last check: 1459750263
CRITICAL: Next check: 1.45975e+09 Last check: 1459750273
CRITICAL: Next check: 1.45975e+09 Last check: 1459750283
CRITICAL: Next check: 1.45975e+09 Last check: 1459750293

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-06-16 13:16:42 +00:00

  • Assigned to changed from mfriedrich to gbeutner
  • Target Version set to 2.5.0

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-06-16 13:20:03 +00:00

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

Applied in changeset bc6f7d7.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-06-20 12:39:08 +00:00

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

The floating point numbers are causing problems with external add ons such as PNP.

Can be reproduced using the icinga2x Vagrant box.

vagrant up
vagrant ssh
sudo -i

[root@icinga2 ~]# cat /etc/icinga2/features-enabled/perfdata.conf
/**
 * The PerfdataWriter type writes performance data files and rotates
 * them in a regular interval.
 */

library "perfdata"

object PerfdataWriter "perfdata" { }

less /var/log/pnp4nagios/perfdata.log

2016-06-20 14:33:40 [24842] [0] RRDs::create /var/lib/pnp4nagios/icinga2/random-002.rrd RRA:AVERAGE:0.5:1:2880 RRA:AVERAGE:0.5:5:2880 RRA:AVERAGE:0.5:30:4320 RRA:AVERAGE:0.5:360:5840 RRA:MAX:0.5:1:2880 RRA:MAX:0.5:5:2880 RRA:MAX:0.5:30:4320 RRA:MAX:0.5:360:5840 RRA:MIN:0.5:1:2880 RRA:MIN:0.5:5:2880 RRA:MIN:0.5:30:4320 RRA:MIN:0.5:360:5840 DS:1:GAUGE:8640:U:U --start=1466426016.461956 --step=60
2016-06-20 14:33:40 [24842] [0] RRDs::create ERROR start time: unparsable trailing text: '....461956'
2016-06-20 14:33:40 [24842] [0] RRDs::create /var/lib/pnp4nagios/icinga2/random-005.rrd RRA:AVERAGE:0.5:1:2880 RRA:AVERAGE:0.5:5:2880 RRA:AVERAGE:0.5:30:4320 RRA:AVERAGE:0.5:360:5840 RRA:MAX:0.5:1:2880 RRA:MAX:0.5:5:2880 RRA:MAX:0.5:30:4320 RRA:MAX:0.5:360:5840 RRA:MIN:0.5:1:2880 RRA:MIN:0.5:5:2880 RRA:MIN:0.5:30:4320 RRA:MIN:0.5:360:5840 DS:1:GAUGE:8640:U:U --start=1466426016.865014 --step=60
2016-06-20 14:33:40 [24842] [0] RRDs::create ERROR start time: unparsable trailing text: '....865014'
2016-06-20 14:33:40 [24842] [0] RRDs::create /var/lib/pnp4nagios/icinga2/random-003.rrd RRA:AVERAGE:0.5:1:2880 RRA:AVERAGE:0.5:5:2880 RRA:AVERAGE:0.5:30:4320 RRA:AVERAGE:0.5:360:5840 RRA:MAX:0.5:1:2880 RRA:MAX:0.5:5:2880 RRA:MAX:0.5:30:4320 RRA:MAX:0.5:360:5840 RRA:MIN:0.5:1:2880 RRA:MIN:0.5:5:2880 RRA:MIN:0.5:30:4320 RRA:MIN:0.5:360:5840 DS:1:GAUGE:8640:U:U --start=1466426017.204547 --step=60

We're using the "last_check" attribute if not specified.

"TIMET::$host.last_check$\t"

"TIMET::$service.last_check$\t"

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-06-20 13:21:56 +00:00

I've looked through the PNP process_perfdata.pl code and there are a lot of timet/TIMET references which are not sanitised. RRDTool's time specification expects timestamps in seconds, but cannot handle floating point numbers.

Seems we've hit yet another undefined specification for runtime macro timestamps.

I see 4 possibilities

  • Fix the PNP code and interpret all floating point numbers as integers (this will obviously not being released soon enough for the next Icinga 2 release, and affects anyone using older PNP releases, e.g. upstream packages)
  • Only allow long() for macro resolved values
  • Specifically format the time macro values (e.g. by a field marking this as timestamp value)
  • Introduce a new format for {host,service}_format_template attributes and use lambda functions to properly format the timestamp in seconds.

I'd go for the last option as I find it strange that external add ons cannot handle timestamps in anything other than non-floating point notation.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-06-21 06:20:25 +00:00

Or we could just make an exception for $timet$ and cast it to a long.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-06-21 06:25:06 +00:00

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

Applied in changeset b5a38f6.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-06-21 10:40:22 +00:00

  • File added icinga_11483_fixed.png

Confirmed working again with PNP.

icinga_11483_fixed.png

@icinga-migration icinga-migration added bug Something isn't working libicinga labels Jan 17, 2017
@icinga-migration icinga-migration added this to the 2.5.0 milestone Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant