Azureアドベントカレンダー19日目のエントリ、およびNew Relicアドベントカレンダー16日目の代打のエントリとして投稿しています。

Azure上でシステムを開発・運用されているお客様からNew Relicを使ってみたい、New RelicってAzureでも使えるのと聞かれることがあります。もちろん使えます。ということで、今日はNew Relicを使ってAzureサービスで構成されているシステムを観測する方法を4つの視点から紹介したいと思います。

分散システムの観測

New Relicの特徴の一つは、アプリケーションにAgentを設定するだけで、ブラウザやモバイルと言ったReal User Monitoring領域から、サーバーサイドアプリ、サーバーサイドの分散システム、そして接続先のRDBMSやRedisといったミドルウェアや外部接続先(New Relic Agentをいれていないアプリケーション)の情報をまとめて可視化できることです。それを端的に表す機能が「Service Map」で、このように表示されます。動いているアプリはeShopOnContainersというMicrosoftが提供している.NETのマイクロサービスリファレンス用のサンプルアプリです。

この機能は、APMではサーバーサイドアプリにNew Relic APMエージェントをいれ、Browserの場合は必要なHTMLタグを入れるようにアプリケーションを設定し、Mobileの場合はモバイルアプリに参照ライブラリとしてNew Relic Mobile SDKを設定するだけで利用できます。ネットワークトラフィックが流れるのを検知するとアプリケーション間に矢印が引かれます。RDBMSやRedisなどの場合、APMエージェントが情報を取得するため、ミドルウェア側にインストールは不要です。つまり、SQL DatabaseをはじめとするAzureのマネージドサービスを利用している場合でも問題なく利用できます。

APMエージェントもマネージドなPaaS環境に対応しています。少し説明しますと、APMエージェントのインストールがサポートしている言語ごとにやや異なります。サポートしている言語は、C、Go、Java、 .NET (CoreおよびFrameworkの両方)、Node.js、PHP、Python、Javaです。幅広い言語をサポートしているAzureのWeb Appsとも相性が良いです。

APMエージェントのインストールの方法が複数ある言語(例 .NET Core)もあり混乱を招く側面もありますが、多様な実行環境に対応できるメリットでもあります。Azure VM上でアプリケーションを動かしている場合はインストーラーの実行などOS側の操作でセットアップする手順が利用できます。ACIやAKSなどコンテナとして動かす場合は、コンテナ向けの手順が公開されています。Azure Web AppsなどPaaSとしてアプリパッケージのみを展開する方式の場合は、アプリそのものに組み込む手順が利用できます。また、バッチ処理として動くようなバックグラウンドアプリの観測もサポートしています。

APM、Browser、Mobileなど各種機能の説明はAzureサービス固有のものではないのですが、ぜひ分散トレーシング機能は紹介したいと思います。どのパブリッククラウドでも同じだとは思いますが、Azureのサービスを活用してシステムを作るとマイクロサービス的な複数のアプリケーションが協調して動くものになることが多いと思います。Browserなどから始まった1つのトランザクションが複数のアプリケーションで処理されレスポンスを返す、この一連の流れを一筆書きのように追って行けるのが分散トレーシングです。New Relicではこのようにアクセスできる範囲のアプリケーションで発生したトレーシングを全てまとめて見ることができます。HTTP通信の他に、gRPCでの通信でも自動で検出できます。自動検出は設定を有効にするだけですが、手動で検出することも可能でその場合は任意のプロトコルやメッセージキューを挟んでいる場合でもつなぐことができます。

また閾値など設定することなく、普段とは異なる振る舞いを見つける異常検知の機能も利用できます。

分散トレーシングは.NET Core視点ではありますが、以前にも「C# (.NET Core)アプリでNew Relicを使った分散トレーシングについて」という記事を書きました。

New Relic Logsを使ったアプリケーション視点でのログの可視化

