New Relic University ワークショップ@東京へのご招待

New Relic Template 2015

Getting started with New Relic APM

⽇吉潤⼀郎 (Harry Hiyoshi)Technical Account Manager for Japanjhiyoshi@newrelic.com

本⽇の内容午前の部 New Relic 基礎編10:00 – 10:15 15m New Relic の基本アーキテクチャ10:15 – 10:45 30m New Relic APMでトラブルシューティング10:45 – 11:15 30m 実習#1: トラブルシューティング11:15 – 11:35 20m トラブルシューティングに有効なその他の機能11:35 – 12:15 40m New Relic for Ops12:15 – 12:30 15m 実習#2: アラートの設定12:30 – 13:30 60m 昼⾷午後の部 New Relic 応⽤編13:30 - 13:50 20m New Relic Infrastructure の効果的な利⽤法13:50 - 14:10 20m 実習#３: サーバリソース起因の遅延を確認14:10 – 14:50 40m WEBフロントエンドのパフォーマンス診断14:50 – 15:10 20m モバイルアプリのトラブルシューティング15:10 – 15:40 30m New Relic Insights でパフォーマンス分析15:40 – 16:00 20m 実習#4: Insightsでパフォーマンス分析

10:00 – 10:15 (15m)

New Relic の基本アーキテクチャ

Template 2015

How New Relic APM Works

Template 2015

アプリケーションスタックの全てに対応

Template 2015

10:15 – 10:45 (30m)

New Relic APMでトラブルシューティング

“Overview”から⼊って問題を絞り込む

Time Picker表⽰時間帯を変更

表⽰チャートを変更

Apdexユーザー満⾜度を確認

Error rateエラー件数を確認

Transactionsワースト５トランザクション

処理レイヤー分類

特定のセグメントを更に絞り込んで分析

表⽰するチャートを変更

トランザクションを選択

その処理の詳細

トレースから問題箇所を特定

トレースを選択

トレース取得時刻

⾊で遅延メソッドを特定

Trace details

Drilldown

クエリ詳細

New Relic APM でトラブルシューティング

デモ

10:45 – 11:15 (30m)

実習#1: トラブルシューティング

実習#1: トラブルシューティング1.  https://rpm.newrelic.com/accounts/XXXXXX にアクセス 2.  ご自身のメールアドレスとパスワードでログイン

3.  Application “New Relic Pet Clinic” を開いてください 4.  Time picker で、“Nov.8 1:00 PM までの3時間“　を指定

実習#1: トラブルシューティング

