Icinga 2 – Monitoring automatisiert mit Puppet Teil 14: Profile Part VI

This entry is part 14 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Nachdem letzte Woche der Nginx verwendet wurde, wenden wir uns im nun vorerst letzten Teil der Konfiguration des Apaches als Webserver zur Auslieferung von Icinga Web 2 zu.
Der Apache kommt unter Debian als abhängig zu installierendes Paket von icingaweb2 mit und wird ensprechend konfiguriert. Damit dies unsere Anforderung an den Apache nicht wieder überschreibt, sorgen wir dafür, dass das Paket icingaweb2 vor der Klasse apache installiert wird. Hierfür müssen wir das Managment des Pakets durch die Klasse icingaweb2 unterbinden.
Damit das Icinga-Web-2-Modul für seine Konfigurationsdateien den korrekten Benutzer verwenden kann, ziehen wir diesen nach der Abarbeitung der Klasse apache aus dessen Modul.

 
  
if $web_server == 'nginx' {
     [...]
  } else {
    #
    # Apache
    #
    $manage_package = false
    Package['icingaweb2']
      -> Class['apache']
    package { 'icingaweb2':
      ensure => installed,
    }
    class { '::apache':
      default_mods => false,
      default_vhost =>false,
      mpm_module => 'worker',
    }
    apache::listen { '80': }
    $web_conf_user = $::apache::user
    include ::apache::mod::alias
    include ::apache::mod::status
    include ::apache::mod::dir
    include ::apache::mod::env
    include ::apache::mod::rewrite
    include ::apache::mod::proxy
    include ::apache::mod::proxy_fcgi
    apache::custom_config { 'icingaweb2':
      ensure       => present,
      source        => 'puppet:///modules/icingaweb2/examples/apache2/for-mod_proxy_fcgi.conf',
      verify_config => false,
      priority      => false,
    }
  }
  [...]

Der Apache wird von uns komplett mit allen Modulen für Icinga Web 2 verwaltet, da sich die Defaults für RedHat und Debian zu sehr unterscheiden. Auch hier, wie bei Nginx, entfernen wird alle Konfiguration sonstiger auszuliefernder Webseiten und benutzen die vom Icinga-Web-2-Modul zur Verfügung gestellt Beispielkonfiguration.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 13: Profile Part V

