Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development
Code

Verwenden von New Relic zur Überwachung Ihrer Server

by
Difficulty:BeginnerLength:LongLanguages:
This post is part of a series called Performance Monitoring With New Relic.
Using New Relic to Monitor WordPress Performance
Introduction to New Relic Insights
Sponsored Content

This sponsored post features a product relevant to our readers while meeting our editorial guidelines for being objective and educational.

German (Deutsch) translation by Władysław Łucyszyn (you can also view the original English article)

Eine laufende Anwendung ist nicht nur eine Menge Code, der Code muss auch irgendwo ausgeführt werden. Ich spreche von Ihren Produktionsservern. Es ist genauso wichtig sicherzustellen, dass sich Ihre Produktionsboxen verhalten, wie sicherzustellen, dass Ihr Anwendungscode leistungsfähig ist. Sie können Systeme wie Nagios einrichten, um Ihnen dabei zu helfen. Die Arbeit mit diesen Systemen kann jedoch äußerst komplex sein, erfordert eine erhebliche eigene Infrastruktur und kann völlig übertrieben sein (es sei denn, Ihre Infrastrukturanforderungen sind äußerst komplex). New Relic bietet eine weniger umfassende, aber sehr einfache Alternative für die Überwachung der Infrastruktur.

Wenn Sie einige unserer vorherigen Artikel zu New Relic gelesen haben, sollten Sie mit der Funktionsweise der New Relic-Dashboards vertraut sein. Die Serverüberwachungs-Dashboards verwenden dieselben Konzepte. Wenn Sie New Relic bereits verwenden, können Sie sehr schnell Daten über Ihre Serverleistung empfangen. Auch wenn Sie New Relic noch nicht eingerichtet haben, kann es sich lohnen, es nur für die Serverüberwachung zu verwenden. Die rund sechs Dashboards, die New Relic bereitstellt, können die Notwendigkeit einer umfassenderen Infrastrukturüberwachungslösung erheblich verzögern (oder sogar ganz beseitigen).

Warum brauche ich einen Service, um Boxen überhaupt zu überwachen?

Abhängig von den Anforderungen Ihrer Anwendung verfügen Sie möglicherweise über eine Webkomponente, eine Datenbank, einen Cache, eine Suche, einen Load Balancer usw. Einige davon verwenden möglicherweise dasselbe Feld. Sobald Ihre Anwendung jedoch eine bestimmte Größe überschreitet, werden Sie einige davon in ihre eigenen Boxen stellen. Wenn Sie nur einen Produktionsserver haben, sind die Dinge einfach. Sie SSH in diese Box, führen ein paar Shell-Befehle aus und erhalten eine ziemlich gute Vorstellung vom Zustand dieses einen Servers. Wenn die Anzahl der Kartons zunimmt, kann dies zu einer lästigen Pflicht werden. Es wäre praktisch, wenn Sie auf einmal die Gesundheit aller Ihrer Boxen herausfinden könnten. Dies ist genau das Problem, das New Relic Server-Dashboards lösen. Sie erhalten gleichzeitig eine Momentaufnahme des Zustands aller Ihrer Produktionsserver.

Natürlich ist es nicht am effizientesten, den Zustand aller Ihrer Server manuell zu überprüfen. Wenn etwas schief geht, möchten Sie es sofort herausfinden, nicht beim nächsten Mal, wenn Sie sich für eine Überprüfung entscheiden. Die meisten Infrastrukturüberwachungssysteme bieten die Möglichkeit, Warnungen zu senden, wenn bestimmte Teile der überwachten Server ausfallen (z. B. Festplatte voll, zu viel RAM usw.). New Relic ist nicht anders. Sie können die sehr flexible Infrastruktur für Warnungsrichtlinien verwenden, um Fehlerbenachrichtigungen nach Belieben zu senden, z. B. E-Mail, Web-Hooks usw.

