Share
Eine laufende Anwendung ist nicht nur ein Haufen Code, der Code muss auch irgendwo ausgeführt werden. Ich spreche von Ihren Produktionsservern. Es ist ebenso wichtig sicherzustellen, dass sich Ihre Produktionsboxen verhalten, wie sicherzustellen, dass Ihr Anwendungscode performant ist. Sie können Systeme wie Nagios einrichten, um Ihnen dabei zu helfen, aber es kann sehr komplex sein, mit ihnen zu arbeiten, erfordert eine eigene Infrastruktur und kann ein totaler Overkill sein (es sei denn, Ihre Infrastrukturanforderungen sind äußerst komplex). New Relic bietet eine weniger umfassende, aber sehr einfache Alternative für die Infrastrukturüberwachung.
Wenn Sie einige unserer vorherigen Artikel über New Relic gelesen haben, sollten Sie mit der Funktionsweise der New Relic-Dashboards zu Hause sein. Die Serverüberwachungs-Dashboards verwenden die gleichen Konzepte. Wenn Sie New Relic bereits verwenden, können Sie sehr schnell Daten über die Serverleistung erhalten. Selbst wenn Sie New Relic noch nicht eingerichtet haben, kann es sich lohnen, es nur für die Serverüberwachung zu verwenden. Die etwa sechs Dashboards von New Relic können die Notwendigkeit einer umfassenderen Infrastrukturüberwachungslösung erheblich verzögern (oder sogar ganz beseitigen).
Abhängig von den Anforderungen Ihrer Anwendung verfügen Sie möglicherweise über eine Webkomponente, Datenbank, Cache, Suche, Load Balancer usw. Einige dieser Geräte können dieselbe Box verwenden. Sobald Ihre Anwendung eine bestimmte Größe überschreitet, legen Sie einige davon in ihre eigenen Boxen. Wenn Sie nur einen Produktionsserver haben, ist es einfach. Wenn Sie SSH in diese Box einführen, führen Sie ein paar Shell-Befehle aus und erhalten eine ziemlich gute Vorstellung vom Zustand dieses Servers. Wenn die Anzahl der Boxen wächst, kann dies ein bisschen langweilig werden. Es wäre praktisch, wenn Sie einen Weg finden könnten, sich über den Zustand aller Ihrer Boxen auf einmal zu informieren. Dies ist genau das Problem, das von den New Relic-Server-Dashboards gelöst wird. Sie erhalten gleichzeitig einen Überblick über den Zustand aller Ihrer Produktionsserver.
Natürlich ist es nicht das effizienteste, den Zustand aller Server manuell zu überprüfen. Wenn etwas schief geht, möchten Sie es sofort herausfinden, nicht bei der nächsten Prüfung. Die meisten Infrastrukturüberwachungssysteme verfügen über eine 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 Versagensbenachrichtigungen auf beliebige Weise zu senden, z. B. E-Mail, Web-Hooks usw..
Schließlich erscheinen Infrastrukturprobleme oft nicht plötzlich, der historische Kontext ist wichtig. Der Arbeitsspeicher wird langsam für Stunden aufgebraucht, bevor die Box ausfällt, und die Festplatte wird für Tage voll sein, bevor sich die Dinge zuspitzen. Die Überprüfung Ihrer Server vor Ort gibt Ihnen nicht den historischen Kontext, den Sie benötigen, um Probleme zu vermeiden. Wenn Sie die Plattenbelegung nur überprüfen, wenn sie voll ist, können Sie etwas dagegen unternehmen. Wenn nicht, erfahren Sie nur dann, wenn Ihre Boxen sterben. New Relic sammelt Daten und sendet sie ständig an ihre Server zurück. Die Dashboards beziehen sich also auf den historischen Kontext. Dies macht es sehr leicht, bestimmten Problemklassen vorzubeugen.
Lassen Sie mich 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 abschneiden. Ich loggte mich bei den Boxen ein und stellte fest, dass der Speicherverbrauch sehr hoch war. Also startete ich die Server nacheinander neu und die Dinge schienen für eine Weile in Ordnung zu sein. Aber ein paar Stunden später ging es wieder los. Das roch nach einem Speicherleck.
Also habe ich mich bei New Relic angemeldet, um mir die Grafiken anzusehen. Sicher, eine der zuvor implementierten Implementierungen hatte ein Speicherverlust in die Anwendung eingeführt. Es würde ein paar Stunden dauern, bis der gesamte Speicher für die Anwendung verbraucht war. Zu diesem Zeitpunkt geriet er in einen verzweifelten Müllsammelrausch und verursachte alle möglichen lustigen Probleme. Bei der Betrachtung der Speichergraphen aller Boxen war sofort klar, was los war. Zu dem Zeitpunkt hatten wir keine Warnmeldungen eingerichtet (wir tun dies jetzt), sodass wir uns des Problems nicht bewusst wurden, bis andere Probleme auftreten. Da ich jedoch alle Boxen miteinander vergleichen und über den historischen Kontext verfügen kann, kann ich das Problem leicht diagnostizieren, eine Lösung ausrollen und pünktlich in dieser Nacht einschlafen.
Hier ist noch einer. Vor kurzem gab es einen Ausfall im AWS-Datencenter, in dem Tuts + gehostet wird. Als sich die Dinge endlich beruhigt hatten, starteten wir alle Boxen neu, um sicherzustellen, dass keine störenden Probleme auftraten. Aber wenn die Boxen zurückkamen, würde die Anwendung zeitweise 500 Antworten zurückgeben oder zeitweise sehr schlecht abschneiden. Dies war wahrscheinlich ein Problem mit einem oder mehreren Servern, was sehr ärgerlich ist, wenn Sie feststellen, dass viele Boxen vorhanden sind. Ein Blick auf New Relic erlaubte es uns, das Problem sehr schnell zu lösen. Eine unserer Boxen kam mit einem Schurkenprozess zurück, der viel CPU-Aufwand beanspruchte und dazu führte, dass die App auf dieser Box schlecht funktionierte. Eine andere Box war von einer Art AWS-Störimpuls betroffen, was dazu führte, dass die Festplatten-E / A-Auslastung dieser Box 100% betrug. Wir haben diese Box aus dem Load Balancer genommen, den Schurkenprozess auf der anderen Seite losgelassen und die Anwendung hat wieder einwandfrei funktioniert.
Die Diagramme, die New Relic bietet, sind wirklich nützlich und ich möchte nicht auf sie verzichten. Lassen Sie mich Ihnen zeigen, wie Sie die Serverüberwachung in Betrieb nehmen können.
Im Grunde geht es nur darum, sich bei Ihrem Server anzumelden und den New Relic Server Monitoring Daemon zu installieren (Nrsysmond). Wenn Sie den Artikel "Neues Relic für PHP" gelesen haben, ist die Vorgehensweise nahezu identisch. Nehmen wir wie üblich an, wir sind auf Ubuntu.
Als erstes müssen Sie den Repository-Schlüssel New Relic importieren:
wget -O - https://download.newrelic.com/548C16BF.gpg | sudo apt-key hinzufügen -
Jetzt fügen wir das New Relic-Repository selbst dem System hinzu:
sudo sh -c 'echo "deb http://apt.newrelic.com/debian/ newrelic nicht frei"> /etc/apt/sources.list.d/newrelic.list'
Jetzt benutzen wir einfach geeignet:
sudo apt-get Update Sudo apt-get installieren Sie newrelic-sysmond
Nachdem die Installation abgeschlossen ist, erhalten Sie folgende nette Nachricht:
**************************************************** ************************************************** ************************************** *** *** Der Relikt kann nicht gestartet werden Server Monitor, bis Sie einen *** gültigen Lizenzschlüssel in die folgende Datei eingefügt haben: *** *** /etc/newrelic/nrsysmond.cfg *** *** Sie können dies tun, indem Sie den folgenden Befehl als root ausführen: * ** *** nrsysmond-config --set license_key =*** *** Es werden keine Daten gemeldet, bis der Server-Monitor gestartet werden kann. *** Sie erhalten Ihren New Relic-Schlüssel im Abschnitt "Konfiguration" *** des "Support" -Menüs Ihres New Relic-Kontos (erreichbar unter *** https://rpm.newrelic.com). *** ************************************************ ************************************************** ********************************************
Lass uns machen, was es sagt. Lassen Sie uns zunächst auf die Kontoeinstellungen von New Relic zugreifen, um nach unserem Lizenzschlüssel zu suchen (dieser befindet sich auf der rechten Seite):
Jetzt führen wir den Befehl aus:
nrsysmond-config --set license_key =
Wenn Sie jetzt die Konfigurationsdatei überprüfen: /etc/newrelic/nrsysmond.cfg. Dort sehen Sie Ihren Lizenzschlüssel. Wir sind bereit, den Agenten zu starten:
/etc/init.d/newrelic-sysmond start
Sie können jetzt Ihre Prozessliste überprüfen, um sicherzustellen, dass sie ausgeführt wird:
ps -ef | grep nrsys newrelic 10087 1 0 09:25? 00:00:00 / usr / sbin / nrsysmond -c /etc/newrelic/nrsysmond.cfg -p /var/run/newrelic/nrsysmond.pid newrelic 10089 10087 0 09:25? 00:00:00 / usr / sbin / nrsysmond -c /etc/newrelic/nrsysmond.cfg -p /var/run/newrelic/nrsysmond.pid ubuntu 10100 9734 0 09:25 pts / 1 00:00:00 grep - -color = auto nrsys
Laut 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 einfach den Worker, und wenn der Worker stirbt, aus welchem Grund auch immer, entsteht ein neuer.
Wir können die Protokolle auch überprüfen, um sicherzustellen, dass beim Start keine Fehler aufgetreten sind:
cat /var/log/newrelic/nrsysmond.log 2014-05-25 09:25:02 [10089 / main] immer: Neue Relic Server Monitor-Version 1.4.0.471/C+IA gestartet - pid = 10089 background = true SSL = wahres ca_bundle =ca_path = host = ip-10-196-10-195 2014-05-25 09:25:03 [10089 / main] info: RPM-Weiterleitung: collector-102.newrelic.com (50.31.164.202) Port 0 (0 bedeutet Standardport.) )
Alles sieht gut aus und Sie sollten jetzt Daten auf der New Relic-Benutzeroberfläche sehen.
In den meisten Fällen müssen Sie nichts weiter als den Lizenzschlüssel konfigurieren. Wenn Sie jedoch die Protokollebene oder einen Proxy konfigurieren möchten, ist dies auf jeden Fall 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 Neustart der daemon:
/etc/init.d/newrelic-sysmond neu starten
Es gibt nur eine kleine Sache, wenn es um die Konfiguration der Serverüberwachung geht. Dies ist der Name des Servers, wie es in den New Relic-Dashboards zu sehen ist. Standardmäßig nimmt New Relic den Hostnamen der Box und macht den Namen des Servers in den Dashboards (d. H. Die Ausgabe von) Hostname Befehl). Ich empfehle Ihnen, es so zu belassen. Wenn Sie New Relic auch für die Anwendungsüberwachung verwenden, behalten Sie den Hostnamen bei, der vom ausgegeben wird Hostname Befehl, da der Name des Servers sicherstellen kann, dass New Relic korrekt herausfinden kann, welche Anwendungen auf welchen Boxen ausgeführt werden, und dass alles ordnungsgemäß in der Benutzeroberfläche eingebunden wird.
Wenn Sie wirklich müssen, können Sie den Namen des Servers so ändern, wie er in der Benutzeroberfläche angezeigt wird hostname = Parameter in der Konfigurationsdatei: /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 Daemon auswirkt.
Das erste, was Sie sehen, wenn Sie auf klicken Server Link auf der linken Seite ist eine Momentaufnahme aller Ihrer Server und der wichtigsten Kennzahlen für alle Server (CPU, Festplatte, Speicher, E / A)..
Auf dieser Seite können Sie sehen, ob sich eine oder mehrere Ihrer Boxen offensichtlich falsch verhalten. Hier können Sie auch einen Server umbenennen oder bei Bedarf Tags hinzufügen.
Wenn wir auf einen der Server klicken, gelangen wir zum Hauptserver-Dashboard:
Hier gibt es sechs Hauptkennzahlen:
Dadurch erhalten Sie einen schnellen Überblick über einen bestimmten Server. Sie können die einzelnen Diagramme detailliert darstellen, um weitere Informationen zu erhalten. Sie können beispielsweise einen Drilldown in den CPU-Graphen durchführen, um zu sehen, welche Prozesse die CPU verwenden:
Sie können auch einen Drilldown-Vorgang in der Datenträgergrafik durchführen, um Ihre E / A-Rate, eine Aufschlüsselung der Lese- und Schreibvorgänge sowie eine Schätzung der Zeit anzuzeigen, bevor Ihre Festplatte voll ist.
Das Beste ist, Sie können für alle diese Diagramme dieselben Operationen wie für Diagramme auf Anwendungsebene verwenden. So können Sie ein fünfminütiges Fenster vergrößern, um die CPU-Auslastungsspitze genauer zu betrachten, oder Sie können einen Blick auf einen Sieben-Tage-Trend bei der Speichernutzung werfen.
Das Beste ist, die Grafiken sind einfach zu verstehen, Sie sind nicht mit Metriken überfordert und Sie können ähnliche Kästchen miteinander vergleichen. Auf diese Weise können Sie 99% der häufigsten Probleme diagnostizieren, die bei Ihrer Infrastruktur wahrscheinlich auftreten.
New Relic hat kürzlich eine Menge Arbeit geleistet, um die Alarmierungsfunktionen zu verbessern. Alert-Richtlinien sind das, was sie in ihrem gesamten System gefunden haben (z. B. gibt es Anwendungs-Alert-Richtlinien für Anwendungs- und Server-Alert-Richtlinien für Boxen). Es mag auf den ersten Blick etwas verwirrend sein, aber es ist ziemlich einfach, wenn Sie einmal den Dreh raus haben. Es gibt zwei Hauptkonzepte, Richtlinien und Kanäle. In Bezug auf Server-Alarme funktioniert das so:
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:
Sie weisen dann 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 Ausfallzeit). Sie erhalten Benachrichtigungen über diesen Kanal.
Das einzige Verwirrende an den Richtlinien für Alarme ist, wo sie zu finden sind. Sie leben unter Tools-> Benachrichtigungsrichtlinien:
Sie müssen dann auf klicken Server Klicken Sie im Menü oben auf, um Richtlinien für Serverwarnungen zu suchen.
Wenn Sie bereits eine Infrastrukturüberwachungslösung wie Nagios verwenden, die für Sie gut funktioniert, erhalten Sie durch die Überwachung des New Relic-Servers möglicherweise nicht zu viel (obwohl die Diagramme und historischen Trends sehr gut sind). Wenn Sie Ihre Infrastruktur jedoch überhaupt nicht überwachen oder Ihre aktuelle Lösung für Sie nicht funktioniert, sollten Sie New Relic auf jeden Fall ausprobieren. Für mich ist es das erste Tool, das ich verwende, wenn ich vermute, dass mit meinen Servern etwas nicht stimmt. Und oft genug wird es mich wissen lassen, dass sich die Probleme brauen, bevor die Situation kritisch wird. Als Entwickler benötigen wir alle diese Werkzeuge in unserem Arsenal.
Accentsconagua