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

5 Gründe, warum New Relic der beste Freund eines Entwicklers ist

by
Length:LongLanguages:
This post is part of a series called Performance Monitoring With New Relic.
Getting Started With New Relic in 30 Minutes
3 New Relic Power Features You Should Be Using Today
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 Valentina (you can also view the original English article)

Sobald Sie sich mit New Relic befassen, werden Sie feststellen, wie viele interessante Funktionen der Dienst zur Überwachung der Leistung und des Zustands Ihrer Anwendung bietet. Es war wirklich schwierig, nur fünf Dinge auszuwählen, über die gesprochen werden sollte. Statt sich auf die offensichtlichen Merkmale zu konzentrieren, schauen wir uns einige der weniger gehypten Funktionen an, die New Relic bietet, und wie wir sie auf interessante und manchmal unorthodoxe Weise verwenden können.

Als wir Sie das letzte Mal verlassen haben, hatten wir eine grundlegende 'Hello World'-Rails-Anwendung (New Relic_rails1, die in ~/project/tmp/New Relic lebt). Wir werden diese App weiterhin verwenden, erweitern und prüfen, ob wir damit die Funktionen von New Relic demonstrieren können, die wir uns ansehen werden.

Gesponserte Inhalte

Dieser Inhalt wurde von New Relic in Auftrag gegeben und vom Tuts+-Team geschrieben und/oder bearbeitet. Unser Ziel mit gesponserten Inhalten ist es, relevante und objektive Tutorials, Fallstudien und inspirierende Interviews zu veröffentlichen, die unseren Lesern einen echten pädagogischen Wert bieten und es uns ermöglichen, die Erstellung nützlicherer Inhalte zu finanzieren.


Verfügbarkeitsüberwachung

Dies ist eine New Relic-Funktion, die normalerweise nicht die Titelseite des Marketingmaterials bildet. Es steckt nicht viel dahinter, aber wenn Sie darüber nachdenken, was ist wichtiger, als sicherzustellen, dass Ihre App tatsächlich läuft und für Ihre Benutzer zugänglich ist?

Erstens, wenn Sie die Verfügbarkeitsüberwachung einrichten, wird Ihre Anwendung in Ihrem Hauptanwendungs-Dashboard mit einem schönen Sternchen versehen:

newrelic_availability_asterisk

Es ist eine schöne visuelle Erinnerung, sodass Sie sehen können, für welche Apps die Verfügbarkeitsüberwachung noch aktiviert sein muss.

Schauen wir uns nun an, wie wir die Verfügbarkeitsüberwachung einrichten und was wir daraus machen können. Zuerst müssen Sie in Ihre Anwendung springen und dann zu Einstellungen->Verfügbarkeitsüberwachung gehen. Sie werden so etwas sehen:

newrelic_availability_monitoring

Sie müssen eine URL angeben, an die New Relic pingen soll, das Kästchen ankreuzen, Ihre Änderungen speichern und loslegen. New Relic trifft alle 30 Sekunden auf Ihre URL. Aber der Spaß hört hier nicht auf. New Relic pingt Ihre URL über eine HTTP-HEAD-Anforderung (und hält alles für OK, wenn ein 200-Antwortcode empfangen wird). Sie können jedoch eine Antwortzeichenfolge angeben, nach der New Relic suchen soll. In diesem Fall führt es eine GET-Anforderung aus und Überprüfen Sie die Antwort für die von Ihnen angegebene Zeichenfolge. Dies kann sehr praktisch sein, wenn Sie eine benutzerdefinierte Seite "Gesundheitscheck" haben, auf die Sie klicken möchten.

Sie können auch eine E-Mail-Benachrichtigung einrichten, wenn Ausfallzeiten auftreten:

newrelic_availability_notifications

Nachdem Sie die Verfügbarkeit überwacht haben, haben Sie Zugriff auf einen schönen Bericht, der Ihnen visuell anzeigt, wenn Ausfallzeiten aufgetreten sind:

newrelic_availability_report

Tatsächlich haben viele Ihrer Diagramme (z. B. die Anwendungsübersicht) diese visuelle Anzeige:

newrelic_availability_overview

Sie müssen zugeben, dass dies eine ziemlich nette Funktionalität für so wenig Aufwand ist.

Sie können die Überwachung natürlich deaktivieren und wieder aktivieren (über die New Relic REST-API), wenn Sie Bereitstellungen durchführen, um sicherzustellen, dass keine falschen Ausfallzeiten auftreten.

Ein weiterer interessanter Nebeneffekt ist, dass Sie, wenn Sie Ihr Haustierprojekt auf einem einzelnen Prüfstand für Heroku bereitstellen, diese Ping-Funktion verwenden können, um zu verhindern, dass Ihr Prüfstand schläft, was Ihre Website ärgerlich langsam machen kann, wenn Sie keinen haben viel Verkehr.


Benutzerdefinierte Fehleraufzeichnung

Wenn in Ihrer Anwendung unerwartete Fehler auftreten, zeichnet New Relic diese für Sie auf und gibt Ihnen ein schönes Diagramm. Unsere kleine 'Hello World'-App hat im Moment eine bewundernswerte Leistung erbracht, sodass wir an dieser Front nichts zu sehen haben. Aber wir können absichtlich unsere App brechen und sehen, was New Relic uns bietet.

Lassen Sie uns unseren HelloController so ändern, dass in etwa 50% der Fälle zufällig ein Fehler auftritt:

Wir werden jetzt ein paar hundert Anrufe bei unserer App tätigen und sehen, was passiert:

Unser New Relic-Fehlerdiagramm sieht jetzt viel interessanter aus:

newrelic_error_overview

Und wir können einen Drilldown durchführen, um einige Einzelheiten zu erfahren:

newrelic_error_detailed

Wie Sie sehen, können wir unsere Fehler sortieren und filtern sowie Fehler aus Webanfragen und Hintergrundaufgaben separat betrachten. Dies ist ein unglaublich leistungsfähiges Material, mit dem Sie Probleme mit Ihrer Anwendung diagnostizieren und beheben können. Sie können natürlich auch die Stapelverfolgung für jeden Fehler sehen:

newrelic_error_trace

Es gibt Dienste, die speziell für die Erfassung von Fehlern in Ihrer Anwendung vorgesehen sind. Einige der bekanntesten sind Airbrake und Bugsnag. Hierbei handelt es sich um kostenpflichtige Dienste, die von vielen Anwendungen verwendet werden. Die von New Relic bereitgestellten Funktionen machen diese Dienste jedoch überflüssig. Wenn wir benutzerdefinierte Fehler an New Relic senden könnten (anstatt Fehler erfassen zu lassen, die wir nicht gerettet haben), könnten wir überzeugend dafür eintreten, keinen separaten Fehlersammeldienst zu verwenden (und etwas Geld sparen und einen zusätzlichen Fehler beseitigen) Juwel im Prozess).

Während New Relic keine Möglichkeit dokumentiert, dies zu tun, können wir jederzeit zur Quelle gehen, um zu sehen, ob das, was wir tun möchten, schwierig ist. Es scheint mir ziemlich trivial zu sein, benutzerdefinierte Fehler an New Relic zu senden. Probieren wir es also aus. Wir werden unsere Controller-Aktion erneut ändern, um alle Fehler zu beheben und einen benutzerdefinierten Fehler an New Relic zu senden:

Nachdem wir noch ein paar Anrufe getätigt und darauf gewartet haben, dass die Daten eingehen, sehen wir Folgendes:

newrelic_error_custom

Es hat funktioniert, unser benutzerdefinierter Fehler kommt durch! New Relic kann definitiv als unser Fehlererfassungsservice fungieren. Wir verwenden hier natürlich eine private Schnittstelle, was nicht sehr schön ist, aber wir können den Aufruf notice_error hinter eine Fassade setzen, die uns die Dinge ein wenig erleichtert, wenn sich die Schnittstelle ändert.