This entry is part 13 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Im heutigen Teil dieser Reihe, fügen wir den ausstehenden Code zur Konfiguration von Nginx als Webserver für Icinga Web 2 hinzu. Neben den benötigten Nginx-Ressources, vor allem der Umleitung auf den PHP-FPM, ist darauf zu achten, dass Nginx vor der Klasse icingaweb2 und damit vor dem Paket icingaweb2 abzuarbeiten ist. Wird dies nich beachtet installiert das icingaweb2-Paket automatisch den Apache als Abhängigkeit und man hätte zwei Webserver bei sich auf dem Icinga-2-Server.
Damit das Icinga-Web-2-Modul für seine Konfigurationsdateien den korrekten Benutzer verwenden kann, ziehen wir diesen nach der Abarbeitung der Klasse nginx aus dessen Modul.

  [...]
 if $web_server == 'nginx' {
    #
    # Nginx
    #
    $manage_package = true
    Class['nginx']
      -> Class['icingaweb2']
    class { '::nginx':
      manage_repo  => false,
      server_purge => true,
      confd_purge  => true,
    }
    $web_conf_user = $::nginx::daemon_user
    nginx::resource::server { 'icingaweb2':
      server_name          => [ 'localhost' ],
      ssl                  => false,
      index_files          => [],
      use_default_location => false,
    }
    nginx::resource::location { 'icingaweb2':
      location       => '~ ^/icingaweb2(.+)?',
      location_alias => '/usr/share/icingaweb2/public',
      try_files      => ['$1', '$uri', '$uri/', '/icingaweb2/index.php$is_args$args'],
      index_files    => ['index.php'],
      server         => 'icingaweb2',
      ssl            => false,
    }
    nginx::resource::location { 'icingaweb2_index':
      location       => '~ ^/icingaweb2/index\.php(.*)$',
      server         => 'icingaweb2',
      ssl            => false,
      index_files    => [],
      fastcgi        => '127.0.0.1:9000',
      fastcgi_index  => 'index.php',
      fastcgi_param  => {
        'SCRIPT_FILENAME'         => '/usr/share/icingaweb2/public/index.php',
        'ICINGAWEB_CONFIGDIR' => '/etc/icingaweb2',
        'REMOTE_USER'         => '$remote_user',
      },
    }
  } else {
  [...]

Beim Nginx selbst werden alle von der Standard-Installation kommenden virtuellen Hosts (server_purge => true) und sonstigen Konfigurationsdateien entfernt. Der Artikel der kommenden Woche schließt diesen Abschnitt über eine komplexere Konfiguration vorerst ab. Dort wird dann der noch fehlende Code präsentiert, der einen Apache-Webserver zum Ausliefern von Icinga Web 2 verwendet.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

OpenStack Summit Berlin 2018

Vom 13. bis zum 15. November 2018 fand in Berlin der OpenStack Summit statt, der etwa 2700 Interessierte aus aller Welt in die deutsche Hauptstadt lockte. Entsprechend der Releasezyklen des OpenStack Softwareprojekts, wird diese Veranstaltung alle sechs Monate an wechselnden Orten rund um den Globus abgehalten. Der nächste Summit steigt Ende April 2019 in Denver – dann jedoch unter dem neuen Namen „Open Infrastructure Summit“, was den universellen Anspruch von OpenStack deutlich macht.
Dass mit Berlin zum ersten mal ein Austragungsort in Deutschland gewählt wurde, liegt auch an der großen OpenStack Nutzergemeinde hierzulande. Gemessen an den Nutzerzahlen ist Deutschland laut User Survey eine der Top 3 „OpenStack-Nationen“. Als große Anwender wären unter anderem die Deutsche Telekom, BMW und VW zu nennen, die allesamt auf der Konferenz vertreten waren.
Auch bei Netways ist Openstack seit einiger Zeit produktiv im Einsatz. Folgerichtig ließ sich das Team von Netways Web Services dieses Event „vor der eigenen Haustür“ nicht entgehen. Auf dem Programm standen mehr als hundert Workshops und Vorträge auf dem Gelände des CityCube Berlin.
Besonders interessant war eine Keynote über den Einsatz von OpenStack im Bereich Network Functions Virtualization (NFV). AT&T eröffnete dem Publikum, dass OpenStack eine zentrale Rolle bei der Bereitstellung der Infrastruktur für den Mobilfunkstandard 5G spielt. Das Software-definierte Kernnetz läuft auf einer Openstack Undercloud, die komplett containerisiert ist und mithilfe von Airship verwaltet wird. Zur Demonstration der Verlässlichkeit des Systems startete der Referent von AT&T ein Videotelefonat mit einem Kollegen in den USA, der über ein 5G Testnetzwerk verbunden war. Die Virtuelle Maschine, auf der diese Session lief, wurde daraufhin heruntergefahren. Innerhalb eines Augenblicks übernahm eine andere VM diese Session, so dass das Videotelefonat ohne eine besondere Beeinträchtigung aufrecht erhalten werden konnte.
Ein weiterer eindrucksvoller Vortrag hatte den Anwendungsfall AI/Machine Learning zum Thema. Mit dem PCI Passthrough Feature von Nova werden PCI Geräte wie GPUs und FPGAs als Hardwareressourcen über die Cloud verfügbar gemacht, die dann vom Nutzer per REST API dynamisch angefordert werden können. So können aufwändige Machine Learning Anwendungen über die Cloud hardwarebeschleunigt werden. Die Spracherkennung und Übersetzung eines kurzen Videoausschnitts erfolgte in der Demo dank GPU-Hardwarebeschleunigung doppelt so schnell wie bei der alleinigen Nutzung von CPU. Im zweiten Beispiel verwendete man FPGAs zur Beschleunigung von Gesichtserkennungssoftware. Wichtige Funktionen hierzu liefert Cyborg, womit FPGAs in der Cloud verwaltet und programmiert werden können.
Wer es nicht zum Summit nach Berlin geschafft hat, kann sich hier Mitschnitte der Vorträge anschauen.

Dominik Seidel
Dominik Seidel
Junior Systems Engineer

Dominik ist seit Kurzem Azubi in der Abteilung Managed Services. Er interessiert sich für Geschichte, die Natur, und hört und macht gerne Musik. Wenn er nicht arbeitet, spielt er Gitarre oder wandert durch heimische Wälder.

New Request Tracker Extensions: Search Result Highlights, Quick Assign & User Overview

We use Request Tracker on a daily basis, and have written many extensions for our own workflows and visualizations. Lately we’ve been helping a customer to migrate from OTRS to RT running in NWS, and learned about new ways to improve our workflows.
 

Highlight Search Results on Conditions

When you own a ticket, but someone else updated the ticket with a comment/reply, you want to immediately see this. Our extension makes this possible with either a background color or an additional icon (or both).
You can also limit this to replies/comments from customers, where the last update wasn’t performed by users in a specific group. This allows to immediately see support or sales tickets which need to be worked on in the dashboards.
Another use case is to highlight search result rows when a custom field matches a specified value. If you’re setting tickets for example, you can visually see the difference between a “bought ticket” and “paid ticket” state.
While developing the extension, I’ve also fixed an upstream RT bug which has been merged for future releases. There’s even more possibilities, as we’ve recognised that one of the BestPractical/RT developers forked our extension already 🙂

 

Quick Assign People to Tickets

By default, one needs to edit the “People” tab to assign a ticket to a privileged user, or modify adminCC and the requestor. This takes far too long and as such, our own NETWAYS extension improved this with drop-downs and action buttons. We have now open-sourced this feature set into a new extension on GitHub: rt-extension-quickassign.

 

Show Ticket Count per User and Status

This extension was released a while ago, and we’ve fixed a bug with empty sets in there. In addition to that, we’ve added a new configuration option which allows to list specific groups and their members, and not only privileged users. This comes in handy to only show the NETWAYS members but not any root or meta accounts. Read more on GitHub.
 
Do you need more customizations for Request Tracker, or want to run RT in a managed cloud environment? Just get in touch 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler 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 und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Icinga 2 – Monitoring automatisiert mit Puppet Teil 11: Profile Part III

This entry is part 11 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Die heutige Fortsetzung dieser Serie befasst sich mit dem Management einer PHP-Umgebung für daen Betrieb eines Icinga Web 2 auf dem Icinga-Server. Icinga Web 2 benötigt in aktuellen Versionen mindestens ein PHP in der Version 5.6, kommen dann noch Module hinzu, wird damit einhergehend ein PHP 7 oder neuer vorausgesetzt.
Server mit Debian Stretch bekommen ein aktuelles PHP aus ihren eigenen Repositories, bei RedHat 7 muss auf das SCL (Softwarer Collection Linux) Repository zurückgegriffen werden.

class profile::icinga2::server(
  ...
) {
  case $::osfamily {
    'redhat': {
      require ::profile::repo::epel
      require ::profile::repo::icinga
      require ::profile::repo::scl
      $manage_package = false
      $manage_repo    = false
      $php_globals    = {
        php_version => 'rh-php71',
        rhscl_mode  => 'rhscl',
      }
      $php_extensions = { mbstring => {}, json => {}, ldap => {}, gd => {}, xml => {}, intl => {}, mysqlnd => {}, pgsql => {}, },
      ...
    }
    'debian': {
      $manage_package = true
      $manage_repo    = true
      $php_globals    = {}
      $php_extensions = { mbstring => {}, json => {}, ldap => {}, gd => {}, xml => {}, intl => {}, mysql => {}, pgsql => {}, },
      ...
    }
    default: {
      fail("'Your operatingsystem ${::operatingsystem} is not supported.'")
    }
  }
  ...

PHP selbst lässt sich mit dem Puppet-Module puppet/php des Projektes Vox Pubuli konfigurieren. Hierbei werden über die Klasse php::globals Einstellungen getätigt, welches PHP, aus welchen Quellen benutzt werden soll. Im Anschluss wir über die Hauptklasse php das Management auf das Betreiben eines FPM (FastCGI Process Manager) eingeschränkt. Dieser lauscht standardmäßig auf TCP-Port 9000 ausschließlich auf localhost.
Neben einem erhöhen des Speicherlimits und dem Setzen der Zeitzone, werden auch die von Icinga Web vorausgesetzten PHP-Extensions aktiviert.

...
#
# PHP
#
class { '::php::globals':
  * => $php_globals,
}
class { '::php':
  ensure        => installed,
  manage_repos  => false,
  apache_config => false,
  fpm           => true,
  extensions    => $php_extensions,
  settings      => {
    'PHP/memory_limit'   => '128M',
    'Date/date.timezone' => 'Europe/Berlin',
  },
  dev           => false,
  composer      => false,
  pear          => false,
  phpunit       => false,
  require       => Class['::php::globals'],
}

Bei der Klasse profile::repo::scl beschränken wir uns im folgenden Beispiel auf CentOS basierte Systeme, wie es auf RHEL einzubinden ist muss aus der Installations-Dokumentation abgeleitet werden.

class profile::repo::scl {
  case $::operatingsystem {
    'centos': {
      package { 'centos-release-scl':
        ensure => installed,
      }
    } # CentOS
    default: {
      fail("'Your plattform ${::operatingsystem} is not supported.'")
    }
  } # case
}
Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Tracing PHP memory usage with Xdebug


In addition to Xdebug’s great profiling and debugging features it also supports tracing memory usage. This helps to find functions which consume a lot of memory or to identify memory leaks. The following options enable tracing right away:

xdebug.auto_trace=1
xdebug.trace_format=1

Traces are written to /tmp by default. You may change this via the xdebug.trace_output_dir setting. With xdebug.trace_format=1 you tell Xdebug to write traces in an easy-to-parse tab separated format. The logged information includes the start and end times of function calls as well as the amount of used memory when entering and leaving the function. The last two numbers help to figure out which functions increase the memory usage a lot. Luckily you don’t have to interpret the traces yourself but use a script for that.
The script parses the trace files and aggregates the numbers by function name. It accepts a few different keys to sort the output: time-own, memory-own, time-inclusive, memory-inclusive and calls. You can also configure the number of elements to show:

php tracefile-analyser.php trace.662975268.xt memory-own 10
Showing the 10 most costly calls sorted by 'memory-own'.
                                                          Inclusive        Own
function                                          #calls  time     memory  time     memory
------------------------------------------------------------------------------------------
Icinga\Application\ClassLoader->loadClass             90  0.9151  2638176  0.0814  1262312
Zend_Loader::loadFile                                 17  0.1496  1183528  0.0345   882928
PDOStatement->execute                                 22  0.0102   395368  0.0102   395368
require                                               85  0.6066  1548112  0.0157   338512
require_once                                          22  0.0506   566296  0.0107   149128
Icinga\Application\ClassLoader->requireZendAutoloader  1  0.0045   154360  0.0023   120136
Composer\Autoload\includeFile                          8  0.0148    86544  0.0028    59448
Zend_Db_Select->_join                                 41  0.2599    59368  0.0627    57072
explode                                              135  0.0341    55672  0.0341    55672
Icinga\Application\Benchmark::measure                 94  0.2099    47448  0.0737    47352
Eric Lippmann
Eric Lippmann
Lead Senior Developer

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.