Share
Når du først blir introdusert til New Relic, er det lett å bli overveldet av alle funksjonene. Men som med de fleste verktøy, når du langsomt klatrer læringskurven og blir kjent med funksjonene som er gitt ut av esken, begynner du å lure på hvordan alt sammen henger sammen under hetten og hvis det er mer du kan gjøre med det du har på hånd.
I dag vil jeg se på hvordan New Relic faktisk overvåker transaksjoner og hvordan du kan hekte inn i prosessen. Vi vil ta et raskt blikk på støtten fra New Relic for å overvåke bakgrunnsjobber, og vi vil også grave inn New Relic tilpassede beregninger, hvordan du vil bruke dem og fordelene du får fra å gjøre det. Til slutt vil du få en dypere forståelse av hvordan New Relic fungerer og kunne utnytte det mer fullstendig. Med andre ord vil vi få en dypere kunnskap om våre verktøy - noe hver utvikler bør streve for.
La oss begynne med å ta en rask titt på hvordan New Relic faktisk kroker inn for å følge ytelsen til søknaden din.
Sponset innholdDette innholdet ble bestilt av New Relic og ble skrevet og / eller redigert av Tuts + -laget. Vårt mål med sponset innhold er å publisere relevante og objektive opplæringsprogrammer, casestudier og inspirerende intervjuer som gir ekte pedagogisk verdi til våre lesere og gjør det mulig for oss å finansiere etableringen av mer nyttig innhold.
Det kan virke litt som magi, du inkluderer en perle i din Gemfile:
perle 'newrelic_rpm'
Og på den måten overvåker New Relic all koden din. Selvfølgelig er det bare kode, så la oss se hvordan New Relic faktisk styrer appen din, slik at den kan begynne å overvåke den når agentens perle er nødvendig. Vi vil gjøre dette i sammenheng med en Rails 4 app.
Det første stedet å se er newrelic_rpm.rb, som har følgende relevante kode i den:
... hvis Rails :: VERSION :: MAJOR.to_i> = 3 modul NewRelic klasse Railtie < Rails::Railtie initializer "newrelic_rpm.start_plugin" do |app| NewRelic::Control.instance.init_plugin(:config => app.config) slutten slutten annet ...
Så en Railtie blir opprettet når Rails versjonen er over tre, dette får en NewRelic :: Kontroll singleton eksempel (når den initialiseres) og ringer init_plugin. Når NewRelic :: Kontroll eksempel er opprettet det viser ut hvilket rammeverk som kjører (Rails 4 i vårt tilfelle) og laster inn noen relevant kode; vi kan se dette inn new_relic / kontroll / class_methods # load_framework_class. De init_plugin metode som blir henrettet, lever i new_relic / kontroll / instance_methods. Den interessante koden her er:
... hvis Agent.config [: agent_enabled] &&! NewRelic :: Agent.instance.started? start_agent install_instrumentation load_samplers med mindre Agent.config [: disable_samplers] ...
De install_instrumentation samtale er den viktigste. Gjennomføringen lever i new_relic / kontroll / instrumentering. Hopp over boilerplate-brikkene, dette virker ut hvilke instrumenteringsfiler den trenger å laste og krever dem en etter en. I vårt tilfelle vil det laste filer under new_relic / middel / instrumentering / rails4. En av filene her er action_controller.rb, når dette blir nødvendig, utfører det til slutt følgende kode via noen metaprogrammerings magi:
utfører klassen ActionController :: Base inkluderer NewRelic :: Agent :: Instrumentasjon :: ControllerInstrumentation include NewRelic :: Agent :: Instrumentation :: Rails4 :: ActionController end NewRelic :: Agent :: Instrumentasjon :: ActionControllerSubscriber \ .subscribe (/ ^ process_action .action_controller $ /) slutt
Og her kommer vi til kjernepunktet av det: ActionController :: Base (hvorfra alle dine kontrollører arver) får et par moduler inkludert i den, den viktigste er NewRelic :: Agent :: Instrumentation :: ControllerInstrumentation. Dette er starten på hvordan New Relic begynner å overvåke alle dine kontrollerhandlinger som «transaksjoner». Selvfølgelig er det en noe forenklet visning, og vi glir over mye detalj, men det gir deg en ide om hvordan New Relic overvåker koden din. Spørsmålet er, hvordan kan du bruke denne informasjonen?
Du er svært lite sannsynlig å finne deg selv i en situasjon der du bruker et webramme som New Relic ikke allerede har instrumentering for (i Ruby-verdenen), men la oss si at du gjorde det. Å vite hva vi kjenner nå, kan vi enkelt manuelt styre styringshandlingene i denne tilpassede rammen. Hvis vi har en kontroller som dette:
klasse CustomController def custom_action ... slutten
Vi kan instrument det slik:
klasse CustomController inkluderer NewRelic :: Agent :: Instrumentasjon :: ControllerInstrumentation def custom_action ... end add_transaction_tracer: custom_action end
Nå vil kontrolleringsmetoden spores som en transaksjon på samme måte. Rails handlinger blir sporet. Selvfølgelig, hvis du har rullet ditt eget webrammeverk som inkluderer databasehåndteringskode, må du gjøre ekstra arbeid til instrumentet mye av den koden, slik at New Relic kan overvåke mer enn bare kontrollerhandlinger. Men den generelle ideen er fortsatt god.
Ovennevnte mønster blir mer nyttig når du vil at New Relic skal spore bakgrunnsjobber i søknaden din. Du har mye mer sannsynlighet for å ha rullet litt tilpasset bakgrunns jobbhåndteringskode enn du skal ha skrevet din egen webramme. Faktisk gjorde vi bare dette med Tuts + i utgangspunktet, selv om vi nå migrerer til Sidekiq. Hvis du bruker et av de kjente bakgrunnsjobbsystemene som Sidekiq, Resque eller Delayed Job, har New Relic allerede instrumentering innebygd, men hvis du rullet ditt eget, er dette mønsteret alt du trenger for å overvåke oppgavene dine..
For eksempel var våre tilpassede Tuts + bakgrunnsjobber regelmessige rubinklasser som reagerte på henrette metode, så alt vi trenger å gjøre er dette:
klassen SomeBackgroundJob inkluderer NewRelic :: Agent :: Instrumentasjon :: ControllerInstrumentation def execute ... end add_transaction_tracer: custom_action, kategori:: oppgave ende
Den siste biten, Kategori:: Oppgave, er å sikre at New Relic ikke sporer det som en webtransaksjon, men behandler den i stedet som en bakgrunnsoppgave, og får den til å vises under kategorien Bakgrunnsoppgaver i New Relic-brukergrensesnittet. Hvis vi lager en grunnklasse for alle våre jobber, kan vi sette instrumentasjonen der og barnklasser vil arve den, så vi trenger ikke å bekymre oss for å gjøre det ovenfor i hver jobbklasse.
Interessant nok, selv de nettransaksjoner som New Relic automatisk overvåker, er ikke sakrosomme. Du kan for eksempel legge til noen egendefinerte parametere som skal sendes til New Relic for transaksjonen som for øyeblikket kjører (hvis du har slått på fange parametere).
Du kan gjøre dette når som helst under transaksjonen. Alt du trenger å gjøre er å ringe :: NewRelic :: Agent.add_custom_parameters (: key => 'value') Når som helst og parametrene du sender inn, blir det lagt til parameterdataene du ser i New Relic. For eksempel, hvis vi hadde en kontroller som så ut som dette:
klasse HelloController < ApplicationController def index ::NewRelic::Agent.add_custom_parameters(:hello => 'verden') slutten
Sakte transaksjoner vil gi oss følgende:
Dette er ikke alt vi kan gjøre. Vi kan segmentere en transaksjon mens den kjører ved å gi nytt navn til den. La oss si at vi ønsker å behandle en transaksjon som spesiell når den utføres av en bestemt bruker. Du kan gjøre noe slikt:
Accentsconagua
klasse HelloController < ApplicationController def index new_relic_name = NewRelic::Agent.get_transaction_name if current_user.name == 'Joe Customer' NewRelic::Agent.set_transaction_name("#new_relic_name - Joe Customer") end end end Nå blir denne transaksjonen behandlet som en separat transaksjon i New Relic-brukergrensesnittet:
Selv standard New Relic instrumentasjon har noe rom for tilpasning, men noen ganger, akkurat som Captain Kirk, trenger du bare mer kraft. Dette er hvor tilpassede beregninger kommer inn.
Tilbake på dagen ville du ha brukt egendefinerte beregninger for å overvåke ting som ekstern tjenestekommunikasjon og bruk av ulike vanlige verktøy som Redis. I disse dager har New Relic bedre måter å overvåke de tingene på, så hva trenger vi tilpassede beregninger for? Jeg har funnet tilpassede beregninger for å være nyttig i fire situasjoner:
La oss ta en rask titt på hver av dem.
New Relic er ganske bra på å bryte ned ytelsen til dine forskjellige applikasjonsmetoder i et transaksjonsspor, men noen ganger ser du noe slikt i et spor:
Det ser ut til at det er applikasjonskode som New Relic ikke kunne instrument av en eller annen grunn. Hva vi kan gjøre er å hjelpe New Relic (og oss selv) med noen tilpassede beregninger. Vi må finne ut hvilken metode New Relic hadde problemer med å overvåke og koble inn noen egendefinerte beregninger for å spore hvor lang tid denne metoden tok for å utføre. Dette vil da vises i alle etterfølgende spor. La oss si at vi har en klasse med en metode vi vil overvåke via egendefinerte beregninger:
klasse Bestill def amount ... slutten
Vi kan begynne å spore beløp metode slik:
krever 'new_relic / agent / method_tracer' klasse Bestill inkluderer :: NewRelic :: Agent :: MethodTracer def amount ... end add_method_tracer: beløp, 'Custom / amount' end
Den andre parameteren til add_method_tracer er navnet som denne egendefinerte metriske vil få i New Relic brukergrensesnittet. Metriske navn er skråstrekede strenger, og alle tilpassede beregninger skal begynne med 'Tilpasset /'. Du kan for eksempel nevne egendefinert beregning som 'Egendefinert /beløp metode i transaksjonssporene dine, i New Relic-brukergrensesnittet. Men hva om vår beløp Metoden er svært kompleks og vi vil overvåke deler av den som vi mistenker er sakte? Mitt råd er at du bør refactor metoden din - den er for stor, men hvis du ikke kan gjøre det, kan du instrument-tilfeldig kode som dette:
klasse rekkefølge :: NewRelic :: Agent :: MethodTracer def amount ... self.class.trace_execution_scoped (['Custom / amount / complex_code']) gjør ... komplekse kode ... ende ... ende ende
Nå rapporteres den instrumenterte delen av metoden separat i transaksjonssporene dine. Hvis du tidligere har instrumentet metoden selv, blir den nye "indre" metriske gruppen gruppert under den forrige.
Dette er langt den vanligste måten du ender med å bruke egendefinerte beregninger i koden din, men la oss se på de andre uansett.
Ofte kan du bruke et bibliotek som du mistenker, senker søknaden din. New Relic vil ikke være instrument som en tilfeldig perle for deg som standard, så hva kan du gjøre? Du kan gaffel perlen og legge til noen instrumentering ved hjelp av metoden vi så over, men en enda enklere løsning finnes - bruk initialiseringsverktøy. La oss si at du bruker foobar bibliotek som har en klasse foo med en metode Bar at du mistenker har en sakte kode i den. Alt du trenger å gjøre er å lage en initialiserer foobar_instrumentation.rb, og legg følgende i det:
krever 'new_relic / agent / method_tracer' Foo.class_eval inkluderer :: NewRelic :: Agent :: MethodTracer add_method_tracer: bar end
Som du ser, er koden veldig lik det vi hadde over, vil New Relic finne ut et fornuftig navn for den nye egendefinerte metriske din, basert på klassen og metodenavnet, og du vil begynne å se det i transaksjonssporene dine. Bruk dette til å fungere hvis dette mistenkelige biblioteket faktisk gjør koden din dårlig, men ikke hold denne instrumentasjonen permanent. Det spammer unødvendige initiativer i appen din Rails og forurenser New Relic-brukergrensesnittet ditt med egendefinerte beregninger som du ikke virkelig trenger å spore permanent.
En del av webapplikasjoner som ofte blir oversett, er skript. For å omskrive en presentasjon jeg nylig gjorde, er de fortsatt produksjonskode og bør behandles som sådan. Du vil ikke at produksjonskoden skal utføre dårlig, spesielt hvis du utfører det kontinuerlig via cron-jobber (eller en lignende metode som ikke er en bakgrunnsjobb i systemet), slik at vi kan bruke New Relic til å finne ut om Skriptene dine er tregte.
Du kan måle skriptkoden din ved hjelp av egendefinerte beregninger som beskrevet ovenfor. Det kommer ikke opp i transaksjonsspor som det ikke vil være en del av en transaksjon. Hva du vil kunne gjøre selv, er å lage et egendefinert dashbord fra de beregningene du samler, som burde gi deg en ide om skriptet ditt utfører dårlig.
Den andre tingen du kan gjøre er å behandle skriptet ditt som en type bakgrunnsjobb og instruere det i henhold til dette (inkludere NewRelic :: Agent :: Instrumentation :: ControllerInstrumentation og så videre). Det vil bli klumpet sammen med andre bakgrunnsoppgaver i brukergrensesnittet, men du trenger ikke å bekymre deg for egendefinerte dashboards.
Den eneste advarselen med skript er dette: New Relic sender bare data over ledningen med jevne mellomrom. Med et engangsskript som kjører raskt, må du sørge for at de innsamlede dataene faktisk blir sendt, slik at du kanskje må slå av New Relic-agenten manuelt. En god tommelfingerregel er å manuelt starte agenten i begynnelsen av hvert skript og å stenge den på slutten:
krever 'newrelic_rpm' :: NewRelic :: Agent.manual_start ... codez ... :: NewRelic :: Agent.shutdown
På denne måten trenger du aldri å lure på hvorfor dataene dine ikke vises i brukergrensesnittet.
En av de interessante tingene om New Relic er at den lar deg dra nytte av brukergrensesnittet og dataaggregatene for beregninger som ikke har noe å gjøre med ytelse (i teorien). For eksempel kan det hende du vil ha litt synlighet på hvor ofte brukere registrerer seg for søknaden din, hyppigheten av salget eller det totale beløpet brukerne betaler når de foretar kjøp. Dette er flere forretningsmessige verdier enn resultatene, men hvis det er for mye problemer med å spore disse separat, kan du bruke New Relic å gjøre det.
New Relic lar deg registrere egendefinerte beregninger direkte via to API-samtaler:
record_metricincrement_metricDu kan bruke record_metric for å spore noen beregning som har et beløp og increment_metric er ganske selvforklarende. Så vi kan for eksempel gjøre dette:
... kjøp av (beløp) ... :: NewRelic :: Agent.record_metric ('Custom / buy_amount', mengde) :: NewRelic :: Agent.increment_metric ('Custom / buy_count') ... end ... Den eneste måten for deg å se disse beregningene i brukergrensesnittet, er å lage noen egendefinerte oversikter. Jeg må nevne at dette ville være en noe "kreativ" bruk av New Relic API som den er designet med prestasjonsdata i tankene, men det er absolutt en praktisk ting å vite når du må kaste et raskt dashbord sammen og ikke ønsker å sette opp en haug med ekstra infrastruktur.
Selvfølgelig har all denne kraften en kostnad. Hvis du samler for mange egendefinerte beregninger, kan det begynne å redusere søknaden din. Det kan også redusere New Relic brukergrensesnittet og gjøre det vanskelig å tolke dataene da New Relic vil kollapse tilsvarende beregninger i en oppsummering. New Relic anbefaler å holde antall tilpassede beregninger du samler under 2000. Jeg har funnet ut at egendefinerte beregninger blir best brukt regelmessig. Instrumentet koden du trenger, bruk instrumentasjonen til å løse problemet du har, og fjern deretter instrumentasjonen. På denne måten får du løse ytelsesproblemene dine, og antallet tilpassede beregninger du bruker, er usannsynlig å vokse for høyt.
Vi har gravd inn i internals av newrelic_rpm perle og har lært å fortelle New Relic om kode som du anser for en webtransaksjon. Vi har sett på hvordan du kan endre transaksjoner i fly, hvordan du overvåker bakgrunnsjobber og de ulike situasjonene hvor det er fornuftig å bruke egendefinerte beregninger. Det er mye du kan gjøre med New Relic utover funksjonaliteten den gir ut av boksen, og du er nå mye mer i stand til å utnytte det til sitt fulle potensiale. Men det er alltid mer å lære, for eksempel hvordan du bygger egendefinerte dashboards ut av beregningene du tar, eller hvordan du overvåker infrastruktur med plugins. Vi vil dekke disse emnene og mer i etterfølgende artikler, så sørg for å sjekke tilbake ofte. Og som alltid hvis du har et spørsmål, vil du dele din egen New Relic-historie eller bare vil si hei, ikke glem å legge igjen en kommentar.
