Monitor Application

Latest version can be downloaded here.

1. Basic Concepts
2. Priority and Status
3. Services
4. Notifiers
5. Modules
   1. Core Modules
   2. Alert Manager Service
   3. Deployment Case Notifier
   4. DevOps Light Notifier
   5. Gerrit Code Review Service
   6. Jenkins Service
   7. JIRA Service
   8. Notification Tabs Notifier
   9. Notifications Notifier
   10. Sonar Service
   11. Storyboard Service
   12. Syndication Feed Service
   13. System Tray Notifier

Basic Concepts

Everything revolves around a StatusItem in the Data module. ServiceModules have to translate the state of their services to it and send a list of StatusItems to the StatusCollector. The StatusCollector caches those StatusItems and notified all Notifiers about new updates. An StatusItem is, e.g., a Jenkins Job, a Sonar Project or an alert from Alert Manager.

Every time the collection of StatusItems changes the Notifier modules get notified. Depending on their capability they can display them. So for example the System Tray module can display only one StatusItem. Another example may be the DevOps Light module which can display a collection of StatusItems. Then it presents the corresponding light patterns and colors.

Priority and Status

Every status item has a Status and Priority. To understand how to configure the application those two properties are probably the most important ones. Although each Notifier is free to implement its decision making what and how to display, there are common guidelines which are followed in standard cases. To decide what is going to be displayed by the Notifiers the worst Status is calculated. All StatusItem with this "worst" Status are then ordered by Priority. Additionally the common Notifier API defines, both, minimum Status and minimum Priority. This filter is applied before the worst Status is calculated. This is a common case for StatusItems with the Priority "NONE".

Services

Currently only REST service are implemented.

Each such service can configure the following:

• Name: A name to easily identify the defined service in the UI.
• Enabled: If enable, the service makes actual REST calls based on their configuration.
• Default priority: In case an unknown/not configured item is found, where the Priority cannot be determined, the Priority defined here will be used.
• Check interval: A interval in milliseconds in which the REST calls will be made to check for new StatusItems. If left empty no calls will be made automatically, but can still be made manually, e.g., by pressing the "refresh" button.
• URL: The URL of the concrete service.
  • Optionally, one of "HTTP Basic Auth" or "Bearer Token" can be used for service authorization.
• Proxy: Proxy address and port.
  • Optionally, one of "HTTP Basic Auth" or "Bearer Token" can be used for proxy authorization.
• Connection timeout: Optionally a non-default connection timeout in milliseconds can be specified. The default is 10 seconds.
• Read timeout: Optionally a non-default read timeout in milliseconds can be specified. The default is 10 seconds.
• Write timeout: Optionally a non-default write timeout in milliseconds can be specified. The default is 10 seconds.

Notifiers

Common settings for all Notifiers are the following:

• Name: A name to easily identify the defined notifier in the UI.
• Enabled: If enable, the notifier listens to StatusItem updates.
• Minimum priority: Priority filter. All StatusItems with priority below than defined here will be ignored.
• Minumum status: Status filter. All StatusItems with status below than defined here will be ignored. This may result into an empty StatusItem collection. In default case this means no negative StatusItems have occured. E.g., the Alert Manager explicitly pushes an "OK" StatusItem
• Services: By default any Notifier listens to all Services. This can be changed by selecting one or more Service.

Modules

Core Modules

The core of the application is made up from Data, API, Control and UI modules. The Data module contains common data classes and enums, e.g., ModuleConfig, Status, Priority. The API module contains interface logic, e.g., Module, ServiceModule, NotifierModule. The Control module puts the things together and the UI module contains some common UI elements and specific stuff for modules which want to use UI.

Then we have a bunch of modules: Jenkins, Sonar and System Tray among others. The former two are Services modules and the last is a Notifier module. Service modules check a status of a certain service and lets the Controller know about its one or more StatusItems through the API module. While Notifier modules are notified by the Controller over the API about StatusItems changes and react to them.

Some modules can be instantiated multiple times. Whether a module can be instantiated multiple times only once (singleton) depends on its implementation.

Alert Manager Service

Alert manager service module implements a REST Client for Prometheus's Alert Manager. This service scrapes in a specified interval an Alert Manager instance and translates triggered alerts into StatusItems. A mapping between an alert's labels/annotations and their values, and Priority and Status can be defined in the Service's configuration. All alerts not matching any rule will be simply ignored. Therfore it is recommended to have some kind of "catch-all" rule.

Additionally to the common configuration the alert manager service defines the following:

