Slik bruker du New Relic Custom Dashboards og hvorfor du vil

I dag skal vi se på New Relic tilpassede dashboards. Spesielt vil jeg vise deg tre måter som jeg pleier å bruke egendefinerte dashboards:

  • skaper et oversiktspanel fra eksisterende diagrammer
  • lage dine egne diagrammer fra eksisterende data fanget av New Relic
  • oppretter dashboards for dine egendefinerte beregninger
Sponset innhold

Dette 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.

Men før vi kommer inn i noe av det, må vi først stille oss et spørsmål, hvorfor skal vi bruke tilpassede instrumentpaneler i det hele tatt? New Relic gjør en ganske god jobb med å presentere programdataene dine. Bare ved hjelp av det vanlige brukergrensesnittet, kan du samle inn mer informasjon om ytelsen til appen din enn du noensinne kunne ha før du begynte å bruke New Relic. Så før jeg viser deg hvordan du bruker egendefinerte instrumentbrett, forklarer jeg hvorfor jeg tror at alle som bruker New Relic, bør se på dem snarere enn senere.


Hvorfor bruke Egendefinerte Dashboards i det hele tatt?

Det er sant, de fleste bruker gjerne New Relic uten å se på den tilpassede dashbord-funksjonaliteten som den gir. Det er ikke før du er en ganske avansert bruker som du kan bestemme deg for å se på tilpassede instrumentpaneler og se hva de har å tilby deg. Jeg synes dette er synd, å spille rundt med egendefinerte instrumentpaneler kan ikke bare gi deg mulighet til å skjære og titte appens ytelsesdata på forskjellige måter, men kan også:

  • lær deg ganske mye om hvordan New Relic fanger beregninger
  • lar deg lære nøyaktig hvilken type data som blir lagret for beregningene som blir fanget
  • lær deg om begrensningene i New Relic-diagrammer

Du kan lære alle disse tingene ved å lese dokumentasjonen, men å spille rundt med egendefinerte instrumentpaneler lar oss begynne å forstå noen av disse tingene ved eksempel (på et mer intuitivt nivå), i stedet for bare å kjenne det som en haug med punktpunkter. Som det ofte er tilfellet med teknologi, tinkering med et ikke-relatert område av et verktøy, vil det noen ganger gi deg mer innsikt og forståelse for hvordan de mer brukte områdene av det samme verktøyet fungerer. Ved å bruke tilpassede instrumentpaneler vil du få en mer kunnskapsrik New Relic-bruker, og hvis du har lest de andre New Relic-innleggene jeg har skrevet, vet du hvordan jeg føler meg kjent med verktøyene dine.


Opprette et oversiktspanel fra eksisterende diagrammer

Det ene egendefinerte instrumentbrettet jeg alltid liker å bygge er det jeg kaller "24 timer med et blikk". Jeg tar en rekke eksisterende diagrammer som jeg anser viktig for et enkelt program, lås tidsperioden til de siste 24 timene og legg dem alle sammen på ett dashbord. Når jeg ser på et bestemt program i New Relic, blir dette det første skjermbildet jeg ser på for å se om det er noe spesielt dårlig som hopper ut på meg fra de siste 24 timene. La oss se hvordan vi kan bygge denne typen instrumentpanel.

For det første må vi opprette et nytt tilpasset dashbord. I New Relic UI klikker du på Dashboards-> Opprett egendefinert dashboard. På neste skjermbilde gir vi vårt betjeningspanel et navn (du kan bruke "24 timer med et blikk", eller ditt eget navn) og velg gridoppsettet. Grunnoppsett er i hovedsak en samling av diagrammer av samme størrelse og oversiktslayout er et stort diagram omgitt av en gruppe mindre diagrammer (vi vil bruke oversiktslayout i neste avsnitt).


Nå må vi velge appen som vi vil lage dashbordet til, og deretter finne noen relevante diagrammer å legge til. Jeg liker å legge til følgende:

  • server gjennomsnittlig svartid
  • Historisk server gjennomsnittlig svartid
  • gjennomsnittlig svartid for nettleseren
  • feil rate
  • gjennomstrømming
  • historisk gjennomstrømning
  • applikasjon CPU bruk av verten
  • applikasjonsminnebruk av verten
  • Topp fem webtransaksjoner ved hjelp av vegguretid
  • nedetid
  • toppland etter gjennomstrømning
  • topp fem database operasjoner av vegg klokke tid

