Seite wählen

NETWAYS Blog

Maximale Datenkontrolle: OpenSearch Dashboards und Icinga Integration

von | Sep 9, 2023 |

Moderne Unternehmens-IT erfordert nicht nur eine zuverlässige Überwachung. Eine tiefgehende Analyse der Daten hilft dabei, relevante Erkenntnisse zu erhalten und damit die Leistungsfähigkeit des Systems kontinuierlich zu verbessern. Die Integration von Icinga in OpenSearch hilft dir dabei, dieses Ziel zu erreichen und dabei Leistung, Sicherheit und Analysemöglichkeiten deiner IT-Umgebung zu steigern.

Mit dem Elasticsearchwriter (als Fork von Elastic funktioniert das Tool auch in OpenSearch) kannst du OpenSearch zum Beispiel um Check Ergebnisse, Metriken und Performanz-Daten ergänzen. Icingabeat erweitert das Ganze um nahezu alle Ergebnisse deiner Checkresults, Downtimes, Notifications, Acknowledgements, um nur ein paar Parameter zu nennen. Damit bekommst du noch mehr Spielraum für Customization, Visualisierung, Data-Science Analytics und Alarmierung.
Im besten Fall ist bei dir Icinga Version 2.14 im Einsatz. Falls du Hilfe bei der Installation und Konfiguration von Icinga auf Ubuntu oder RHEL benötigst, empfehle ich dir einen Blick in unsere Guides zu werfen.

Sicherheit ist das Kernthema dieses Artikels, denn bei der Integration zweier Systeme ist es umso wichtiger, dass deine Daten auf dem Transportweg sicher verschlüsselt sind (Stichwort TLS-Verschlüsselung). Das macht vor allem bei verteilten Setups mit mehreren Netzwerken Sinn.

OpenSearch – Icinga Integration: Zertifikate vorbereiten

Um die sichere Kommunikation von OpenSearch und Icinga zu ermöglichen, müssen zunächst vertrauenswürdige Zertifikate erstellt werden, die bei der TLS-Verschlüsselung zum Einsatz kommen.
Für eine umfassende und ausführliche Erklärung zur Erstellung von Zertifikaten in OpenSearch kannst du einfach den Schritten der offiziellen Dokumentation folgen.

Um dir diese Arbeit abzunehmen und direkt eine in der Praxis von mir getestete Lösung zur Verfügung zu stellen, teile ich für dir für diese Task meine Zertifikatsgenerierung.
In diesem Beispiel heißt meine CA-Stelle graylog-root-ca und der Client Icinga2Opensearch.lan. Wenn du andere Bezeichnungen nutzt oder nutzen willst, musst du sie an den entsprechenden Stellen anpassen.

# 1. Generierung Beispiel-Ordner zum Ablegen der Zertifikate
mkdir -p /etc/ssl/certs/graylog/Icinga2OpenSearch

# 2. Generierung des Icinga2Opensearch Client-Keys
openssl genpkey -algorithm RSA -out /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch.key -pkeyopt rsa_keygen_bits:4096

# 3. Template um die Alt Names zu setzen
# 3. Start
cat << EOF > /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch_openssl.cnf
[ req ]
default_bits       = 4096
default_keyfile    = /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch.key
distinguished_name = req_distinguished_name
req_extensions     = req_ext
prompt             = no

[ req_distinguished_name ]
countryName                     = de
stateOrProvinceName             = by
localityName                    = nbg
organizationName                = nw
organizationalUnitName          = nps
commonName                      = Icinga2OpenSearch.lan

[ req_ext ]
subjectAltName = @alt_names

[alt_names]
DNS.1 = Icinga2OpenSearch.lan
IP.1 = 6.6.6.6
EOF
#3. Ende

#4. Generieren des CSRs
openssl req -new -key /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch.key -out /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch.csr -config /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch_openssl.cnf

