Manage Elasticsearch, Kibana & icingabeat with Puppet

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 🙂

 

 

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉

Speed up your work with Alfred 3 Workflows

Make things easy at work. Save time for the important bits. That’s something everyone talks about but there’s no real “that’s mine” guide out there. A while ago I decided to try something new – I switched my entire work place from Linux to macOS. Working with colleagues using their tools on a daily basis made me ask several times – how does that work? How could I use that workflow? Can you show me how the trackpad works? Swiping with two fingers going back in browser history?

Turns out there are a couple of tools which help me save time day by day. Some of them are not part of macOS themselves and thus require you to buy them. If a tool really saves my life (and time) I am willing to do so.

One of these tools is Alfred. Generally speaking Alfred can be used to search your mac, quickly open files and applications, use hotkeys for actions. Things you can achieve with Apple’s Spotlight already. The coolest thing is the additional Alfred Powerpack. This allows you to run shell commands on your macOS. You can extend the functionality by adding custom Alfred workflows. That way you can manage your chat clients, music apps, search the mail application and so on.

Locking your screen requires a somewhat quirky key combination or moving the cursor to hot corners. Both of which I don’t like and therefore just type in “lock” into the Alfred command popup. These days locking my screen is just “Cmd + Space, l, Enter” because Alfred remembers the history. Another tip from Bernd – type “empty” and automatically empty your trash bin.

We’re using Jabber at work, and I’m a heavy Adium user. When I want to chat with a co-worker, I just open Alfred and start typing “im <name>” and a new Adium chat tab opens. This is all thanks to this workflow. If you’re sending an email over the ocean, what time is it? Use this workflow to avoid googling. Another cool tip – if you are for instance converting inches to the metric system, a workflow called units comes in handy.

Yet another workflow is for Github repos which really helps after the migration for all Icinga repositories. Just type in “gh icinga2” and open the corresponding Github repository in your browser. Search for repos or users or open a new issue in a specific repository.

Alfred saves me a lot of time already. Keep focus and develop faster 🙂

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉

It’s magic: git squash

training_gitA common technique for feature development with Git is to start with a new feature branch. You’ll continue to add and commit changes into that branch and at some point in time you want to merge the many work-in-progress commits into one. The Git terminology references that as “squash“.

Another common best practice is to use the Git forking model you are probably familiar with on GitHub. You’ll fork your own repository, start adding a new Icinga 2 ITL CheckCommand definition, later on you are adding the missing documentation bits. Then you’ll send a pull request to the upstream repository. Developers will review your changes and probably ask you to rebase and squash your commits into one commit.

Let’s just try that.

michi@mbmif ~/coding/icinga/icinga2 (master) $ git checkout -b feature/itl-checkcommand-13079

<change, add, commit>

michi@mbmif ~/coding/icinga/icinga2 (feature/itl-checkcommand-13079) $ git l
* ed6a68f- (HEAD -> feature/itl-checkcommand-13079) Docs: Fix phrasing (5 minutes ago) 
* ce90e16- Add documentation for logfiles (5 minutes ago) 
* 5a31d9e- Add CheckCommand "logfiles" (6 minutes ago) 
* dc29924- (origin/master, origin/HEAD, master) Deprecate the client 'bottom up' mode w/ node update-config (2 hours ago) 
...

Now I want to merge that feature branch back to the master. Our development guidelines require me to squash the three commits first.

Generally speaking you can use the interactive “git rebase -i” command here. It requires an additional parameter about the commits we will be editing, counting from HEAD back in the history. In my case I want to edit HEAD minus 3 commits.

The interactive mode will open the configured editor, vim in my case.

michi@mbmif ~/coding/icinga/icinga2 (feature/itl-checkcommand-13079) $ git rebase -i HEAD~3

pick 5a31d9e Add CheckCommand "logfiles"
pick ce90e16 Add documentation for logfiles
pick ed6a68f Docs: Fix phrasing

# Rebase dc29924..ed6a68f onto dc29924 (3 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

Git informs us about the possible options here. I could just use “edit” which iterates over the commits, stops for amending the commit message and/or the commit changes itself.

I want to squash the commits. This requires the base commit (usually the first one) to stay on “pick” while the others are changed to “squash”.

pick 5a31d9e Add CheckCommand "logfiles"
squash ce90e16 Add documentation for logfiles
squash ed6a68f Docs: Fix phrasing

This will squash the commits one by one onto the last picked one. Save the changes and continue.

