General

How VSHN’s organization evolves using Sociocracy 3.0

23. Dec 2020

As we grew beyond 25 VSHNeers (that’s what we call our employees), we realized more and more things that were preventing us from meeting our customers’ needs, developing innovative new products or maintaining our unique employee culture. The bigger we got, the more we thought we needed to improve the organization to stay fit for the future. This is about the first steps on our journey how Sociocracy 3.0 helps us evolve our organizational structure, empower people and improve customer service.

VSHN automates software build, deploy, provisioning, backup, observability, alerting and incident management for production applications on any cloud with 24/7 support. A top down, waterfall like hierarchical organization would probably not have helped or brought us there. We always worked in a very agile and democratic way. Furthermore we believe that people do their best if the organization effectively empowers them to do so. Most of the organizational changes were just done by “gut feeling” and talking to each other.

Identifying Pain Points

We felt that it is no longer scalable or beneficial to organize our tech teams around technology (like OpenShift or Puppet managed services). This separation worked well as long as customers used one technology stack or the other. Today’s customers benefit from all the technologies in which VSHN has expertise. As a consequence, customers have been served by two or more teams. To counteract this lack of customer ownership somewhat, we have introduced the concept of Service Managers, who take responsibility for a customer across multiple teams.

  • Ultimately, this still resulted in customers being served inconsistently. Customers had to be in contact with two or more teams. Both is by no means efficient or customer-friendly.
  • The teams sometimes felt controlled and overruled by the Service Managers. It also led to a sort of “fight” between Service Managers as to who would get a team’s help first.
  • Teams also could not decide for themselves how best to serve a customer or change their work methods.
  • Day-to-day business and customer projects usually took precedence over product development. This is, because there was no clear separation between these areas of activity.
  • It was often not clear who to ask regarding a particular product or customer.
  • In order to change such organizational conditions, we lacked the structures to make major decisions as a company with the involvement of everyone affected. This resulted in some decisions being made by individuals, which negatively impacted some of the teams. “Gut feeling” was no longer good enough.

As you can see, it was time to rethink aspects of our organization to keep VSHN fit for the future – and to better enable VSHNeers to do their jobs and improve customer experience as well.

Where to Start

One of the first organizational changes we thought about was organizing our teams by customer and product instead of by technology group. An idea that already started to emerge at the VSHNDay 2019.

  • We want several cross-functional Customer Solution Teams, each of which is assigned a group of customers. This means that a customer is served solely by one team. With the Service Manager as a full member of the team, the team could decide independently on the working methods, work planning and the most suitable solutions for their customers in order to provide the best possible service.
  • Additionally we want one or more Product Teams, each responsible for a specific group of products. With the product owner as a team member, the team could decide autonomously about the product backlog, working methods and technical solution approaches. This would allow the team to fully focus on its products to develop features, fix bugs and maintain the (code-) base, and support the Solution Teams which use their products.

So how do we do this? At the end of 2019, we decided that we will start using patterns from Sociocracy 3.0 as soon as we see something we can use to evolve. Sociocracy 3.0 – or S3 for short – (not the Simple Storage Service ) because it fits best what we have already been doing implicitly for the last few years – mainly the principle about equivalence and consent.

Autonomy of Teams

Just give our teams autonomy to do what they think is best, right? Fortunately, there’s more to this story. We want to give autonomy to a team, as long as the team is aligned with the wider company goals, knows its area of influence, its tasks, and its constraints. Or, to put it another way, each team needs to know the parameters within which it exists, works, and can grow as a team. But that’s not all, each person or team will encounter situations that they cannot address or decide on their own, we need structures to support our teams in discussing and deciding on issues that affect multiple teams or other domains of the business.

We (and S3) call this Accountability which includes Autonomy and Alignment.  To achieve company alignment and team accountability, we figured out that we need:

  • Clear descriptions on what a team is accountable for: This is where S3 Domains and Circles came into play.
  • Once we knew our areas of influence within the company (the domains) we could find out how they relate to or are contained in each other. This lead us to a clear idea of who delegates “accountability” a team for example.

Decision Making

Starting to transform our organizational structures required us to make a lot of decisions.

  • We needed a way to make those decisions quickly while still involving the people affected.
  • We needed a way to make decisions on “usable” over “perfect” solutions.

S3 with the concepts and patterns of ConsentNavigate via Tension and Proposal Forming is the way we choose to address this challenge. Now we could start making decisions that are good enough for now, safe enough to try until the next review.

Good enough might sound wrong, right? Not really, in the volatile, uncertain, complex and ambiguous world we live in, there is never a perfect plan or solution. Something we knew from Agile Software Development. We want iterative and small changes, learn fast what impact something has and react by reviewing and making the next decisions quickly again. VSHN actually did this from day one – just that now we need to do this for decisions with wider reach, affecting much more people and customers.

The key here is Consent. Consent does not mean that everyone agrees (often confused with consensus), it means to do something unless there is a reason not to do it, until we review it again. One reason might be if there is a risk to the organization or if we would overlook a worthwhile opportunity to directly improve the proposal.

Who decides

Involving everyone in every decision that we have to make can hinder agility and speed. Furthermore getting involved in too many different topics would also put a high mental strain on everyone. The key here is to limit people’s areas of influence through domains, that is, to make it clear which decisions are the responsibility of which group.

In response to that, we adapt the S3 concept of Delegate Circles. Here, all teams that would be affected send a representative to form a “virtual” circle. Delegates can then make decisions on behalf of their teams. This is about trust – people should be able to trust their delegate or other teams or groups that are responsible for other domains in the company. In return, they have the peace of mind that they don’t have to take care of everything that goes on in your company themselves – knowing that ultimately they will always have a means to raise an objection to a past decision, existing agreement or activity.

Sociocracy 3.0 (S3) in a Nutshell