Ein noch besserer Ansatz könnte darin bestehen, benutzerdefinierte Fehler überhaupt nicht wie normale Fehler zu behandeln, sondern stattdessen eine benutzerdefinierte Metrik zum Verfolgen zu erstellen und anschließend ein benutzerdefiniertes Dashboard zum Visualisieren zu erstellen. Auf diese Weise verwenden wir keine undokumentierten Funktionen und würden trotzdem alle Vorteile erhalten - brillant!


Verfolgung wichtiger Transaktionen

New Relic verfolgt normalerweise Ihre Transaktionen für Sie:

newrelic_transaction_tracking

Sie können sehen, wo Ihre Anwendung die meiste Zeit verbringt (z. B. im Controller, Modell, in der Datenbank usw.). New Relic erfasst jedoch keine detaillierte Ablaufverfolgung, es sei denn, die Transaktion dauert länger als Appdex * 4 Sekunden. Normalerweise ist dies in Ordnung, aber manchmal haben Sie Transaktionen, die für Ihre Anwendung oder Ihr Unternehmen viel wichtiger sind. Möglicherweise haben diese Transaktionen ein extrem hohes Volumen oder befassen sich mit wichtigen Ereignissen wie Zahlungen. Es genügt zu sagen, dass Sie sicherstellen müssen, dass diese Art von Transaktion immer sehr gut funktioniert.

Die Sache ist jedoch, wenn eine Transaktion so wichtig ist, hat sie wahrscheinlich bereits viel Liebe von Ihnen erhalten und kann ziemlich gut abschneiden. Angenommen, Sie haben eine Transaktion mit einem extrem hohen Durchsatz (tritt mehrmals pro Minute auf). Wenn diese Transaktion optimal ausgeführt wird, ist alles in Ordnung. Sollte sich die Leistung jedoch aufgrund des Verkehrsaufkommens geringfügig verschlechtern, kann dies sich überproportional nachteilig auf Ihre Anwendung auswirken. Was Sie wollen, ist so etwas wie:

  • ein separater Apdex T-Wert nur für diese Transaktion
  • die Fähigkeit, Warnungen zu erhalten, wenn sich die Leistung dieser Transaktion verschlechtert
  • eine detaillierte Ablaufverfolgung jedes Mal, wenn diese Transaktion auch nur geringfügig nicht optimal ausgeführt wird

Genau das bieten Ihnen wichtige Schlüsseltransaktionen!

Bevor wir eine wichtige Transaktion für unsere 'Hello World'-App einrichten, müssen wir eine interessantere Transaktion erstellen, die normalerweise gut, manchmal aber auch etwas schlecht abschneidet. Wir werden die Fähigkeit aufbauen, Automarken und -modelle zu betrachten und eine bestimmte Automarke zu erhalten, um die Transaktion zu verlangsamen. Erstens die Route:

Wir wollen in der Lage sein, ein zufälliges Auto zu bekommen, dies wird dem CarsController zugeordnet:

Wir bekommen ein zufälliges Auto aus der Datenbank und wenn die Automarke 'Ford' ist, haben wir eine langsame Transaktion in unseren Händen. Natürlich brauchen wir ein Car-Modell:

Wir müssen unsere Datenbank so konfigurieren, dass MySql in der Entwicklung verwendet wird (ich habe dies getan, aber Sie können sich an sqlite halten):

Wir brauchen eine Migration, um eine cars-Tabelle zu erstellen:

Und wir brauchen einige Seed-Daten, die wir in unsere Datei db/seeds.rb einfügen:

Zuletzt sollten wir uns wahrscheinlich die Ansicht cars/show_random.html.erb ansehen:

Sie müssen auch den mysql2-Edelstein zur Gemfile hinzufügen, wenn Sie sich für MySql entschieden haben. Danach müssen wir nur noch die Datenbank erstellen und füllen, unseren Server neu starten und los geht's:

Sie müssen die URL eingeben, um sicherzustellen, dass New Relic erkennt, dass diese Transaktion vorhanden ist:

Wir sind jetzt bereit, diese Transaktion als Schlüsseltransaktion zu überwachen. Wechseln Sie zunächst in die Registerkarte Transaktion:

newrelic_transaction_tab

