NETWAYS Blog

OSMC 2021 | Thola – A tool for monitoring and provisioning network devices

by Björn Berg | Jan 4, 2022 | OSMC

This entry is part 3 of 23 in the series OSMC 2021

In November this year the OSMC 2021 took place. The two-days conference here in Nurembergs Old Town was all about Open Source Monitoring Solutions. This year, two students from Saarbrücken, Tobias Berdin and Stephan Schmidt from Inexio Deutsche Glasfaser talked about Thola, a new open source (licensed under the BSD 2-Clause license) tool for reading, monitoring and provisioning network devices.

How Thola has developed

Before they developed Thola, they used an old check plugin written in Perl for monitoring network devices. With the growth of their network, the usage of hardware resources also increased. In order to save resources, they began to create a new tool for monitoring and proviosiong network devcies in Go called Thola. Its first beta release was in late October 2020. The last major release 0.5 was in October 2021. It serves as a unified interface for communication with network devices and features a check mode which compiles with the monitoring plugins development guidelines.

Some of its features:

reading, monitoring and configuring of network devices
- from many vendors like Huawei, Nokia, Cisco
- from different device types like switches, routers, UPS
you can easy add support for more devices with YAML configuration files
support for icinga
RESTful API

Thola’s commands

With Thola you can monitor network interfaces, hardware stats and many more. This can be done by simply using Tholas’s CLI mode. Thola has some different commands:

thola identify – for automatically identifying a device with its properties like Vendor, Model, Serialnumber by its IP-Address
thola read interfaces – for reading out special interface informations of a device
thola check – can check metrics of devices and outputs them in a check plugin format, it can be used in monitoring tools like Icinga2
thola api – for configuring the thola api. Afterwards you can use the thola-client binary

Here is an example for checking out the cpu-load of a network device with thola check:

./thola check cpu-load 192.168.112.35 --warning 80 --critical 90
WARNING: average cpu load is 84% | 'cpu_load'=84%;80;90;0;100

For every supported vendor exists a specific device class, so for the ip10 devices from Ceragon exists a subclass in the ceraos-device-class. These device classes are written in a .yaml file. They are easy to write, not bound to a programming language and embedded in a binary. You can also automate the usage of thola with Ansible.

Full talk and more from and about OSMC 2021

Watch the whole talk by Tobias Berdin and Stephan Schmidt here:

Since OSMC 2021 is unfortunately over we still have something for you: Did you already check out this year’s conference archives? They provide you slides and videos of each talk and also some photographs of the conference itself.

OSMC 2022 will take place from November 14 – 16 and we’re already looking forward to meeting you all again!

Stay tuned!

Björn Berg

Junior Consultant

Björn hat nach seinem Abitur 2019 Datenschutz und IT-Sicherheit in Ansbach studiert. Nach einigen Semestern entschied er sich auf eine Ausbildung zum Fachinformatiker für Systemintegration umzusteigen und fing im September 2021 bei NETWAYS Professional Services an. Auch in seiner Freizeit sitzt er viel vor seinem PC und hat Spaß mit diversen Spielen, experimentiert auch mit verschiedenen Linux-Distributionen herum und geht im Sommer gerne mal campen.

Read more from Björn and meet the Team

OSMC 2021 | On the Bleeding Edge of OpenTelemetry

by Marc Rupprecht | Dec 28, 2021 | OSMC

This entry is part 2 of 23 in the series OSMC 2021

OSMC 2021 has been over for about a month now. It was a pretty interesting conference, and also my first one as a trainee at NETWAYS. The two-day conference including a workshop and hackathon was all about open source monitoring software like Icinga2, CheckMK or Prometheus.
Today I give you some insights about one of the talks:

About the Speaker

Philipp Krenn is a development advocate and EMEA team lead at the american-dutch company Elastic NV, best known for the Elastic Stack. Most of his time he is traveling Europe and beyond to speak and discuss open source software, search, databases, infrastructure and security. At the Open Source Monitoring Conference 2021 in Nuremberg he’s shown his passion to demo interesting technology, when he introduced the audience to OpenTelemetry.

What is OpenTelemetry?

OpenTelemetry (OTel) is an open source project, which is backed by the CNCF (Cloud Native Computing Foundation). The CNCF is a project founded in 2015 by the Linux Foundation to help advance container technology and to align the big tech companies around its evolution.

OpenTelemetry combines traces, metrics and logs. With this approach the plan is to unify instrumentation and down the road replace OpenTracing and OpenCensus.
One key factor of the new tool is its vendor neutrality. The compatibility and interoperability approach has wide support throughout the telemetry industry, including global players like Google, Elastic or Splunk.

Including the forementioned companies, a lot of vendors are helping to build OpenTelemetry, while almost everyone who works in the observability space is more or less standardizing in OpenTelemetry right now.

What problem can OpenTelemetry solve?

The question you might be asking right now is: why should I start using OpenTelemetry?
If it’s about logging/events, you can use the Elastic Stack. And you are right. But especially in a distributed environment with multiple instances of an application, load balancing and databases, to recognize and analyze issues you also need metrics and traces.

Metrics can help you to identify bottlenecks in your infrastructure and outputs them in measurable numbers, while traces give you a much-needed overview to understand what happens when an application is running as well as the possibility to retrace e.g. the way of a customer or a session through the entire system.

With all of these parameters combined in one software as well as the targeted goal as industry standard, there are going to be multiple advantages like time saved by not having to develop the right agent or a new layer of communication.