#5. Signieren des CSRs
openssl x509 -req -days 3650 -in /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch.csr -CA /etc/graylog/server/graylog-ca-root.crt -CAkey /etc/ssl/certs/graylog/central/graylog-ca-key.pem -out /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch.crt

#6. Graylog-CA mitkopieren
cp /etc/ssl/certs/graylog/central/graylog-ca-root.crt /etc/ssl/certs/graylog/Icinga2OpenSearch/


#7. In den Ordner wechseln und Packen um danach SCP zum Ziel-Icinga2-Server
cd /etc/ssl/certs/graylog/Icinga2OpenSearch && tar-czvf Icinga2OpenSearch.gz Icinga2OpenSearch.crt Icinga2OpenSearch.key graylog-ca-root.crt

#8. Nach dem SCP auf den RHEL-Icinga2-Server User & Permissions anpassen
chown -Rv icinga:icinga /etc/icinga2/Icinga2OpenSearch
chmod -Rv 750 /etc/icinga2/Icinga2OpenSearch

Mit dem ElasticsearchWriter Daten an OpenSearch schicken

Nachdem die Vorbereitungen für eine sichere Kommunikation zwischen Icinga und OpenSearch abgeschlossen sind, kann nun die eigentliche Kommunikationsschnittstelle eingerichtet werden. Damit du mit dem ElasticsearchWriter die gewünschten Daten übertragen kannst, benötigt es nur ein paar kleine Einstellungen in der elasticsearch.conf aufseiten von Icinga.

Füge Host und Port, einen Namen für deinen Index sowie deinen Service-/Benutzer-Account (wie du diesen anlegst, erkläre ich in einem anderen Blogpost) hinzu. Zudem gibst du den Pfad zu den vorher angelegten Zertifikaten an und fügst eine Aktivierungsflagge hinzu. Damit sind alle relevanten Informationen in der Konfigurationsdatei verfügbar.

Wenn du noch keine Erfahrung mit dem ElasticsearchWriter hast und mehr darüber erfahren willst, empfehle ich dir den entsprechenden Abschnitt in der offiziellen Icinga Dokumentation. Darin sind Handhabung und weitere Details gut beschrieben.

vim /etc/icinga2/features-available/elasticsearch.conf
object ElasticsearchWriter "elasticsearch" {
  
  host = "opensearch.lan"
  port = 9200
  index = "icingabeat-7.17.4"
  enable_send_perfdata = true
  flush_threshold = 1024
  flush_interval = 10s
  
  username = "Icinga2Opensearch_Service_Account"
  password = "Icinga2Opensearch_Service_Password"

  ca_path = "/etc/icinga2/Icinga2OpenSearch/graylog-ca-root.crt"
  cert_path = /"etc/icinga2/Icinga2OpenSearch/Icinga2OpenSearch.crt"
  key_path = "/etc/icinga2/Icinga2OpenSearch/Icinga2OpenSearch.key"

  # Je nachdem ob self-signed oder nicht sowie die Hostnames/IPs passen hier auf true/false
  insecure_noverify = false

  enable_tls = true
}

Nun aktivierst du das Feature mit dem Befehl icinga2 feature enable elasticsearch. Anschließend kannst du via tail -f /var/log/icinga2/icinga2.log sehen, ob alles funktioniert.
Hast du den Icingabeat Index richtig referenziert, solltest du (wie in meinem Screenshot erkennbar) im Discover die Daten fließen sehen.

OpenSearch und Icingabeat

Damit Icingabeat und OpenSearch überhaupt miteinander sprechen können, müssen die Zugriffsrechte seitens Icinga freigegeben werden. Dazu erstellst du unter /etc/icinga2/features-available/api.conf ein ApiUser Objekt mit entsprechenden Rechten, beispielsweise mit dem Namen icingabeat.

object ApiListener "api" {
  accept_config = true
  accept_commands = true
  ticket_salt = "my_salt"
}

object ApiUser "icingabeat" {
  password = "icingabeat_service_password"
  permissions = ["events/*", "status/query"]
}