Avhengig av søknaden din vil du kanskje legge til noen andre, men jeg finner dette gir meg et ganske godt øyeblikksbilde av hva som skjer med søknaden og hva du skal undersøke om noe er galt. La oss finne et av disse diagrammene og legge dem til i vårt nye dashbord. Serverens gjennomsnittlige svartid er en enkel, da det er det store diagrammet i Oversikt delen av Overvåkning fanen for et program. Hvert diagram i New Relic-brukergrensesnittet har en liten New Relic-logo nederst til høyre, når du svever musen over denne logoen, blir den til et pluss-tegn. Ved å klikke på plusset kan du legge til dette diagrammet til et dashbord:


Men før vi legger til vårt diagram, må vi endre tidsvinduet for New Relic-brukergrensesnittet til å være 24 timer. Vi må gjøre dette for å gi oss selv muligheten til å "låse" diagrammet til de siste 24 timene når vi faktisk legger det til dashbordet (dette er ubehagelig UX etter min mening, men vi har i det minste en måte å gjøre hva vi trenger):


Vi kan nå gå videre og legge til diagrammet:


Ikke glem å krysse Lås for å spenne boksen. Når vi nå besøker vårt nye dashbord, må diagrammet vi nettopp har lagt til:


Vi kan skylle og gjenta ovennevnte prosess inntil vi har lagt til alle kartene vi ønsker. Til slutt bør det se slik ut:


Du kan klikke på Rediger dashbordet knappen øverst til høyre som lar deg dra diagrammene rundt og ordne dem i den rekkefølgen du vil ha. Det eneste du må merke seg er at du ikke kan endre de enkelte kartene på noen måte (for eksempel, du har kanskje ønsket å ha en mer beskrivende diagramtittel, men du kan ikke endre den) siden de er standard New Relic charts.

Det andre tilpassede dashbordet jeg alltid liker å bygge fra eksisterende diagrammer, er "Alle applikasjoner med et blikk". Dette gjelder bare hvis du har flere programmer du leter etter. Her velger vi en eller to av de viktigste kartene for hver relevant søknad og legger dem sammen. Det er vanligvis et trygt alternativ for å bruke diagrammet "Response Time" fra hvert program. Den faktiske prosessen med å sette sammen instrumentbrettene er det samme som beskrevet ovenfor, du trenger bare å bytte applikasjoner for å få de relevante diagrammene fra hver. Til slutt bør du ende opp med noe slikt:


Dette er skjermen jeg vil se på først når jeg logger på New Relic. Det kan være nyttig å låse tiden til hvert diagram i 24 timer, akkurat som vi gjorde for dashbordet "24 timer med et blikk", men det er opp til deg. Selvfølgelig er dette bare relevant hvis du støtter flere applikasjoner. Når det er sagt, hvis du har flere preproduksjonsmiljøer for din søknad (for oppstart eller belastningstest), vil du kanskje sette dem sammen i et dashbord som ligner på dette. Det kan hjelpe deg med å fange endringer som forringer ytelsen før kode ender opp i produksjonen.


Opprette dine egne diagrammer fra eksisterende data

New Relic UI lider av noen nødvendige begrensninger. Det må være alle ting for alle mennesker, så de kan bare gruppere sammen diagrammer og tabeller som ville gi mening for alle webapplikasjoner. Mesteparten av tiden vil brukergrensesnittene begrense deg til å se på en transaksjon om gangen og ett eller to sett med beregninger av gangen, hvis du trenger tilgang til andre du må klikke rundt. Den gode nyheten er, med tilpassede instrumentpaneler, gjelder ikke denne begrensningen lenger. Vi vet hvilke transaksjoner som er relatert til domenet vårt, vi vet også hvilke beregninger som er viktige for oss på basis av transaksjoner. Vi kan bygge et dashbord som grupperer flere relaterte transaksjoner med alle viktige beregninger for hver og ser på den på den ene skjermen.

La oss si at vi har en spesielt viktig transaksjon i vår søknad, det kan være fornuftig å ha et dashbord hvor vi kan se mesteparten av den viktige informasjonen om denne transaksjonen på et øyeblikk. Her på Tuts + har vi et konsept av artikler (åpenbart) og artikler er ganske viktige for oss, la oss bygge et dashbord for å holde øye med dem.