Sociocracy 3.0 (S3) is a free social technology for growing agile and resilient organizations at any size, from small start-ups to large international organizations. Using S3 can help to achieve objectives and successfully navigate complexity. You can make changes one step at a time, without the need for sudden radical reorganization or planning a long-term change initiative. S3 is:

  • Flexible: adaptable patterns, independent and mutually reinforcing, to help you with all aspects of collaboration
  • Principles-based: a coherent way for growing organizational integrity and developing an agile mindset
  • Free: Sociocracy 3.0 is free, and licensed under a Creative Commons Free Culture license

You can learn more about S3 on: https://sociocracy30.org/

Where we are right now and what the next steps are

We have managed to form three accountable Teams. One product team and two customer solution teams. The first review of these teams shows that our approach of building teams around customers OR products works. The autonomy allows our teams to find the best way to work and improve as a team.

We have clear domain descriptions for most areas of VSHN by now. This already helps other teams that are not directly affected by the ongoing team changes by clarifying who is responsible for what.

Our Alignment Framework already gives us clarity on what VSHN actually is, what our goals are and how we prioritize features and products for product development and drivers for organizational improvement.

We found a way to implement Consent Decision Making (from Tension, Driver over Decision Making and Review of Agreement) in a mostly asynchronous and written way, which is important in the current, nearly fully-remote world. We call this the VSHN Improvement Process.

As a side effect we’re getting rid of the terms Squad and Chapters which came from the Spotify “model” (There Is No Spotify Model).

Next steps

  • Bring the remaining old tech teams into the new model of Solution Teams.
  • Improve how our  Delegate Circles work.
  • Simplify the VSHN Improvement Process to be more a helping tool instead a formal process.
  • Sociocracy 3.0 Internal Learning Group and Educations – we need to spread the S3 knowledge.
  • S3 Facilitators that can lead by example. It’s important that people can guide VSHNeers in their daily work live and through decision making.

Summary – Our Experience

Change is hard. But overall so far, we believe that we are on the right way. We understand why we are making these changes, together as VSHN and while keeping a strong customer focus.

We learned that organizations can be broken down into two “spaces”. There is the system and there are people in the system. People need the system to see their purpose, to know what they are responsible for, what is expected of them, and where the boundaries and limitations are. Without people finding their place and being committed to make the system work, the system can’t work. We focused a lot on the new structures in the last months. Now again we need to focus on continuously invest in people to enable them to thrive in the system.

What we really like about S3 is the iterative approach. Incremental changes, experimenting and flexibility combined with consent decision making – all these patterns form a better organization in our view. On the other hand incremental changes can leave people between an old and the new world – we saw this being a problem, confusing people and breaking processes that worked earlier – it’s important to find the balance between small enough, incremental changes and not loosing track of where we want to go.

What do you think? What are your experiences? We would be happy to hear the stories you can tell about organizational changes.

Marco Fretz

Marco is one of VSHN's General Managers and Chief Operating Officer.

Contact us

Our team of experts is available for you. In case of emergency also 24/7.

Contact us
General Internal

First change in the VSHN management, André and Marco

16. Jul 2020

As announced in this blog post we’re changing our corporate governance. A first step is that André Keller leaves the management and Marco Fretz joins with a strong focus on organizational development and daily operations. This change happens on request of André because he decided to shift the focus back to technical work and day-to-day customer service management and resign from his management role. Here is why:
When VSHN was founded back in 2014 the first management of VSHN was assembled. VSHN always followed a role concept, this includes the members of the management. This means that being a member of the management is not considered a full-time job (yet) but an additional role. Members of the management work primarily in System Engineering, Finance, Sales or Project- and Product management.
With VSHN rapidly growing over the last years, certain roles became more and more effort and mental load for VSHNeers – especially the management member role. This made it harder for VSHNeers to concentrate on their daily job – which in case of André was always being a System Engineer and taking care of customer needs in projects and daily business.

“In fall 2018, the management team went to Malta for a week-long retreat, where we focused on the challenges that came with our growth as well as the company strategy for the upcoming years. Among other topics, part of these discussions were the individual goals of the members of the management. This was when I first started to really think about my own role in the company and what the things are that I enjoy doing and I find interesting and what aspects of the job I would rather do without. As you can imagine this is not something that is easily figured out in a few hours. At least for me it was a process lasting several months.
At the end of this process I started to realize that it is not my ambition to be part of the management, I would rather concentrate on the day-to-day business, working on projects together with our customers and partners.”
– André

“One of the things I love about VSHN is the fact that everyone has the chance to evolve beyond the current job description, that you can take new roles and resign from roles you don’t like anymore.”
– Marco

The new board and management structure will have a strong focus on people, organizational development (OrgDev) and the refining of the strategy set by the board. André is happy to handover his position in the management to Marco Fretz who has been supporting the management in an advisory capacity for some time. Marco started early 2016 as a system engineer at VSHN. From the beginning he became more and more interested in organizational topics far beyond his daily job and contributed with constructive ideas and concepts to the success of VSHN.

“Being an “old” VSHNeer, knowing all the good and bad stories and having an open mind I’m sure I can be a driver for the changes VSHN needs to overcome future challenges. Together, we can improve things for us as VSHNeers and our customers likewise – and maintain our great family-like culture we value that much.
I know André long before VSHN and I’m convinced this decision is the right one for both André and me. We all should focus on where our ambitions are to be successful and happy – privately and in our job.”
– Marco

Marco Fretz

Marco is one of VSHN's General Managers and Chief Operating Officer.

Contact us

Our team of experts is available for you. In case of emergency also 24/7.

Contact us
Events Tech

Open Source Monitoring Conference 2018

14. Nov 2018

Our Marco Fretz has visited the OSMC (Open Source Monitoring Conference) 2018 in Nuremberg and reports his impressions below.

The OSMC 2018

The four-day OSMC with around 300 visitors is all about monitoring tools, concepts and the automation of the monitoring system. Of course, Icinga2 is very well represented – in the talks, among the participants and organizers. The conference is organized by NETWAYS, the company behind Icinga2, and takes place annually at the Holiday Inn Hotel in Nuremberg.

