für den IT-Administrator

Redaktion IT-Administrator

In jeder Ausgabe präsentiert Ihnen IT-Administrator Tipps, Tricks und Tools zu den aktuellen Betriebssystemen und Produkten, die in vielen Unternehmen im Einsatz sind. Wenn Sie einen tollen Tipp auf Lager haben, zögern Sie nicht und schicken Sie ihn per E-Mail an tipps@it-administrator.de.

Monitoring

In unserem Unternehmen nutzen wir PRTG für die Überwachung der IT-Infrastruktur. Bisher verwenden wir hauptsächlich die Standardansichten. Ich möchte nun für verschiedene Abteilungen (IT-Leitung, Netzwerkteam, Serverteam) individuelle Dashboards erzeugen, die genau die für sie relevanten Informationen übersichtlich darstellen. Wie kann ich das ansprechend und funktional tun und für die verschiedenen Teams zugänglich machen?

Mit der Funktion "Map Designer" erstellen Sie in PRTG individuelle Dashboards, die genau auf die Bedürfnisse verschiedener Teams zugeschnitten sind. Diese Überblicksseiten, in PRTG eben auch Maps genannt, ermöglichen eine übersichtliche Darstellung der wichtigsten Monitoringdaten für unterschiedliche Nutzergruppen. Klicken Sie zum Erzeugen des neuen Dashboards in der Hauptmenüleiste auf "Maps" und wählen Sie "Add Map". Geben Sie einen aussagekräftigen Namen ein, zum Beispiel "Dashboard Netzwerkteam", und legen Sie die gewünschte Größe in Pixeln fest. Nun öffnet sich der Map Designer. Dieser besteht aus drei Hauptbereichen: dem Gerätebaum auf der linken Seite, dem Designbereich in der Mitte und dem Eigenschaftenbereich auf der rechten Seite. Ziehen Sie per Drag and Drop Objekte aus dem Gerätebaum auf Ihr Dashboard. Sie können einzelne Sensoren, Geräte oder ganze Gruppen hinzufügen. Alternativ lässt sich ein Objekt auch per Doppelklick hinzufügen. Im Eigenschaftenbereich rechts legen Sie fest, wie die Objekte dargestellt werden sollen. Zur Auswahl stehen unter anderem:

- Datentabellen für weitergehende, detaillierte Informationen

- Statusanzeigen in verschiedenen Stilen

- Grafiken für die Visualisierung von Messwerten

- Geo-Maps für auf den Standort bezogene Übersichten

- Top-10-Listen für kritische Werte

Passen Sie das individuelle Layout an und positionieren Sie die Elemente nach Ihren Wünschen auf dem Dashboard. Sie können auch Verbindungslinien zwischen Elementen ziehen, um logische Zusammenhänge darzustellen. Optional lässt sich ein Hintergrundbild im JPG-, PNG- oder GIF-Format einbinden, beispielsweise Ihr Firmenlogo, einen Grundriss oder eine geographische Darstellung Ihres Netzwerks.

Um das Dashboard schnell zugänglich zu machen, setzen Sie die Priorität auf fünf Sterne. Dadurch erscheint es im "Home"-Menü der Hauptmenüleiste. Sie können dort bis zu zehn Dashboards anzeigen. Damit die verschiedenen Teams nur ihre eigenen Dashboards sehen können, müssen Sie entsprechende Zugriffsrechte vergeben. Gehen Sie dazu in die Einstellungen der Map und legen Sie fest, welche Benutzergruppen Zugriff haben sollen. Sie haben dabei verschiedene Möglichkeiten, um Dashboards zu teilen:

- Link mit Login-Pflicht: Benutzer müssen sich mit ihren PRTG-Zugangsdaten anmelden.

- Link ohne Login: Ermöglicht öffentlichen Zugriff ohne Anmeldung.

- Einbettung in andere Webseiten: Per iframe-Code können Sie das Dashboard in Intranetseiten einbinden.