５. 以下を確認してください ! 最も時間が費やされているのはどの処理レイヤーか？ ! 最も遅延しているトランザクションは何か？ ! それらの処理の中で、最も遅延しているメソッドは？ !  (補足質問）Overview でTransaction はミリ秒で表示されているが、Transactionsでは%表示。その違いは？

11:15 – 11:35 (20m)

トラブルシューティングに有効なその他の機能

Custom Instrumentation の活⽤! 任意のクラス・メソッドを、測定対象としたい場合に利⽤

Custom Instrumentation の活⽤! クラス名、メソッド名がわかる場合はManualで⼊⼒! わからない場合は、Thread Profiler で確認しながら設定

Error Analytics の活⽤1.  エラーを分類＝Error Grouping 2.  エラーの傾向を分析＝Error Profiling

Deployment tracking の活⽤!  fixをdeployしたら、その前後のパフォーマンスを⽐較

Deployment tracking の活⽤! Deployment makerをNew Relicに渡すための2通

りの設定⽅法

・エージェントのインストーラから

・REST APIをコール

トラブルシューティングに有効なその他の機能

デモ

11:35 – 12:15 (40m)

New Relic for Ops

! NewRelicが発明した業界標準のユーザ満⾜度を測る指標! 全リクエストのレスポンス時間を以下に分類し、その件

数をカウントするSatisfied ： T (閾値）以下Tolerating : T 以上、4T 以下Frustrated : 4T 以上

!  Apdexの計算（直近の５分をまとめて、２分おきに）

Apdexとは？

なぜApdexが必要とされるのか？! 平均応答時間は、ユーザ全体を表す指標となりうるか？!  https://blog.newrelic.com/2013/09/10/breaking-

down-apdex/#references

平均値 95％中央値,50%

25％から 75%

最適な閾値（T）をどう設定したら良いのか？! 低すぎればアラート多発、⾼すぎれば⾒逃し

・パーセンタイルから割り出すのが妥当？!  https://blog.newrelic.com/2017/06/29/how-to-

choose-apdex-t/

Key Transactionとは？! 重要なトランザクションにフォーカスして監視! X-Rayセッション

・特定のキートランザクションのスレッドダンプを収集

New Relic Alerts

まず、Alert Policyを定義

! Alert Condition (複数）

! Notification Channel（複数）

Baseline Alert! アブノーマルな状態を検出する

・異常度合いをスライダーで調整しながら決定

アラートの通知とインシデントの管理Alert Policy!  Alert Condition !  Notification Channel

Incident!  Violations!  Acknowledge

Violation発⽣

Incident Preferenceに基づいて実施

New Relic for Ops

デモ

12:15 – 12:30 (15m)

実習#2: アラートの設定

実習#２: アラートの設定

1.  https://rpm.newrelic.com/accounts/XXXXXX にアクセス 2.  ご自身のメールアドレスとパスワードでログイン 3.  Application “New Relic Pet Clinic” を開いてください 4.  以下を実施してください・少なくとも５分間において、当アプリケーションが、１分あたり１００件以上のリクエストを受信した場合に、自分に通知する様にアラートの定義を行う・実際にメールが受信できるか確認する

12:30 – 13:30 (60m)

昼⾷

13:30 – 13:50 (20m)

New Relic Infrastructure の効果的な利⽤法

! グルーピング機能を利⽤して効率的に分析

New Relic Infrastructure の活⽤(１)システムメトリックを監視するだけに留まらない有効な活⽤⽅法

! イベントを活⽤して、問題発⽣前後に何が変わったのかを確認

New Relic Infrastructure の活⽤(２)システムメトリックを監視するだけに留まらない有効な活⽤⽅法

! ヘルスマップで、アプリケーションとの相関関係を確認

New Relic Infrastructure の活⽤(３)システムメトリックを監視するだけに留まらない有効な活⽤⽅法

New Relic Infrastructure

デモ

13:50 – 14:10 (30m)

実習#３: サーバリソース起因の遅延を確認

実習#３:サーバリソース起因の遅延を確認 1.  https://rpm.newrelic.com/accounts/XXXXXX にアクセス 2.  ご自身のメールアドレスとパスワードでログイン 3.  Infrastructureを開いてください 4.  Time picker で、“Nov.8 11:00 AM から Nov.8 12:30 PM”を指定

実習#３:サーバリソース起因の遅延を確認

５. 以下を実施してください・何か異常が見られるでしょうか？・アプリケーションへの影響はどうでしょうか？・その時間帯にサーバの設定変更はなかったでしょうか？誰がログインしていたでしょうか？・何が原因でその問題が発生していたのでしょうか？ (ヒント：プロセス）

14:10 – 14:50 (40m)

WEBフロントエンドのパフォーマンス診断

New Relic Browser のアーキテクチャ!  Java Script Snippet をWeb ページに inject

・APMエージェント利⽤中：エージェントが⾃動挿⼊・それ以外：⼿動でJavaScriptをWebページに挿⼊

injection

JS snippet

WEBフロントエンドのパフォーマンス診断ブラウザ上の処理を４つに切り分け

! Network! Web app time! Dom Processing! Page rendering

４つの切り分けの詳細

Network(1st part)

Web app time

Network(2nd part)

DOM processing

Page rendering

1. リクエスト送信

2. リクエストがサーバへ到着3. アプリコード実⾏完了

4. BrowserのHTML受信, 処理開始5. HTML処理完了、DOMContentLoaded イベント

6. ページレンダリング完了、Window load イベント

フロントエンド処理時間

Session Trace でユーザ体験を確認!  全ユーザセッションを“ランダムに”ピックアップ

!  以下の内容を確認したい時は、Session Tracesを

・ページ毎のブラウザイベントのタイミング・リソース毎のロード時間、AJAXレスポンスタイム・セッション中のユーザーのインタラクション・JavaScript エラーを起こしたアクティビティ

Session Traces でセッションを丸⾒えに

最⻑で10分間のセッション記録をとります

New Relic Browser

Session Traces のデモ

RUM (Real User Monitoring) vs Syntheticユーザー体感の監視をしたいが、RUMには限界が…!  パフォーマンスに影響を与える要素が多すぎる

・パフォーマンス問題をコントロールできない・アラートの有効性が薄れる

!  ユーザーがページを開かなければ監視できない・もし深夜にアプリが停⽌していたら…

Synthetics が解決します

New Relic Synthetics

!  Ping無償。HTTPリクエスト送信。ブラウザ起動なし

!  Simple BrowserHTTPリクエストを送信。ブラウザを起動しページをロード

!  Scripted Browserスクリプトで動作を指定。ブラウザを起動しページをロード

!  API Testブラウザ起動なし。APIをコール

4タイプのモニタを、指定のロケーションから、指定したタイミングで実⾏

New Relic Synthetics

Results のデモ

RUM(Browser)とSyntheticsを同時利⽤し切り分け

Browser での応答時間に異常あり

Syntheticsでの応答時間と⽐較

特殊な環境に依存した問題？

ページ⾃体やバックエンドに依存した問題？

Key Transactions については両⽅の観点で監視すべき

14:50 – 15:10 (20m)

モバイルアプリのトラブルシューティング

!  ネイティブアプリをサポート。SDKを組み込んでビルドすれば、⾃動でUX関連データを収集

!  ハイブリッドは、Browser で監視

New Relic Mobile とは

!  Group と Filter で絞り込み → ドリルダウン

Crash analysis の活⽤ビジネス上のプライオリティと照らし合わせ、効率的にトラブルシュート

!  “Stack trace & Interactions“, ”Event”

個別のクラッシュにドリルダウン

New Relic Mobile

Crash analysisデモ

!  （クラッシュしていないものも含めて）発⽣した全てのExceptionについて、Group & Filter

Handled Exceptions NEW!!

15:10 – 15:40 (30m)

New Relic Insights の活⽤

!  APM 等の各製品だけではデータが⾜りない時

New Relic Insights が必要となるケース

このピークでの処理時間は、８２５４件のトランザクションの1分間の平均。実際の分布は？？

平均応答時間は573msだが、実際には３秒を超えるものも複数計測されている

!  Query(NRQL)を記述または Data Explorer

New Relic Insights のデータ出⼒⽅法

Custom Attributes!  エージェント毎にイベントを収集

・APM : Transactions・Browser : PageView と PageAction・Mobile : Mobile・Synthetics : SynthetiCheck と SyntheticRequest

! 上記のイベント内に欲しいデータがない場合、アプリのソース内にカスタムAPIを挿⼊して、エージェントにCustom Attributeを送信させる

New Relic Insights

デモ

(デモでお⾒せしたクエリ）・セッション数の延べ数を条件付きでSelectcount(session)fromPageViewWhereappName='NewRelicPetClinic'・時間範囲を追加（SINCE)Selectcount(session)fromPageViewWhereappName='NewRelicPetClinic'since1dayago・条件を追加SelectCount(session)fromPageViewWhereappName='NewRelicPetClinic’andpageUrl='hEp://xxxxxxxx.compute.amazonaws.com/petclinic/'since1dayago ・条件を正規表現で指定(LIKE)SelectCount(session)fromPageViewWhereappName='NewRelicPetClinic'andpageUrlLIKE'%owners%'since1dayago

(デモでお⾒せしたクエリ）・グルーピング（FACET)SelectCount(session)fromPageViewWhereappName='NewRelicPetClinic'facetpageUrlsince1dayago・複数の値を比較SelectCount(session),average(duraSon)fromPageViewWhereappName='NewRelicPetClinic'facetpageUrlsince1dayago・ユニーク数の計測SelectuniqueCount(session)fromPageViewWhereappName='NewRelicPetClinic'since1dayago・histogramの表示Selecthistogram(duraSon,8,32)fromPageViewWhereappName='ecomm'since1dayago

15:40 – 16:00 (20m)

実習#4:Insightsでパフォーマンス分析

実習#4: Insightsでパフォーマンス分析

1.  https://rpm.newrelic.com/accounts/XXXXXX にアクセス 2.  ご自身のメールアドレスとパスワードでログイン 3.  Insightsを開いてください 4.  以下を確認してください

!  過去３０分で、“のべ”何セッションが New Relic Pet Store にアクセスしていますか？同様の条件で、ユニークなセッション数は？

ヒント：　“SELECT count()”, “SELECT uniqueCount()” !  過去24時間で、どのcityからのアクセスが最も多いですか？

ヒント：　“FACET xxx “ xxx でグループ分け

本日はこれで終了です！！お疲れ様でした

ご質問はメールでご連絡ください

日吉潤一郎 (Harry Hiyoshi) jhiyoshi@newrelic.com

New Relic University ワークショップ@東京へのご招待

Technology

Analog t Relic A

Relic Hunter Mar April2013

ChatOps New Relic & Chef

Gospodarska Matematika Relic

Relic Rulebook - 1jour-1jeu

Hemoliticna bolest marijana relic

Relic Runners - jemmagazin.hu

RE01 Relic Rulebook

Relic Inscriptions

Screenplay - The Relic

Bhattiprolu Relic Casket Inscription.docx

Relic Knights

Relic Hunter

Relic sculpturemag-presentation

Supernova relic neutrinos

Relic at Ion

Relic Knights Rulebook Beta

Monitoring - New Relic

Jesus Real Not Relic

Gc new relic