On the first day there were workshops on various topics and on the fourth day a hackathon, with projects that were determined spontaneously. The English and German talks took place on the second and third day and were divided into three tracks. Thanks to the agenda (online, in front of the rooms and at the back of the badge), it was usually easy to decide on the most exciting track. Talks that you missed can be watched later online as video.

I only visited days two and three again (with the talks). With around EUR 1500.- for two days conference, three evening events and three nights in the hotel, the conference is also very attractively priced.

In any case, the OSMC is also known for the rich and excellent catering (all-you-can-eat) from breakfast to the evening events and the smooth organization – the hotel and conference check-in are completed in under a minute. This has come true again this year.

More impressions: #OSMC

Highlights

For me, the most important thing was to meet new and familiar faces and the related exchange about their own and other monitoring landscapes including their problems and solutions as well as, of course, the direct line to NETWAYS / Icinga. Thanks to the talk from @ekeih (scaling Icinga2 …), some people quickly found themselves running Icinga2 in a setup similar to ours.

Prometheus

Exciting talks about Prometheus or concepts that rely on Prometheus made me feel that Prometheus is becoming more widespread, not only in the “cloud native” world but, for example also for HTTP SLA monitoring (MORITZ TANZER, nic.at), network monitoring (MATTHIAS GALLINGER, ConSol), etc.

Our current plans at VSHN for the integration of Prometheus into our monitoring environment were thus confirmed.

IcingaDB

A big bottleneck in Icinga2 and Icingaweb2 is the IDO database (MySQL / Postgres), whose schema dates back to the Nagios and Icinga1 era and has been steadily worsening over time. At that time, a relational database for actually volatile status information such as service and host states, etc. seemed to make sense. In larger setups, however, the writes from Icinga2 to the DB are the bottleneck. Also, the query performance of Icingaweb2 suffers greatly in certain configurations for larger setups.

A lot of details are not yet known, however, Redis is used for the volatile status information and a SQL DB for the historical data. A first version already runs on a trial basis at Icinga and was presented in a live demo. I think it’s great that you can probably use the IDO DB and the IcingaDB module in parallel (transitionally), the same applies to the Icingaweb2 monitoring module – this will greatly simplify migration.

To take away

Try it out…

OpenAPM

OpenAPM is not a tool in itself but shows in a simple way which tools can be combined with each other to build an application performance management / monitoring landscape. Just try it here: https://openapm.io/landscape

Maps

Certainly exciting are the maps for Icinga2. You can give each host or service object the geolocation via custom variable, then they are automatically displayed on the map and grouped according to the zoom factor: https://github.com/nbuchwitz/icingaweb2-module-map

Rancher Monitoring

From the talk of @ClaudioKuenzler a plugin for easy monitoring of Rancher2 and Kubernetes: https://github.com/Napsty/check_rancher2

Conclusion

I have taken great ideas with me, met new people, ate a lot (and yes, the gin was good too (big grin)). A great conference that’s really worth it. I like to go again.

.

Marco Fretz

Marco is one of VSHN's General Managers and Chief Operating Officer.

Contact us

Our team of experts is available for you. In case of emergency also 24/7.

Contact us
Events

Icinga Camp Berlin 2018

19. Mar 2018

Auch dieses Jahr war Marco Fretz wieder am Icinga Camp in Berlin (08.03.2018) und berichtet.
Begonnen hat für mich das #icingacamp bereits am Mittwoch Abend: Nach der Landung in Berlin, einen kurzen Abstecher ins Hotel, dann auf Twitter gelesen, dass ein Tisch in einem Restaurant reserviert sei, 10min zu Fuss und da war ich. Gleich hat man bei Bier und deftigem Essen bekannte Gesichter getroffen und auch gleich weitere Icinga-Fans kennengelernt.
Ausgeschlafen ging es dann am Donnerstag mit Kaffe und Frühstück, gefolgt von der Eröffnung und einem Update zum Icinga-Projekt und der Community von Bernd Erk, los. Sogar unser Icinga Meetup in Zürich am 23.03. wurde erwähnt.

Tech-Talks

Im Talk von Blerim (Icinga), der die fiktive Geschichte des Sysadmins “Dave” erzählte, ging es darum, wie viele einzelne Tools wie Logging, Alerting, Metrics, Grafiken, etc. erst richtig mächtig werden, wenn man das ganze miteinander kombiniert und integriert. Das hat er vor allem anhand von Icinga2, Elastic Stack und Grafana gezeigt. Mir hat besonders gefallen, wie hilfreich es ist, wenn man Icinga-Events wie “Service Critical” z. B. direkt über den Graph des Server Loads drüber legt und so Ereignisse mit den Metriken korrelieren kann.
Nicolai Buchwitz widmete seinen Talk dem Virtualisierungstool Proxmox VE (PVE) und dessen Integration in Icinga2, dies einmal mit der automatischen Konfiguration via Icinga Directory Import und anderseits mit einem allround-check-plugin (check_pve) für Icinga, welches dank der mitgelieferten Icinga2 Command-Definitionen die wichtigsten Aspekte einfach von PVE überwachen kann.
Gestärkt vom tollen Mittags-Buffet und nach interessanten Gesprächen mit Icinga-Fans und Icinga-Devs ging es im Vortrag von Michael Medin um sein Projekt NSClient++, dem Monitoring Client für Windows, der, wie es ausschaut, immer mächtiger wird, und übrigens auch unter Linux benutzt werden kann. Für Windows-User waren sehr interessante Neuheiten dabei, wie z. B. das Senden von Event Logs direkt an Elasticsearch oder das automatische Verteilen von Scripts, welche die Funktionalität von NSClient++ erweitern können.
Die Vorträge von Michael Friedrich (Integrationsmöglichkeiten von Icinga2 mit InfluxDB, Graphite, ES, Graylog, Dashboard, etc.) und Thomas Gelf (Icinga Director) waren für mich begrenzt interessant, da die Vorträge sehr ähnlich mit denen von der OSMC im November waren, über die ich ebenfalls einen Blogpost geschrieben hatte. Beim Beispiel, wie man kaputtformatierte Excel Host-Listen via Director importiert, mussten dann doch die meisten lachen – solche Anforderungen solls ja in der Praxis geben.


