Am 27.7. fand bei ConSol das Sommer-Meetup der Gruppe “Münchner Monitoring-Stammtisch” statt. Das Thema war diesmal “Ansible im Monitoring-Umfeld”.
Ansible ist ein Framework, mit dem üblicherweise Server nach der Grundinstallation nachkonfiguriert und mit ausgewählten Softwarepaketen versorgt werden. Oder mit dem im laufenden Betrieb immer wieder Patches und sonstige Updates ausgerollt werden. Dabei wird in einem sogenannten Ansible-Playbook lediglich der Soll-Zustand beschrieben und Ansible kümmert sich im Hintergrund um die dazu nötigen Aktionen. Das hat grundsätzlich noch nichts mit Monitoring zu tun, aber da wir über den Tellerrand hinausschauen und bei allen Kunden keine Insel installieren, sondern Teil einer Unternehmens-IT mit allen möglichen Verflechtungen sind, gehört Ansible seit längerem zum Werkzeugkasten des ConSol-Monitoring-Teams. Es gibt übrigens auch eine eigene Ansible-Meetup-Gruppe, die unsere Veranstaltung freundlicherweise auch auf ihrer Seite ankündigte.
Die Fachsimpelei bei Augustiner und Pizza wurde immer wieder durch einen Vortrag unterbrochen, als da waren:
| Author: | Gerhard Laußer |
|---|---|
| Tags: | Meetup, Ansible, Nagios |
| Categories: | monitoring |
Prometheus is an open-source systems monitoring and alerting toolkit. At its core, Prometheus uses time-series data, and provides a powerful query language to analyze that data. Most Prometheus deployments integrate Grafana dashboards and an alert manager.
Prometheus is mainly intended for white box monitoring: Applications either provide Prometheus metrics natively, or they are instrumented with an exporter to make application-specific metrics available.
For some applications, parsing log files is the only way to acquire metrics. The grok_exporter is a generic Prometheus exporter extracting metrics from arbitrary unstructured log data.
This post shows how to use grok_exporter to extract metrics from log files and make them available to the Prometheus monitoring toolkit.
| Author: | Fabian Stäber |
|---|---|
| Tags: | PrometheusIO, grok_exporter |
| Categories: | monitoring |
IDoc ist das Austauschformat von SAP ERP-Systemen, welches benutzt wird, um per Import und Export Daten sowohl untereinander als auch mit Fremdsystemen auszutauschen. Typische Beispiele solcher Daten sind Bestellungen, Lieferscheine, Überweisungen, Stundenbuchungen, etc. Ein IDoc besitzt neben Control- und Data-Records auch Status-Records, in denen jeder einzelne Verarbeitungsschritt protokolliert wird. Diese Status-Records werden in der Tabelle EDIDS gespeichert. Die neue Version 1.9 von check_sap_health kennt den Mode failed-idocs, mit dem in EDIDS nach Fehlermeldungen gesucht wird.
Seit der Version 2.6.3 von check_mssql_health ist es möglich, den für das Monitoring benötigten Datenbankbenutzer direkt vom Plugin erzeugen zu lassen. Angenommen, der Benutzer soll NAGIOS heißen und das dazugehörige Passwort ES_ku_el. Der Plugin-Aufruf lautet dann:
$ check_mssql_health --hostname dbsrv1 --port 1433 \
--username sa --password 'Str3ng!g3heim' \
--mode create-monitoring-user \
--name NAGIOS --name2 'ES_Ku_el'Anstelle des Benutzers sa kann man auch jeden beliebigen Administrator-Account nehmen. NAGIOS wird in jeder einzelnen Datenbank angelegt. Kommen neue Datenbanken dazu, so wiederholt man einfach den create-monitoring-user-Befehl.
In der neuesten Version von GLPlugin habe ich die Möglichkeit vorgesehen, Thresholds auch als reguläre Ausdrücke anzugeben. Wie schaut das nun genau aus?
$ check_wut_health --hostname dcenv2.de.xxxx --community public --mode sensor-status
OK - return air temperature Unit 1.1 is 21.40C, humidity Unit 1.1 is 49.40%, return air temperature Unit 2.1 is 22.40C, humidity Unit 2.1 is 46.80% | 'temp_Unit 1.1'=21.40;25;28;; 'hum_Unit 1.1'=49.40%;40:60;35:65;0;100 'temp_Unit 2.1'=22.40;25;28;; 'hum_Unit 2.1'=46.80%;40:60;35:65;0;100Wir sehen hier die hartcodierten Default-Schwellwerte 25 und 28 für die Temperatur bzw. 40:60 und 35:65 für die Luftfeuchtigkeit.
Bisher gab es zwei Möglichkeiten, diese zu ändern, z.b. in 20 und 30 für die Temperaturen zu ändern.
“Sakuli”, das Open-Source-Framework zum automatisierten Testen von Applikationen, ist vor kurzem in Version 1.0 erschienen. Ein kleiner Blick auf die zurückliegenden Änderungen.
| Author: | Simon Meggle |
|---|---|
| Tags: | e2e, end2end, monitoring, nagios, omd, sakuli |
| Categories: | sakuli, omd, nagios, development |
Markdown is great for writing documentation or tutorials. However, executing the steps from a tutorial usually means to copy and paste the commands into a shell. There is no guarantee that the documentation is complete, and there is no protection against copy-and-paste errors.
This post shows how to use Packer for automatically executing code snippets from Markdown files on a variety of platforms. Machine images are created directly from the code snippets in the documentation. That way, documentation is guaranteed to be up-to-date and complete, and it can be integrated in an automated delivery pipeline.
| Author: | Fabian Stäber |
|---|---|
| Tags: | markdown, packer, documentation |
| Categories: | packer |
There are many reasons to enable encryption on your webserver and since Let’s Encrypt openend its public beta, there are no more excuses to not use ssl. Besides the official scripts, programs and webpage, there is also already a Perl module Crypt::LE available which uses the Lets Encrypt API and makes requesting and renewing certificates super easy and most important… scriptable.
In a previous article we went through how to build a chat room web application that used REST and STOMP for communicating between the client and server. In this article I use the very same application and show how to write automated integration tests using the open source Citrus integration test framework.
If you haven’t read the first article don’t worry. A quick summary of all the important bits will be shown shortly below. But before I get to that lets talk a little bit about automated integration testing and citrus.
One of the biggest challenges when testing any application is being able to simulate all endpoints.
| Author: | Martin Maher |
|---|---|
| Tags: | citrus, stomp, websocket |
| Categories: | citrus, integration-testing, development |
A couple of years have passed since we last looked into in-memory caches here at ConSol. In that time a bunch of things have happened:
Probably the most significant thing that happened was that the oldest Java Service Request JSR 107, also known as JCache, finally reached ‘Release’ status. This JSR was a long time in the making taking a whole 13 years since the initial proposal back in 2001.
Grid Gains In-memory Data Fabric became an open source project and is now available under the Apache Foundation Project and known as Apache Ignite.
The existing In-memory caches providers, like Hazelcast, have received a whole host of new features including things like support for distributed transactions, a new Map-Reduce API, interceptors for executing business logic, when the cache entries change, to mention just a few.