Klicken Sie auf die Schaltfläche 'Verfolgen einer Schlüsseltransaktion' und wählen Sie unsere neu erstellte Transaktion aus:

newrelic_transaction_create

Wir können unserer neuen Schlüsseltransaktion einen Namen geben, den Apdex T auswählen, mit dem wir zufrieden sind, und einige Warnungen einrichten. Wenn unsere Transaktion länger dauert als der von uns ausgewählte Apdex, erfasst New Relic eine detaillierte Ablaufverfolgung, anhand derer wir herausfinden können, woher das Leistungsproblem stammt. Lassen Sie uns ein paar Anrufe über unsere neue URL tätigen und sehen, welche Daten wir erhalten:

Hmm, es scheint, dass einige unserer Transaktionen unsere Benutzer frustrieren:

newrelic_transaction_frustrating

Mal sehen, ob New Relic einige Transaktionsspuren für uns erfasst hat:

newrelic_transaction_slow_traces

Schauen wir uns eine dieser Spuren an. Die Antwort dauerte ungefähr 2 Sekunden, aber nur 10 Millisekunden verwendeten die CPU:

newrelic_transaction_cpu_burn

Alle unsere SQL-Anweisungen waren schnell, sodass die Datenbank nicht das Problem ist:

newrelic_transaction_sql_trace

Es sieht so aus, als würde die meiste Zeit in der Controller-Aktion verbracht:

newrelic_transaction_controller_action

Lassen Sie uns ein wenig in die Spur graben. Es sieht so aus, als ob SQL SELECT schnell war, ein Car.find war auch schnell. Dann verlieren wir ungefähr 2 Sekunden, worauf ein sehr schnelles Rendern von Vorlagen folgt:

newrelic_transaction_trace_detail

New Relic hat freundlicherweise für uns hervorgehoben, wo wir diese zwei Sekunden verloren haben. Nach einem Car.find-Aufruf müssen wir uns unseren Controller-Code ansehen:

Hmm, das anfängliche SELECT muss der Car.count-Aufruf sein, und das Car.find muss auf den Car.offset-Aufruf zurückzuführen sein. Unsere große Verzögerung ist jedoch gleich danach. Ahh schau dir das an, eine dumme Person hat unseren Code um 2 Sekunden verzögert, wenn die Marke des Autos 'Ford' ist. Das würde erklären, warum unsere Verzögerung von 2 Sekunden nur manchmal auftritt. Ich gebe unserem Repository besser git blame, um herauszufinden, wer diesen schrecklichen Code dort abgelegt hat! Bei zweiten Gedanken, ich besser nicht, weil es sagen könnte, dass ich es war.


Externe Service-Anrufaufzeichnung

Wenn Sie in Ihrer App andere Dienste anrufen (z. B. eine HTTP-Anfrage an eine API wie Twitter), überwacht New Relic diese als externe Anrufe. Heutzutage kann eine seriöse Anwendung in eine Reihe externer APIs integriert werden. Oft können diese externen Dienste die Leistung Ihrer App erheblich beeinträchtigen, insbesondere wenn Sie diese Anrufe in Bearbeitung tätigen. New Relic kann anzeigen, welche Ihrer externen Anrufe am langsamsten sind, welche Sie am meisten anrufen und welche im Durchschnitt am langsamsten reagieren. Sie können auch die Leistung jedes externen Dienstes überprüfen, den Sie einzeln verwenden. Lassen Sie es uns versuchen.

Wir erstellen einen eigenen externen Service, indem wir eine kleine Sinatra-App erstellen. Zuerst installieren wir den Edelstein:

Erstellen Sie eine neue Datei für unseren Service:

Und geben Sie dort den folgenden Code ein:

Dieser Dienst wird für eine zufällige Zeit (zwischen 0 und 2000 Millisekunden) in den Ruhezustand versetzt und gibt dann mit der Zeit, in der er geschlafen hat, eine Antwort 'Hallo' zurück. Jetzt müssen wir es nur noch starten:

Zurück in unserer Rails-App bauen wir einen neuen Controller, um unseren externen Service aufzurufen. Wir werden diese Route benutzen:

Unser Controller ruft unseren Sinatra-Service über HTTP auf:

Und wir brauchen eine Ansicht, um die Ergebnisse anzuzeigen:

Jetzt müssen wir nur noch ein paar Anrufe an unseren neuen Endpunkt tätigen:

Mal sehen, was New Relic für uns produziert hat.

newrelic_transaction_external_service

New Relic hat tatsächlich unseren neuen externen Anruf entgegengenommen. Wir haben die Gesamtzahl der Anrufe pro Minute, die wir an den externen Endpunkt tätigen. Und die Summe, die der externe Dienst für die Beantwortung aufgewendet hat. Natürlich sieht unser Diagramm etwas spärlich aus, da wir nur einen externen Service haben, was bedeutet, dass wir nichts zu vergleichen haben.

Wir können auch detailliertere Daten über den spezifischen externen Anruf erhalten sowie darüber, woher dieser Anruf in unserer App stammt:

newrelic_transaction_external_call

Wir können sehen, wann die Anrufe getätigt wurden, den Durchsatz und die durchschnittliche Antwortzeit. Dies mag einfach erscheinen, aber wenn Sie eine App mit vielen externen Diensten haben, kann diese Funktion Ihnen einen sehr schönen Überblick über die Leistung dieser externen Dienste sowie darüber geben, wann und wo sie verwendet werden. Auf diese Weise können Sie Entscheidungen zum Zwischenspeichern bestimmter externer Dienstantworten treffen oder bestimmte externe Dienste löschen, wenn deren Leistung nicht auf dem neuesten Stand ist. Und Sie müssen diese Dinge nicht länger auf der Grundlage von Bauchgefühl und hausgemachten Metriken diskutieren, sondern verfügen über harte Daten, um Ihren Standpunkt für Sie zu beweisen.

Skalierbarkeits- und Kapazitätsanalyse

Es gibt nichts Frustrierenderes für einen Entwickler, als wenn Ihre Anwendung aufgrund eines Verkehrsspitzen umkippt. Alles lief reibungslos, bis diese zusätzlichen paar hundert Benutzer kamen und Ihre Anwendung explodierte. Sie hatten das Gefühl, dass dies passieren könnte, konnten sich aber nicht sicher sein - die abwartende Haltung schien der pragmatischste Ansatz zu sein. Mit den Kapazitäts- und Skalierbarkeitsberichten von New Relic müssen Sie nicht länger abwarten. Sie können sofort feststellen, wie gut Ihre App skaliert, Sie können Auslastungstests durchführen und sofort feststellen, ob Ihre Anwendung die Auslastung bewältigen kann. Sie können die Antwortzeittrends Ihrer Anwendung beobachten, wenn Ihre Benutzerbasis wächst, und vorhersagen, wann Sie Kapazität hinzufügen müssen. All das sind wirklich wundervolle Dinge.

Schauen wir uns zunächst die Kapazitätsberichte an:

newrelic_capacity_instance_busy

Hmm, dieser zeigt eine große Spitze, aber sonst nichts. Nun, wir laufen im Entwicklungsmodus, das ist also verständlich. Dieser Anstieg ist darauf zurückzuführen, dass wir vor einiger Zeit eine Reihe von Anfragen gleichzeitig gestellt haben. Wie Sie sehen können, haben wir bei dieser gleichzeitigen Anfrage unsere arme, einsame Webrick-Instanz voll ausgeschöpft. Wenn dies Produktion wäre und diese Last konstant wäre, wäre unsere Instanz immer zu 100% ausgelastet, was wahrscheinlich darauf hinweisen würde, dass wir eine andere Instanz benötigen.

Der Instanzanalysebericht unterscheidet sich geringfügig:

newrelic_capacity_instance_analysis

