Share
Een draaiende applicatie is niet alleen een stel codes, de code moet ook ergens draaien. Ik heb het over je productieservers. Het is net zo belangrijk om ervoor te zorgen dat uw productievakken zich gedragen zoals het is om ervoor te zorgen dat uw toepassingscode performant is. Je kunt systemen zoals Nagios opzetten om je hiermee te helpen, maar deze kunnen zeer complex zijn om mee te werken, vereisen een aanzienlijke eigen infrastructuur en kunnen een totale overkill zijn (tenzij je infrastructuurbehoeften buitengewoon complex zijn). New Relic biedt een minder compleet maar zeer eenvoudig alternatief als het gaat om het monitoren van infrastructuur.
Als u enkele van onze eerdere artikelen over New Relic hebt gelezen, zou u zich thuis moeten voelen hoe de New Relic-dashboards werken. De servercontroledashboards gebruiken dezelfde concepten. Als u New Relic al gebruikt, kunt u heel snel gegevens over uw serverprestaties ontvangen. Zelfs als u niet eerder New Relic hebt opgezet, is het misschien de moeite waard om het alleen voor servermonitoring te gebruiken. De ongeveer zes dashboards die New Relic biedt, kunnen de behoefte aan een meer complete infrastructuurbewakingsoplossing aanzienlijk vertragen (of zelfs geheel verwijderen)..
Afhankelijk van de behoeften van uw toepassing, hebt u mogelijk een webcomponent, database, cache, zoeken, load balancer enz. Sommige hiervan kunnen dezelfde box delen. Maar als uw toepassing eenmaal een bepaalde omvang heeft bereikt, begint u sommige ervan in hun eigen dozen te plaatsen. Als u slechts één productieserver hebt, zijn de dingen eenvoudig. Je SSH in dat vak, voer een paar shell-commando's uit en krijg een vrij goed idee met betrekking tot de gezondheid van die ene server. Naarmate het aantal dozen groeit, kan dit een beetje een hele klus worden. Het zou handig zijn als u een manier zou hebben om de gezondheidstoestand van al uw dozen in één keer te weten te komen. Dit is precies het probleem dat dashboards van New Relic-servers oplossen. U krijgt een momentopname van de gezondheid van al uw productieservers tegelijk.
Natuurlijk is het handmatig controleren van de gezondheid van al uw servers niet het meest efficiënte dat u kunt doen. Als er iets misgaat, wil je dat weten zodra het gebeurt, niet de volgende keer dat je besluit om het te controleren. De meeste infrastructuurbewakingssystemen hebben een manier om waarschuwingen te verzenden wanneer bepaalde delen van de bewaakte servers falen (bijv. Schijf vol, met teveel RAM enz.). Nieuwe Relic is niet anders. U kunt de zeer flexibele, alerte beleidsinfrastructuur gebruiken om foutmeldingen op elke gewenste manier te verzenden, zoals e-mail, webhaken enz.
Ten slotte komen infrastructuurproblemen vaak niet plotseling naar voren, historische context is belangrijk. RAM wordt langzaam urenlang opgegeten voordat het vak begint te falen, de schijf zal dagen vol raken voordat alles op zijn kop komt te staan. Ter plaatse controleren van uw servers geeft u niet de historische context die u nodig hebt om de problemen te voorkomen. Als je toevallig het schijfgebruik controleert wanneer het een beetje vol raakt, kun je er iets aan doen. Zo niet, dan leer je alleen over het probleem wanneer je dozen sterven. New Relic verzamelt gegevens en stuurt het de hele tijd terug naar hun servers, dus de dashboards hebben allemaal te maken met de historische context. Dit maakt het heel gemakkelijk om bepaalde klassen van problemen te voorkomen.
Ik zal je een paar verhalen vertellen. We gebruiken New Relic in Tuts + voor zowel monitoring van applicatieprestaties als servermonitoring. Een paar maanden geleden was ik op afroep, toen onze dozen zich om de paar minuten misdroegen. Ze waren niet helemaal omgevallen, maar de toepassing zou zeer slecht presteren gedurende korte perioden. Ik meldde me aan bij de vakjes en ontdekte dat het geheugengebruik erg hoog was. Dus herstartte ik de servers één voor één en het leek een tijdje goed te gaan. Maar een paar uur later begon het allemaal weer te gebeuren. Dit rook naar een geheugenlek.
Dus heb ik me aangemeld bij New Relic om de grafieken te bekijken. Zeker, een van de implementaties die we eerder hadden gedaan, introduceerde een geheugenlek in de applicatie. Het zou een paar uur duren voordat al het geheugen door de toepassing was verbruikt. Op dat moment zou het een wanhopige garbage collection-rage ingaan, met allerlei grappige problemen tot gevolg. Kijkend naar de geheugengrafieken op alle vakken was meteen duidelijk wat er aan de hand was. Op dat moment hebben we geen meldingen ingesteld (we doen het nu), dus we zijn ons niet bewust geworden van het probleem totdat er andere problemen zijn opgetreden. Maar als ik alle vakjes met elkaar kan vergelijken en de historische context kan hebben, kan ik het probleem gemakkelijk diagnosticeren, een probleem oplossen en op tijd op tijd gaan slapen..
Hier is er nog een. Onlangs was er een storing in het AWS-datacenter waar Tuts + wordt gehost. Toen de zaken eindelijk tot een goed einde kwamen, startten we alle dozen opnieuw op om er zeker van te zijn dat er geen knellende problemen waren. Maar toen de boxen terugkwamen, zou de applicatie af en toe 500 reacties retourneren of een deel van de tijd erg slecht presteren. Dit was waarschijnlijk een probleem met een of meer van de servers, wat erg vervelend is om te diagnosticeren wanneer je veel boxen hebt. Nogmaals, als we naar New Relic keken, konden we het probleem heel snel onder de aandacht brengen. Een van onze dozen kwam terug met een rogue-proces dat veel CPU's kostte, waardoor de app in die box slecht presteerde. Een ander vak werd getroffen door een of andere AWS-glitch, waardoor het gebruik van de schijf IO van die box 100% was. We haalden die doos uit onze load balancer, schrapten het rogue-proces van de andere en de applicatie begon weer prima te presteren.
De grafieken die New Relic biedt zijn echt nuttig en ik zou niet zonder willen doen, dus laat me laten zien hoe je de server-controle up and running krijgt.
In principe komt het er op neer dat u zich aanmeldt bij uw server en de New Relic server monitoring daemon installeert (nrsysmond). Als u het artikel Nieuw relikwie voor PHP hebt gelezen, is de procedure vrijwel identiek. Zoals gewoonlijk, laten we aannemen dat we op Ubuntu zijn.
Het eerste dat u moet doen, is het importeren van de New Relic-gegevensopslagsleutel:
wget -O - https://download.newrelic.com/548C16BF.gpg | sudo apt-key toevoegen -
Nu voegen we de New Relic-repository zelf toe aan het systeem:
sudo sh -c 'echo "deb http://apt.newrelic.com/debian/ newrelic non-free"> /etc/apt/sources.list.d/newrelic.list'
Nu gebruiken we het gewoon geneigd:
sudo apt-get update sudo apt-get installeer newrelic-sysmond
Nadat het klaar is met installeren, krijg je een leuk bericht zoals dit:
************************************************** ******************* *************************** ********************************** *** *** Kan het nieuwe relikwie niet starten Server Monitor totdat u een *** geldige licentiecode in het volgende bestand invoegt: *** *** /etc/newrelic/nrsysmond.cfg *** *** U kunt dit doen door het volgende commando als root uit te voeren: * ** *** nrsysmond-config --set license_key =*** *** Er worden geen gegevens gerapporteerd totdat de servermonitor kan starten. *** Je kunt je nieuwe relicatiesleutel krijgen via het gedeelte 'Configuratie' *** van het menu 'Ondersteuning' van je nieuwe relic-account (te vinden op *** https://rpm.newrelic.com). *** ************************************************ ********************** ************************ *****************************************
Laten we doen wat het zegt. Laten we eerst naar onze New Relic-accountinstellingen gaan om onze licentiecode op te zoeken (deze staat aan de rechterkant):
Laten we nu het commando uitvoeren:
nrsysmond-config --set license_key =
Als je nu het configuratiebestand checkt: /etc/newrelic/nrsysmond.cfg. Je ziet je licentiecode daar. We zijn klaar om de agent te starten:
/etc/init.d/newrelic-sysmond start
U kunt nu uw proceslijst controleren om te controleren of deze werkt:
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
Volgens de PHP-agent zijn er twee processen. Een daarvan is een monitorproces en de tweede is de werknemer. De medewerker doet eigenlijk het werk om te communiceren met de New Relic-servers, het bewakingsproces kijkt gewoon naar de werknemer en als de werker sterft, om welke reden dan ook, zal hij een nieuwe ontketenen.
We kunnen ook de logboeken controleren om er zeker van te zijn dat er geen fouten zijn bij het opstarten:
cat /var/log/newrelic/nrsysmond.log 2014-05-25 09:25:02 [10089 / main] altijd: Nieuwe Relic Server Monitor versie 1.4.0.471/C+IA gestart - pid = 10089 background = true SSL = true ca_bundle =ca_path = host = ip-10-196-10-195 2014-05-25 09:25:03 [10089 / main] info: RPM redirect: collector-102.newrelic.com (50.31.164.202) poort 0 (0 betekent standaard poort )
Alles ziet er goed uit en je zou nu moeten beginnen met het zien van gegevens in de gebruikersrelatie van New Relic.
Meestal hoeft u niets anders dan de licentiesleutel te configureren, maar als u het logniveau moet verhogen of een proxy moet configureren, is dit absoluut mogelijk. Het leeft allemaal in /etc/newrelic/nrsysmond.cfg. Het bestand is zeer goed becommentarieerd en spreekt voor zich. Als u iets verandert, denk eraan herstarten de daemon:
/etc/init.d/newrelic-sysmond restart
Er is slechts één subtiel iets als het gaat om het configureren van serverbewaking en dat is de naam van de server, zoals deze te zien zal zijn in de New Relic-dashboards. Standaard neemt New Relic de hostnaam van het vak en maakt dat de naam van de server in de dashboards (d.w.z. de uitvoer van de hostname commando). Ik raad aan dat je het zo houdt. Als u ook New Relic gebruikt voor applicatiemonitoring, houdt u de hostnaam, zoals uitgevoerd door de hostname opdracht, omdat de naam van de server ervoor zorgt dat New Relic correct kan bepalen welke toepassingen op welke vakken worden uitgevoerd en alles goed in de gebruikersinterface kan koppelen.
Als dat echt nodig is, kunt u de naam van de server wijzigen zoals deze in de gebruikersinterface wordt weergegeven door de hostnaam = parameter in het configuratiebestand: /etc/newrelic/nrsysmond.cfg. U moet de daemon opnieuw starten om deze te activeren. U kunt ook de naam van de server rechtstreeks in de gebruikersinterface wijzigen, wat de daemon niet zal beïnvloeden.
Het eerste wat je ziet als je op de Servers link aan de linkerkant is een momentopname van al uw servers en de belangrijkste statistieken voor al deze servers (CPU, schijf, geheugen, IO).
Op deze pagina kunt u zien of een of meer van uw vakken zich duidelijk misdragen. Hier kunt u de naam van een server ook wijzigen of, indien nodig, tags toevoegen.
Als we op een van de servers klikken, komen we bij het hoofdserversdashboard:
Er zijn zes belangrijke statistieken hier:
Dit geeft je een snel overzicht van een bepaalde server. U kunt in elk van de grafieken inzoomen om meer informatie te krijgen. U kunt bijvoorbeeld de CPU-grafiek doorlopen om te zien welke processen de CPU gebruiken:
Of u kunt naar de schijfgrafiek gaan om uw IO-snelheid te bekijken, een uitsplitsing van lees- en schrijfbewerkingen te lezen en een schatting te krijgen van hoe lang het zal duren voordat uw schijf vol is.
Het beste deel is dat u dezelfde bewerkingen in al deze grafieken kunt gebruiken als op grafieken op applicatieniveau. U kunt dus inzoomen op een venster van vijf minuten om de spike van het CPU-gebruik nauwkeuriger te bekijken, of u kunt een zevendaagse trend in geheugengebruik bekijken.
Het beste is dat de grafieken eenvoudig te begrijpen zijn, dat je niet overstelpt raakt met statistieken en dat je vergelijkbare vakken met elkaar kunt vergelijken. Dit kan u helpen bij het vaststellen van 99% van de veelvoorkomende problemen die u waarschijnlijk met uw infrastructuur tegen zult komen.
New Relic heeft onlangs veel werk verzet om hun waarschuwingsmogelijkheden te verbeteren. Waarschuwingsbeleid is wat ze hebben bedacht voor hun hele systeem (er zijn bijvoorbeeld toepassingswaarschuwingsbeleid voor beleid voor toepassingen en serverwaarschuwingen voor vakken). Het kan in het begin wat verwarrend zijn, maar het is vrij simpel als je het eenmaal onder de knie hebt. Er zijn twee hoofdbegrippen, beleid en kanalen. In termen van serverwaarschuwingen werkt het als volgt:
We hebben een beleid ingesteld en er enkele servers aan toegewezen:
U maakt ook een kanaal (bijvoorbeeld e-mail, webhook) waaraan waarschuwingen kunnen worden verzonden:
Vervolgens wijst u een kanaal toe aan een beleid. Vanaf dat moment afhankelijk van de instellingen voor het kanaal (bijvoorbeeld de eerste kritieke gebeurtenis, alle kritieke gebeurtenissen, alleen uitvaltijd). Je ontvangt meldingen op dat kanaal.
Het enige verwarrende deel over waarschuwingsbeleid is waar je ze kunt vinden. Ze leven onder Hulpmiddelen-> Waarschuwingsbeleid:
U moet dan op klikken Servers in het menu bovenaan om serverwaarschuwingsbeleid te vinden.
Als je al een infrastructuur monitoring oplossing zoals Nagios gebruikt en het werkt goed voor je, dan krijg je misschien niet teveel extra van New Relic server monitoring (hoewel de grafieken en historische trends best goed zijn). Als u echter uw infrastructuur helemaal niet bewaakt of als uw huidige oplossing niet voor u werkt, kunt u New Relic zeker een kans geven. Voor mij is het de eerste tool geworden waar ik naar toe ga als ik vermoed dat er iets mis is met mijn servers. En vaak laat het me weten dat er problemen ontstaan voordat de situatie kritiek wordt. Als ontwikkelaars, dat is het soort tools dat we allemaal willen in ons arsenaal.
Accentsconagua