Ihre Website antwortet, doch auf ihrem Server wird der Speicherplatz knapp. Oder Anfragen werden immer dann langsamer, wenn ein Hintergrundauftrag die CPU auslastet. Server-Monitoring hilft, diese Beobachtungen zusammenzubringen: Was hat sich auf dem Host geändert, wann ist es passiert und welche Ressource sollten Sie genauer prüfen?
Mit MetriBeacon erfassen Sie Messwerte Ihres eigenen Linux-Servers, sehen ihre Historie und richten passende Alarme ein. Diese Anleitung beginnt mit CPU, Arbeitsspeicher, Speicherplatz und dem Lebenszeichen des Agenten. Die Werte ergänzen die Anleitung zum Website-Monitoring, ohne damit jede Funktion Ihrer Anwendung zu beweisen.
Was ist Server-Monitoring?
Server-Monitoring erfasst regelmäßig die Ressourcennutzung und relevante Zustände eines Hosts. Ein einzelner Wert beschreibt einen Moment. Die Historie hilft Ihnen, wiederkehrende Last, allmähliches Wachstum und Änderungen nach einer Veröffentlichung zu erkennen.
Ein HTTP-Monitor betrachtet den Dienst von außen. Der Agent beobachtet die Maschine von innen. Eine erfolgreiche HTTP-Antwort sagt nicht, ob auf dem Dateisystem genug Platz für den nächsten Import vorhanden ist. Ebenso beweist eine niedrige CPU-Auslastung nicht, dass sich Besucher anmelden können. Nutzen Sie beide Beobachtungen zusammen.
Mit diesen vier Signalen anfangen
| Signal | Hilfreiche Frage | Worauf Sie bei der Auswertung achten |
|---|---|---|
| CPU-Auslastung | Ist der Prozessor länger als üblich beschäftigt? | Anhaltende Last mit Aufgabe und Zeitpunkt vergleichen |
| Arbeitsspeicher | Bleibt genug nutzbarer Speicher für die Aufgabe? | Messdefinition, Cache und Entwicklung berücksichtigen |
| Dateisystembelegung | Füllt sich das relevante Laufwerk? | Verbleibenden Platz und Wachstum prüfen |
| Letzter Kontakt | Meldet der Agent weiterhin? | Host, Agent, Verbindung und Kontingent prüfen |
Beginnen Sie mit Signalen, aus denen eine Handlung folgt. Ergänzen Sie Netzwerkverkehr oder weitere unterstützte Komponenten, wenn Sie eine konkrete Frage haben. Eine im Inventar erkannte Komponente aktiviert nicht automatisch jeden möglichen Messwert.
CPU: Ein kurzer Ausschlag ist etwas anderes als Dauerlast
Ein kurzer CPU-Ausschlag während eines Imports kann erwartbar sein. Wiederholt hohe Auslastung zusammen mit langsamen HTTP-Antworten verdient eine Prüfung. Sehen Sie Ihnen denselben Zeitraum in beiden Historien an und vergleichen Sie ihn mit Veröffentlichungen oder geplanten Aufgaben.
CPU-Prozent und Load Average sind verschiedene Kennzahlen. Behandeln Sie einen Load-Average-Wert nicht als Prozentzahl und einen beschäftigten Prozessor nicht automatisch als ausgefallenen Server. Monitoring hilft Ihnen bei der Eingrenzung; ein einzelnes Diagramm legt keine Ursache fest.
RAM: Wenig vollständig freier Speicher braucht Kontext
Linux verwendet Arbeitsspeicher auch für Caches. Wenig vollständig freier RAM allein beweist keinen Speicherengpass. Prüfen Sie, welche Größe die Messreihe abbildet und ob die Aufgabe unter Speicherdruck steht.
MemAvailable schätzt unter Linux den Speicher, der neuen Anwendungen ohne Auslagerung zur Verfügung steht. Die Linux-Kernel-Dokumentation erklärt den Unterschied. Verschiedene Werkzeuge können andere Speichersummen anzeigen, weil sie unterschiedlich rechnen.
Speicherplatz: Das richtige Dateisystem überwachen
Ein Wert für das Systemlaufwerk sagt wenig über ein separates Datenlaufwerk. Wählen Sie das Dateisystem, auf das Anwendung, Uploads oder Datenbank tatsächlich schreiben. Ein nicht eingehängtes Datenlaufwerk ist außerdem etwas anderes als ein leeres Laufwerk.
Bei einer lokalen Prüfung unter Linux zeigen diese lesenden Befehle Speicherplatz und Inode-Nutzung des Root-Dateisystems:
df -h /
df -i /
Ersetzen Sie / durch den relevanten eingehängten Pfad. -h macht Platzangaben besser lesbar; -i zeigt die Inode-Nutzung. Ein Dateisystem kann keine freien Inodes mehr haben, obwohl noch Bytes frei sind. Die GNU-Dokumentation zu df beschreibt die Optionen. Die lokale Prüfung ergänzt die Beobachtung, ersetzt aber keine Historie.
Linux-Server mit MetriBeacon einrichten
1. Host auswählen und verständlich benennen
Melden Sie sich an oder erstellen Sie ein kostenloses Konto. Wählen Sie einen Arbeitsbereich und öffnen Sie die Vorlage Server/NAS. Benennen Sie den Monitor eindeutig, etwa „Webserver Produktion“. Verwenden Sie für verschiedene Hosts eigene Monitore, damit eine Alarmmeldung die betroffene Maschine erkennen lässt.
2. Erste Messwerte auswählen
Beginnen Sie mit CPU, Arbeitsspeicher und Systemdateisystem. Prüfen Sie gewählte Komponenten, Einheiten und Intervalle. Ergänzen Sie ein separates Datenlaufwerk, wenn Ihre Anwendung eines verwendet. Aktivieren Sie vorgeschlagene Alarme bewusst, nachdem Sie ihre Eignung für Ihren Host geprüft haben.
3. Agent installieren und verbinden
Nutzen Sie den geprüften Download und die Installationsschritte der Agent-Anleitung. Installieren Sie auf dem Host, den Sie beobachten möchten, und folgen Sie der Verbindung mit Ihrem vorhandenen Konto und dem gewählten Monitor.
Der Agent sendet Daten über ausgehendes HTTPS. Sie müssen für MetriBeacon keinen eingehenden öffentlichen Port öffnen. Halten Sie seine Identität und Schlüssel privat. Optionale Erfassungen können zusätzliche lokale Rechte benötigen; wählen Sie nur Prüfungen, die Sie benötigen.
4. Erste Werte und Lebenszeichen prüfen
Öffnen Sie den Monitor und kontrollieren Sie, dass der letzte Kontakt fortschreitet und die gewählten Reihen Werte erhalten. Achten Sie auf Einheit und Zeitstempel, nicht nur auf die angezeigte Zahl. Manche Messwerte benötigen zunächst eine erste Beobachtung, bevor sie einen brauchbaren Wert liefern können.
Wenn Werte fehlen, hilft die Anleitung zum Linux-Server-Monitoring. Auf dem Host bietet die CLI Status und Diagnose:
metribeacon status
metribeacon doctor
Die Beispiele setzen voraus, dass der installierte Befehl über Ihren PATH erreichbar ist. Prüfen Sie gewählte Komponenten, Agentzustand und lokale Rechte, bevor Sie Alarmgrenzen ändern.
Veränderungen in der Historie erkennen
Eine hilfreiche Untersuchung beginnt mit einem Zeitfenster. Wurde die Website gegen 09:00 Uhr langsam, prüfen Sie CPU und RAM zu diesem Zeitpunkt und vergleichen Sie sie mit der HTTP-Antwortzeit. Wächst die Laufwerksbelegung jede Nacht, vergleichen Sie das mit geplanten Aufträgen.
Wählen Sie den Zeitraum lang genug, um ein Muster zu erkennen. Eine minutengenaue Spitze und ein Stundenmittel beantworten unterschiedliche Fragen. Prüfen Sie Auflösung, Datenabdeckung und Lücken, bevor Sie daraus einen unauffälligen Verlauf ableiten.
MetriBeacon bietet Historien und Exporte für Ihre Messreihen. Die Anleitung zu Historie und Export erklärt Zeitraumwahl und Datenabfrage. Ein Export enthält die erfassten Beobachtungen; er füllt unbeobachtete Zeit nicht mit erfundenen Werten.
Alarme mit einer klaren nächsten Handlung einrichten
Anhaltende CPU-Auslastung
Ein beispielhafter Ausgangspunkt wäre ein Alarm bei mehr als 90 Prozent CPU-Auslastung über fünf Minuten und eine Entwarnung unter 75 Prozent. Diese Zahlen sind Beispiele und keine allgemeingültigen Empfehlungen. Wählen Sie sie erst, nachdem Sie die Aufgabe beobachtet haben.
Eine Bestätigungsdauer filtert kurze Spitzen. Eine getrennte Entwarnungsgrenze reduziert ständige Wechsel nahe am Grenzwert. Die Alarm-Anleitung erklärt Bedingungen und Zustellung.
Steigende RAM- oder Dateisystembelegung
Prüfen Sie die Einheit der Reihe vor der Eingabe eines Zahlenlimits. Erwartet ein Feld Bytes, bedeuten 90 GB 90000000000 Bytes und nicht die Zahl 90. GB und GiB sind verschiedene Einheiten. Stimmen Sie Grenze, Eingabefeld und gewählte Messgröße aufeinander ab.
Setzen Sie den verbleibenden Laufwerksplatz ins Verhältnis zu Wachstum und Reaktionszeit: Kann jemand untersuchen, bevor das Laufwerk voll ist? Wählen Sie für RAM eine Grenze passend zur Hostgröße und Bedeutung der Messung. Ein fester Wert von einem anderen Server ist selten ein hilfreicher Standard.
Fehlendes Lebenszeichen oder fehlende Werte
Aktivieren Sie den benötigten Kontakt- oder Datenlückenalarm. Ein zuletzt aufgezeichneter Wert kann normal aussehen und bereits veraltet sein. Ein fehlendes Signal kann vom Agenten, Netzwerk, Host oder einem ausgeschöpften Datenbudget kommen; es beweist nicht automatisch einen Hostausfall.
Verbinden Sie E-Mail oder Telegram und senden Sie eine Testbenachrichtigung. Planen Sie Wartungsfenster für absichtliche Unterbrechungen. Jede Regel sollte einen vorgesehenen Empfänger und eine praktische erste Prüfung haben.
Praxisbeispiel: Website während eines Imports langsam
Angenommen, Ihr HTTP-Monitor zeigt zeitgleich mit einem nächtlichen Import erhöhte Antwortzeiten. Die Serverhistorie zeigt ebenfalls mehr CPU-Auslastung. Das sind Beispielbeobachtungen und keine Messungen Ihres eigenen Hosts.
Vergleichen Sie zuerst die Zeitstempel. Prüfen Sie anschließend Importdauer, lokale Logs und die genutzten Ressourcen. Hohe CPU-Auslastung ist ein Hinweis; auch eine Datenbanksperre oder andere Abhängigkeit könnte beteiligt sein. Die Anleitung zum Cronjob-Monitoring hilft, Starts, Abschlüsse und ausgebliebene Läufe des Auftrags getrennt zu beobachten.
Vergleichen Sie nach einer Änderung erneut ein ähnliches Zeitfenster. Das ist hilfreicher als die Annahme, ein einzelner grüner Wert beweise die vollständige Behebung.
Häufige Fragen zum Server-Monitoring
Ist Server-Monitoring mit MetriBeacon kostenlos?
Ja, innerhalb der technischen Kontingente des Dienstes. Die Übersicht zum kostenlosen Monitoring nennt die aktuellen Grenzen; Ihr Konto zeigt den Verbrauch. Wählen Sie hilfreiche Reihen und passende Intervalle statt jeden möglichen Wert zu sammeln.
Brauche ich einen Agenten für Servermesswerte?
Der Agent erfasst lokale Ressourcenwerte auf Ihrem Host. Ein öffentlicher HTTP-Check beobachtet einen Endpunkt ohne Agenten, misst aber weder CPU noch RAM oder Dateisystembelegung dieses Servers.
Kann ich einen Server im privaten Netzwerk überwachen?
Der Agent kann Beobachtungen über ausgehendes HTTPS senden, wenn der Host MetriBeacon erreicht. Der öffentliche HTTP-Checker erreicht dagegen keine privaten Adressen und kein localhost. Das sind unterschiedliche Erfassungswege.
Was bedeutet ein fehlender oder nicht verfügbarer Wert?
Prüfen Sie Agentdiagnose, Rechte, gewählte Komponente und Zeitstempel. Ein nicht unterstützter oder nicht verfügbarer Messwert ist nicht null. Eine Datenlücke beweist keinen gesunden Host.
Ersetzt Server-Monitoring die Prüfung meiner Anwendung?
Ressourcen und Kontakt helfen, das Hostverhalten zu verstehen. Ergänzen Sie HTTP-Checks und eigene Anwendungsbeobachtungen für die Funktionen, von denen Ihre Nutzer abhängen. Ein Server kann freie Kapazität haben, während eine Anwendungsaktion fehlschlägt.
Mit einem Server und einem hilfreichen Vergleich beginnen
Verbinden Sie einen Linux-Server, prüfen Sie CPU, RAM, Dateisystemwerte und Kontakt und beobachten Sie die normale Nutzung. Ergänzen Sie wenige Alarme, auf die Sie reagieren können, und testen Sie ihre Zustellung. Erweitern Sie das Profil, wenn eine weitere Messung eine konkrete Frage beantwortet.
Starten Sie Ihr Server-Monitoring mit einem kostenlosen Konto und wählen Sie anschließend Server/NAS in Ihrem Arbeitsbereich. Die Übersicht zum Server-Monitoring erklärt, wie lokale Werte, Historie und Alarme zusammenspielen. Der Button unter diesem Artikel öffnet die Vorlage Website/API für einen ergänzenden HTTP-Check Ihres öffentlichen Dienstes.
