Seite wählen

NETWAYS Blog

Gnocchi und Archiv Policies

Gnocchi ist eine time series database die aus dem OpenStack Projekt hervorgegangen ist. Da Gnocchi erst 2014 entstanden ist, wurde versucht die Schwächen vorhandener Lösungen zu umgehen. Im Vergleich fallen mir vor allem folgenden Features auf:

  • Mandantenfähigkeit
  • Skalierbarkeit
  • Hochverfügbarkeit
  • REST Interface (HTTP)
  • Unterstützung moderner Backends wie Ceph (librbd), Swift und S3
  • OpenSource

Ein weiters Feature ist die Unterstützung von archive policies. Diese legen fest wie lange und in welcher Granularität Metriken vorgehalten werden. Zusätzlich kann auch die Art der Aggregation definiert werden. Sendet man den unten stehenden json Text per HTTP an /v1/archive_policy wird z.B. eine Policy angelegt die Metriken mit einer Granularität von 5 Minuten für 62 Tage speichert und dafür 17856 Punkte benötigt (12 Metriken je Stunde * 24 Stunden * 62 Tage = 17856). Zusätzlich werden die Metriken in aggregierter From  für 365 und 3650 Tage gespeichert.
 

{
  "name": "router-metriken",
  "back_window" : 0,
  "definition" : [
    {
      "points" : 17856,
      "granularity" : "00:05:00",
      "timespan" : "62 days, 0:00:00"
    },
    {
      "points" : 8760,
      "granularity" : "1:00:00",
      "timespan" : "365 days, 0:00:00"
    },
    {
      "points" : 3650,
      "granularity" : "24:00:00",
      "timespan" : "3650 days, 0:00:00"
    }
  ],
  "aggregation_methods" : [
    "min",
    "max",
    "mean",
    "sum"
  ]
}

 
Welche archive policy für einzelne Metriken angewendet wird kann über rules bestimmt werden. Neue Metriken werden per Regex geprüft und ggf. einer Policy zugewiesen. Treffen mehrer Regeln greift der längste Regex. Mit der folgenden Regel werden alle Metriken die mit router beginnen zu der oben definierten Policy hinzugefügt.
 

{
  "archive_policy_name": "router-metriken",
  "metric_pattern": "router.*",
  "name": "router-metriken"
}

 
Mein erster Eindruck von Gnocchi ist durchaus positiv und mit den genannten Features kann sich die OpenStack Lösung von der Konkurrenz abheben. Aktuell ist Gnocchi wohl am besten für die Bedürfnisse von OpenStack ausgelegt. Es gibt aber auch Integrationen zu collectd, statsd, Icinga und Grafana.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

Windows performance counters with NSClient++ and Graphite

Windows performance counters have been there for ages. While modern interfaces such as WMI attempt to replace performance counters they still provide access to unique metrics. Fetching performance counters through NSClient++ is helped with the check_pdh query.
We’ve had an interesting issue with performance counters being received from a Windows client and then written to  Graphite. The involved components in this setup are

  • Icinga 2 as master
  • GraphiteWriter feature enabled and Graphite running
  • An Icinga 2 client on the windows machine checked via cluster config sync
  • nscp-local“ CheckCommand objects for querying nscp.exe directly (config sync, global zone)
  • NSClient++ installed on the Windows client

 

The Problem

perfcounter_errorGraphite Web refuses to display any value for that metric as seen in the screenshot. A similar problem is discussed at the monitoring portal (German).
While further analysing the problem we’ve come around this blog post. It did not help resolve the problem but provided insights on the problem within Graphite itself.
The culprit lies in the performance data label containing the „%“ character. You will encounter similar issue with the „*“ character. The filesystem does not allow to store and load these files.
There’s an issue on the Graphite bug tracker which targets dealing with special characters and better error handling.
 

The Solution

It may sound reasonable to remove such strings in the Carbon Cache backend, or use a shell wrapper for calling the nscp.exe and reformatting the returned metrics. Though those are just workarounds for the real issue.
perfcounter_fixedAt first glance we looked into perf-config but that only allows to modify the performance data label suffix. The documentation is still a TODO so it was more or less reading the source code and figuring out what other options are available.
In the end it turned out to be far more easy – Michael Medin, you’re a genius – perf-syntax provides the ability to just format your metrics as plugin performance data for your likings. The following example overrides the counter label to „Processor Time“ – Graphite works again!

C:\Program Files (x86)\NSClient++>nscp.exe client --load-all --log info -b -q check_pdh counter="\Processor(_Total)\% Processor Time" perf-syntax="Processor Time"
11:02 OK: \Processor(_Total)\% Processor Time = 0|'Processor Time_value'=0;0;0

 

