オブザーバビリティツールのNew Relicを導入しよう！～概要編～

みなさんこんにちは。ネコ好きなマネージドサービス部の塩野です。

前回のブログ記事「【書評】オブザーバビリティ・エンジニアリングを読んでみた」に記載した「オブザーバビリティ・エンジニアリング」の本を読むことで、実際にオブザーバビリティってどんなものかという感触はつかめたような気がしました。では、実際にオブザーバビリティツールを使用してオブザーバビリティを始めるにはどうしたらいいんだろうかという点にフォーカスして今回は記事を書いてみました。

前回のブログはこちら

blog.serverworks.co.jp

前提条件

オブザーバビリティツールはアプリケーションモニタリングの領域に強みを持つNew Relicを想定

データを取り込む前に
～オブザーバビリティ成熟度モデルの紹介～

オブザーバビリティを進めていくにあたり、オブザーバビリティのガイドラインとして成熟度モデル（Observability Maturity Model）というものが存在します。オブザーバビリティ成熟度モデルはオブザーバビリティを進めていくための概念のような考え方で、「オブザーバビリティ・エンジニアリング」の書籍にも記載があり、もちろんNew Relicの公式ドキュメントだけでなく、AWSのベストプラクティスとしてにも 扱われています。

ドキュメントを見る限り、各社それぞれの考え方はありますが、まず大前提としてやるべきことはデータの取り込みになります。

New Relic社　可観測性成熟度シリーズの紹介ページから引用

上記画像のステップ0がデータの取り込みになります。そして取り込んだデータをステップ１で社内の体制作り、ステップ２で取り込んだデータを評価し、アプリケーションのパフォーマンス、信頼性向上に向けて分析・改善活動を進めていきます。次にステップ３である程度アプリケーションのパフォーマンス問題が潰せたら、顧客体験構造に向けて改善活動を進めていきます。ステップ３まで進めば、コードの品質やパフォーマンス問題はある程度解決できていると思いますので、その状態をステップ４として継続して改善活動を続けていくことでビジネス価値を向上させていきましょうという流れになります。

AWSの可観測性成熟度モデルが記載されているドキュメントでは、もっと技術寄りのステップとなっており、テレメトリデータの取り込み、テレメトリ分析と洞察、相関と異常検出、プロアクティブな可観測性といった流れとなっています。このあたりの考え方の違いは、監視を専門に扱っている会社とインフラを専門に扱っている会社の考え方の違いなのかもしれません。

この記事ではステップ0のデータ取り込み部分について深堀していきたいと思います。

New Relic環境にデータを取り込む

New Relic環境にデータを取り込む方法として、OSやアプリケーションにエージェントをインストールしてエージェント経由でデータを取り込む方法とエージェントを使用せず、直接APIを叩いたり、Webサイトにアクセスしたりして監視する方法と、大きく2種類の監視方法があります。

ざっくりとしたWebシステムの場合、どこにどのような設定が必要になるかは下記の図を見て頂ければイメージがしやすいかと思います。

適用箇所と監視内容

適用箇所概要

監視内容と適用先

New Relicで使用するエージェントの種類

New Relicで使用する主だったエージェントとその特徴は下記の通りです。

下記の表では、Infrastructure agentとAPM agentで同じようにアプリケーションの情報取得ができるような書き方をしていますが、Infrastructure agentのプラグインではNginxやMySQLなどの汎用製品のみが対象で、個別開発したアプリケーションについてはAPM agentを用いて監視をおこないます。

エージェントの 種類	機能概要	備考
Infrastructure agent (直接インストール)	OS内部のメトリクスやイベント、ログなどを取得する	OS毎（Windows、Linux、MacOS など）にエージェントがあり、さらにシステムにインストールされているアプリケーションの状態を取得するプラグインを有効化するとNginxやMySQLなどの情報を取得することができる
Infrastructure agent (コンテナ版)	OS内部のメトリクスやイベント、ログなどを取得する	docker環境にコンテナを立てることで、ホストOSの情報を取得。アプリケーションをコンテナで展開する場合や、ホストOSに直接エージェントがインストールできないようなECS、Fargate、Kubanetesなどの環境下での利用を想定
application performance monitoring (APM) agent	アプリケーションに設定したエージェントから、サービス間の連携やトランザクション時間、スループットなどアプリケーションの分析に必要なあらゆる情報を取得する	Java、.Net、Node.JS、PHP、Python、Rubyなどの言語をサポート
mobile monitoring agent	モバイルアプリに特化した情報を取得する	android、iOSなどの個別開発環境だけでなく、Capacitor、Flutter、.Net MAUI、React Native、Unity、Unreal Engine、Xamarinなどの共通開発環境もサポート

※ Infrastructure agentの導入詳細は、こちらの記事をご参照ください blog.serverworks.co.jp

New Relic環境でのマネージドサービス監視や
WEBページやモバイルアプリのパフォーマンスの測定