Three Ways to integrate an application in OpenTelemetry

To use OpenTelemetry in your projects, it is necessary to integrate your application into OTel. There are three different options available for you to do this, while the vendor can implement one or more of these.

Your possibilities are:

You have your application in whatever language you want together with the OpenTelemetry agent. Within every agent of every language you have something called vendor exporter who can talk to the backend of the vendor you are using. This way is not the ideal one because everything after the OpenTelemetry agent, e.g. wire protocoll, is from the vendor. Because of this, you have to write the vendor exporter for every single programming language and even constantly maintain it.
The second option is the OpenTelemetry collector. With this approach, the agent speaks the language of the OpenTelemetry protocol and sends his information to your centralized collector. A vendor exporter is located in the collector, from where your data is transferred to your vendor. A big benefit of this approach is that you only need one exporter for all applications, instead of one for every application.
The last way is to push back the vendor and his protocol even more. For this approach, your agent speaks the OpenTelemetry protocol, while the vendor just takes the protocol and implements it in his workflow. This option can be described as vendor neutral because you only need to implement the OTel protocol and not like in e.g. possibility one must have an agent in every language for every one of your applications.

What you can see in the OpenTelemetry demo

After explaining a lot of background information to the possibilities of OpenTelemetry, Philipp Krenn used one third of his speaking time to show a demo of what the program can do.
He demonstrated the combination of a java agent and elastic exporter as collector. With this setup, all the information is transferred to the Elastic Stack, so the storage takes place in Elastic Search while it is displayed in Kibana.

As a speciality he explains the preloading that is possible with java. He also talks about how this procedure works for other languages and shows how to implement your own information apart from the ones available as standard.
If you want to learn more about the possibilities OpenTelemetry has to offer, check out their Homepage for further and more in-depth information.

Full talk and more from and about OSMC 2021

Watch the whole talk by Philipp Krenn here:

OSMC 2022 will take place from November 14 – 16 and we’re already looking forward to meeting you all again!

Stay tuned!

OSMC 2021 | Introduction into OpenSearch

by Björn Berg | Dec 7, 2021 | NETWAYS

This entry is part 1 of 23 in the series OSMC 2021

OSMC 2021 has been over for about a month now, and it was a pretty good conference, and also my first conference at NETWAYS. The two-day conference with Workshop and Hackathon was all about open source monitoring software like Icinga2, CheckMK and Prometheus. Now I want to give you some insights about one of the talks:

About the author

Jochen Kressin, CEO of floragunn, the Company behind SearchGuard, which provides Security and Alerting for OpenSearch and ElasticSearch, introduced the audience into OpenSearch at the Open Source Monitoring Conference 2021 in Nuremberg. In his talk, he gave us an overview about the history of ElasticSearch and the reasons for the license change of ElasticStack in early 2021, which was the main reason for the emergence of OpenSearch and OpenSearch Dashboards.

OpenSearch

OpenSearch is an open source search and analytics software suite, initiated by Amazon Web Services (AWS) and supported by other big IT companies like Red Hat and SAP. It is derived from Elasticsearch 7.10.2 and Kibana 7.10.2, which were licensed under the Apache Software License 2.0 (ASLv2). OpenSearch consists of two parts:

a search engine daemon called OpenSearch
a visualization and user interface, OpenSearch Dashboards

OpenSearch combines the features of Elasticsearch 7.10.2 with the features from Open Distro for ElasticSearch by AWS. OpenSearch was first announced in April 2021 and released in July 2021. The current Version 1.2 has been released just two weeks ago, on November 23.

But why was OpenSearch forked from ElasticSearch 7.10.2? Until January 2021, ElasticSearch had a free version with basic features using the ASLv2 and some commercial add-ons. In January 2021, ElasticSearch switched to a dual license model using the SSPL (Server-side public license) and the Elastic License v1. One month later, in February 2021, Elastic License v1 got replaced with the Elastic License v2, which is a more permissive license, but still not approved by the Open Source Initiative as an Open Source software license. The license change also means that ElasticSearch and Kibana cannot be offered as a managed service anymore. Elastic made this license change in order to prevent companies like AWS from making money with their products while not collaborating with Elastic. In other words: It is meant as a response to the continued non-collaborative engagement AWS pursued with ElasticSearch. Afterwards, AWS said that they will create and maintain a ASLv2-licensed fork of ElasticSearch and Kibana in order to ensure the availability of open source versions.

Free and Open Source Software

This raises the question of what are the benefits of FOSS (free and open source software). The goals of making open source software are getting developers on the board to contribute in order to improve the software, making the project known in the FOSS space and to increase its popularity in general. But there are also several disadvantages – many open source projects are fighting with a lack of funding, developers and time. Really successful projects are often backed by big companies or organizations, like the Apache2 Web Server (Apache Software Foundation) or Fedora Linux (Red Hat). Jochen Kressin also shared some of his thoughts about all this.

Choose your weapons and license wisely
You should fully understand what the license allows and disallows, and evaluate the advantages and disadvantages for your project
Stick to your guns and license
If you have chosen your license, stick with it.
Wide adoption is often only possible with permissive license
FOSS is not a business model
it is not a means to generate revenue and can’t be the only foundation of a company

The future of OpenSearch and ElasticSearch will be very interesting. Elastic has more parts than only Kibana and ElasticSearch, it’s a whole ecosystem (with Logstash, Beats…). Building a community for the FOSS OpenSearch Project requires effort and steadiness. And enterprises require production readiness, professional services and good support (with SLAs).