Seite wählen

NETWAYS Blog

OSMC 2023 | Journey to Observability: Tracking every Function Execution in Production

In his talk at OSMC 2023 Lucas Copi, Kubernetes Expert at IBM Cloud, tells us about their journey to observability in their modern cloud environment based on RedHat Openshift.

First of all, let’s look at the differences between observability and monitoring.

  • Monitoring means tracking things happening on your infrastructure. It helps you to detect issues as they occur and to take action in order to counter them.
  • Observability, on the other hand, involves the collection of data. By analyzing them, it allows you to get insights about the system’s overall state.

As Lucas and his team at IBM Cloud faced issues with their old infrastructure as a big monolithic, they decided to separate it into many smaller parts – you could call them microservices. They integrated tons of tests, like about 50k of regression cases, and refactored many parts of their infrastructure’s code for better unit tests. All of that made them learn one lesson: Testing in pre production environments is not always enough.

Not testing in prod is like not practicing with the full orchestra because your solo sounded fine at home.

Usually, even the best pre-prod environment is much smaller than the actual prod environment and therefore not suitable for certain tests. Testing in production does not mean only testing in production.
Another lesson they learned: It’s not always possible to fix issues in your environment, due to not having enough metrics and logs. There are 4 golden pillars for every operation: Latency, Throughput, Errors and Saturation. There are some existing solutions that are great at adding observability to the interactions between services. They include Grafana, OpenTelemetry, istio and honeycomb. But all these were not able to satisfy all needs of Lucas‘ Team. As a solution, they made a custom tool in golang, called „The Observability context“. Basically, it provides consistency throughout execution flows and across the observability pillars. They are using the new tool for measuring code performance.

Observability changed their mindset. Now, it’s not only about features and „Runs everything?“, but more „How good is it working?“. Introducing observability actually decreased the number of problems customers are facing. This shift not only overcomes testing limitations but also minimizes customer-facing issues. Observability emerges as a key catalyst for continuous improvement and reliability in modern cloud environments.

Björn Berg
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.

OSMC 2022 | Monitoring multiple Kubernetes Clusters with Thanos

By now, Prometheus has become the defacto standard for monitoring containerised applications, especially when you are using orchestration tools like Kubernetes or Consul. However, when it comes to monitoring multiple Kubernetes clusters through a single plane of glass, additional tools are required. In his talk at the Open Source Monitoring Conference 2022 (OSMC), Pascal Fries showed how to set up a production monitoring landscape based on Prometheus and Thanos, spanning several Kubernetes clusters. Focussing on examples and best practices. He also elaborates on how to securely communicate between the individual components.

Pascal Fries works as a IT Consultant at the ATIX AG in Garching (near Munich) in Germany. As a specialist for Cloud Native technologies, among his main fields of expertise are configuration and administration of multi cluster Kubernetes environments. Including their monitoring with Prometheus and Thanos.

As an introduction, Paul asked the audience if they were using Kubernetes (in a single or multi cluster setup) or Prometheus. Prometheus works very well at monitoring multiple Kubernetes Clusters. But there are several problem areas that you should be aware of, like long term storage, high availability and redundancy. To illustrate this with an example, he mentioned a customer story about Kubernetes usage where multiple teams use Kubernetes, in sum over 20 clusters. There are shared, managed and owned clusters all together in that environment, and all teams need to have a single endpoint for getting their metrics. Other requirements are long term storage, high availability and push based monitoring. How can we make yure to meet all there requirements with our monitoring setup?

Thanos, a storage layer for Prometheus

To solve these requirements, he introduced us to Thanos. It is basically a storage layer for Prometheus.

 

 

 

 

 

 

 

 

 

To set it up, you can use sample configurations. Its also more secure, as gRPC and TLS auth are being used instead of REST and basic authentication. When Thanos is communicating with Thanos, they use TLS auth – otherwise of course basic auth.

The long term storage is realized by saving the data in an S3, which can be self hosted or on a cloud service like NETWAYS Web Services. For realizing a push-based monitoring, Thanos can act as a receiver and compactor. The receiver is a short term DB and shards/replicates the timeseries by labels. Unfortunately, the results are duplicates in the S3. The compactor on the other side deduplicates in the S3, and downsamples the data for faster queries.

All in all, Thanos is a great tool for a redundant and highly available long term storage for Prometheus Monitoring.

And the OSMC is a great conference with many interesting talks every year! Especially if you want to learn more about everything related to Open Source Monitoring. There were talks about monitoring, automation and open source in general. And many interesting talks with the attendees. Hearing and discussing the different opinions and use cases of and about technology is exciting for me. I have been working at NETWAYS as a Junior Consultant for 2 years now, and it was the second OSMC. I am looking forward to next year already!

The recording and slides of this talk and all other OSMC talks can be found in our Archives. The next OSMC takes place from November 7 – 9, 2023 in Nuremberg. Early Bird tickets are already on sale!

Björn Berg
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.

1 Jahr Ausbildung – ein Rück- und Ausblick

Seit September 2021 bin ich nun Auszubildender zum Fachinformatiker bei NETWAYS, genauer gesagt im Professional Services Team.

Rückblick

Ich startete direkt mit einer Linux-Grundlagen Schulung, und daran anschließend arbeitete ich an verschiedensten weiterführenden Projekten. Ab Anfang 2022 baute ich mein Wissen über Netzwerkgrundlagen, Icinga2, DNS, DHCP, Ansible und GitLab Stück für Stück aus und immer auch in praktischen Projekten zur Ausführung gebracht. Und alle paar Wochen natürlich auch die Berufsschulblöcke, wo allgemeinere Themen dran kamen. In Summe verging dieses erste Jahr trotz der Fülle an Themen sehr schnell.