下記の表では、New RelicでマネージドサービスやWebパフォーマンスを監視する場合に、どういった設定があってその際の注意点がどのようなものかをまとめたものになります。

Infrastructure Integration設定

種類	機能概要	備考
AWS Integration (API Polling)	AWS基盤の情報を取得する	従来からある設定方法で、Amazon CloudWatch Metricsのメトリクスの中でNew Relicが監視に必要なメトリクスとして定義されたもの。Amazon CloudWatch Metricsで新しくできたメトリクスはAPI Polling方式で対応していないものもある反面、CloudWatch Metric Streams で取得できない一部のメトリクスは現在もAPI Pollingでデータ取得する必要がある
AWS Integration (Metrics Stream)	AWS基盤の情報を取得する	New Relic推奨設定。Amazon CloudWatch Metrics 情報を元にデータの取り込みができるが、CloudTrail、Health、Trusted Advisor、X-Rayの情報や、RDS拡張、VPC フローログには対応できていないため、 これらの情報を取得したい場合はAPI Polling方式でデータ取得する必要がある
Google Cloud Integration	Google Cloud基盤の情報を取得する	クラウド監視 APIを利用してデータを取得する
Microsoft Azure Integration	Microsoft Azure基盤の情報を取得する	AzureでNew Relicアプリケーションとキーを作成し、このアプリケーションにモニターするAzureサービスへのアクセスを付与することで基盤側のデータを取得する

Synthetics設定

種類	機能概要
Ping monitor	指定したURLに対してHTTP(S)リクエストを送信し、ステータスコードやレスポンス時間を確認する最も基本的な監視
Certificate check monitor	SSL証明書の期限切れを監視
Broken links monitor	ページ上のすべてのリンクをチェックし、正しいページやコンテンツが返ってくるかどうかをテスト
Simple browser monitor	実際のブラウザ(Chrome)を使って、JavaScriptやCSSなどを含めたページ全体の表示までを監視
Scripted browser monitor	Simple browser monitorをベースに、ログインや複数ページの遷移などの複雑な操作をスクリプトで自動化して監視
API tests	APIエンドポイントに対してHTTPリクエストを送信し、レスポンスのステータスコードやボディを確認する監視
Step monitor	コードを書かずに、Webアプリに対する複数ステップの操作フローを定義して監視するコードレス監視

Mobile設定

エージェントの種別	機能概要
Android エージェント	・起動時間測定 ・ネットワークリクエスト監視 ・クラッシュレポート ・カスタムイベントとメトリクスの記録 ・分散トレーシング
iOS エージェント	・ネットワークリクエスト監視 ・クラッシュレポート ・カスタムイベントとメトリクスの記録 ・分散トレーシング
Capacitor エージェント	・JavaScript errorsの記録 ・ネットワークリクエスト監視 ・カスタムイベントとメトリクスの記録 ・分散トレーシング
Flutter エージェント	・Dart errorsの記録 ・ネットワークリクエスト監視 ・カスタムイベントとメトリクスの記録 ・分散トレーシング
.NET MAUI エージェント	・C# errorsの記録 ・ネットワークリクエスト監視 ・カスタムイベントとメトリクスの記録 ・分散トレーシング
Cordovaエージェント	・JavaScript errorsの記録 ・ネットワークリクエスト監視 ・カスタムイベントとメトリクスの記録 ・分散トレーシング
React Nativeエージェント	・JavaScript errorsの記録 ・ネットワークリクエスト監視 ・カスタムイベントとメトリクスの記録 ・分散トレーシング
Unityエージェント	・C#とNative C++ errorsの記録 ・ネットワークリクエスト監視 ・カスタムイベントとメトリクスの記録 ・分散トレーシング
Unreal Engineエージェント	・C++ errorsの記録 ・カスタムイベントとメトリクスの記録
Xamarinエージェント	・C# errorsの記録 ・ネットワークリクエスト監視 ・カスタムイベントとメトリクスの記録 ・分散トレーシング

まとめ

オブザーバビリティツール（New Relic）を導入しようの概要編では、最も基本的な監視内容についてどこに対してどのような設定すればいいかをまとめてみました。次回は実際のアプリケーションに対してどのように設定をすればいいかについてまとめていきたいなと思います。

宣伝

弊社では、お客様環境のオブザーバビリティを加速するためのNew Relicアカウント開設を含めた伴走型のNew Relic導入支援サービスをご提供しております。 もしご興味をお持ちの方は、こちらのお問合せフォームよりお問合せ頂けましたら幸いでございます。

関連記事

blog.serverworks.co.jp blog.serverworks.co.jp blog.serverworks.co.jp

◆　塩野　正人
◆　マネージドサービス部　所属
◆　X（Twitter）：@shioccii
◆　過去記事はこちら

前職ではオンプレミスで仮想化基盤の構築や運用に従事。現在は運用部隊でNew Relicを使ってサービス改善に奮闘中。New Relic User Group運営。