Schließlich treten Infrastrukturprobleme oft nicht plötzlich auf, der historische Kontext ist wichtig. Der Arbeitsspeicher wird langsam stundenlang aufgebraucht, bevor die Box ausfällt. Die Festplatte füllt sich tagelang, bevor sich die Dinge zuspitzen. Durch die Stichprobenprüfung Ihrer Server erhalten Sie nicht den historischen Kontext, den Sie benötigen, um das Auftreten von Problemen zu verhindern. Wenn Sie gerade die Festplattennutzung überprüfen, wenn sie etwas voll ist, können Sie etwas dagegen tun. Wenn nicht, lernen Sie das Problem erst kennen, wenn Ihre Boxen sterben. New Relic sammelt Daten und sendet sie ständig an ihre Server zurück, sodass sich die Dashboards ausschließlich mit dem historischen Kontext befassen. Dies macht es sehr einfach, bestimmte Problemklassen zu vermeiden.

Es funktioniert im wirklichen Leben

Lassen Sie mich Ihnen ein paar Geschichten erzählen. Wir verwenden New Relic in Tuts+ sowohl für die Überwachung der Anwendungsleistung als auch für die Serverüberwachung. Vor ein paar Monaten war ich auf Abruf, als sich unsere Boxen alle paar Minuten schlecht benahmen. Sie fielen nicht ganz um, aber die Anwendung würde für kurze Zeit sehr schlecht funktionieren. Ich habe mich bei den Boxen angemeldet und festgestellt, dass die Speichernutzung sehr hoch war. Also habe ich die Server einzeln neu gestartet und die Dinge schienen für eine Weile in Ordnung zu sein. Aber ein paar Stunden später fing alles wieder an. Dies roch nach einem Speicherverlust.

Also habe ich mich bei New Relic angemeldet, um mir die Grafiken anzusehen. Sicher genug, eine der Bereitstellungen, die wir zuvor durchgeführt haben, hatte einen Speicherverlust in die Anwendung eingeführt. Es würde ein paar Stunden dauern, bis der gesamte Speicher von der Anwendung verbraucht war. Zu diesem Zeitpunkt würde es zu einem verzweifelten Müllsammelrausch kommen, der alle möglichen lustigen Probleme verursacht. Bei Betrachtung der Speichergraphen auf allen Feldern war sofort ersichtlich, was geschah. Zu diesem Zeitpunkt hatten wir noch keine Warnungen eingerichtet (wir tun dies jetzt), sodass wir uns des Problems erst bewusst wurden, als sich andere Probleme manifestierten. Da ich jedoch in der Lage bin, alle Boxen miteinander zu vergleichen und den historischen Kontext zu haben, kann ich das Problem leicht diagnostizieren, eine Lösung finden und in dieser Nacht pünktlich einschlafen.

Hier ist noch einer. Vor kurzem gab es einen Ausfall im AWS-Rechenzentrum, in dem Tuts+ gehostet wird. Als sich die Dinge endlich beruhigt hatten, haben wir alle Boxen neu gestartet, um sicherzustellen, dass es keine Probleme gab. Aber wenn die Boxen zurückkamen, gab die Anwendung zeitweise 500 Antworten zurück oder lief manchmal sehr schlecht. Dies war wahrscheinlich ein Problem mit einem oder mehreren Servern, dessen Diagnose bei vielen Boxen sehr ärgerlich ist. Durch den Blick auf New Relic konnten wir das Problem erneut sehr schnell aufdecken. Eine unserer Boxen kam mit einem Schurkenprozess zurück, der viel CPU verbrauchte und dazu führte, dass die App auf dieser Box eine schlechte Leistung erbrachte. Eine andere Box war von einer Art AWS-Störung betroffen, die dazu führte, dass die Festplatten-E/A-Auslastung dieser Box 100% betrug. Wir haben diese Box aus unserem Load Balancer genommen, den Rogue-Prozess auf der anderen Seite entfernt und die Anwendung hat wieder eine gute Leistung erbracht.

Die Grafiken, die New Relic bereitstellt, sind wirklich nützlich und ich möchte nicht darauf verzichten. Lassen Sie mich also zeigen, wie die Serverüberwachung zum Laufen gebracht wird.

Installieren des New Relic Server Monitoring Agent