Wie bei allen Beats werden Logs ausgelesen und entweder über Mittelsmänner wie Logstash weitergeleitet oder direkt an Elasticsearch gesendet.

Bei OpenSearch ist es aktuell allerdings so, dass ein „direkter“ Sendeweg nur über einen Mittelsmann wie Logstash oder Graylog geht. Von hier werden die Daten anschließend an OpenSearch weitergegeben.
Es gibt also zwei Optionen, aus denen man wählen kann. Ich zeige dir zuerst einen Graylog-Input und danach einen Logstash Input.

Icingabeat Konfiguration

Bevor ich genauer auf die beiden Möglichkeiten eingehe, zeige ich dir zunächst die Icingabeat Konfiguration. Hier arbeitest du in einem Konfigurationsfile, das an einen Beat angelehnt ist. Du kannst nach Interesse verschiedene Eventstreams auswählen, denen du wie zuvor Host-IP, Service-Passwörter für OpenSearch, Zeitintervalle und Zertifikate mitgibst.

vim /etc/icingabeat/icingabeat.yml
icingabeat:
 host: "127.0.0.1"
 user: "icingabeat_opensearch_service_account"
 password: "icingabeat_opensearch_service_password"
 ssl.verify: false 
 ssl.certificate_authorities: ["/var/lib/icinga2/ca//ca.crt"] 

 eventstream.types:
   - CheckResult 
   - StateChange 
   - Notification 
   - AcknowledgementSet 
   - AcknowledgementCleared 
   - CommentAdded 
   - CommentRemoved 
   - DowntimeAdded 
   - DowntimeRemoved 
   - DowntimeStarted 
   - DowntimeTriggered 

eventstream.filter: "" 
eventstream.retry_interval: 10s 
statuspoller.interval: 60s 

# Graylog Output Variante: 
  output.logstash: 
   hosts: ["graylog.lan"] 
   ssl.enable: true 
   ssl.verification_mode: "certificate" 

   ssl.certificate_authorities: ["/etc/icinga2/Icinga2OpenSearch/graylog-ca-root.crt"] 
   ssl.certificate: "/etc/icinga2/Icinga2OpenSearch/Icinga2OpenSearch.crt" 
   ssl.key: "/etc/icinga2/Icinga2OpenSearch/Icinga2OpenSearch.key"

Graylog Input an OpenSearch

Hier vergebe ich einen Graylog-Input Namen, eine Listener Bind-Addresse und gebe ein eigenes Graylog-CA-Server Zertifikat an. Für dieses Beispiel habe ich ein extra ein Clientzertifikat namens 5044 angelegt. In meinem Screenshot siehst du, wie das komplett ausgefüllte Eingabe-Formular aussehen sollte:

Icingabeat sendet seine Informationen an den Graylog-Input, der diesen Input verarbeitet und anschließend entsprechend der Graylog-Dokumentation, weiter an OpenSearch sendet.
Damit der zweite Schritt möglich ist, musst du in /etc/graylog/server/server.conf den Weg von Graylog zu OpenSearch angeben:

"elasticsearch_hosts = https://my_graylog_service_account:my_graylog_service_password@opensearch.lan:9200"

Icingabeat Input via Logstash-OSS

In Möglichkeit Nummer 2 benutzt du das Logstash-OSS Paket von Elasticsearch auf das Amazon referenziert, und machst dir so einen Logstash-Input, der einen Output auf OpenSearch hat:

Nachdem du das Paket geladen hast, kannst du dir die verfügbaren Plugins ansehen und sichergehen, dass die benötigten Input und Output Plugins vorhanden sind:

/usr/share/logstash/bin/logstash-plugin list --verbose
/usr/share/logstash/bin/logstash-plugin install logstash-input-beats
/usr/share/logstash/bin/logstash-plugin install logstash-output-opensearch

Bedenke, dass du aus historischen Gründen zuerst deinen Logstash-Schlüssel des Inputs in das PKCS8-Format bringen musst:

# Beispiel PKCS8-mit Passphrase
openssl pkcs8 -in logstash-oss.key -topk8 -out logstash-oss-pkcs8.key

# Beispiel PKCS8-ohne Passphrase
openssl pkcs8 -in logstash-oss.key -topk8 -nocrypt -out logstash-oss-pkcs8.key

Jetzt legst du dir eine neue Pipeline an, z.B. /etc/logstash/conf.d/icingabeat-pipeline.conf. Hier legst du Beats-Input und Opensearch-Output Einstellungen fest, die via /etc/logstash/pipelines.yml angezogen werden.

Folgende Parameter müssen angegeben werden:

Input:

  • Input Port
  • SSL-Aktivierungsflaggen
  • Privater Logstash-Schlüssel im PKCS8 Format
  • CA mitgegeben

Output:

  • das OpenSearch-Backend mit IP und Port
  • Index-Format
  • Zertifikate
  • Zugangsdaten der/des Service-Accounts
input {
  beats {
  # id => "icingabeat"
    port => "5044"
    ssl => "true"
    ssl_key => '/etc/logstash/logstash-oss-pkcs8.key'
  #  ssl_key_passphrase => 'deine_passphrase_hier_falls_vorhanden' 
    ssl_certificate => '/etc/logstash/logstash-oss.crt'
    ssl_certificate_authorities => ["/etc/logstash/graylog-ca-root.crt"]
  }
}

output {
  opensearch {
    hosts => ["https://10.3.0.171:9200"]
    index => "%{[@metadata][beat]}-%{[@metadata][version]}"
    cacert => '/etc/logstash/opensearch.crt'
    ssl => "true"
    ssl_certificate_verification => "true"
    user => "logstash_oss_service_opensearch_pass""
    password => "logstash_oss_service_opensearch_pass"
  }
}

Da du Logstash-OSS als Vermittler nutzt, muss die icingabeat.yml ebenso angepasst werden. Statt auf Graylog wird nun auf Logstash-OSS referenziert, alle anderen Einstellungen bleiben unverändert:

# Logstash OSS Output Variante

output.logstash:
  hosts: ["logstash.lan"]

  ssl.enable: true
  ssl.verification_mode: "certificate"
  ssl.certificate_authorities: ["/etc/icinga2/Icinga2OpenSearch/graylog-ca-root.crt"]
  ssl.certificate: "/etc/icinga2/Icinga2OpenSearch/Icinga2OpenSearch.crt"
  ssl.key: "/etc/icinga2/Icinga2OpenSearch/Icinga2OpenSearch.key"

Bedenke, dass deine Schlüssel und Zertifikate für Icingabeat & Logstash mit den passenden File-Berechtigungen ausgestattet sind (sie müssen lesbar sein) und deine weiteren Parameter fehlerfrei sind. Sollten dennoch Fehler auftreten oder du willst alles vor dem Einsatz überprüfen, kannst du sowohl Logstash-OSS als auch Icingabeat mit den folgenden Befehlen einfach debuggen:

tail -f /var/log/logstash/logstash-*.log

/usr/local/bin/icingabeat -c /etc/icingabeat/icingabeat.yml -e -d "*"

OpenSearch und Icinga erfolgreich verknüpft

An dieser Stelle hast du die Verknüpfung von OpenSearch und Icinga erfolgreich durchgeführt. Du kannst nun komplett frei und nach deinen Interessen und Bedürfnissen Felder für die Anzeige auswählen.
Um in den vollen Genuss von Open Source Customization zu kommen, kannst du dir Dashboards so anlegen, wie du sie brauchst. Ab diesem Punkt kannst du mit deinen Icinga-Daten mehr Data Science in OpenSearch durchführen. Mir hat es sehr viel Spaß gemacht, verschiedene Trends oder Anomalien zu erkennen und der Ursache auf den Grund zu gehen.