Der Vortrag zu “Netways Web Services” fand ich auch spannend. Sebastian Saemann (Netways) erklärte das Setup mit Docker/Mesos/Marathon, welches hinter NWS steckt, und wie sie “Icinga as a Service” auf dieser Plattform betreiben. Bei NWS kann man sich kinderleicht einen Icinga2-Master inklusive Graphite, Grafana, Director, etc. einrichten oder einen Icinga2-Satelliten konfigurieren, der dann Teil des eigenen Icinga2 Clusters wird – ganz ohne ein einziges CLI command einzugeben.
Im letzten Vortrag plauderte Eric Lippmann (CTO Icinga) etwas aus dem Nähkästchen und ging darauf ein, was sich so bei der Icinga2-Entwicklung tut. Besonders spanned hier die Entwicklung in Richtung IcingaDB, welches das alte, überholte Icinga2 IDO DB Schema ablösen soll. Es wird wohl aber nicht eine eigene DB werden, sonder eher ein neues DB-Schema für MySQL/Postgres plus zusätzlich ein KVP-Store wie Redis für die live-Daten, nur historische Daten sollen zukünftig in die neue SQL DB. Das Ganze steckt aber trotz bereits länger andauernder Entwicklung immer noch in den Kinderschuhen, verständlich, kein einfaches Unterfangen, wenn man sich die technischen Abhängigkeiten aller Komponenten auf die IDO DB genauer anschaut.


Weitere neu Entwicklungen sind die IcingaApp für Android und iOS inklusive Push Notifications, Reporting Features mit anpassbaren Templates und Filtern für Icingaweb2 und ein Notification Manager (NoMa), der ein vereinfachtes verwalten von Notification Contacts und Schedules direkt in Icingaweb2 bringen wird.

Afterevent Beering

Nach dem letzten Vortrag und der Verabschiedung machten sich dann ein Teil der Besucher zusammen mit den Netways/Icinga-Leuten auf die Suche nach einer Bar, die spontan genug Platz für uns hatte. Im Murphy’s Irish Pub eingefunden konnten wir dann noch länger über Icinga2- und Monitoring-Themen diskutieren, bis es dann beim Bier und Essen immer etwas weniger technisch wurde.

Fazit

Trotz ein paar grösserer Probleme mit meinen Rückflügen von Berlin, ein sehr lohnenswerter Event und Ausflug nach Berlin. Man knüpft neue Kontakt zu Icinga2-Entwickler und anderen Benutzern und spricht direkt über aktuelle Probleme, Verbesserungen und neue Ideen.

Marco Fretz

Marco is one of VSHN's General Managers and Chief Operating Officer.

Contact us

Our team of experts is available for you. In case of emergency also 24/7.

Contact us
Events

OpenSource Monitoring Konferenz

27. Nov 2017

Für alle, die nicht dabei waren

Mit über 250 Teilnehmenden fand dieses Jahr die 12. OpenSource Monitoring Conference (kurz OSMC) in Nürnberg statt. Nicht jeder hat Zeit, das Budget oder Lust solche Konferenzen zu besuchen. Was ist die OSMC eigentlich und was war für mich persönlich am spannendsten? Dies erfahrt ihr in diesem Blogpost.
Es hat sich gelohnt und ich kann jedem, der im Bereich Monitoring arbeitet oder daran interessiert ist, diese Konferenz wärmstens empfehlen.

Was ist die OSMC

Bei der OSMC dreht sich alles um Monitoring und heutzutage natürlich auch um die Automatisierung des Monitoring Systems. Die Konferenz wird von NETWAYS, der Firma hinter Icinga2, organisiert. Mit 4 Tagen ist die Konferenz grundsätzlich nicht in die Länge gezogen, bietet aber dennoch genügend Platz viele interessante Talks und genügend Pausen für Networking unterzubringen. Die eigentlichen Talks fanden am zweiten und dritten Tag statt. Tag eins war in vier Workshops aufgeteilt und an Tag vier fand ein Hackathon statt, mit Themen, welche spontan bestimmt wurden. Ich habe nur Tag zwei und drei besucht (die Vorträge), kann darum zu den Workshops und dem Hackathon nicht viel sagen.  Mit EUR 899.- für Tag 2 und 3, ohne Unterkunft ist die Konferenz nicht gerade günstig, aber für das gebotene Programm und die professionelle Organisation ein durchaus fairer Preis. Weitere, etwas teurere Pakete, enthalten auch die Unterkunft im Hotel und / oder den Workshop- und Hackathon-Tag. Ich hatte mich aufgrund privater Planung für ein anderes Hotel in fünf Gehminuten Entfernung entschieden.

Location, Organisation und Ablauf

