みなさんこんにちは。ネコ好きなマネージドサービス部の塩野です。
前回のブログ記事「【書評】オブザーバビリティ・エンジニアリングを読んでみた」に記載した「オブザーバビリティ・エンジニアリング」の本を読むことで、実際にオブザーバビリティってどんなものかという感触はつかめたような気がしました。では、実際にオブザーバビリティツールを使用してオブザーバビリティを始めるにはどうしたらいいんだろうかという点にフォーカスして今回は記事を書いてみました。
前回のブログはこちら
前提条件
オブザーバビリティツールはアプリケーションモニタリングの領域に強みを持つ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）を導入しようの概要編では、最も基本的な監視内容についてどこに対してどのような設定すればいいかをまとめてみました。次回は実際のアプリケーションに対してどのように設定をすればいいかについてまとめていきたいなと思います。
宣伝
弊社では、こうしたオブザーバビリティの導入を促進するツールのご紹介を行っております。もしご興味をお持ちの方は、こちらのサービスご紹介ページの一番下にあるお問合せフォームよりお問合せ頂けましたら幸いでございます。
関連記事
blog.serverworks.co.jp blog.serverworks.co.jp blog.serverworks.co.jp
