Updated by mfriedrich on 2015-10-28 18:55:48 00:00

• Status changed from New to Assigned
• Assigned to set to mfriedrich

I'd like to play with it in my spare time :)

Updated by mfriedrich on 2015-10-30 23:35:20 00:00

http://stackoverflow.com/questions/33350314/usecases-influxdb-vs-prometheus/

Updated by mfriedrich on 2015-11-25 16:04:52 00:00

• Status changed from Assigned to New
• Assigned to deleted mfriedrich

I'm postponing this until InfluxDB reaches 1.0.0 ... talked to many at OSMC and it seems 0.9.5 again broke the backend.

Updated by mfriedrich on 2015-12-03 17:01:54 00:00

• Blocks set to 9072

Updated by mfriedrich on 2016-03-31 06:11:24 00:00

https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/

Updated by spjmurray on 2016-04-12 14:44:56 00:00

As discussed on IRC I'm happy to pick this up and maintain it. Here's what I imagine the configuration to look like:

library "perfdata"

object InfluxdbWriter "influxdb" {
  host = "influxdb.example.com"
  port = 8086
  ssl_enable = true
  ssl_ca_cert = "/var/lib/puppet/ssl/certs/ca.pem"
  ssl_cert = "/var/lib/puppet/ssl/certs/icinga2.example.com.pem"
  ssl_key = "/var/lib/puppet/ssl/private_keys/icinga2.example.com.pem"
  host_template = "$host.check_command$,hostname=$host.name$domain$"
  service_template = "$service.check_command$,hostname=$host.name$,service=$service.name$"
  enable_send_thresholds = true
  enable_send_metadata = false
}

The important bits:

• Optional server side SSL support with ssl_enable and ssl_ca_cert
• Optional mutually verified SSL support with ssl_enable, ssl_ca_cert, ssl_cert and ssl_key
• Flexible configuration allows the measurement and tags to be specified to your preference
• Tags can be utterly arbitrary e.g. domain=$host.vars.domain$
• Icinga2 implicitly adds metric and type tags which maps to a nagios perfdata label and a perfdata element (e.g. value, warn, crit. min, max) respectively

InfluxDB also advises not to have more that one piece of data in a tag. Say if we had an MTU check applied to an interface we'd potentially generate mtueth0 as the service name from the check command mtu and the key we applied the check to eth0. In this case the mtu part is redundant as it's already available as $service.check_command$ and all we really care about is this data point is tagged to the interface eth0. This could be possibly surfaced by attaching the key to the service object.

Another idea is to make tags programmable:

service_template = {
  measurement = "$service.check_command$"
  tags        = {
    hostname = "$host.name$"
    instance = "$service.instance$"
  }
}

In this example rather than encoding the template as a fixed string, it can be encoded as a hash. The measurement field is required, tags is optional. Any unresolved macros are omitted from the final set of tags to be sent to InfluxDB.

All I can think of right about now. Feel free to highlight any technical snafus I may be making.

Updated by spjmurray on 2016-04-14 13:31:39 00:00

Working branch: https://github.com/spjmurray/icinga2/tree/feature/influxdb-writer-10480

Updated by mfriedrich on 2016-04-19 15:24:52 00:00

• Status changed from New to Assigned
• Assigned to set to mfriedrich
• Target Version changed from Backlog to 2.5.0

You're way too fast for us catching up with a review. Much appreciated though :)

I've seen your blog post, leaving as a reference here: http://www.datacentred.co.uk/blog/integrating-icinga2-with-influxdb-and-grafana/

I'll take it for a review though it might take a while. Since it is a new feature it should target 2.5.0 then.

Kind regards,
Michael

Updated by spjmurray on 2016-04-19 16:24:53 00:00

shroud has already kicked my ass into shape so most of the major points should have been fixed! Bloody hell, the marketing droids don't hang about... well at least you get a bigger picture of what this is about.

Updated by spjmurray on 2016-05-03 12:15:03 00:00

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

Applied in changeset 79c1e88.

Updated by mfriedrich on 2016-05-03 12:35:40 00:00

You are actually using the http bits from libremote and fixed a bug over there, nice :)

The rest looks like you know your development foo, also helped by shroud :)

I've partially updated the documentation for addons/features and amended those changes into your patch.

I have no objections against the patch though I'm lacking a test setup for now. Once the snapshot packages are built, please invite others to test them before they are hitting the release 2.5.0 then.

Updated by spjmurray on 2016-05-05 05:26:05 00:00

Thanks Michael. I take it I can start testing the snapshots in staging once 2.4.8 is released?

Updated by mfriedrich on 2016-05-05 07:03:16 00:00

Snapshot packages are built on each git commit for el7 (vagrant/docker trsts) and via cron for all other distributions once a day. You don't have to wait for the bugfix release 2.4.8, that release will just backport certsin fixes from the master development branch which currently targets 2.5.0 :)

TL;DR - start now.

Updated by spjmurray on 2016-05-09 09:43:57 00:00

Soak test started with 2.4.7 snapshot2016.05.09 1~trusty as of 10:41 09/05/16...

Updated by mfriedrich on 2016-06-07 19:00:36 00:00

• Relates set to 11912

Updated by mfriedrich on 2016-06-07 20:01:58 00:00

• Relates set to 11904