# This is a combination of 3 commits.
# This is the 1st commit message:
Add CheckCommand "logfiles"

# This is the commit message #2:

Add documentation for logfiles

# This is the commit message #3:

Docs: Fix phrasing

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:      Wed Nov 23 17:19:55 2016 +0100
#
# interactive rebase in progress; onto dc29924
# Last commands done (3 commands done):
#    squash ce90e16 Add documentation for logfiles
#    squash ed6a68f Docs: Fix phrasing
# No commands remaining.
# You are currently editing a commit while rebasing branch 'feature/itl-checkcommand-13079' on 'dc29924'.
#
# Changes to be committed:
#       modified:   doc/10-icinga-template-library.md
#       modified:   itl/plugins-contrib.d/logmanagement.conf

Edit the commit message (comments starting with “#” will be ignored) and make it a good one (also something you learn in the training session ;)).

Add CheckCommand "logfiles"

refs #13079

Save and continue.

[detached HEAD f1445eb] Add CheckCommand "logfiles"
 Date: Wed Nov 23 17:19:55 2016 +0100
 3 files changed, 8 insertions(+)
Successfully rebased and updated refs/heads/feature/itl-checkcommand-13079.

Verify the changed commit history.

michi@mbmif ~/coding/icinga/icinga2 (feature/itl-checkcommand-13079) $ git l
* f1445eb- (HEAD -> feature/itl-checkcommand-13079) Add CheckCommand "logfiles" (3 minutes ago) 
* dc29924- (origin/master, origin/HEAD, master) Deprecate the client 'bottom up' mode w/ node update-config (2 hours ago) 

When you are updating your remote repository you’ll need to override the remote history with the local history. Be careful when using “-f”!

michi@mbmif ~/coding/icinga/icinga2 (feature/itl-checkcommand-13079) $ git push -f origin feature/itl-checkcommand-13079

Voilà – our Git commit history is now rebased and squashed.

This example works in a similar fashion with a forked repository on GitHub, thus requiring you to update your PR then.

Hint: I’m using Git shell integration as well Git aliases here (“git l”). We’ll dive into these topics in our Git training too 🙂

$ git config --list | grep 'alias.l'
alias.l=log --graph --pretty=format:'%Cred%h%Creset-%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative --
Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉

NETWAYS on tour: PuppetConf in San Diego

img_3844Heading to the US and PuppetConf the 5th year – this time, the NETWAYS folks moved to sunny San Diego. We had the annual Icinga Camp on Tuesday in the same venue as PuppetConf in the beautiful Town & Country Resort.

Bernd organised the entire trip – from flights to our lovely AirBnB, even going shopping (aka raiding) the local Walmart Neighbourhood market, cooking a meal for the hungry crowd. Last but not least – anyone flying over the US was offered the possibility to extend the trip with his/her vacation plans. Bernd, Julian, Lennart and Florian arrived earlier and so the other folks (Tom, Eric, Dirk, Blerim, Michael) joined them on Monday afternoon.


img_3792
Guess what happened after getting onto the rental cars?  The first visit at the In-N-Out burger right around the corner at LAX. This round was on Bernd too, thanks a lot man! We agreed on visiting the AirBnb first, then looking for some food. Spaghetti and tasty salad accompanied with the obligatory G&T. Some of us were just chilling after an 11 hours flight, others still preparing for their Icinga Camp talks.

The next day we arrived at the PuppetConf venue – their brand was nearly everywhere although the room for Icinga Camp was a bit tad hard to find. Cosy warm and sunny weather and a full day of #monitoringlove. I’ll continue with details over at the Icinga blog soon.

Wednesday was sort of a free day for those attending PuppetConf. I went for Sea World with Lennart and Dirk, the others joined the beach. Unfortunately Bernd had to leave to Nuremberg so I was surprised with luckily attending PuppetConf. I’ve been learning and improving my Puppet skills in the past year quite a lot, also helped with our newly designed Puppet Open Source training sessions. Glad I could join this opportunity.

Therefore I’d like to share my experience with this year, also compared to previous events. To start with PuppetConf offered a delicious breakfast again on the first day. Bonus: Weather was hot and sunny, what a beautiful start into the day. The rooms for the sessions were loosely connected inside this building but still sometimes confusing. Everyone was friendly and in comparison to last year, you were not “marketing scanned” by Puppet folks everywhere.

img_3941Nigel Kersten kicked off PuppetConf and also announced the date next year in SFO, 10.-12. October 2017. Then former CEO and creator of Puppet, Luke Kanies, started with his keynote. From container numbers (starting/stopping 1.58 * 10^10 containers over 3 years is a hell of a number) to open source commitment heard from Puppet CEO Sanjay Mirchandani. In case you haven’t been following closely, Puppet Enterprise got certain exclusive features not available in the community version. When it comes to server metrics available PE only I could imagine that community members are not amused (I wasn’t). Time for changes.

I decided to join the Github talk since it is always interesting to get insights into their operations management. Nearly everything is managed with HuBot. GitHub really is living the #chatops dream. Kevin Paulisse also talked about Puppet as culture, dealing with new contributors and then announced a new open-source tool: octocat-diff. This allows to compare Puppet catalogs and avoid deploying unwanted changes in production.

Everyone was really crazy about using Puppet to create and update Docker images. And so was David Lutterkort decoupling the challenges with containers and their management with Kubernetes into a fascinating talk. Note: That specific nginx demo was used everywhere 😉

“Making Puppet clean up its own mess” sounded provoking and so we went for it. You might be asking – which mess? Take for example changed configuration file locations generating collisions. “Write code to cleanup code” or “Use Ansible to cleanup after Puppet?”. Sounded funny but still can be a common approach instead of waiting for the Puppet agent’s 30 minute update interval.

img_4005On Thursday evening the social event was happening from 6 to 8 pm. Hey, a NETWAYS party isn’t even started yet at that time 😀 And Jenny is waiting later at night, OSMC is near! From what the others told me, the location and food was great. Blerim and I decided to raid Walmart – again – and go for some barbecue together with the other folks not attending the conference. Florian took care of grilling tasty meat, and of course the drinks later on when the PuppetConf party people joined us again.

You would guess – no-one attends the keynotes on the second day. We made it, and listened to interesting insights into Microsoft’s plans on Azure with containers, Nano server 2016 setup plans and of course Powershell deployment strategies. Lots of things happening here, definitely worth keep watching.

During the keynotes the internet broke. Ok, actually Twitter was down so I couldn’t tweet about #puppetconf. The DNS DDOS even affected Puppet itself – livestream and forge were unreachable. Back in Germany everyone was sleeping but I guess some participants had to deal with their notification email stream rather than listening to sessions 😉

Martin Alfke gave a training session…ehm…talk about moving exec into types and providers. And everyone in the audience could follow and left the session both entertained and well trained. Since Blerim and I were pretty much into containers, management and also monitoring, we went for Gareth Rushgrove and him doing lots of demos showcasing Puppet and Docker. Did I mention the nginx demo already? 😉

img_4043We were a bit undecided where to head for the last talk but then we saw Ben’s session “How you actually get hacked” differing from the usual Puppet suspects in topics. Oh boy, such sarcasm combined with actual matters of security. Ben, if you really lost your job, join NETWAYS. Will be fun 🙂

There were a couple of sessions talking about the transition from Puppet 3 to 4. Though it did not really feel that people are aware that Puppet 3 will reach EOL by the end of 2016. Most recently an interesting discussion on twitter started.

Compared to last year, PuppetConf including the session topics, venue and friendlyness nailed it this year. I’m looking forward to San Francisco next year – probably the best location to attract even more IT people. In case you’ve missed PuppetConf this year – their event archive including video recordings is already online.

We left San Diego on Friday evening spending two more days in lovely Los Angeles. Lennart, Dirk and I went for LEGOLand California, colleagues enjoined Venice beach. And then we got our rental car for our road trip to Grand Canyon and more. But that’s a different story … join the NETWAYS tour!

Enjoy some pictures we’ve taken during our NETWAYS “school trip” 🙂

 

 

 

 

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉

Diving into Elastic Stack 5.0.0-beta1 and Elastic Beats

logo2_elastic_150x75I’m always trying to look into new devops tools and how they fit best with Icinga 2 as a monitoring solution. Often demanded is an integration with Elastic Stack and Elastic Beats with Icinga 2. Gathering metrics and events, correlated to additional input sources analysing a greater outage and much more.

Last week the first 5.0.0 beta1 release hit my channels and I thought I’d give it a try. The installation is pretty straight forward using packages. Note: This is my first time installing Elastic Stack, still have little knowledge from colleague hero stories and the OSDC talk by Monica Sarbu and earlier conferences.

(more…)

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