Falls dich mein Anwendungsbeispiel zur Verknüpfung von OpenSearch und Icinga inspiriert hat, diese Möglichkeit selbst zu testen, wünsche ich dir viel Spaß dabei! Solltest du bei deiner Konfiguration jedoch auf Probleme stoßen, freue ich mich auf eine Nachricht von dir.
Neben OpenSearch bieten meine Kolleg:innen und ich auch Consulting und Support für andere hier genannte und verwendete Tools, zum Beispiel Graylog, Elastic oder Icinga an.

Wir helfen dir gerne weiter!

Annotations in Grafana

von | Dez 8, 2017 | ,

Im Zuge der diesjährigen Open Source Monitoring Conference durfte ich mit Timeseries & Analysis with Graphite and Grafana einen der Workshops am Vortag der eigentlichen Konferenz halten. Wie man dem Titel unschwer entnehmen kann spielte dabei auch Grafana eine besondere Rolle. Grafana ist vielen als schöneres Dashboard für Graphite bekannt und unterstützt mit Elasticsearch, CloudWatch, InfluxDB, OpenTSDB, Prometheus, MySQL als auch Postgres in der aktuellen Version 4.6.2 allerdings noch eine ganze Reihe weiterer Datensourcen nativ. Zusätzlich können diese herkömmlichen Datensourcen auch noch durch Community Plugins ergänzt werden.
Ganz besonders hilfreich ist es wenn man die Informationen aus verschiedenen Datensourcen miteinander vereint. So lassen sich beispielsweise Zusammenhänge besser erkennen und Rückschlüsse auf bestimmte Ereignisse ziehen, die ansonsten vielleicht unentdeckt blieben. Metriken, die z.B. aus Graphite stammen, können bei Grafana nun durch sogenannte Annotations um zusätzliche Informationen angereichert werden. Neben Annotations aus den unterstützten Datensourcen können solche Events seit v4.6 übrigens auch direkt in der eigenen Grafana-Datenbank gespeichert werden, ob man das wiederum möchte ist allerdings eine ganz andere Frage…
Als Praxisbeispiel habe ich für meinen Workshop im Rahmen der OSMC überraschenderweise Icinga gewählt. Hier ist es möglich über die Icinga 2 API verschiedene Daten wie Checkergebnisse, Statusänderungen, Benachrichtigungen, Bestätigungen, Kommentare oder auch Downtimes mit dem Icingabeat direkt an Elasticsearch oder wenn man möchte alternativ auch an Logstash zu senden. Über das Annotation-Feature von Grafana lassen sich so die Benachrichtigungen aus Icinga über die Elasticsearch Datasource passend zu den jeweiligen Statusänderungen der Host- oder Serivcechecks einblenden:

Wer dazu mehr erfahren möchte dem kann ich unsere Graphite + Grafana Schulung ans Herz legen, neben vielen anderen Themen werden dort auch Grafana und Annotations in aller Ausführlichkeit behandelt. Und wer’s nicht schafft, für den findet sich vielleicht der ein oder andere passende Workshop im Rahmen unserer Konferenzen.

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.
Lies mehr von Markus und triff unser Team

Manage Elasticsearch, Kibana & icingabeat with Puppet

von | Mrz 30, 2017 | , ,

A while back I’ve already looked into the Elastic Stack 5 Beta release and the beats integration. Time flies and the stable release is here. Blerim announced the icingabeat 1.0.0 release last week, and so I was looking into a smooth integration into a Vagrant box here.
The provisioner uses Puppet, which Puppet modules could be used here? I’m always looking for actively maintained modules, best by upstream projects which share the joy of automated setups of their tools with their community.
 

Elastic and Kibana Puppet Module

The Elastic developers started writing their own Puppet module for Kibana 5.x. Previously I’ve used community modules such as puppet-kibana4 or puppet-kibana5. puppet-elasticsearch already supports 5.x for a while, that works like a charm.
Simple example for a low memory Elasticsearch setup:

class { 'elasticsearch':
  manage_repo  => true,
  repo_version => '5.x',
  java_install => false,
  jvm_options => [
    '-Xms256m',
    '-Xmx256m'
  ],
  require => Class['java']
} ->
elasticsearch::instance { 'elastic-es':
  config => {
    'cluster.name' => 'elastic',
    'network.host' => '127.0.0.1'
  }
}

Note: jvm_options was released in 5.0.0.
 

Default index pattern

If you do not define any default index pattern, Kibana greets you with a fancy message to do so (and I have to admit – i still need an Elastic Stack training to fully understand why). I wanted to automate that, so that Vagrant box users don’t need to care about it. There are several threads around which describe the deployment by sending a PUT request to the Elasticsearch backend.
I’m using a small script here which waits until Elasticsearch is started. If you don’t do that, the REST API calls will fail later on. This is also required for specifying index patterns and importing dashboards. A Puppet exec timeout won’t do the trick here, because we’ll have to loop and check again if the service is available.

$ cat/usr/local/bin/kibana-setup
#!/bin/bash
ES_URL="http://localhost:9200"
TIMEOUT=300
START=$(date +%s)
echo -e "Restart elasticsearch instance"
systemctl restart elasticsearch-elastic-es
echo -e "Checking whether Elasticsearch is listening at $ES_URL"
until $(curl --output /dev/null --silent $ES_URL); do
  NOW=$(date +%s)
  REAL_TIMEOUT=$(( START + TIMEOUT ))
  if [[ "$NOW" -gt "$REAL_TIMEOUT" ]]; then
    echo "Cannot reach Elasticsearch at $ES_URL. Timeout reached."
    exit 1
  fi
  printf '.'
  sleep 1
done

If you would want to specify the default index pattern i.e. for an installed filebeat service, you could something like this:

ES_INDEX_URL="$ES_URL/.kibana/index-pattern/filebeat"
ES_DEFAULT_INDEX_URL="$ES_URL/.kibana/config/5.2.2" #hardcoded program version
curl -XPUT $ES_INDEX_URL -d '{ "title":"filebeat", "timeFieldName":"@timestamp" }'
curl -XPUT $ES_DEFAULT_INDEX_URL -d '{ "defaultIndex":"filebeat" }'

One problem arises: The configuration is stored by Kibana program version. There is no symlink like ‚latest‘, but you’ll need to specify ‚.kibana/config/5.2.2‘ to make it work. There is a certain requirement for pinning the Kibana version, or finding a programatic way to automatically determine the version.
 

Kibana Version in Puppet

Fortunately the Puppet module allows for specifying a version. Turns out, the class validation doesn’t support package revision known from rpm („5.2.2-1“). Open source is awesome – you manage to patch it, apply tests and after review your contributed patch gets merged upstream.
Example for Kibana with a pinned package version:

$kibanaVersion = '5.2.2'
class { 'kibana':
  ensure => "$kibanaVersion-1",
  config => {
    'server.port' => 5601,
    'server.host' => '0.0.0.0',
    'kibana.index' => '.kibana',
    'kibana.defaultAppId' => 'discover',
    'logging.silent'               => false,
    'logging.quiet'                => false,
    'logging.verbose'              => false,
    'logging.events'               => "{ log: ['info', 'warning', 'error', 'fatal'], response: '*', error: '*' }",
    'elasticsearch.requestTimeout' => 500000,
  },
  require => Class['java']
}
->
file { 'kibana-setup':
  name => '/usr/local/bin/kibana-setup',
  owner => root,
  group => root,
  mode => '0755',
  source => "puppet:////vagrant/files/usr/local/bin/kibana-setup",
}
->
exec { 'finish-kibana-setup':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "/usr/local/bin/kibana-setup",
  timeout => 3600
}

 

Icingabeat integration

That’s fairly easy, just install the rpm and put a slightly modified icingabeat.yml there.

