Zenn
Open27

New Relic の主要機能 - バックエンド

Kota ShimozuruKota Shimozuru

アプリケーションのパフォーマンス分析をする

https://newrelic.wistia.com/medias/7siq8pn2zf

Summary

  • アプリケーションの応答状況を色分けしている
  • このメニューからはどの時間帯で遅くなっているかを確認できる

Transactions

以下の3つが選択可能。

  • Most Time Consuming
  • Slowest average response time
  • Throughput (calls per minute)

Most Time Consuming

  • 平均応答時間とスループットを掛け算した値が大きい順に並べている。
  • アプリケーションのパフォーマンスに影響を与えている順にトランザクションを見ることができる

遅くなっている時間帯でDatabaseの時間が遅くなっている事がわかる。
Brakedown tableではMySQLでAvg Calls/Txnから177回クエリを実行しており、ここで遅くなっている事がわかる。Transaction Traceを見ることでピンポイントにボトルネックの箇所を確認できる。

Kota ShimozuruKota Shimozuru

これは大変お世話になった機能。本当に使える。これがないとキツい。

Kota ShimozuruKota Shimozuru

アプリケーションのエラー分析をする

https://newrelic.wistia.com/medias/uz8psa6k82

Errors

  • Errorの詳細を分析するにはErrorsを選択する
  • Group byにより情報が整理された状態で確認ができる
  • Errorを選択すると、詳細画面が表示され、1件1件の詳細を見ることができる
  • New RelicにユーザIDをカスタムの設定を入れることでどのユーザでエラーが発生指定単価を見ることができる
  • Logs in contextを構成していると「View logs」を選択することで関連するエラーを抽出してみることができる。
Kota ShimozuruKota Shimozuru

Logs in contextなんて機能あったのかよ。。これもっと早く知っておけばなぁ。
全然使えてなかった。めちゃめちゃいいじゃん。

Kota ShimozuruKota Shimozuru

リリース前後のアプリケーションの品質を評価する

https://newrelic.wistia.com/medias/uwzxs8hskr

Deployment

アプリケーションのパフォーマンスやエラーを見る際、リリース前後がある。
リリースの前後で印（Deployment Marker）を送ることで簡単に比較することができる。

リリースによってアプリケーションの品質に影響を与えていないかを確認することができる。
REST APIでデプロイメントを記録することで簡単に組み込むことができる。
トランザクションの長時間化やCPU使用率が高くなっている箇所を確認することができるようになる。
https://docs.newrelic.com/jp/docs/apm/apm-ui-pages/events/record-deployments/#post-deployment

Kota ShimozuruKota Shimozuru

Lambda関数を観測する

https://newrelic.wistia.com/medias/sf5wioemka

Lamba Functions

  • AWSの各種サービスは、Metric streamまたはAPI Callingを利用してNew Relicに連携できる
  • New Relic上では、各種サービスごとに分類され、Entityとして扱われる
  • Lambda functionsを選択すると、詳細情報を確認できる
  • 注目すべきはInstrumentationで、これがYESかどうかで見れる情報が決まる

Lambda Extensions

AWS Lambda拡張によってより詳細な情報が見れる。

  • マイクロサービス毎のつながりをみる分散トレーシング
  • Invocations
  • Errors
Kota ShimozuruKota Shimozuru

そんな難しいことはないね。Extensionsって有料なのかしら？ひとまずExtensions入れときゃいいのかなと思った。サーバレス監視を有効にするとnewrelic-log-ingestion Lambda 関数を呼ぶようになるらしいのだが、AWSのコストが発生することは認識しておいたほうが良さそう。といってもいくらくらいなんでしょうね。
https://docs.newrelic.com/jp/docs/serverless-function-monitoring/aws-lambda-monitoring/instrument-lambda-function/introduction-lambda/#costs

Kota ShimozuruKota Shimozuru

Lambda関数を呼び出している処理を含めて観測する

https://newrelic.wistia.com/medias/1fypopa5gz

Lambda Functions

  • Lambda FunctionsのInstrumentionがYESとなっていると詳細な情報が取れている
  • メモリ利用状況などが追加されている

Distributed Tracing

  • Lambda関数が関わる分散情報が表示できる
  • 個々のLambda関数がどこから呼ばれているのかなどを可視化してみることができる
Kota ShimozuruKota Shimozuru

なるほど、たしかにLambda関数などのサーバレスだとどこから呼ばれているのかを確認できると便利そう

Kota ShimozuruKota Shimozuru

Lambda関数からのログを可視化する

https://newrelic.wistia.com/medias/8lgcn4c2fs

AWS Cloudwatch Collectorが有効化されていればLambdaに関するログも自動的に収集できる

  • Invocationsを選択して長い時間のか買ったリクエストを選択
  • invocations detailsのLogsを選択すると、Lambdaやアプリケーションから履かれたログを一箇所で確認することができる。