Wollen Sie mehrere Dashboards darstellen, richten Sie eine automatische Rotation ein. Wählen Sie dazu in der Maps-Übersicht die gewünschten Übersichtsseiten aus und klicken Sie auf das Rotationssymbol. Für jedes Team ist auf diese Weise ein maßgeschneidertes Dashboard möglich: Die IT-Leitung erhält eine Gesamtübersicht mit den wichtigsten Statusinformationen, das Netzwerkteam bekommt detaillierte Bandbreitengrafiken und Switch-Status, während das Serverteam CPU-, Speicher- und Festplattenauslastungen im Blick behält. Weitere Tipps für das Erstellen von Dashboards in PRTG finden Sie unter dem Link https://www.paessler.com/de/support/how-to/map-designer.

Für weitere Tipps und Tricks rund um das Thema Monitoring mit PRTG bietet Paessler unter [Link-Code: https://www.youtube.com/c/PRTGNetworkMonitorByPAESSLER?utm_source=itadministrator&utm_medium=referral&utm_campaign=tipps] auch einen YouTube-Kanal mit Tutorials an.

Support

Als MSP müssen wir viele unterschiedliche, komplexe Berichte für unsere Kunden erstellen. Um diesen Prozess zu vereinfachen, suchen wir nun ein KI-gestütztes Werkzeug. Welche Möglichkeiten stehen uns dafür in LogMeIn Resolve zu Verfügung?

Als MSP mit Zugang zu den Funktionen der Open-Beta-Phase haben Sie die Möglichkeit, GoTos künstliche Intelligenz zum Erstellen von benutzerdefinierten Berichten zu verwenden. Dies ist insbesondere dann nützlich, wenn die integrierten Standardberichte und Diagramme Ihnen nicht alle benötigten Einblicke bezüglich Geräteaktivitäten, Remoteausführungen oder Antivirusupdates liefern. LogMeIns KI unterstützt Sie sowohl beim Erzeugen neuer Berichte als auch bei der Anpassung bestehender Reports. Das Ganze funktioniert durch Eingabe natürlicher Sprache und ohne komplexe Coding-Kenntnisse oder tiefgehendes technisches Wissen zu besitzen.

Möchten Sie einen neuen individualisierten Bericht erstellen, wählen Sie in der Konsole erst die Seite "Berichte" und anschließend "Neuen Bericht erstellen" aus. In einem zweiten Schritt legen Sie die Art des Reports beziehungsweise das Widget fest. Dazu beschreiben Sie im KI-Chatfenster in natürlicher Sprache, welche Diagramme und Elemente Sie für Ihren Bericht benötigen und bestätigen die Eingabe anschließend über die Enter-Taste. Alternativ können Sie auch eine der vordefinierten Diagrammoptionen unter dem Eingabefeld als Basis für Ihren Bericht verwenden. Über das KI-Chatfenster verfeinern Sie Ihr Diagramm dann mit mehr Details passend zu Ihren spezifischen Bedürfnissen. Anschließend klicken Sie oben auf "Zum Bericht hinzufügen".

Um vorhandene Berichte anzupassen, duplizieren Sie zunächst den Report, den Sie bearbeiten möchten. Bewegen Sie dazu den Cursor über den Bericht, um das Menü in der oberen rechten Ecke zu öffnen und wählen Sie "Duplizieren". Dadurch erscheint auf der Seite "Berichte" eine Kopie, die Sie mit KI-Unterstützung weiter verbessern können. Klicken Sie oben rechts auf "Verfeinern", um das Chatfenster zu öffnen, in dem Sie der KI genau mitteilen können, welche Änderungen Sie vornehmen möchten. Nachdem die KI das Widget Ihrem Input entsprechend angepasst hat, speichern Sie die Änderungen über das Feld "Änderungen sichern".

Sie können diesen Prozess auch rückgängig machen, indem Sie "Widget entfernen" auswählen. Diese Aktion entfernt nur die Anpassungen, nicht das Widget selbst. Wenn Sie weitere Hilfe benötigen, finden Sie zusätzliche Informationen zur Nutzung von KI für personalisierte Berichte unter dem Link https://support.logmein.com/resolve/help/create-your-own-custom-report-in-logmein-resolve.

Weitere Tipps rund um das Thema IT-Management finden Sie im Blog "Products in Practice" von GoTo unter http://www.goto.com/de/blog/products

Cloud

In unserem Unternehmen erstellen Entwickler IAM-Policies für ihre Anwendungen, um Berechtigungen leicht zu verwalten. Allerdings führen wir manuelle Reviews aller Policies durch, bevor sie in die Produktionsumgebung gelangen, um übermäßige oder unerwünschte Berechtigungen zu verhindern. Diese Prozesse sind zeitaufwendig und komplex, was zu Verzögerungen bei Deployments führt. Wie können wir diese Überprüfungen automatisieren und beschleunigen?

Die Balance zwischen Entwicklungsgeschwindigkeit und Sicherheit fordert von vielen Unternehmen, ihre IAM-Policy-Reviews effizient und fehlerfrei durchzuführen. "IAM Access Analyzer Custom Policy Checks" bieten einen automatisierten Ansatz für manuelle Policy-Reviews. Diese Funktion nutzt automatisierte Reasoning-Techniken, um IAM-Policies proaktiv auf kritische Berechtigungen und übermäßige Privilegien zu überprüfen. Custom-Policy-Checks lassen sich direkt in CI/CD-Pipelines integrieren, sodass Policies bereits vor dem Deployment analysiert werden, ohne sie in produktiven Umgebungen zu Testzwecken einsetzen zu müssen.

Das CheckNoNewAccess-API ermöglicht es, neue Policy-Versionen systematisch mit bestehenden Referenz-Policies zu vergleichen und sicherzustellen, dass keine ungewünschten Berechtigungen gewährt werden. Entwickler erhalten sofortiges Feedback, ob ihre Policy-Änderungen mehr Zugriff verschaffen als vorgesehen. Diese Vergleichsfunktion identifiziert problematische Policies und verhindert, dass es zu umfangreichen Berechtigungen in Produktionsumgebungen kommt. Gehen Sie dazu gemäß folgenden Schritten vor:

1. Installieren und konfigurieren Sie das AWS-CLI sowie das AWS-CDK für die Nutzung der Custom-Policy-Checks-APIs. Stellen Sie sicher, dass Ihre Identität über die erforderlichen Berechtigungen für IAM Access Analyzer verfügt.

2. Erzeugen Sie eine Referenz-Policy, die als Vergleichsbasis dient. Sie sollte maximal erlaubte Berechtigungen definieren und kritische Aktionen wie "iam: PassRole" für sensible Ressourcen explizit verweigern.

3. Erstellen Sie Test-Policy-Dokumente für verschiedene Szenarien. Beginnen Sie mit einer restriktiven Policy, die Bedingungen enthält, und zusätzlich einer permissiveren Version ohne all diese Einschränkungen.

4. Nutzen Sie das CheckNoNewAccess-API über das AWS-CLI, um neue Policy-Dokumente mit bestehenden zu vergleichen und sicherzustellen, dass keine erweiterten Berechtigungen gewährt werden.

5. Integrieren Sie die Policy-Vergleiche in Ihre Entwicklungsprozesse, indem Sie automatisierte Checks vor Code-Deployments oder in Pull-Request-Workflows implementieren.

Eine proaktive Automatisierung von IAM-Policy-Vergleichen mit dem CheckNoNewAccess-API reduziert Sicherheitsrisiken und beschleunigt Entwicklungsprozesse. Durch die systematische Überprüfung auf Berechtigungserweiterungen erhalten Entwickler sofortiges Feedback, während Sicherheitsteams die Kontrolle über Policy-Änderungen behalten. Das ermöglicht es Unternehmen, die Balance zwischen Entwicklungsgeschwindigkeit und Sicherheit zu optimieren. Weitere Hinweise zum Thema finden Sie unter https://aws.amazon.com/de/blogs/security/introducing-iam-access-analyzer-custom-policy-checks/.

Tools

Kommt es in Kubernetes-Clustern zu Problemen, die sich so tief im System verstecken, dass der IT-Verantwortliche auf eine Analyse des Datenverkehrs zurückgreifen muss, steht er vor diversen Herausforderungen. Denn zum einen laufen hier die Anwendungen in Pods, die über virtuelle Netzwerke und Service-Abstraktionen miteinander kommunizieren. Diese Ebenen verschleiern den tatsächlichen Datenfluss. Sichtbar sind oft nur Metriken oder Logs, nicht aber, welche Anfragen konkret zwischen Services ausgetauscht werden. Zudem sind Fehler in Microservice-Umgebungen – etwa falsche API-Aufrufe, Timeout-Probleme oder unerwartete Antwortcodes – oft schwer zu reproduzieren. Klassische Tools wie Logs oder APM-Systeme liefern nur Teilinformationen. Und schließlich arbeiten viele Netzwerkanalysetools wie etwa Platzhirsch Wireshark auf Paketebene, ohne Kontext zu Kubernetes-Ressourcen oder Protokollen. In einer Cluster-Umgebung ist aber entscheidend, welcher Pod, Container oder Service hinter einem Datenpaket steht. Zeit also für Kubeshark.

Kubeshark ist ein Open-Source-Tool zur Netzwerkanalyse und Paketinspektion in Kubernetes-Clustern. Es bietet Administratoren eine transparente Sicht auf den Netzwerkverkehr zwischen Containern, Pods und Services – ähnlich wie das bekannte Desktoptool Wireshark, jedoch speziell für cloudnative und containerisierte Umgebungen konzipiert. Ziel der Software ist es, eine einfache, nicht-invasive Methode zur Fehlersuche und Laufzeitanalyse in Kubernetes bereitzustellen. Da Kommunikation zwischen Microservices in verteilten Systemen oft über interne APIs, Service Meshes oder verschachtelte Netzwerkebenen erfolgt, gestaltet sich das Debugging solcher Datenflüsse häufig komplex. Kubeshark adressiert dieses Problem, indem es Paket- und Protokolldaten direkt im Cluster erfasst, analysiert und visuell aufbereitet.

Dabei bringt das Tool eBPF (Extended Berkeley Packet Filter) zum Einsatz – eine Kerneltechnologie, die es ermöglicht, Netzwerk- und Systemereignisse effizient zu überwachen, ohne den Cluster signifikant zu belasten. Dadurch lassen sich sämtliche Netzwerkpakete, Requests und Responses innerhalb eines Pods oder zwischen Services in Echtzeit mitlesen. Kubeshark interpretiert die Daten automatisch auf Anwendungsebene, etwa für HTTP, gRPC oder Redis, und stellt sie über eine interaktive Weboberfläche oder über die Kommandozeile dar.

Link: https://github.com/kubeshark/kubeshark

In vielen Infrastrukturen ist der Betrieb von Ceph-Storage-Clustern für Kubernetes komplex, fehleranfällig und stark von manuellen Eingriffen abhängig. Dies gilt insbesondere bei laufenden Systemen, wenn es um das Ersetzen von Knoten, dem Skalieren oder Dekommissionieren von OSDs geht. Dies will die Open-Source-Software Pelagia durch Automatisierung über deklaratives Lifecycle-Management verbessern. Administratoren können einen gewünschten Systemzustand vorgeben, während Pelagia die notwendigen Änderungen eigenständig umsetzt und die Konsistenz des Clusters sicherstellt.

Pelagia dient als Lifecycle-Management-Ebene über bestehende Ceph-Deployments und richtet sich in erster Linie an Unternehmen, die große, skalierbare Speicherinfrastrukturen betreiben – insbesondere in cloudnativen oder Bare-Metal-Szenarien. Ziel des Tools ist es, wiederkehrende und komplexe Verwaltungsaufgaben im Zusammenhang mit Ceph zu automatisieren, die bislang oft manuell oder über eigene Skripte abgebildet wurden.Technisch agiert Pelagia dabei als Kubernetes-Controller, der den kompletten Lebenszyklus von Ceph-Clustern überwacht und steuert. Hierbei nutzt die Software Custom Resource Definitions (CRDs), um Speicherressourcen und Cluster-Zustände deklarativ zu beschreiben. Anwender können so gewünschte Konfigurationen im Sinne von GitOps-Workflows festlegen, während Pelagia dann selbständig für deren Umsetzung und Konsistenz sorgt. Im Fokus stehen vor allem die sogenannten "Day-2-Operationen" – also Aufgaben wie das Skalieren, Ersetzen oder Entfernen von Storage-Knoten.

Im Gegensatz zu bestehenden Projekten wie Rook, das Ceph auf Kubernetes orchestriert, versteht sich Pelagia nicht als Ersatz, sondern als ergänzende Abstraktionsschicht. Während Rook das Deployment auf Kubernetes ermöglicht, konzentriert sich Pelagia auf das übergeordnete Management und die Automatisierung komplexer Betriebsprozesse. Dadurch sollen Administratoren in die Lage versetzt werden, selbst umfangreiche Ceph-Installationen stabiler, reproduzierbarer und mit weniger manuellem Eingriff zu betreiben.

Link: https://github.com/Mirantis/pelagia

Der eingebaute Horizontal Pod Autoscaler (HPA) in Kubernetes reagiert standardmäßig nur auf interne Metriken wie CPU- oder Speicherauslastung. Viele Anwendungen – etwa Message-Queue-Verarbeiter, Event-Listener oder Batch-Prozesse – erzeugen jedoch Last, die sich in diesen Kennzahlen kaum widerspiegelt. Zudem müssen in klassischen Deployments Pods oft permanent aktiv bleiben, um auf Ereignisse reagieren zu können, selbst wenn keine Arbeit anliegt. Das führt zu unnötiger Ressourcennutzung und höheren Kosten. Die freie Anwendung KEDA löst das Problem, dass Kubernetes von Haus aus nicht versteht, wann eine Anwendung Arbeit hat – etwa, wenn neue Nachrichten eintreffen oder Daten verarbeitet werden müssen. Es bringt intelligente, ereignisgesteuerte Skalierung ins System und hilft so, Kosten zu senken, Reaktionszeiten zu verkürzen und Cloudressourcen bedarfsgerecht einzusetzen.

KEDA – kurz für Kubernetes Event-Driven Autoscaling – ist ein Open-Source-Projekt der Cloud Native Computing Foundation (CNCF), das darauf abzielt, Workloads in Kubernetes dynamisch anhand externer Ereignisse zu skalieren. Während der native HPA in Kubernetes wie angesprochen vor allem auf interne Metriken wie CPU- oder Speicherauslastung reagiert, erweitert KEDA dieses Konzept um ereignisbasierte Trigger aus einer Vielzahl von Quellen. Der Hauptzweck von KEDA liegt darin, Skalierungsentscheidungen anwendungsnaher und ressourceneffizienter zu gestalten. Statt kontinuierlich eine feste Anzahl an Pods aktiv zu halten, kann KEDA Anwendungen automatisch hoch- oder herunterskalieren, sobald bestimmte Ereignisse eintreten – etwa eine steigende Nachrichtenlast in einer Warteschlange oder eine erhöhte Zahl eingehender HTTP-Anfragen. In ruhigen Phasen kann die Anzahl der Pods sogar auf null reduziert werden, wodurch Infrastrukturkosten sinken.

Das Tool arbeitet dazu als Add-on auf Kubernetes-Ebene und integriert sich nahtlos in bestehende Cluster. Es nutzt die Standardmechanismen des HPA, erweitert diese jedoch um zusätzliche "ScaledObjects" und "ScaledJobs", die definieren, auf welche Ereignisse oder Metriken reagiert werden soll. Die Kommunikation mit den jeweiligen Event-Quellen übernehmen sogenannte Scaler, von denen KEDA inzwischen mehr als 60 unterstützt – darunter Azure Service Bus, Kafka, RabbitMQ, Prometheus, AWS SQS, PostgreSQL, Redis und HTTP-Requests. Die Software eignet sich damit besonders für Event-getriebene Architekturen, wie sie in Microservice- oder Serverless-Umgebungen häufig vorkommen. Durch die Verbindung von Event-basiertem Triggering und der Kubernetes-Skalierungslogik lässt sich eine fein abgestimmte Reaktion auf Lastveränderungen realisieren, ohne dass Entwickler auf komplexe Eigenlösungen zurückgreifen müssen.