$icingabeatVersion = '1.0.0'
yum::install { 'icingabeat':
  ensure => present,
  source => "https://github.com/Icinga/icingabeat/releases/download/v$icingabeatVersion/icingabeat-$icingabeatVersion-x86_64.rpm"
}->
file { '/etc/icingabeat/icingabeat.yml':
  source    => 'puppet:////vagrant/files/etc/icingabeat/icingabeat.yml',
}->
service { 'icingabeat':
  ensure => running
}

I’ve also found the puppet-archive module from Voxpupuli which allows to download and extract the required Kibana dashboards from icingabeat. The import then requires that Elasticsearch is up and running (referencing the kibana setup script again). You’ll notice the reference to the pinned Kibana version for setting the default index pattern via exec resource.

# https://github.com/icinga/icingabeat#dashboards
archive { '/tmp/icingabeat-dashboards.zip':
  ensure => present,
  extract => true,
  extract_path => '/tmp',
  source => "https://github.com/Icinga/icingabeat/releases/download/v$icingabeatVersion/icingabeat-dashboards-$icingabeatVersion.zip",
  checksum => 'b6de2adf2f10b77bd4e7f9a7fab36b44ed92fa03',
  checksum_type => 'sha1',
  creates => "/tmp/icingabeat-dashboards-$icingabeatVersion",
  cleanup => true,
  require => Package['unzip']
}->
exec { 'icingabeat-kibana-dashboards':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "/usr/share/icingabeat/scripts/import_dashboards -dir /tmp/icingabeat-dashboards-$icingabeatVersion -es http://127.0.0.1:9200",
  require => Exec['finish-kibana-setup']
}->
exec { 'icingabeat-kibana-default-index-pattern':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "curl -XPUT http://127.0.0.1:9200/.kibana/config/$kibanaVersion -d '{ \"defaultIndex\":\"icingabeat-*\" }'",
}

The Puppet code is the first working draft, I plan to refactor the upstream code. Look how fancy 🙂

Conclusion

Managing your Elastic Stack setup with Puppet really has become a breeze. I haven’t tackled the many plugins and dashboards available, there’s so much more to explore. Once you’ve integrated icingabeat into your devops stack, how would you build your own dashboards to correlate operations maintenance with Icinga alerts? 🙂
If you’re interested in learning more about Elastic and the awesome Beats integrations, make sure to join OSDC 2017. Monica Sarbu joins us with her talk on „Collecting the right data to monitor your infrastructure“.
PS: Test-drive the integration, finished today 🙂

Test-drive #icingabeat inside the #icinga vagrant box 'icinga2x-elastic' 🙂 https://t.co/DJuThyy6uu #elastic pic.twitter.com/qH1Kt8NB1l

— Icinga (@icinga) March 30, 2017


 
 

Timelion, eine Kibana Erweiterung

von | Mrz 16, 2017 | ,