Kota ShimozuruKota Shimozuru

AWS Cloudwatch Collectorと言語エージェントのログ遷移コンテンテキストをオンにしていればより詳細な情報が見れるといっていたが、あっている？

Kota ShimozuruKota Shimozuru

サーバーのリソース使用状況やログを分析する

https://newrelic.wistia.com/medias/4m6amky2m4

Infrastructure

  • サーバ管理に必要なイベントを可視化・分析することができるようになっている
  • See logsを選択することでサーバのログにジャンプすることもできる
Kota ShimozuruKota Shimozuru

サーバーリソース分析をアプリケーション分析と関連付ける

https://newrelic.wistia.com/medias/t1e65gzoji

  • New Relic InfrastructureとAPMの両方をセットアップしている場合、両方を関連付けて見ることができる。
  • CPU使用率、Load Average、Memory空き状況がデフォルトでは表示されている。
  • ただ、定期的になぜCPU使用率が高騰しているのかはアプリと組み合わせないとわからない。
  • Application Error RateがCPU使用率のグラフと連動していることがわかれば、Infraレイヤではなく、アプリレイヤの原因を特定することがポイントだとわかる。
Kota ShimozuruKota Shimozuru

サーバーの構成管理を行う

https://newrelic.wistia.com/medias/497twpays6

Inventory

  • SEARCH INVERTORYフィールドから見たい条件のフィルタをかけることができる
  • 例えばOpenSSHの脆弱性が発見された場合、該当するパッケージをフィルタできる
  • Itemsリンクを開くことですぐに特定することができるようになっている
  • これまではExcelなどのスプレッドシートで管理しているケースがあったが、この機能で設計書との不整合な状態から脱却ができる
Kota ShimozuruKota Shimozuru

え、サーバ構成管理までNew Relicの守備範囲だったのね。。意外と知らない機能ってかなりあるもんですねえ。

Kota ShimozuruKota Shimozuru

Kubernetes クラスターを可視化する(Pixie編)

https://newrelic.wistia.com/medias/st0ycitxbm

Live debbuging with Pixie

  • px/cluster: defaultではレイテンシベースであるが、Error Rateベースでも表示できる。
  • px/dns_flow_graph: DNS周りも簡単に

Flamegraph

  • Podを選択して、Check flamegraph in Pixieを選択
  • CPUが実行した処理とその時間を積算した形でグラフ描画してくれる

Instant APM

  • Pixieが取得した情報をOpenTelemetry形式で見ることができる。
  • APMの設定をしなくても、簡易的なAPMを利用できる
Kota ShimozuruKota Shimozuru

Flexを使ってコマンド実行結果などのカスタム指標を収集して可視化する

https://newrelic.wistia.com/medias/a0t51c1p2k

  • 任意のコマンド実行結果をNew Relicに送信することができるFlexという機能がある
  • Infrastructure Pluginとして簡単な設定で利用ができる
  • 既定の情報では満たせない場合に利用するとよい
# 設定ファイルはこちら
$ cd /etc/newreli-infra/integrations.d
$ ls -l
docker-config.yml
integrations.yml
# integrations.ymlの設定を変更することで登録できる
$ vim integrations.yml

Data explorer

  • nameをpingで登録するとpingSampleとして、登録される。
Kota ShimozuruKota Shimozuru

NPM_ネットワーク監視概要と、各機能の違いを知る

https://newrelic.wistia.com/medias/yiza2mz5q6

Network

  • Device performance：NW機器から収集したSNMPデータを確認できる。CPUやMEM、IF情報を確認できる。
  • Network syslogs：各NW機器の動作状況を収集する。
  • Cloud flow logs：Amazon VPC flow logsに対応しており、各サービスの通信内訳をリアルタイムに把握できる。
  • Network flows：NW機器から収集したflowデータを収集する。

収集するには？

  • ktranslate docker コンテナイメージをNW機器のアクセスできる環境にデプロイすればよい
  • Agent health：デプロイしたエージェントのヘルスチェックが可能
Kota ShimozuruKota Shimozuru

NPM_Cloud Flow Logsでネットワーク機器の監視を行う

https://newrelic.wistia.com/medias/ze1lg9haua

Cloud flow logs

  • Amazon VPC Flow Logsをサポートしている
  • AWS側で送信するためのAmazon Kinesis Data Firehoseの設定が必要
  • New Relic側でガイド付きインストールを利用すれば楽に利用できる
  • 連携できるようになるとCloud flow logsでサンキーダイアグラム形式で確認できるようになる
  • Add to dashboadもダッシュボードに追加できて便利
  • Infrastructure、APMに加えてプラスアルファとして利用ができると原因分析がより詳細に行える