Ausblick

Und was kommt nun? Einerseits im Frühjahr die Abschlussprüfung Teil 1 (ehemals: Zwischenprüfung). Und andererseits: Auf jeden Fall mehr Icinga2 und ein Einstieg in den Elastic Stack. Jetzt im Zweiten Jahr stehen außerdem immer wieder Einsätze im Operations-Team und auch im Consulting-Team an. Falls Ihr auch Interesse an einer Ausbildung bei NETWAYS habt schaut doch mal rein 😉

Björn Berg
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.

NETWAYS stellt sich vor – Björn Berg

This entry is part 41 of 62 in the series NETWAYS stellt sich vor

Name: Björn Berg

Alter: 21

Position bei NETWAYS: Junior Consultant

Bei NETWAYS seit: September 2021

Wie bist du zu NETWAYS gekommen und was genau gehört zu deinem Aufgabenbereich?

Ich habe 2019 mein Abitur gemacht und nach diversen Praktika in IT-Abteilungen und nach einigen Semestern Studium (Datenschutz & IT-Sicherheit) mich für eine Ausbildung zum Fachinformatiker für Systemintegration entschieden. Bei der Suche nach interessanten Betrieben stieß ich recht schnell auf NETWAYS und kam im Professional Services Team als Junior Consultant an Bord .
Dort nehme ich an Schulungen teil und mache zur Vertiefung basierend auf den Schulungsthemen verschiedene spannende Projekte, die auch immer mehr Transferleistungen abverlangen. Mit dem zweiten Lehrjahr kommt nun immer mehr Bewegung von “Grüne-Wiesen”-Projekten wie auch reelleren Umgebungen hinzu.

Was macht dir an deiner Arbeit am meisten Spaß?

Dass ich immer was dazulerne, und dabei auch immer wieder ganz neue Seiten sehe und mein Wissen in bekannten Feldern intensivieren kann. Auch habe ich großen Spaß daran, mir bei Projekten zusätzlich zur ursprünglichen Aufgabenstellung weitere sinnvolle Ergänzungen zu überlegen und tiefere Recherchen anzustellen.

Was machst du, wenn du nicht bei NETWAYS bist?

z.B. die abendliche Zockerrunde, Serien und Filme und immer wieder mal Campen. Außerdem wären da noch diverse private IT-Projekte und ich bin in verschiedensten Online-Communities sehr gern aktiv.

Wie geht es in Zukunft bei dir weiter?

Jetzt erstmal die Ausbildung abschließen, und dabei sehen, welches Team/Aufgabenfeld und welche Themen mich am meisten reizen.

 

Björn Berg
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.

HUGO: GitLab-CI/CD-Pipeline für eine statische Website

Vor etwa 4 Monaten habe ich hier einen Blogpost geschrieben, in dem ich Hugo vorgestellt habe – eine Software zum Generieren statischer Webseiten aus Markdown-Dateien.

Im Lauf meiner Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS habe ich vor kurzem an einer GitLab Fundamentals Schulung teilgenommen, um mehr über Git im allgemeinen und die Besonderheiten von GitLab im speziellen zu lernen. Auf Basis dieser Schulung und dem Projekt hinter oben genannten Blogpost habe ich nun eine CI/CD-Pipeline – CI/CD steht für Continous Integration and Continous Deployment – zum automatisierten Testen, Bauen und Ausrollen einer mit Hugo erzeugten Website gebaut.

Für dieses Projekt habe ich NETWAYS Web Services (NWS) eine GitLab CE App gestartet und außerdem in der Cloud von NWS zwei Webserver – einen als Testumgebung, einen als Produktivumgebung. Mithilfe meines Laptops als Client habe ich an der Website gearbeitet und die anfallenden Daten regelmäßig in ein eigenes GitLab Repository gepusht. Zum Testen, Bauen und Ausrollen auf die beiden Webserver laufen in der GitLab App zwei GitLab Runner. Das sind im Prinzip Agenten die für die GitLab App auf einem anderen System Befehle ausführen können.

Die CI/CD Pipeline

Die CI/CD Pipeline wird über die .gltiab-ci.yml gesteuert. Anfangs werden in der Pipeline die Quelldateien mithilfe zweier Markdown-Linter (vale.sh und markdownlint) getestet – in der .gitlab-ci.yml schaut das so aus:

lint:
   stage: lint
   tags: 
    - hugo
   allow_failure: true
   script:
    - cd tutorial
    - mdl ./content
    - vale ./content

Diese überprüfen die Inhalte der Website auf die Einhaltung eines Styleguides und auch auf die Sprachliche Korrektheit. Anschließend wird die Webseite mit Hugo gerendert, das heißt aus den Markdown-Dateien für den Websiteinhalt entsteht nun die wirkliche Website:

testBuild:
   stage: build
   tags:
    - test
   script:
    - cd tutorial
    - mkdir test
    - hugo -DEF --debug -d test
   artifacts:
   paths:
    - tutorial/test

Falls diese Operation auf der Testumgebung erfolgreich ist, wird sie auch auf der Produktivumgebung durchgeführt. Als Abschluss wird die gerenderte Webseite noch für den genutzten Webserver (z.B. Apache HTTPD oder nginx) bereitgestellt):

testDeploy:
   stage: deploy
   needs: [testBuild]
   tags:
    - hugotest
   script:
    - cp -r tutorial/test/* /var/www/html/
   only: 
    - main

Grafisch sieht diese Pipeline so aus:

Wenn auch Du solche interessanten Projekte in Deiner Ausbildung zum Fachinformatiker machen möchtest, kannst du Dich gerne für eine Ausbildung ab Herbst 2022 bewerben!

Björn Berg
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.