Grundsätzlich kommt es darauf an, sich bei Ihrem Server anzumelden und den New Relic Server Monitoring Daemon (nrsysmond) zu installieren. Wenn Sie den Artikel New Relic for PHP gelesen haben, ist die Vorgehensweise nahezu identisch. Nehmen wir wie üblich an, wir sind auf Ubuntu.

Als erstes müssen Sie den New Relic-Repository-Schlüssel importieren:

Jetzt fügen wir das New Relic-Repository selbst zum System hinzu:

Jetzt verwenden wir nur apt:

Nach Abschluss der Installation erhalten Sie eine nette Nachricht wie folgt:

Lassen Sie uns machen, was es sagt. Lassen Sie uns zunächst in unsere New Relic-Kontoeinstellungen springen, um unseren Lizenzschlüssel nachzuschlagen (er befindet sich rechts):

Führen wir nun den folgenden Befehl aus:

Wenn Sie die Konfigurationsdatei jetzt überprüfen: /etc/newrelic/nrsysmond.cfg. Dort sehen Sie Ihren Lizenzschlüssel. Wir sind bereit, den Agenten zu starten:

Sie können jetzt Ihre Prozessliste überprüfen, um sicherzustellen, dass sie ausgeführt wird:

Gemäß dem PHP-Agenten gibt es zwei Prozesse. Einer ist ein Überwachungsprozess und der zweite ist der Arbeiter. Der Worker kommuniziert tatsächlich mit den New Relic-Servern. Der Überwachungsprozess überwacht den Worker einfach und wenn der Worker aus irgendeinem Grund stirbt, wird ein neuer erstellt.

Wir können auch die Protokolle überprüfen, um sicherzustellen, dass beim Start keine Fehler aufgetreten sind:

Alles sieht gut aus, und Sie sollten jetzt beginnen, Daten in der New Relic-Benutzeroberfläche anzuzeigen.

Konfigurieren des Server Monitoring Agent

Meistens müssen Sie nichts anderes als den Lizenzschlüssel konfigurieren, aber wenn Sie die Protokollstufe erhöhen oder einen Proxy konfigurieren müssen, ist dies definitiv möglich. Es lebt alles in /etc/newrelic/nrsysmond.cfg. Die Datei ist sehr gut kommentiert und ziemlich selbsterklärend. Wenn Sie etwas ändern, denken Sie daran, den Dämon neu zu starten:

Bei der Konfiguration der Serverüberwachung gibt es nur eine subtile Sache: Dies ist der Name des Servers, wie in den New Relic-Dashboards angezeigt wird. Standardmäßig übernimmt New Relic den Hostnamen der Box und macht diesen zum Namen des Servers in den Dashboards (d. h. Der Ausgabe des Befehls hostname). Ich empfehle Ihnen, es so zu halten. Wenn Sie New Relic auch für die Anwendungsüberwachung verwenden, wird durch Beibehalten des Hostnamens als Ausgabe des Befehls hostname als Name des Servers sichergestellt, dass New Relic korrekt ermitteln kann, welche Anwendungen auf welchen Boxen ausgeführt werden, und alles ordnungsgemäß verknüpft in der Benutzeroberfläche.

Wenn Sie wirklich müssen, können Sie den Namen des Servers so ändern, wie er in der Benutzeroberfläche angezeigt wird, indem Sie den Parameter hostname= in der Konfigurationsdatei festlegen: /etc/newrelic/nrsysmond.cfg. Sie müssen den Daemon neu starten, damit dies wirksam wird. Sie können den Namen des Servers auch direkt in der Benutzeroberfläche ändern, was sich nicht auf den Dämon auswirkt.

Verwenden der Serverüberwachungs-Dashboards

Das erste, was Sie sehen, wenn Sie links auf den Link Server klicken, ist eine Momentaufnahme aller Ihrer Server und der wichtigsten Metriken für alle (CPU, Festplatte, Speicher, E/A).

Auf dieser Seite können Sie feststellen, ob sich eine oder mehrere Ihrer Boxen offensichtlich schlecht verhalten. Hier können Sie bei Bedarf auch einen Server umbenennen oder Tags hinzufügen.

