インフラの可視性を高める：StatsDとAppSignalスタンドアローンエージェントであらゆるシステムを監視する方法

アプリケーション本体だけを監視していても、システム全体の状況を把握できるとは限りません。サテライトアプリ（補助的なアプリケーション）で動作するサービスが、日々の運用に大きな影響を与えることは珍しくありません。データベースサーバーはその代表例です。また、バックアップスクリプトやその他のバックグラウンドジョブも、システムを遅延させる原因になりながら、見落とされがちです。

Node.js向けAppSignal APM、Ruby APM、Elixir APMは、アプリケーション自体を自動的に計測（instrument）します。しかし、デフォルトではAppSignalはこれらのサテライトプロセスを監視しません。監視範囲をあらゆる場所へ拡大し、すべてのデータを1つのアプリで確認したいなら、AppSignalのスタンドアローンエージェントをインストールしましょう。

AppSignalのスタンドアローンエージェント

スタンドアローンエージェントは、通常Ruby、Elixir、JavaScriptアプリケーションの計測に使われているものと同じソフトウェアをベースにしており、スタンドアロンモードでも動作します。

スタンドアローンエージェントは、次のような対象の監視に活用できます。

• インフラストラクチャ： システムを構成するマシンの中でも、アプリケーションコードを実行していないもの。
• バックグラウンドジョブ： 負荷の高いcronジョブや長時間実行されるデータ処理スクリプトなど。これらのジョブが対応言語（Ruby、Elixir、Node.js）で書かれている場合は、標準のインテグレーションを利用できます。
• その他の言語： 標準でサポートされていない言語で書かれたプログラム。

たとえば、スタンドアローンエージェントを使えば、Pythonで書かれた機械学習モデルの追跡、バックアップスクリプトの計測、Kafkaブローカーの監視、Webファームにおけるホストメトリクスの収集などが可能です。これらの情報はすべてAppSignal上で確認でき、メインアプリケーションに関する既存のメトリクスを補完できます。

仕組み

エージェントはdebパッケージまたはrpmパッケージとして提供されており、言語依存は一切ありません。Debian/Ubuntu系およびRed Hat系のシステムであれば動作します。詳細なインストール手順については、エージェントのドキュメントをご確認ください。

インストール後は数分で設定が完了し、以降はデーモンとして永続的に稼働し、静かにインフラを見守り続けます。さらに、このエージェントにはStatsDサーバーが内蔵されており、ログに記録した任意のカスタムデータをAppSignalダッシュボードへ中継します。

StatsDとは？

StatsDは、任意のデータを収集・集約するための標準規格です。メトリクスやパフォーマンス情報の記録に特化しており、UDP接続上の軽量なテキストプロトコルを使用するため、マシンへの負荷が非常に小さくなっています。

StatsDメッセージは次のような形式です：

KEYには任意の文字列、VALUEには数値を指定します。typeの値によって、その数値がどのように処理されるかが決まります。

3種類のメトリクスタイプをサポートしています：

• c： 呼び出されるたびに増加するカウンター（counter）です。たとえば、active_users:1|cと送信すると、active_usersカウンターに1が加算されます。
• g： 数値を受け取り、更新されるまでその値を保持するゲージ（gauge）です。スループットやアクティブユーザー数、キュー内の保留タスク数など、時間とともに増減する値の記録に便利です。
• t： タイミング（timing）値を保存します。処理時間の追跡に最適です。AppSignalは、記録されたすべてのタイミングについて平均値、回数、パーセンタイルを自動的に算出します。

未対応のメトリクスタイプは、黙って無視されます。

StatsDへのデータ送信

スタンドアローンエージェントは、ポート8125でUDPパケットを待ち受けます。netcatを使えば、コマンドラインからStatsD形式の文字列を送信できます：

UDPを使っているため、応答を待つ必要はありません。

socatでも同様に送信できます：

これにより、バッチ処理やcronジョブへの計測組み込みも簡単になります。たとえば、次の行ではゲージを使って、バックアップジョブが生成したデータ量を記録しています：

整数に限らず、StatsDは浮動小数点数にも対応しています：

メトリクスにはタグを付けることもできます。StatsDサーバーは、メッセージ末尾にオプションのタグを付加できます：

同じメッセージに複数のタグを適用し、後でフィルタリングできるよう値を割り当てることも可能です：

AppSignalでのデータ確認方法については、後ほど解説します。

各言語での計測

StatsDサーバーは、UDPパケットを送信できるあらゆる言語と互換性があります。いくつか例を見てみましょう。

Pythonはデータマイニングや機械学習で人気の言語です。標準ライブラリのsocketモジュールを使えば、Pythonアプリケーションに計測機能を追加できます：

Javaでも、java.netライブラリを使って同様のことが実現できます：

PHPも非常に人気のある言語の一例です。socket_sendto関数でUDPパケットを送信できます：

StatsDクライアント

ここまでは、各言語に組み込まれているネットワーク機能を使ってきました。しかし選択肢はそれだけではありません。多くの言語や製品には、サードパーティ製のStatsDクライアントやアドオンが存在します。対応データ型の範囲内であれば、StatsD互換のクライアントであればどれでも動作するはずです。クライアントの一覧は、StatsDプロジェクトのWikiで確認できます。

AppSignalでホストデータを表示する

Host Metrics（ホストメトリクス）ダッシュボードには、マシンのリソース使用率が表示されます：

スタンドアローンエージェントが稼働しているマシンごとに、AppSignalがエントリを追加します。

ダッシュボードには、負荷とCPU平均、ディスク、ネットワーク、メモリ、スワップ使用量が表示されます：

ダッシュボードの作成

AppSignalは、送信したStatsD値のダッシュボードを自動生成しません。カスタムダッシュボードを作成する必要があります。

まず、ダッシュボードメニューのAdd dashboardをクリックします：

ダッシュボードに名前を付けます：

Add graphボタンをクリックすると、グラフビルダーが表示されます：

グラフに名前を付け、Add metricをクリックします：

メニューから目的のメトリクスを選択します。

必要に応じて、タグを使ったフィルタリングも可能です：

次に、Back to overviewをクリックします。表現したいデータに最も適したグラフタイプや値の単位を、いろいろ試してみるとよいでしょう。

タイミングデータは、平均値とパーセンタイルがより明確に表示されるため、面グラフ（area graph）が適しています。

カウンターとゲージには、折れ線グラフ（line graph）が最適です。

結果に満足したら、Create graphをクリックします。

なお、Node.js向けAPM、Ruby（on Rails）APM、Elixir APMとしてAppSignalをパフォーマンス監視ツールとして設定している場合は、自動計測された他のメトリクスについてもダッシュボードを追加できます。

まとめ

今回は、AppSignalのスタンドアローンエージェントを使って、マシンやサテライトコードを監視する方法を学びました。内蔵のStatsDサーバーを利用すれば、任意のパフォーマンスデータを記録し、あらゆるプロセスに計測機能を組み込めます。

スタンドアローンエージェントの使い方について詳しくは、以下のリンクをご覧ください：

• StatsDリファレンス
• カスタムメトリクスの送信方法
• AppSignalでのダッシュボード作成
• スタンドアローンエージェントによるKafka問題の特定と解決

Tomas Fernandez

ゲスト執筆者のTomasは、IBMで10年間勤務し、開発、サービス提供、データベース管理、クラウドエンジニアリングなど幅広い業務に携わりました。現在は独立系コンサルタント兼テクニカルライターとして活動しています。

Tomas Fernandezの記事一覧はこちら