Man hätte sich eigentlich keine bessere Location als das Holiday Inn Nürnberg vorstellen können: viele Konferenzräume, genügend Platz für Small Talk und Networking in den Pausen und natürlich mit ausgezeichneter und reichlicher Verpflegung zum Frühstück, in den Pausen und am Mittag.
NETWAYS hat tolle Arbeit mit der Organisation und Durchführung der Konferenz geleistet. Der Empfang war herzlich und die Damen und Herren von NETWAYS waren bei Fragen immer leicht auffindbar. Der (technische) Smalltalk mit den Entwicklern von Icinga2 kam vielen Besuchern sehr gelegen, verständlich, wenn man schon mal direkt an der Quelle ist.
Die Talks wurden am 2. Tag in drei Tracks aufgeteilt, am 3. Tag in zwei Tracks. Das heisst, man konnte bzw. musste sich jeweils für einen der zwei oder drei parallel stattfindenden Talks entscheiden. Dies war dank des klaren Programms mit Uhrzeit, Titel, Sprecher und Sprache immer recht einfach. Mir ist es in den zwei Tagen nur zwei Mal passiert, dass ich das Gefühl hatte, besser den anderen Talk gewählt zu haben – ein Verbesserungsvorschlag meinerseits wäre hier, eine Art “Skill-Level” im Programm zu vermerken. Zum Glück werden aber alle Talks professionell in hoher Qualität aufgezeichnet und später veröffentlicht – das Aufzeichnen als Video finde ich persönlich sehr viel sinnvoller als Slides zu teilen, da diese alleine meistens kaum den Inhalt eines Talks wiedergeben können.
Am Abend des zweiten Tages konnte man beim Socialevent im Club nachtkind, ca. 10 Minuten zu Fuss vom Holiday Inn, bei reichlich Bier, Wein, Drinks und super Essen auch mal etwas weniger ernsthaft und technisch diskutieren und feiern – eine gelungene Abwechslung zwischen den Konferenztagen. Für die Teilnehmer des Hackathon gab es auch am 3. Tag einen ähnlichen Abendanlass.

Es gibt nicht nur Icinga

Auch wenn NETWAYS die Konferenz organisiert, drehte sich absolut nicht alles nur um Icinga2 und auch nicht nur um Produkte und deren Implementation. So wurde z. B. in den Talks von Markus Thiel und Marianne Spiller vor allem die Erfahrungen, Theorie, best-practices und Konzepte zum “perfekten Monitoring” aufgezeigt – sehr hilfreich, um auch einmal die eigene Monitoring Landschaft mit etwas Abstand zu hinterfragen.


In mehreren Talks wurde auch gezeigt, was Sensu so alles kann und warum das Konzept von Sensu durchaus Sinn macht in verteilten und hoch dynamischen Setups (Auto-Scaling, Docker, etc.). Sehr spannend bei Sensu ist, dass man z. B. mit Puppet oder Ansible die ganze Check-Konfiguration auf dem Agenten macht und nicht auf Sachen wie Exported-Resources (Puppet) angewiesen ist. Mir persönlich fehlt bei Sensu jedoch immer noch etwas die “Gesamtlösung” (UI mit Mandantenfähigkeit / Rollen, Downtimes, Graphen direkt beim Service, usw.). Die Community, die alternativen WebUIs und Tools rund um Sensu scheinen aber zuzunehmen und das Potenzial von Sensu ist gross, gerade da es auf RabbitMQ für den Datenaustausch und als Message-Bus aufbaut und das Konzept dadurch sehr einfach erscheint.
Einer der besten Vorträge war für mich der von James Shubin mit “Next Generation Config Mgmt” über mgmtconfig. James hat, neben seiner Aufgabe das Publikum zum ersten Vortag wachzuritteln (mit einer kleinen Feuer-Show und Musik), gezeigt, dass ein modernes Konfiguration-Management (in golang und auf Basis von etcd) auch eine Art Monitoring sein kann und direkt auf Events reagiert, statt nur periodisch und in langsamen Durchläufen Änderungen forciert. Dank einer gewissen Kompatibilität zu Puppet und der wachsenden Community ist dies sicherlich ein Projekt, welches wir bei VSHN im Auge behalten werden.


Natürlich gab es auch Vorträge zu Prometheus z. B. wie man zusammen mit Grafana, MySQL besser montioren kann von Julien Pivotto.

Trotzdem kommt man als Icinga Fan nicht zu kurz

Der Vortrag “Current State of Icinga” war (wie auch schon am Icinga Camp und am Icinga Meetup Zurich) sehr informativ. Mir gefällt die Richtung der Icinga2 Entwicklung sehr, denn man erfindet nicht das Rad neu, stattdessen wird viel investiert um mit Icinga2 im Zusammenspiel mit Elasticsearch, Kibana, Logstash, InfluxDB, Grafana, Graphite, usw. integrierte Lösungen zu ermöglichen.
Auch in Icinga2 selbst und Icingaweb2 tut sich viel:

  • Die neue IcingaDB wird zwar erst konzipiert (die Umsetzung ist für nächstes Jahr geplant), trotzdem eine sehr wünschenswerte Entwicklung, ist das aktuelle IDO-DB Schema doch sehr veraltet und kämpft mit Performance Problemen.
  • Mit Icinga2 Release 2.8 wurde der CA-Proxy eingeführt, ein echt wichtiges Feature, mit dem Agents nun auch über einen Satelliten Zertifikate anfragen (CSR) können – bis anhin ging das nur direkt über den CA Host (meistens Master-Zone), was in verteilten Setups mit abgelegenen Netzwerk-Segmenten immer schwierig ist.
  • Icingaweb2 2.5 bring ein optisch überarbeitetes GUI.

Der Director  (Modul für Icingaweb2) wird langsam aber sicher zum Mittelpunkt der automatischen  Konfiguration von Icinga2. Mit Import-Modulen für die PuppetDB, LDAP / MS AD, CSV, SQL, VMWare und vielen mehr lässt sich die Konfiguration von Icinga2 Hosts, Services, etc. auch ohne Konfigurations-Management (Puppet, Ansible, u.Ä.) automatisieren und die Konfiguration dieser Imports und Syncs wird immer übersichtlicher und einfacher.
https://twitter.com/dnsmichi/status/933666420277334017
Mehrere Vorträge drehten sich um die automatische Konfiguration von Icinga2 (Puppet / Ansible) oder um Projekte mit Icinga, dessen Integration und damit gemacht Erfahrungen.

Fazit

Es ist mir natürlich nicht möglich, die 28 Vorträge im Rahmen dieses Blogposts zusammen zufassen, darum empfehle ich allen sich mit #monitoringlove dringend sich die Talks später online anzusehen und natürlich die nächste OSMC zu besuchen – dann aber bitte auch (Wissens-)Hunger mitbringen.

Marco Fretz

