The [Prometheus] monitoring tool follows a white-box monitoring approach: Applications actively provide metrics about their internal state, and the Prometheus server pulls these metrics from the applications using HTTP.

If you can modify the application’s source code, it is straightforward to instrument an application with Prometheus metrics: Add the Prometheus client library as a dependency, call that library to maintain the metrics, and use the library to expose the metrics via HTTP.

However, DevOps teams do not always have the option to modify the source code of the applications they are running.

At this year’s [JavaZone] conference, Fabian Stäber did a [talk] on how to instrument Java Web Applications with Prometheus metrics without modifying the application’s source code.

weiterlesen...

At this year’s [FOSDEM] conference I did a 30 minutes presentation on [Monitoring Legacy Java Applications with Prometheus]. The talk gives an overview of some of the options you have for monitoring Java applications with [Prometheus] when you cannot modify the application’s source code:

• Logfile monitoring ([grok_exporter]), and how it differs from [Elastic stack]
• Blackbox monitoring ([blackbox_exporter])
• JMX ([jmx_exporter])
• Write your own Java agent ([promagent.io])

The video is available below.

weiterlesen...

The [Prometheus] monitoring tool follows a white-box monitoring approach: Applications actively provide metrics about their internal state to the Prometheus server. In order to instrument an application with Prometheus metrics, you have to add a metrics library and call that library in the application’s source code. However, DevOps teams do not always have the option to modify the source code of the applications they are running.

At this year’s [Devoxx] conference, Fabian Stäber did a [talk] on how to instrument Java Web Applications with Prometheus metrics without modifying the application’s source code.

weiterlesen...

The Prometheus monitoring tool follows a white-box monitoring approach: Applications actively provide metrics about their internal state to the Prometheus server. In order to instrument an application with Prometheus metrics, you have to add a metrics library and use that library in the application’s source code. However, DevOps teams do not always have the option to modify the source code of the applications they are running.

Promagent is a Java agent using Bytecode manipulation for instrumenting Java Web applications without modifying their source code. Promagent allows you to get white-box metrics for Java Web applications even if these applications do not implement any metrics library out-of-the-box.

weiterlesen...

[Prometheus] ist ein quelloffenes Monitoring- und Alarmierungs-Werkzeug. Seine Basis bildet eine Zeitreihen-Datenbank, auf deren Daten mit einer eingebauten, sehr mächtigen Abfragesprache zugegriffen werden kann.

Prometheus verfolgt den Ansatze des sogenannten “whitebox-monitoring”. Anwendungen stellen hier entweder nativ Metriken zur Verfügung, oder alternativ macht ein “[exporter]” Applikations- oder Geräte-Metriken für Prometheus abfragbar.

In diesem Artikel möchte ich zeigen, wie man mit Hilfe des [fritzbox_exporter] und des [speedtest_exporter] im Zusammenspiel mit [Grafana] Einblicke in die Performance seines Heimnetzwerks und seines Internetanschlusses bekommen kann. Die Hardware-Basis für dieses Projekt stellt ein RaspberryPi.

weiterlesen...

[Prometheus] is an open source monitoring tool, which is conceptually based on Google’s internal Borgmon monitoring system. Unlike traditional tools like Nagios, Prometheus implements a white-box monitoring approach: Applications actively provide metrics, these metrics are stored in a time-series database, the time-series data is used as a source for generating alerts. Prometheus comes with a powerful query language allowing for statistical evaluation of metrics.

weiterlesen...

[PromCon 2016] was the first conference around the [Prometheus] monitoring system. It took place from August 25 - 26 2016 at Google Berlin as a single-track event with space for 80 attendants.

We took the opportunity and did a lightning talk introducing [grok_exporter], which is a tool for extracting Prometheus metrics from application logs.

weiterlesen...

Counting the number of error messages in log files and providing the counters to [Prometheus] is one of the main uses of [grok_exporter], a tool that we introduced in the [previous post].

The counters are collected by the [Prometheus] server, and are evaluated using Prometheus’ query language. The query results can be visualized in [Grafana] dashboards, and they are the basis for defining [alerts].

We found that evaluating error counters in Prometheus has some unexpected pitfalls, especially because Prometheus’ [increase()] function is somewhat counterintuitive for that purpose. This post describes our lessons learned when using [increase()] for evaluating error counters in Prometheus.

weiterlesen...

[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.

weiterlesen...