New Relic Logs in Context:ログデータから意味ある情報を得るために」で紹介したLogs in Context、Azure VMに入れた場合に利用できるのはもちろんですが、Web AppsなどのPaaSや、コンテナ内のアプリから直接New Relicにログを送信することもできます。ログデータを送信して検索するだけであれば任意のLoggerライブラリを利用できますが、Logs in Contextの場合はNew Relicが対応しているライブラリを利用するか、ご自身で対応するフォーマットに書き出す必要があります。

転送の方法ですが、AKS上のコンテナの場合はNew Relic Logsのkubernetesプラグインで転送できます。一方、WebAppsの場合、サードパーティのLogを転送するためにはWeb Appsのバックグラウンドプロセスを使う方法もあるかと思いますが、簡単のためにプロセス内でHTTP通信でログを直接送信することにします。例えば.NET Coreの場合、Logs in Contextに対応しているライブラリは今のところSerilogですが、SerilogにはSinkという出力先を制御できる仕組みがありSerilog.Sinks.Http というライブラリを使うと、送信先のエンドポイント、NewRelicのFormatter、ライセンスキーをHTTPヘッダーに入れる処理を行うだけでSerilogを使って出したログをプロセス内のSinkでNew Relicに転送できるようになります。具体的なコードは改めて別のエントリで解説したいと思います。

Azure Integrationの利用

ここまでアプリケーション中心の紹介をしてきましたが、インターネットに公開するためにAzure Load Balancerを使ったり、ストレージとしてAzure Storageを使ったりと様々なAzureサービスと組みわせて使っていると思います。そのようなAzureサービスのメトリクスをNew Relic側に取り込むことができます。それがAzure Integrationという機能で、製品としてはNew Relic Infrastructureに属しています。同様の仕組みをAWS、GCPについても提供しています。Azureの場合、対応しているサービスは現在これだけあります。

それぞれの機能ごとにダッシュボードや取得しているデータの構造、アラートの設定がまとまったページがあります。

IntegrationはNew RelicアカウントとAzureのサブスクリプションでN対Nに設定できます。AzureのAPIが提供している情報ですので、Azure Portalで原則見られる情報ではあるため、この機能単体ですと、1つのNew Relicアカウント内で複数のサブスクリプションの情報をまとめてみれるダッシュボードを作れる、といった活用例になってしまいます。

Azure Integrationの機能は、APM、Browser、Mobileなどの機能と組みわせて活用してみてください。例えば最初のService Mapで出たベース接続しているアプリがありましたが、アプリから見たデータベースやRedisのメトリクスとAzure Integartionで見るデータベースやRedisのメトリクスを合わせて見ることができます。

AKSの可視化

先日の「New Relicでkubernetesを監視する」で紹介したkubernetes cluster explorerの機能、もちろんAKSもサポートしています。紹介した全ての機能がAKSで利用できます。

AKSの場合、ServiceにALBを使ったり、ストレージにAzure DiskやAzure Fileを使ったりするため、Azure Integrationと組み合わせてさらに可視化を進めることができます。例えば、ノードとして使っているAzure VMごとに接続されているディスクの数を見たり(上限に達するとそれ以外のリソースが余っていてもPodをスケジュールできなくなる)、ALBの負荷の様子を見ることができます。このようにまとめてみられるダッシュボードを作成し一覧でみられるようにするとともに、それぞれにアラートを設定することも可能です。

 

以上、4つの視点からAzureサービスで構成されたシステムをNew Relicで監視する方法を紹介してみました。興味を少しでも持っていただけた方はぜひ、一度詳しい話をさせていただくか、無料トライアルを始めていただきたいと思っています。また、Microsoft MVP for AzureですのでAzure関連のイベントなどでお目にかかるかもしれません。その時はぜひお声かけください。こんな使い方ができるのではないか、こういうことをしたいけどNew Relicでできるのか、などなど気になることはぜひご質問ください。

無料トライアル