Marco is one of VSHN's General Managers and Chief Operating Officer.

Contact us

Our team of experts is available for you. In case of emergency also 24/7.

Contact us
Tech

Distributed Monitoring mit Icinga2 und Puppet

13. Jul 2017

Wir bei VSHN betreiben Applikationen auf Servern und Container Plattformen für Kunden mit verschiedensten Anforderungen. Dabei bilden neben dem Konfigurationsmanagement und der wöchentlichen Maintenance auch die täglichen Backups und natürlich das Monitoring die zentralen Punkte des proaktiven DevOps Betriebs. Bei aktuell über 600 managed Servern mit mehr als 30’000 Services wäre die manuelle Konfiguration sowie das Tuning des Monitorings und der Umsysteme wie InfluxDB, Grafana, etc. recht mühsam – darum haben wir dies komplett automatisiert.

In diesem Blog-Post zeigen wir, wie wir dies bewerkstelligen und wohin die Monitoring-Reise bei VSHN geht.

Architektur

Icinga2 ermöglicht ein komplett verteiltes Monitoring Setup, in dem auf jedem zu überwachenden System eine Icinga2 Instanz läuft. Jeder Client verbindet dann, meistens mit einer ausgehenden TCP Verbindung, verschlüsselt und über x509 authentifiziert, zur Master- oder der überliegenden Satelliten-Zone. Dies ist wichtig, da wir oft Systeme im Enterprise Umfeld betreiben, bei denen wir dann meistens auf einem Jumphost oder dediziert einen Satelliten betreiben. Anschliessend benötigt ausschliesslich dieser eine Verbindung ins Internet zu unserem Monitoring Master.
Des Weiteren kann so ein Server tagelang offline sein und trotzdem haben wir rückwirkend die komplette History und die Performance Daten (man kann auch rückwirkend Performance Daten in die InfluxDB schreiben), weil jede Icinga Instanz lokal ein Replay Log speichert und dieses anschliessend wieder an die überliegende Zone senden kann.
Eine Zone kann auch aus mehreren Icinga2 Instanzen (Servern) bestehen, um die Last zu verteilen und die Verfügbarkeit zu erhöhen.
Für die Authentifizierung und Autorisierung der VSHN- und Kunden-Benutzer ist Icingaweb2 ausserdem an unser zentrales LDAP angebunden. Eine Integration mit Grafana ermöglicht die Vorschau von Performance Data Grafiken direkt in Icingaweb2. Grafana greift auf InfluxDB zu, die wiederum von der Icinga2 Master Instanz mit Performance Daten befüllt wird.

Automatische Konfiguration

Alle unsere Server werden vollständig automatisiert mit Puppet konfiguriert. Dabei weisen wir via Hiera den Servern Rollen zu. Eine Rolle besteht wiederum aus Puppet Profilen (VSHN eigene Puppet Module, die meist auf einem Puppet Base Modul aufbauen). Das Profil steuert immer auch Backup, Firewall und Monitoring. So ist sichergestellt, dass jeder Server eine korrekte Backup-Konfiguration und die richtigen Firewall Rules hat und eben auch automatisch im Monitoring eingerichtet wird. Das heisst, es ist ausgeschlossen, dass ein managed Server nicht im Monitoring eingerichtet ist.

Cluster Konfiguration

Ein Icinga2 Cluster wird immer mittels Zonen und Endpoints konfiguriert. Zonen können mehrere Endpoints (Server mit Icinga2 Instanz) enthalten.

Die manuelle Konfiguration dazu würde vereinfacht so aussehen:

# zones
object Zone "master" {
  endpoints = [ "master1.vagrant.dev" ]
}
object Zone "sat1.vagrant.dev" {
  parent = "master"
  endpoints = [ "sat1.vagrant.dev" ]
}
...
object Zone "clientB.vagrant.dev" {
  parent = "sat1.vagrant.dev"
  endpoints = [ "clientB.vagrant.dev" ]
}
# endpoints
object Endpoint "master1.vagrant.dev" {
  host = "192.168.33.101"
}
object Endpoint "sat1.vagrant.dev" {
  host = "192.168.12.102"
}
...
object Endpoint "clientB.vagrant.dev" {
  host = "192.168.12.104"
}

Das muss dann noch auf allen beteiligten Server so gemacht werden. Ausserdem müssen neben der Icinga2 Grund- und Feature-Konfiguration entweder die Icinga2 eigene x509 PKI konfiguriert und verwendet oder die Zertifikate auf andere Weise ausgestellt und verteilt werden. Details zur manuellen Konfiguration sind hier zu finden: https://www.icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/
Bei uns wird das natürlich alles via Puppet gemacht. In der Regel reicht folgende Konfiguration aus Hiera (Beispiel für einen Client, der zu einem Satelliten verbindet):
Beispiel Client hinter Satellite

profile_icinga2::parent_zone: 'sat1.vagrant.dev'
profile_icinga2::parent_endpoints:
  'sat1.vagrant.dev':
    host: '192.168.12.102'
 profile_icinga2 kümmert sich dann um alles, inklusive der Zonen / Endpoint Konfiguration und konfiguriert die sowieso vorhanden Zertifikate der PuppetCA für die Icinga2 API. Das offizielle Puppet Modul für Icinga2 gibt es hier: https://github.com/Icinga/puppet-icinga2

Host und Service Checks – Konfigurations-Flow

1. Puppet Run auf einem Server inkludiert profile_icinga2 und Service Profile (z.B. profile_mariadb), Beispiel Hieradata:

---
classes:
 - profile_icinga2
 - profile_mariadb
profile_mariadb::manage_monitoring: true # default

2. Icinga2 Profil exportiert

  • Host Object
  • MariaDB Service Check