Nok en gang må vi opprette et nytt dashbord som før, vi kaller det 'Artikkeloversikt', men denne gangen bruker vi et oversiktslayout. Vi trenger ikke å lete etter diagrammer, da vi skal lage våre egne tilpassede diagrammer, så klikk på den store knappen for å lage hovedkortet for oversikten:


Det vil spørre deg om du vil legge til et diagram eller et bord, vi vil legge til et bord senere, for nå velg diagram. Du ser en skjerm som ser slik ut:


Det viktigste å se på her er metriske som du vil vise. Når du klikker inne i tekstfeltet for beregninger, vil det falle ned en liste over toppnivå beregninger som du kan velge. Metrics i New Relic er oppkalt som prefix / kategori / label. I tilfelle av en Rails-app, kan prefikset være Controller eller Active (Hvis du ikke bruker Rails, vil prefikset for transaksjoner være WebTransactions). Til Controller, kategorien vil være navnet på kontrolleren og etiketten vil være handlingsnavnet. Hvis du utforsker noen av beregningene mens du spiller rundt med ditt første diagram, vil du begynne å få en følelse av hva slags beregninger du har tilgang til og hvor du finner dem. Hvis du ikke ser beregningene du forventer, sørg for at du har det riktige programmet valgt innen New Relic, dette ringer meg alltid opp.

Tilbake til vårt hovedkort. Den metriske vi er etter blir knyttet til vår ArticlesController, så navnet heter Controller / artikler / utstilling. Når vi har valgt metriske, innholdet i Verdi rullegardin vil endres for å inneholde alle verdiene som gir mening for denne metriske. Det er verdt å utforske alle de forskjellige verdiene igjen og se hva diagrammet faktisk inneholder. I vårt tilfelle ser "Gjennomsnittlig svartid" ut som en god ting å ha som hovedkort.

På dette tidspunktet, hvis vi gir tittelet vårt og klikker på forhåndsvisning knappen vi kan se hvordan det ser ut:


Dette ser bra ut, men jeg vil at Y-aksen skal være i millisekunder, og jeg vil også ha enhetene på aksen også. Så, la oss slippe ned de avanserte alternativene for diagrammet og endre nummerformatet til å være 'Til millisekunder', vil vi også sette Y-aksenhetens etikett som 'ms':


Vårt diagram ser nå bra ut på forhåndsvisningen. Det eneste som vi ikke har snakket om er at Diagramklikk fall ned. Dette gir i hovedsak diagrammet ditt som en kobling til et annet tilpasset dashbord, når du klikker på diagrammet, vil dashbordet bli vist. Vi trenger ikke denne funksjonaliteten, så vi forlater rullegardinmenyen alene. Vi skal nå gå videre og lagre diagrammet vårt.


Vi kan nå legge til de forskjellige underdiagrammer. I vårt tilfelle skjønner jeg at Tuts + har et opplæringsbegrep (også åpenbart) som er nært knyttet til artikler, så hvis jeg skal holde øye med artikkel gjennomsnittlig svartid, er det sannsynligvis en god ide å ha en opplærings gjennomsnittlig responstid i nærheten som en sammenligning, så jeg vil lage et diagram for det. Vi følger de samme trinnene som ovenfor, til slutt ser dashbordet vårt ut slik:


Hmm, det ser ut til at gjennomsnittlig svartid for artikler er mye høyere enn opplæringsprogrammer, men jeg skjønner at begge deler deler en betydelig mengde kode, merkelig. Men det er også en indikasjon på at vårt tilpassede dashbord allerede betaler utbytte, og vi har ikke engang ferdig med å bygge den ennå. Jeg kunne ha funnet denne informasjonen ved å se den opp i det vanlige New Relic brukergrensesnittet, men å ha diagrammer side ved side som dette bidrar til å virkelig bringe hjem det faktum at det kan være et problem.

Det kan også være bra å se hvor vår ArticlesController sitter i forhold til andre kontroller, så langt som deres maksimale responstid går, er dette en jobb for et bord. Vi legger til et annet diagram som før, men denne gangen velger du tabell i stedet for diagram. For å lage tabeller med flere rader, må vi bruke jokertegn i vårt metriske navn. I vårt tilfelle vil jeg sette metriske til å være Controller /, Dette vil velge alle beregningene under * Controller prefiks, jeg vil nå sette grense tekstboks å være 10 som vil gjøre akkurat som du forventer og sette antall rader i bordet vårt til ti. Til slutt bør vi ha noe som ser slik ut, rett før vi lagrer:


Vårt tilpassede dashbord vil nå være:


Det synes som ArticlesController # viser har den lengste maksimale responstiden ut av alle kontrollerhandlingene, inkludert TutorialsController # viser, Dette er veldig nysgjerrig, og jeg burde nok lage et notat for å se på dette.

Vi kan fortsette å legge til en haug med andre diagrammer som sluttbrukerens gjennomsnittlige svartid eller samtaler per minutt. Men noen ting du bare ikke kan konstruere ved hjelp av et tilpasset diagram, for eksempel historisk gjennomstrømming eller svartid. Heldigvis kan vi alltid falle tilbake på å finne diagrammer som vi vil ha et annet sted i New Relic, og bare legge dem til vår egendefinerte dashboard.

Den eneste begrensningen ved å bruke et dashbord som har egendefinerte diagrammer, er at du må ha den riktige appen valgt i New Relic, ellers vil alle egendefinerte diagrammer på oversikten din være tomme.


Opprette oversikter for dine tilpassede beregninger

Hvis du leser min siste artikkel om egendefinerte beregninger, kan du huske at jeg nevner at den eneste måten du kan se de egendefinerte metriske dataene du har samlet, er å opprette et tilpasset dashbord i New Relic, dette er den tredje grunnen til å bruke egendefinert oversikter. Hvis du samler mange tilpassede beregninger, kan dette være den beste grunnen til alle.

På Tuts + har vi et konsept av kategorier (enda en gang, selvsagt), jeg skjønner bare at vi har noen få tilpassede beregninger som flyter rundt for kategorier. La oss se om vi kan sette disse på et dashbord og faktisk få en ide om hva som skjer. Vi lager et annet dashbord og kaller det 'Kategorien tilpassede beregninger'. Alle tilpassede beregninger i New Relic skal leve under Tilpasset prefiks og det er her vi finner de beregningene vi leter etter:


Vi lager et par diagrammer, en for å se hvor lenge bygningen presenterer CategoriesController tar og den andre for å se hvor lang tid det tar å få en koblingshash fra presentatørene. Den viktigste tingen å vite med egendefinerte beregninger, er hva slags data du faktisk sender til New Relic. I dette tilfellet skjer jeg å vite at vi måler tid, så jeg kan velge 'Gjennomsnittlig verdi'som min metriske verdi og angi Nummerformat til millisekunder for å få et rimelig utseende diagram. Etter at du har opprettet begge kartene, ser vårt tilpassede dashbord ut slik:


Det ser ut som om å få koblingen hash fra presentatørene er veldig rask og ikke svinger for mye, det er ikke nødvendig å optimalisere noe her, og jeg kan nok ikke slutte å samle denne metriske fullstendig (ikke nødvendigvis å fange unødvendige data). Men bygningen av presentatørene tar betydelig mer tid, vi kan se nærmere på dette for å se om det kan optimaliseres. Vi kan også holde øye med diagrammet (ved å se på det egendefinerte dashbordet av og til) for å sikre at ytelsen ikke forringes mens vi fortsetter å jobbe på applikasjonen.


Konklusjon

Egendefinerte dashboards er ikke et panacea. Bortsett fra å lage diagrammer for egendefinerte beregninger, kan du gjøre alt som egendefinerte dashboards kan gjøre med det vanlige New Relic-brukergrensesnittet. Men å spille med tilpassede instrumentpaneler vil definitivt hjelpe deg med å bli mer av en kraftbruker av New Relic, med en dypere forståelse av hvordan det fungerer under hetten. I tillegg kan muligheten til å se på resultatene dine på forskjellige måter være et uvurderlig verktøy for å hjelpe deg med å overføre potensielle ytelsesproblemer før de har stor innvirkning på søknaden din.

Hvis du har spørsmål om New Relic-tilpassede dashboards, vær ikke redd for å legge igjen en kommentar, og jeg vil gjøre mitt beste for å svare. Hvis du har brukt vanlige dashboards til en god effekt tidligere, kan du også dele noen tips du kanskje har, det er alltid interessant å se hvordan andre bruker verktøyene sine..