timelion logoIch habe mich in der Vergangenheit mit verschiedenen Tools beschäftigt die Performancedaten bzw. Metriken speichern und darstellen können. Aktuell beschäftige ich mich näher mit Timelion aus dem Hause Elastic und das hat zwei Gründe: Zum einen wurde mir die Kibana Erweiterung auf der ElasticON letzte Woche wieder schmackhaft gemacht, nachdem ich es eigentlich schon zur Seite gelegt hatte. Zum anderen erweist sich Timelion als sehr nützlich in Verbindung mit meinem Icingabeat. Ein Beat der Daten aus Icinga 2 zur weiteren Verarbeitung entweder an Logstash oder direkt an Elasticsearch schicken kann.
Timelion, übrigens Timeline ausgesprochen, ist eine Erweiterung für das bereits bekannte Kibana Webinterface. Es ist dazu gedacht Daten aus einem Elasticsearch Cluster visuell darzustellen. Anders als die bisherigen Visualisierugsmethoden von Kibana wird bei Timelion aber nichts zusammen geklickt und gefiltert. Stattdessen müssen die eingebauten Funktionen direkt aufgerufen und mit Parametern gefüllt werden. Klingt erst mal kompliziert, nach etwas Übung geht das aber schneller als alles mit der Maus zu bedienen.
Ein Beispiel: Um die Anzahl der Dokumente in Elasticsearch zu zählen, wird die Funktion es() verwendet. Sie erwartet als Parameter eine Query. Mit es(*) werden sämtliche Dokumente gezählt, die Query dabei ist *
timelion default query
Als Query kann alles eingegeben werden was das normale Kibana Interface auch versteht, also Apache Lucene Syntax. Zum Beispiel kann ich die Anzahl der Checkresults darstellen, die mein Icinga gerade ausführt: .es(type:icingabeat.event.checkresult)timelion icingabeat checkresults
Einfach Dokumente zu zählen reicht aber oft nicht aus, insbesondere im Hinblick auf Metriken. Wichtig an dieser Stelle ist der eigentliche Wert von einem Eintrag, nicht die Anzahl der Einträge. Die es() Funktion kann mit ihrem metric Parameter genau das tun. Man muss sich lediglich entscheiden mit welcher Methode man die Daten aggregieren möchte. Auch wenn die Daten nicht in einem definierten Zeitrahmen in Elasticsearch gespeichert werden, müssen sie spätestens bei der Darstellung irgendwie zusammengefasst werden um einen gleichmäßigen Graphen anzeigen zu können. Timelion versucht den Abstand in dem Daten aggregiert werden automatisch zu ermitteln, meistens ergibt das „Sekündlich“. Ob das der richtige Intervall ist, hängt davon ab wie schnell die Daten rein fließen. Wie viele MySQL Queries Icinga 2 innerhalb der letzten Minute ausgeführt hat, lässt sich zum Beispiel folgendermaßen ermitteln:
.es(metric=avg:perfdata.idomysqlconnection_ido-mysql_queries_1min.value).label("1 min").title("MySQL Queries").color(green)timelion icingabeat mysql
Hier sieht man auch das sich mehrere Funkionen aneinander ketten lassen. Zum Beispiel zum setzen von Titel oder Farbe. Timelion bringt eine ganze Fülle an Funktionen mit die die Darstellung der Daten beeinflussen. Ich will nicht alle aufzählen, weitere Beispiele aber sind:

  • bars(): Ein Barchart anstelle einer Linie
  • movingaverage(): Berechnet den gleitenden Durchschnitt
  • min(), max() und sum(): Erklärt sich von selbst

Es können auch mehrere Linien innerhalb eines Graphen angezeigt werden, dazu wird die Funktion einfach mehrfach aufgerufen. Hier ein vergleich der Ausführungszeiten von Icinga Plugins:
.es(metric=avg:status.avg_execution_time), .es(metric=avg:status.max_execution_time), .es(metric=avg:status.min_execution_time) timelion icingabeat execution time
Insgesamt ist das nur ein kleiner Teil dessen was Timelion kann. Auch wenn die Bedienung etwas gewöhnungsbedürftig ist, so kommt man nach etwas Übung schnell rein. Die Graphen die erstellt werden können entweder als eigenständige Dashboards abgespeichert werden oder als einzelne Visualisierungen. Werden die Graphen einzeln abgespeichert können Sie zu Kibana Dashboards hinzugefügt werden. Dadurch ergibt sich eine gute Ergänzung zu den normalen Visualisierungen.

Blerim Sheqa
Blerim Sheqa
COO
Blerim ist seit 2013 bei NETWAYS und seitdem schon viel in der Firma rum gekommen. Neben dem Support und diversen internen Projekten hat er auch im Team Infrastruktur tatkräftig mitgewirkt. Hin und wieder lässt er sich auch den ein oder anderen Consulting Termin nicht entgehen. Inzwischen ist Blerim als COO für Icinga tätig und kümmert sich dort um die organisatorische Leitung.
Lies mehr von Blerim und triff unser Team

Trainings

Web Services

Events