3. Puppet run auf Monitoring Master
4. Im selben Puppet run auf dem Monitoring Master werden alle Host Objects und Service Objects gesammelt und in Icinga2 angelegt
5. Die Hosts und Services werden im Config Sync Verzeichnis (zones.d) der jeweiligen Client Zone von Puppet angelegt
6. Icinga2 config check wird von Puppet durchgeführt und Icinga2 reloaded
7. Icinga2 synchronisiert die Config via Top-Down-ConfigSync auf alle Satelliten und Clients

  • Jede Satellite und Client Instanz bekommt dabei nur die Config, die ihn auch wirklich betrifft
  • Jede Instanz validiert und aktiviert die Config

8. Icinga2 Satelliten syncen die Configs auf ihre Clients
9. Check ist im Monitoring:

Die Nachteile von Exported Resources

Puppet ist unser primäres Konfigurationsmanagement und Automatisierungs-Werkzeug. Allerdings ist bei der Verwendung von Exported Resources immer Vorsicht geboten.

  • Verlust der PuppetDB Daten führt zum Wegräumen aller Hosts und Services im Monitoring, was sich zwar wieder – nachdem jeder Server wieder einen Puppet run gemacht hat – von selbst “heilt”. Trotzdem unschön.
  • Die ganze Sache ist sehr träge, da jede Änderung einen Puppet run auf dem Server (Icinga2 Client) und auf dem Icinga2 Master benötigt, bevor die Änderungen wirksam sind.
  • Der Puppet run auf dem Monitoring Master sammelt tausende Zone-, Endpoint-, Host- und zehntausende Service-Objects Resources zusammen und ergibt somit einen Puppet run, der locker länger als 20-30 Minuten dauert. Das System wird somit noch träger.

Mögliche Lösungen

Wir wollen in Zukunft auf das Einsammeln von Exported Resources verzichten und Icinga2 direkt mit den Daten aus der PuppetDB konfigurieren. Warum? Weil ein Puppet Run auf fast allen Servern im 1-2 Minuten-Bereich oder weniger liegt, der Puppet Run auf dem Monitoring Master jedoch das Problem ist.
Es gibt auch bereits eine Lösung: Icinga2 Director mit PuppetDB Anbindung 

Dabei würden die Server weiterhin Host und Service Objects via Puppet exportieren, jedoch sammelt ein Import / Sync Job (3) des Directors die Objekte direkt aus der PuppetDB zusammen, filtert und konfiguriert daraus Icinga2 Objekte.

Resultat

Nur noch ein schneller Puppet Run auf den eigentlich betroffenen Server, Änderungen sind innert 1-2 Minuten in Icinga2 aktiv. Der Puppet Run auf dem Monitoring Master gerät in der Hintergrund und ist maximal noch für die Zonen Konfiguration und PKI zuständig, welche im Vergleich zu Service Checks und dem damit verbundenen Tuning eher statisch ist.

Fazit

Verglichen mit der manuellen Konfiguration von Hosts und Services in einem Monitoring System oder der für uns fast komplett unbrauchbaren Auto-Discovery Funktionen anderer Systeme, haben wir mit top Open Source Software eine Lösung geschaffen, die unsere Anforderungen erfüllt, sich komplett in unsere DevOps Arbeitsweise integriert und uns somit den proaktiven Betrieb für unsere Kunden ermöglicht sowie extrem vereinfacht. Es gibt aber an zahlreichen Punkten Verbesserungspotential und uns wird es darum sicher nie langweilig.
Mehr zu Distributed Monitoring mit Icinga2: https://www.icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/
Dies wird sicher nicht der letzte Blog Post zu Icinga2, Icinga2 Director, Monitoring usw. gewesen sein.

Marco Fretz

Marco is one of VSHN's General Managers and Chief Operating Officer.

Contact us

Our team of experts is available for you. In case of emergency also 24/7.

Contact us
Events

Icinga Camp Berlin 2017 – VSHN war dabei!

12. Mar 2017

Am 07. März 2017 fand das jährliche Icinga Camp in Berlin statt. Marco Fretz war dabei und berichtet.
Mit der Kalkscheune als Event Location in Berlin Mitte haben die Organisatoren eine gute Wahl getroffen. Die Kombination aus zeitgemässer technischer Ausstattung und dem historischen Charme einer alten Fabrikstätte war die ideale Kulisse für das Icinga Camp. Das leckere Chilli con carne Mittagsbuffet trug ebenfalls zur guten Stimmung der Teilnehmer bei. Dank der Aktion “Eine Flasche Gin geschenkt, wer das letzte Ticket kauft” war die Konferenz dann auch ausverkauft. Trotzdem hatten alle Teilnehmer angenehm Platz in der Galerie der Kalkscheune.

Ein Hauptargument für das Icinga Camp ist für mich, dass ein Grossteil des Core Entwicklerteams und der Community Manager anwesend sind. Man kann persönlich über Ideen und technische Fragen diskutieren – wofür sich das Icinga Team auch offiziell anbot und sich mit Icinga2 Bekleidung zu erkennen gab.

Stand der Dinge