Icinga 2 Integration

The nscp-local CheckCommand definitions must be included by editing the icinga2.conf file on both the master and the client.

include <nscp-local>

If you prefer to use your own CheckCommand definition ensure to deploy it using a global zone defined on both the master and the client.
CheckCommand example:

object CheckCommand "nscp-local-pdh" {
        import  "nscp-local"
        arguments += {
            "counter" = {
                value = "counter=$pdh_counter$"
                required = true
                skip_key = true
            }
            crit = {
                value = "crit=value > $pdh_crit$"
                skip_key = true
            }
            warn = {
                value = "warn=value > $pdh_warn$"
                skip_key = true
            }
            "perf-syntax" = {
                 value = "perf-syntax=$pdh_perfsyntax$"
                 skip_key = true
            }
        }
        vars.nscp_query = "check_pdh"
        vars.pdh_perfsyntax = "$pdh_counter$"
}

Service apply example (via cluster config sync):

apply Service "perfcounter_test" {
    import "generic-service"
    check_command = "nscp-local-pdh"
    vars.pdh_counter = "\\Processor(_total)\\% Processor Time"
    vars.pdh_perfsyntax = "Total Processor Time"
    vars.pdh_warn = "1"
    vars.pdh_crit = "5"
    assign where host.address
}

 
I’ve created an Icinga 2 issue for extending the Icinga 2 NSCP CheckCommands to provide the perf-config and perf-syntax natively.
 

More Hints

NSClient++ 0.4.2 changed the performance data label for counters and added the „_value“ suffix. More recent versions allowed to override the suffix by defining the perf-config attribute. Although there is a bug which does not allow to remove the suffix. This should be fixed in the most recent stable release.

perf-config=*(suffix:none)

 

Conclusion

A tricky problem which probably affects a lot of users. A benefit of Open Source development – read the source, Luke 🙂
read_the_source_luke
(Copyright by http://blog.codinghorror.com/learn-to-read-the-source-luke/)

host sFlow und Graphite

Es gibt ja die verschiedene Möglichkeiten Graphite mit entsprechenden Metriken zu versorgen. Neben den Klassikern wie zum Beispiel collectd existieren auch zahlreiche andere Tools, die mit Graphite zusammen arbeiten. Eines davon ist host sFlow, welches ich hier nachfolgend vorstellen möchte.
Wie der Name des Tools schon sagt, steht es im Zusammenhang mit sFlow, dem Standard aus dem Netzwerkbereich zur Trafficweiterleitung bzw. -analyse. host sFlow wird u.a. als DEB oder RPM-Paket zum Download angeboten.
Nach der Installation müssen in der Konfigurationsdatei „/etc/hsflowd.conf“ Sammelwerte und die sFlow Kollektoren eingetragen werden, hier ist das nur einer:

sflow{
  packetSamplingRate=400
  counterPollingInterval=20
  collector{
    ip = 127.0.0.1
}

Der Daemon hsflowd sollte jetzt bereits gestartet werden, allerdings benötigen wir für den Transfer der Metriken von host sFlow an Graphite noch ein zusätzliches Skript names sflow2graphite. Da dieses auf sflowtool zurück greift, müssen wir das im Vorfeld installieren:

# git clone https://github.com/sflow/sflowtool.git
# automake
# autoconf
# ./configure
# make
# make install

Schlussendlich benötigen wir eben nur noch sflow2graphite, welches im Anschluss gestartet wird:

# wget 
# tar -xf sflow2graphite-0.5.2.tar.gz
# ./sflow2graphite

Nun sollten die Metriken bereits von Graphite empfangen und als Whisper Files abgelegt werden:

├── cpu
│   ├── contexts.wsp
│   ├── idle.wsp
│   ├── ...
├── disk
│   ├── bytes_read.wsp
│   ├── bytes_written.wsp
│   ├── ...
│   ├──
├── load
│   ├── load_fifteen.wsp
│   ├── load_five.wsp
│   └── ...
├── mem
│   ├── buffers.wsp
│   ├── cached.wsp
│   ├── ...
└── net
    ├── bytes_in.wsp
    ├── bytes_out.wsp
    ...

Für eine bessere Visualisierung der Metriken bieten sich beispielsweise noch Dashboards mit Grafana an, hier am Beispiel der von host sFlow gesammelten Netzwerkmetriken:
Bildschirmfoto vom 2015-09-04 07:36:19

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.