Wenn wir auf einen der Server klicken, gelangen wir zum Hauptserver-Dashboard:

Hier gibt es sechs Hauptmetriken:

  • CPU auslastung
  • Speichernutzung
  • Festplatten-E/A-Auslastung
  • Netzwerk-E/A.
  • Durchschnittslast
  • Prozessliste

Dadurch erhalten Sie einen schnellen Überblick über einen bestimmten Server. Sie können einen Drilldown in jedes der Diagramme durchführen, um weitere Informationen zu erhalten. Sie können beispielsweise einen Drilldown in das CPU-Diagramm durchführen, um zu sehen, welche Prozesse die CPU verwenden:

Sie können auch einen Drilldown in das Datenträgerdiagramm durchführen, um Ihre E/A-Rate, eine Aufschlüsselung der Lese- und Schreibvorgänge sowie eine Schätzung der Zeit zu erhalten, die benötigt wird, bis der Datenträger voll ist.

Das Beste daran ist, dass Sie für alle diese Diagramme dieselben Operationen verwenden können wie für Diagramme auf Anwendungsebene. Sie können also ein Fünf-Minuten-Fenster vergrößern, um einen Anstieg der CPU-Auslastung genauer zu betrachten, oder Sie können sich einen 7-Tage-Trend bei der Speichernutzung ansehen.

Das Beste daran ist, dass die Grafiken einfach zu verstehen sind, Sie nicht mit Metriken überfordert sind und ähnliche Felder miteinander vergleichen können. Auf diese Weise können Sie 99% der häufig auftretenden Probleme mit Ihrer Infrastruktur diagnostizieren.

Einrichten von Serverüberwachungswarnungen

New Relic hat in letzter Zeit viel Arbeit geleistet, um die Alarmierungsfunktionen zu verbessern. Warnungsrichtlinien sind das, was sie im gesamten System entwickelt haben (z. B gibt es Anwendungswarnungsrichtlinien für Anwendungs- und Server-Warnungsrichtlinien für Boxen). Es mag zunächst etwas verwirrend sein, aber es ist ziemlich einfach, sobald Sie den Dreh raus haben. Es gibt zwei Hauptkonzepte, Richtlinien und Kanäle. In Bezug auf Server-Warnungen funktioniert dies folgendermaßen:

Wir richten eine Richtlinie ein und weisen ihr einige Server zu:

Sie erstellen auch einen Kanal (z. B. E-Mail, Webhook), an den Benachrichtigungen gesendet werden können:

Anschließend weisen Sie einer Richtlinie einen Kanal zu. Ab diesem Zeitpunkt abhängig von den Einstellungen für den Kanal (z. B. erstes kritisches Ereignis, alle kritischen Ereignisse, nur Ausfallzeiten). Sie erhalten Benachrichtigungen auf diesem Kanal.

Das einzig verwirrende an Warnungsrichtlinien ist, wo sie zu finden sind. Sie befinden sich unter Werkzeuge->Alert Policies:

Sie müssen dann oben im Menü auf Server klicken, um die Richtlinien für Serverwarnungen zu finden.

Abschluss

Wenn Sie bereits eine Infrastrukturüberwachungslösung wie Nagios verwenden und diese für Sie gut funktioniert, erhalten Sie möglicherweise nicht zu viel Extra von der New Relic-Serverüberwachung (obwohl die Grafiken und historischen Trends ziemlich gut sind). Wenn Sie jedoch Ihre Infrastruktur überhaupt nicht überwachen oder Ihre aktuelle Lösung für Sie nicht funktioniert, probieren Sie New Relic auf jeden Fall aus. Für mich ist es das erste Werkzeug, zu dem ich gehe, wenn ich den Verdacht habe, dass etwas mit meinen Servern nicht stimmt. Und oft genug wird es mich wissen lassen, dass sich Ärger zusammenbraut, bevor die Situation kritisch wird. Das sind die Werkzeugs, die wir alle als Entwickler in unserem Arsenal haben wollen.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.