Bernd Erk (CEO von Netways) eröffnete die Konferenz mit einem Überblick und Status Update des Icinga Projekts. Eine erstaunliche Aussage war hier, dass die Icinga Community eigentlich nur sehr begrenzt weiss, wer Icinga überhaupt und für welche Zwecke einsetzt. Obwohl es für das Einsenden von Referenzen ein Online Formular gibt, scheint dies wenig genutzt. Deshalb ist unsere Bitte als grosse Icinga Fans: Bitte meldet euer Projekt / Firma als Referenz, die Icinga Community wird sich sehr darüber freuen.
Natürlich waren vor allem die technischen News spannend und teils auch überraschend. Noch vor einigen Wochen habe ich mich wieder einmal über das doch recht altmodische DB Schema vom Icinga2 IDO Backend gewundert und jetzt die Info “Wir sind dabei das Datastore Backend von Icinga2 zu ersetzen”. Obwohl noch keine genauen technischen Infos bekannt geben wurden, geht es hauptsächlich Richtung Skalierbarkeit, Performance und Vereinfachung.
Eine weitere erfreuliche Neuigkeit war, dass das komplett neu geschriebene Puppet Modul für Icinga2 nun einen für den produktiven Einsatz tauglichen Stand erreicht hat. Auch sind Play- und Cookbooks für Ansible und Chef verfügbar. Natürlich alles auf Github mit dem Ziel, die Community an der Weiterentwicklung mit einzubeziehen.
Im Bereich der Anbindung an andere Systeme gab Michael Friedrich von Netways (aka @dnsmichi) in einem eigenen Talk einen Überblick über die Integration und Anbindung von Icinga an andere Systeme. Besonders ins Auge fiel hier die Anbindung an Elasticsearch via Icingabeat. Nach der bereits länger verfügbaren Unterstützung für Graylog via GELF sicher eine willkommene Variante für alle, die bereits Elasticsearch und Kibana einsetzen. Michael erwähnte hier mehrmals, dass das Feedback auf Github oder per Mail, sowie Anwendungsbeispiele hier sehr willkommen sind. Sehr interessant ist die Kombination von InfluxDB und Grafana für Performance Daten, wie wir es bei VSHN nun schon länger einsetzen. Für die Einbindung von Grafana in Icinga Web stehen aktuell zwei Module zur Verfügung, eines davon aus der Schmiede von VSHN.

Wie überwacht man richtig?

Einer der kurzweiligsten Talks war definitiv “How to write checks that don’t suck” von Mattis Haase. Anhand eines Publikum-Experiments hat Mattis hier erfolgreich gezeigt, wie ein überlegt umgesetzter Check das Leben eines SysOps oder vor allem OnCall Engineers um 3 Uhr morgens erleichtern kann. Die Kernaussagen waren dabei:

  • Keine nutzlosen Informationen anzeigen, Sachen die funktionieren interessieren nicht – ich will wissen, was NICHT funktioniert und warum ich geweckt wurde.
  • Menschenlesbare Sprache im Text des Checks verwenden, das Monitoring System soll dem Operator Arbeit abnehmen, d. h. somit für ihn arbeiten und nur nützliche Infos liefern.

Mit “Know your Hardware” startet Werner Fischer von Thomas Krenn seinen Talk. Teilnehmer, die mit der Hardware Überwachung von Servern zu tun haben, konnten viele nützliche Tipps mitnehmen. Ausserdem stellt Thomas Krenn tolle fertige Check Plugins für IPMI und weitere Arten der Hardware Überwachung via Icinga zur Verfügung.

Frontends, Icinga Web 2 und Director

Eric Lippmann, CTO von Icinga, und Thomas Gelf (Lead Architect) haben in ihren zwei Talks aufgezeigt, wie mächtig Icinga Web 2 eigentlich ist. Jeder mit minimalen PHP und HTML Kenntnissen hat die Möglichkeit, Module für Icinga Web und das Icinga CLI zu schreiben. Das Beispiel Modul in der Präsentation konnte hier mit wenigen Code Zeilen bereits verschiedene Geschmacksrichtungen von Gin auflisten (smile).
In der aktuellen Version des Icinga Directors stehen neue, für den professionellen Einsatz taugliche Möglichkeiten im Bereich des Config Managements für Icinga zur Verfügung: Von der kompletten manuellen Administration via WebGUI von Host, Services und Templates bis hin zur automatischen Generierung der Konfiguration aus einer CMDB oder z. B. der PuppetDB bietet der Icinga Director nun fast alles, was das Automatisierungs-Herz begehrt. Die Berechtigungs-Verwaltung für die Mandantenfähigkeit des Directors sei aktuell in Arbeit.
Sven Nierlein stellte uns mit Thruk eine Alternative zu Icinga Web genauer vor. Viele Features und grosse Möglichkeiten im Bereich Reporting verdrängen dabei den Eindruck, dass das Frontend zumindest noch ein bisschen nach Nagios aussieht. Auf jeden Fall eine echte Alternative, vor allem wenn man noch Nagios, Icinga1, Shinken oder andere Systeme, die auf Nagios basieren anbinden will.

Die etwas anderen Checks

Mit Alyvix stellte Francesco Melchiori von Würth Phoenix ein End User Experience Monitoring auf Basis von grafischen Checks vor. Alyvix kann neben grafischen Bereichen und OCR regex Matching im Bild einer Applikation sogar Citrix “Video Streams” anhand von Veränderungen in der Frame-Rate erkennen. Die Integration (aktuell leider nur unter Windows) ist mit NSClient++ und einer Kombination aus aktiven und passiven Checks gelöst.
Im “Monitoring the Monitoring of (Siemens) Trains” zeigte uns Eduard Gueldner, wie man mittels der mächtigen Icinga DSL in reinen Dummy-Checks Daten auswertet und dabei auch mit tausenden von Checks praktisch keine Rechen-Ressourcen verschwendet – dies vor allem dann, wenn man keinen Einfluss darauf hat, wie man die Daten bekommt oder keine eigenen Check Scrips auf Fremdsysteme ständig anpassen möchte.

Fazit

Alles in allem ein angenehmer und interessanter Ausflug nach Berlin, von dem ich viele neue Ideen für Verbesserungen und zukünftige Projekte mitnehmen konnte. Wir sind nächstes Jahr sicher wieder dabei. Ebenfalls planen wir als VSHN in absehbarer Zeit ein Icinga Meetup in Zürich abzuhalten, Infos folgen.
Übrigens: Ja, ein Teilnehmer erhielt während des Eröffnungs-Talks wirklich eine Flasche Gin. Es scheint, als gehöre Gin einfach zur Icinga Community.

Links

https://twitter.com/search?q=%23IcingaCamp
Die Slides und Videos sollten bald im Icinga Blog veröffentlicht werden: https://www.icinga.com/blog/ 

Marco Fretz

Marco is one of VSHN's General Managers and Chief Operating Officer.

Contact us

Our team of experts is available for you. In case of emergency also 24/7.

Contact us