• Name annotation/label: An annotation or label which should be used for the StatusItem's name.
• Description: An annotation or label which should be used for the StatusITem's description.
• Labels: Comma separated list of labels which should be considered or filtered out in StatusItem's label collection.
• Label mapping: A mapping between label/annotation, its value and Priority and Status.

Deployment Case Notifier

The Deployment Case is a HW suitcase with programmable buttons, RGB LEDs and LCD display with an USB and Bluetooth interface. It is implemented as a Notifier module although it also serves as a trigger communicating the other direction, back to this application, which then can trigger something. This module only implements the Bluetooth interface.

There were 2 HW implementations of this suit-case. One based on Raspberry PI and one based on Microchip's PIC18x and BM78 module. Both use the same serial protocol and are therefore interchangeable.

See https://blog.kubovy.eu/2018/12/09/deployment-nuklear-football/ for more details.

Additionally to the common configuration the Deployment Case notifier defines a bluetooth address to be used to communicate with it. Security properties, i.e., pairing has to happen on he OS level outside the monitor application.

DevOps Light Notifier

The DevOps Light is a RGB LED notification light based on WS281x protocol (other possible but not produced). It communicates using USB or Bluetooth interface and can be configured to display different patterns based on the Status and Priority of one or more StatusItems.

See https://blog.kubovy.eu/2018/02/11/status-light-with-raspberry-pi-zero-and-w2812-led-strip/.

Additionally to the common configuration the DevOps Light notifier defines the following:

• Bluetooth Address: If specified, used to communicate with the DevOps Light over bluetooth. Security properties, i.e., pairing has to happen on he OS level outside the monitor application.
• USB Port: If specified, used to communicate with the DevOps Light over USB.
• Color Ordering: Defines one of, RGB or GRB, color ordering in the WS281x protocol. This depends on the HW specification of used LED strip build in the light.

Gerrit Code Review Service

The Gerrit code review service implements a scrapper to import changes, reviews and commends from gerrit code review instances to the monitoring application.

Additionally to the common configuration the gerrit code review service defines a mapping between a query and Status with Priority. The resulting list of changes from those queries will be transformed to a list of StatusItems.

Jenkins Service

The Jenkins service implements a scrapper of jenkins jobs and transforms their current/last status to a StatusItems.

Additionally to the common configuration the Jenkins service defines the following:

• Filter: A job filter.
• Job mapping: Defines a mapping between a jenkins job and Priority.

JIRA Service

The JIRA service implements a scrapper of a JIRA instance and transforms issues to StatusItems.

Additionally to the common configuration the JIRA service defines the following:

• Status mapping: Mapping between status, status category (key, name, color), issue type and Status.
• Priority mapping: Mapping betwen priority, issue type and Priority.
• List of queries: List of queries to be used for issue gathering.

Notification Tabs Notifier

The Notification Tabs notifier represents StatusItems in a tree table in a separate tab in the monitor application.

There are no additional configurations to the common configuration.

Notifications Notifier

The Notifications notifier displays new or updated StatusItems as popup notifications.

Additionally to the common configuration the Notifications notifier defines the following:

• Repeat after: Minimal time in seconds to pass between the same StatusItem to be notified.
• Duration - Status mapping*: Time in seconds a notification with a specific Status should be shown before disappearing.

Sonar Service

The Sonar service implements a scraper of sonarqube and transforms the results of a project analysis to StatusItems.

Additionally to the common configuration the Sonar service defines the following:

• Filter: Project filter
• Project mapping: Mapping between project ID, project name and Priority. Only projects defined in this mapping will be considered, others will be ignored.

Storyboard Service

The Storyboard service implements a scraper of storyboard transforming stories and tasks to StatusItems.

Additionally to the common configuration the Storyboard service defines the following:

• Project - Priority mapping*: Mapping between storyboard's projects and Priority. Only projects defined in this mapping will be considered, others will be ignored.

Syndication Feed Service

The Syndication Feed service implements a scraper of RSS and Atom feeds.

Additionally to the common configuration the Syndication Feed service defines the following:

• List of filters: List of title and summary filters with mapping to particular Priority and Status

System Tray Notifier

The [System Tray notifier] shows a StatusItem in the system tray and additionally provides a way to show/hide the main application window, control some of the applications and display StatusItems per service as a sub-menu.

Additionally to the common configuration the System Tray service defines the following:

• Refresh: Whether the StatusItems of services should be displayed and refreshed. Due to compatibility issue with MacOS, where this feature must be turned off.

License

The monitor application is licensed under GNU General Public License (GPL) 3.0