In unserem Fall haben wir nicht viel davon, aber es zeigt uns normalerweise die Anzahl der ausgeführten Instanzen und die Anzahl der Instanzen, die wir tatsächlich benötigen, um die Last zu bewältigen, wenn alle Instanzen zu 100% ausgelastet sind. Wenn wir also 10 Instanzen ausführen und die gleichzeitige Instanzlast 2 beträgt, können wir die Anzahl der ausgeführten Instanzen leicht halbieren (oder sogar mehr als halbieren) und die Leistung überhaupt nicht beeinträchtigen. Für eine kleine App, die nur wenige Instanzen ausführt, ist dies keine große Sache, aber für eine große Anwendung mit Dutzenden und Hunderten von Instanzen kann dies zu erheblichen Kosteneinsparungen führen.

Und dann gibt es die Skalierbarkeitsberichte. Der Antwortzeitbericht ist wahrscheinlich der interessanteste/wichtigste:

newrelic_scalability_response

Wieder einmal ist unser Diagramm sehr verzerrt, da es sich um eine Entwicklungs-App handelt, mit der wir zufällig herumgespielt haben. Die Idee mit diesem Bericht ist, dass mit zunehmendem Durchsatz für Ihre Anwendung (mehr Anforderungen pro Minute) die Antwortzeit nahezu konstant bleiben sollte (d. h. Die Leistung verschlechtert sich nicht, wenn mehr Verkehr vorhanden ist). Dies bedeutet, dass Sie hier immer etwas sehen sollten, das einer flachen Linie ähnelt. Wenn Ihre Leitung erheblich nach oben abfällt, hat Ihre App wahrscheinlich Probleme, den Datenverkehr zu bewältigen, und Sie müssen möglicherweise versuchen, mehr Kapazität hinzuzufügen. Wo Kapazität hinzugefügt werden kann, ist eine andere Frage (z. B. Datenbankkapazität, mehr Server usw.). Die beiden anderen Skalierbarkeitsberichte können Ihnen bei der Beantwortung helfen. Es gibt den Datenbankbericht:

newrelic_scalability_database

Sie können nicht erwarten, dass Ihre Datenbank nicht durch eine höhere Auslastung beeinträchtigt wird. Was Sie hier sehen sollten, ist eine Zeile, die mit zunehmendem Durchsatz Ihrer Anwendung langsam ansteigt. Es liegt an Ihnen, wann die Datenbankantwortzeit als inakzeptabel eingestuft wird (d. h. Die Antwort der Anwendung zu stark beeinflusst), aber wenn Sie entscheiden, dass die Datenbankantworten zu langsam sind, wissen Sie, dass es Zeit ist, die Datenbankkapazität hinzuzufügen. Der andere Bericht ist die CPU:

newrelic_scalability_cpu

Auch hier können Sie nicht wirklich erwarten, dass ein höherer Durchsatz Ihre CPU-Auslastung nicht beeinflusst. Sie sollten eine Linie sehen, die mit zunehmendem Durchsatz langsam ansteigt. Zusammen mit den zuvor erwähnten Kapazitätsberichten können Sie entscheiden, wann weitere Rails-Prozesse/Server hinzugefügt werden sollen, um sicherzustellen, dass Ihre Leistung angemessen bleibt.


Abschluss

Wenn eine oder alle dieser Funktionen eine Augenbraue (oder zwei) für Sie hochgezogen haben, ist die gute Nachricht, dass wir gerade erst die Oberfläche zerkratzt haben. Jedes dieser Merkmale verdient mehr als einen eigenen ausführlichen Artikel. New Relic bietet jedoch auch eine Reihe anderer Funktionen, die möglicherweise noch leistungsfähiger sind. Dazu gehören die Überwachung realer Benutzer, die New Relic-Plattform, der Thread-Profiler, Warnschwellenwerte und Benachrichtigungen sowie viele andere. Wir werden versuchen, einige oder vielleicht sogar alle in späteren Tutorials zu behandeln.

Probieren Sie New Relic zunächst aus, stellen Sie einen Agenten in Ihrer bevorzugten Sprache bereit und prüfen Sie, ob Sie eine sofort einsatzbereite Möglichkeit finden, einige der von New Relic bereitgestellten Funktionen zu nutzen. Und wenn Sie einige innovative Möglichkeiten zur Verwendung von New Relic haben, teilen Sie dies allen mit, indem Sie einen Kommentar hinterlassen.

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.