new relic university ワークショップ@東京へのご招待

New Relic Template 2015

1

Getting started with New Relic APM

Confidential ©2008-16 New Relic, Inc. All rights reserved.

⽇吉潤⼀郎 (Harry Hiyoshi)Technical Account Manager for [email protected]


本⽇の内容午前の部 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. リクエスト送信

time

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) [email protected]

new relic university ワークショップ@東京へのご招待

Technology