Share
Vi har tidligere dekket hvordan du konfigurerer New Relic for en Rails-app, så vel som brukt mye tid på hvordan du bruker New Relic-brukergrensesnittet. Og mens brukergrensesnittet er veldig lik, uavhengig av hvilket språk og rammeverk du bruker, kan det faktisk være radikalt annerledes å få New Relic satt opp. I dag vil vi se på hvordan du overvåker en PHP-applikasjon ved hjelp av New Relic. Mer spesifikt vil vi sette opp en grunnleggende WordPress-installasjon og få noen ytelsesdata om den, i New Relic-oversikten.
Få New Relic satt opp for Ruby er veldig mye miljø agnostisk. Vi legger ganske enkelt til agentens perle til vår søknad, uansett hvordan vi distribuerer vår app (Passenger + Apache, Thin + Nginx etc.), vil perlen gjøre resten av arbeidet for å sikre at vi får våre ytelsesstatistikker. Med PHP-versjonen av agenten er miljøet mye viktigere, ettersom agenten er installert og lever på boksen der applikasjonen vil bli distribuert, i stedet for å være en del av en bestemt app.
La oss sette opp en sandkasse for at vi skal leke med (ved hjelp av en EC2-forekomst) og få en grunnleggende WordPress-installasjon og kjøring.
Vi vil ikke gå inn i for mye detalj her, siden de fleste av tingene vi trenger å gjøre er godt dokumentert andre steder. Men her er en grunnleggende oversikt.
Vi må starte en EC2-forekomst med Ubuntu Server 12.04 LTS på den. Hvis du ikke vil sette opp en EC2-forekomst, kan du bare opprette en virtuell maskin i stedet ved hjelp av VirtualBox (eller ditt VM-verktøy som du velger). Hvis du setter opp en EC2-forekomst, må du huske å gjøre følgende:
Bortsett fra det, bør alt annet være ganske rett frem og du bør ende med en løpende forekomst (eller virtuell maskin) som er klar for neste trinn.
Vi må nå installere Apache, PHP og MySQL. Med Ubuntu Server, bør det være et enkelt spørsmål om å kjøre følgende kommandoer:
sudo apt-get install tasksel sudo tasksel installere lampe-server
Du må velge LAMP i brukergrensesnittet, og du må også skrive inn ditt MySQL-passord når du blir bedt om å gjøre det (jeg bare la det være tomt siden vi ikke bryr oss om at denne boksen er sikker på noen måte). Når installasjonen er fullført, kan vi deretter kjøre noen få kommandoer for å sikre at alt installeres uten problemer.
Kontroller først at Apache er installert:
ubuntu @ ip-10-145-246-196: ~ $ apache2 -V Serverversjon: Apache / 2.2.22 (Ubuntu) Server bygget: 12. juli 2013 13:37:10 Serverens modul Magic Number: 20051115: 30 Server lastet: APR 1.4.6, APR-Util 1.3.12 Utarbeidet med: APR 1.4.6, APR-Util 1.3.12 Arkitektur: 64-biters server MPM: Prefork gjenget: Nei forked: ja (variabel prosess telling) ...
For det andre, sjekk at vi har PHP:
ubuntu @ ip-10-145-246-196: ~ $ php -i phpinfo () PHP versjon => 5.3.10-1ubuntu3.10 System => Linux ip-10-145-246-196 3.2.0-58- virtuell # 88-Ubuntu SMP Tue Des 3 17:58:13 UTC 2013 x86_64 Bygningsdato => 28 februar 2014 23:13:16 Server API => Kommandolinjegrensesnitt Virtual Directory Support => Funnet konfigurasjonsfil (php.ini) Sti => / etc / php5 / cli Lastet konfigurasjonsfil => /etc/php5/cli/php.ini...
Og så sjekk at vi har MySQL:
ubuntu @ ip-10-145-246-196: ~ $ mysql --versjon mysql Ver 14.14 Distrib 5.5.35, for debian-linux-gnu (x86_64) ved hjelp av leselinje 6.2
Vi må kanskje også sjekke at PHP faktisk er aktivert i Apache-konfigurasjonen, men siden vi installerte lampe-server ved hjelp av tasksel Vi kan være ganske sikre på at det er (og vi kan alltid gjøre en rask phpinfo () skript hvis vi virkelig vil sjekke).
Vi kan nå installere WordPress. Før vi faktisk laster ned det, må vi sette opp en database for det slik. Vi kan bare følge instruksjonene fra Codex:
ubuntu @ ip-10-145-246-196: ~ $ mysql Velkommen til MySQL-skjermen. Kommandoer slutter med; eller \ g. Din MySQL-tilkoblings-ID er 103 Serverversjon: 5.5.35-0ubuntu0.12.04.2 (Ubuntu) Skriv 'hjelp;' eller '\ h' for hjelp. Skriv '\ c' for å slette gjeldende inntasting. mysql> CREATE DATABASE myblog1; Forespørsel OK, 1 rad berørt (0.00 sek) mysql> Gi alle privilegier på myblog1. * TIL "myblog1_user" @ "localhost" IDENTIFISERT AV "abc123"; Spørsmål OK, 0 rader berørt (0.00 sek) mysql> FLUSH PRIVILEGES; Spørsmål OK, 0 rader berørt (0,01 sek) mysql> EXIT Bye
Jeg skal ringe til vår nye installasjon myblog1 (så databasen for den heter også myblog1). Vi må nå kjøre følgende kommandoer for å få vår blogg kjører (ikke glem å sudo når nødvendig):
cd / var / www wget http://wordpress.org/latest.tar.gz tar -xzvf latest.tar.gz mv wordpress myblog1 cd myblog1 mv wp-config-sample.php wp-config.php
Fyll i databasenavnet ditt, brukernavn og passord i config-filen (vertsnavnet er lokal vert som er der som standard). På dette tidspunktet bør du kunne gå til nettleseren din, slå den riktige nettadressen (i mitt tilfelle http://ec2-107-20-122-116.compute-1.amazonaws.com/myblog1) og WordPress vil gjøre sin ting (det kan ikke skade for å starte Apache på nytt før du gjør dette sudo apache2 service restart).
Vår sandkasse er nå fullført, og vi kan komme i gang med å installere New Relic.
Som jeg tidligere nevnte, ligger PHP New Relic-agenten på boksen, det er derfor fornuftig at du kan installere det ved hjelp av operativsystemets pakkebehandler (apt-get siden vi bruker Ubuntu). Den første tingen å gjøre er å importere New Relic-depotnøkkelen:
wget -O - https://download.newrelic.com/548C16BF.gpg | sudo apt-key add -
Nå legger vi New Relic-depotet til systemet:
sudo sh-c 'echo "deb http://apt.newrelic.com/debian/ newrelic non-free"> /etc/apt/sources.list.d/newrelic.list'
På dette punktet kan vi bruke standard apt kommandoer for å installere agenten:
sudo apt-get oppdatering sudo apt-get install newrelic-php5
Dette henter PHP-agentpakken fra depotet og setter agentinstallasjonsskriptet på systemet. Skriptet kalles newrelic-install og det lever i / Usr / bin, så du bør kunne komme inn fra hvor som helst. Skriptet heter også noe dessverre, da du kan bruke det til både å installere og avinstallere New Relic fra systemet. For å kunne installere New Relic, må vi kjøre:
newrelic-install install
Skriptet er interaktivt og vil be deg om å skrive inn lisensnøkkelen. Du kan finne dette ved å trykke på stor rød knapp når du setter opp et nytt PHP-program i New Relic-brukergrensesnittet.
Hvis du har mer enn en PHP-installasjon på systemet ditt, vil det også be deg om å velge hvilken installasjon New Relic skal installeres for (du kan velge et hvilket som helst antall installasjoner inkludert alle). Hvis du bare har den ene PHP på systemet, vil skriptet bare bruke det. Det er verdt å merke seg at hvis din versjon av PHP er eldre enn 5,2, vil skriptet kausjonere da eldre versjoner ikke støttes.
Hvis alt går bra, bør du se følgende melding:
New Relic er nå installert på systemet ditt. Gratulerer!
Skriptet vil da skrive ut litt ekstra informasjon for deg, inkludert plasseringen av loggfilene:
/var/log/newrelic/newrelic-daemon.log /var/log/newrelic/php_agent.log
I tillegg til at du må starte webserveren din på nytt (og PHP-FPM hvis du bruker den).
Hvis du starter serveren på nytt og haler demonloggen, bør du se noe slikt:
ubuntu @ ip-10-145-246-196: / var / www / myblog1 $ cat /var/log/newrelic/newrelic-daemon.log 2014-03-23 05: 30: 41.063 (2008 / main) advarsel: nåværende filgrense på 1024 er for lav - forsøker å øke den 2014-03-23 05: 30: 41.064 (2008 / hoved) info: økt filgrense til 2048 2014-03-23 05: 30: 41.064 (2008 / hoved) info : New Relic 4.6 (utgivelsesbygning 40 - "quetzalcoatlus" - "e3d29c5a2e5dc1ee455e831d589ecf5e18c7d6f0") [arbeidere = 1 listen = "/ tmp / .newrelic.sock" pid = 2008 ppid = 2007 uid = 0 euid = 0 gid = 0 egid = 0 backtrace = no os = "Linux" rel = "3.2.0-58-virtuell" mach = "x86_64" ver = "# 88-Ubuntu SMP Tirsdag Des 3 17" node = "ip-10-145-246-196" oppstart = agent] 2014-03-23 05: 30: 41.069 (2008 / hoved) info: RPM config: proto = "https" samler = "collector.newrelic.com" proxy = "none" certfile = "/ etc / ssl /certs/ca-certificates.crt "certdir =" / etc / ssl / certs "2014-03-23 05: 35: 14.928 (2008 / kontakt) info: ['PHP Application'] 'Rapportering til: https: // rpm.newrelic.com/accounts/232928/applications/3262356'
Noe som heter PHP-applikasjon rapporterer. Dette er noe generisk og ser ikke ut som vår WordPress-blogg, men det er en god start. Hva dette betyr er at alle applikasjoner på webserveren din kjører og rapporterer som det samme programmet til New Relic. Denne applikasjonen har et standardnavn på PHP-applikasjon.
I vårt tilfelle, siden vi bare kjører ett program (vår WordPress installasjon), kunne vi faktisk hoppe inn i New Relic brukergrensesnittet og få rimelig statistikk for vår blogg. Men selvfølgelig vil vi gi bloggen et bedre navn, og bare hvis vi ønsker at serveren vår skal tjene mer enn ett program. Vi vil også se hvordan du kan skille apper fra hverandre. Vi vil se på hvordan du gjør dette innen kort tid, men før vi gjør det, la oss se hva som egentlig utgjør en PHP-agent.
Det er to deler til New Relic PHP agent. Den første er en PHP-utvidelse, det heter et delt objekt newrelic.so. Hvis vi ser på agentkonfigurasjonsfilen:
/etc/php5/cli/conf.d/newrelic.ini
Vi kan se den oppført øverst:
; Denne filen inneholder de forskjellige innstillingene for New Relic PHP-agent. Der ; er mange alternativer, som alle er beskrevet i detalj på følgende URL:; https://newrelic.com/docs/php/php-agent-phpini-settings; ; Hvis du bruker en full bane til forlengelsen, isolerer du deg selv fra; Utvidelseskatalog endres hvis du endrer PHP-installasjoner eller versjoner. ; Hvis du ikke bruker en absolutt sti, må filen installeres i; Aktiv konfigurasjon er utvidet katalog. utvidelse = "newrelic.so"
Dette er saken som faktisk vil samle statistikken fra appene dine, men det vil ikke sende statistikken til New Relic, dette er jobben til proxy-demonen.
Agentdemonen er en proxy mellom PHP-utvidelsen og New Relic-serverne. I hovedsak vil PHP-utvidelsen gi dataene det samler inn til demonen, og daemonen vil gjøre ting som å pakke opp og finne ut når du skal sende den til serveren. Du må alltid sørge for at demonen kjører, ellers vil ingen data bli sendt til New Relic. Heldigvis, som standard, når du starter serveren din igjen, vil PHP-utvidelsen forsøke å oppdage om demonen kjører og vil starte den, hvis den ikke er.
En løpende proxy-demon har to prosesser. Den ene er en skjermprosess, og den andre er arbeideren. Arbeidsgiveren jobber faktisk med å kommunisere med New Relic-servere, overvåkingsprosessen ser bare på arbeideren, og hvis arbeideren dør, uansett grunn, vil den gyte en ny. Du kan stoppe demonen ved å løpe:
/etc/init.d/newrelic-daemon stop
Som vil sende et nedleggingssignal til overvåkingsprosessen. Overvåkningsprosessen vil da drepe arbeidsprosessen og deretter stenge seg ned. Hvis du noen gang trenger å drepe demonen manuelt, må du sørge for at du avslutter overvåkingsprosessen først før du dreper arbeideren (ellers vil en ny arbeidstaker bli tatt opp - selvsagt).
Vi har allerede sett konfigurasjonsfilen for New Relic PHP-agent /etc/php5/cli/conf.d/newrelic.ini. Både agenten og demonen er konfigurert ved hjelp av denne filen.
Denne filen er veldig godt dokumentert med alle alternativene og deres standardverdier oppført. La oss snakke om formatet til denne filen. New Relic Ruby-agenten kan konfigureres via YAML, som er et kjent format. PHP-agenten er bare en tekstfil, men vi trenger litt struktur. Hver variabel i filen har en av fire typer (String, Boolean, Number, Duration). String og tall er selvforklarende, boolske verdier kan være ekte, på eller 1 å indikere truthiness og falsk, av eller 0 å indikere falskhet. Varighet er strenger med et bestemt format, for eksempel: "1w3d23h10m" indikerer en uke, tre dager, 23 timer og ti minutter. Verdiene for varighet kan være så granulære som mikrosekunder.
Alle variabler i filen har også et "omfang". Det er tre mulige mål: SYSTEM, PERDIR og SCRIPT. Variabler som har SYSTEM-omfang kan bare settes i den globale konfigurasjonsfilen. Variabler med PERDIR-omfang kan settes i den globale konfigureringsfilen og kan også overstyres på en per katalogbase. Variabler med skriptomfang kan være global, per katalog og kan også overskrides programmatisk.
For eksempel er den vanligste konfigurasjonsvariabelen 'Newrelic.appname'. Denne variabelen er en strengtype, den har en standardverdi på PHP-applikasjon (nå vet vi hvorfor vi så verdien i loggfilen etter at vi installerte agenten og startet serveren på nytt). Omfanget av denne variabelen er PERDIR som gir oss en ide om hvordan å overstyre søknadsnavnet til vår WordPress-blogg.
Det er mange andre variabler som kontrollerer ting som plasseringen av loggfilene, om det er registrert sql spørringer, lognivået for loggutgangen og så. Jeg oppfordrer deg til å studere newrelic.ini fil for å gjøre deg kjent med alternativene.
Vi ønsker å se en egen app i New Relic-brukergrensesnittet for vår WordPress-blogg, så la oss se hvordan vi kan få det til å gå. Alternativene dine for hver katalogkonfigurasjon er forskjellige, avhengig av stabelen din. Hvis du bruker PHP-FPM, er trinnene forskjellige enn hvis du bruker Nginx. I vårt tilfelle, siden vi kjører rett Apache, har vi to alternativer.
For det første, hvis vi har en virtuell vert for appen vår, kan vi sette inn en IfModule blokkere inn i vår virtuelle vertsblokk og endre navnet på appen der:
...php_value newrelic.appname "Min blogg 1" ...
Men jeg har ikke en spesiell virtuell vert bare for bloggen, så det andre alternativet er å bruke en .htaccess fil. Sørg for at du faktisk tillater det .htaccess filer, ved å dumpe følgende inn til din hoved virtuelle vert:
Alternativer indekser FollowSymLinks MultiViews AllowOverride All Order tillat, nekt tillatelse fra alle
Vi kan nå sette en .htaccess fil i toppnivåkatalogen på bloggen vår og legg inn følgende i det:
php_value newrelic.appname "Min blogg 1"
Formatet er akkurat det samme som om jeg setter det inn i IfModule blokkere. Nå trenger vi bare å sprette serveren vår. Hvis vi haler daemonloggene når serveren starter på nytt, ser vi følgende:
ubuntu @ ip-10-145-246-196: / var / www / myblog1 $ cat /var/log/newrelic/newrelic-daemon.log 2014-03-23 05: 30: 41.063 (2008 / main) advarsel: nåværende filgrense på 1024 er for lav - forsøker å øke den 2014-03-23 05: 30: 41.064 (2008 / hoved) info: økt filgrense til 2048 2014-03-23 05: 30: 41.064 (2008 / hoved) info : New Relic 4.6 (utgivelsesbygning 40 - "quetzalcoatlus" - "e3d29c5a2e5dc1ee455e831d589ecf5e18c7d6f0") [arbeidere = 1 listen = "/ tmp / .newrelic.sock" pid = 2008 ppid = 2007 uid = 0 euid = 0 gid = 0 egid = 0 backtrace = no os = "Linux" rel = "3.2.0-58-virtuell" mach = "x86_64" ver = "# 88-Ubuntu SMP Tirsdag Des 3 17" node = "ip-10-145-246-196" oppstart = agent] 2014-03-23 05: 30: 41.069 (2008 / hoved) info: RPM config: proto = "https" samler = "collector.newrelic.com" proxy = "none" certfile = "/ etc / ssl /certs/ca-certificates.crt "certdir =" / etc / ssl / certs "2014-03-23 05: 35: 14.928 (2008 / kontakt) info: ['PHP Application'] 'Rapportering til: https: // rpm.newrelic.com/accounts/232928/applications/3262356 '2014-03-23 06: 07: 58.768 (2008 / kontakt) jeg nfo: ['My Blog 1'] 'Rapportering til: https://rpm.newrelic.com/accounts/232928/applications/3262424'
De PHP-applikasjon er fortsatt der, men nå har den en venn som er vår WordPress-blogg. Og her er det i brukergrensesnittet:
Vi får nå beregninger når vi blar gjennom bloggen vår, både for frontend og administrasjonsgrensesnittet. Siden New Relic støtter WordPress ut av boksen, må beregningene brytes opp fornuftig (når et rammeverk ikke støttes, vil beregningene pleie å bli klumpet sammen).
New Relic er et komplekst stykke programvare, og det er godt å holde det oppdatert da feilene blir løst regelmessig og nye funksjoner blir lagt til. Siden vi installerte alt ved hjelp av apt-get, Det er enkelt å holde ting oppdatert. Vi gjør det samme som vi gjorde for å installere det:
apt-get oppdatering apt-get install newrelic-php5
Hvis vi ikke har installert en annen PHP på systemet, trenger vi nå bare å starte serveren vår, og vi vil være oppdatert. Hvis det er et nytt PHP, må vi kanskje kjøre igjen newrelic-install manus.
Det er bare en advarsel til alt dette. I enkelte situasjoner kan du kjøre New Relic-proxy-demonen separat fra agenten, noe som betyr at gjenstart av serveren ikke starter daemonen automatisk hvis den ikke kjører (dette kalles ekstern demonmodus). Det kan være flere grunner til at du vil gjøre dette, for eksempel, kanskje du vil at en annen bruker skal eie demonstrasjonsprosessen, slik at loggene bare er synlige for den brukeren. I denne situasjonen må du huske å starte om serveren og starte proxy-daemonen på nytt. Hvis du ikke gjør det, vil du se "protokollmatch" -feil i loggene.
Som du kan se, får New Relic satt opp for et PHP-program, er svært forskjellig fra å få det satt opp for Ruby, din faktiske applikasjon er ikke engang faktor i prosessen, mens miljøet du distribuerer er sentralt. Heldigvis betyr dette at hvis du bruker et støttet PHP-rammeverk, er prosessen for å sette opp New Relic akkurat det samme. Foruten WordPress er de fleste av de populære PHP-rammene støttet, inkludert Kake, Symfoni og Laravel (versjon 4 og opp). Det er også mulig å bruke New Relic med et ikke-støttet rammeverk, men du må sette litt seriøs innsats for å få beregningene til å gi mening.
Accentsconagua