StatsDとAppSignalスタンドアロンエージェントでシステム全体を監視する方法

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

Node.js向けAppSignal APM、Ruby APM、Elixir APMは、アプリケーションそのものを自動的に計測します。しかし、デフォルトの状態ではこれらの衛星プロセスまでは監視されません。監視範囲をシステム全体に広げ、すべてのデータを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

KEYは任意の文字列、VALUEは数値です。タイプ(TYPE)の値によって、その数値をどう処理するかが決まります。

対応しているメトリクスタイプは次の3種類です。

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

これ以外の未対応のメトリクスタイプは、警告なく無視されます。

StatsDへのデータ送信

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

echo -n "myscript.myevent.counter:1|c" | nc -4u -w0 localhost 8125

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

socatでも同じことができます。

echo -n "myscript.myevent.counter:1|c" | socat - udp:localhost:8125

この手軽さのおかげで、任意のバッチジョブやcronジョブの計測も容易です。たとえば次の例では、ゲージを使ってバックアップジョブが生成したデータ量を記録しています。

backup_size=$(du -m /backups | cut -f1)
echo -n "backup.data:$backup_size|g" | nc -4u -w0 localhost 8125

送信できるのは整数だけではありません。StatsDは浮動小数点数にも対応しています。

echo -n "network.latency:0.2|g" | nc -4u -w0 localhost 8125

タグの活用

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

KEY:VALUE|TYPE|#TAGS

1つのメッセージに複数のタグを適用でき、後からフィルタリングできるよう値を持たせることも可能です。

echo -n "backup.data:$backup_size|g|#backups,env:production" | nc -4u -w0 localhost 8125

このデータをAppSignal上で確認する方法は、後ほど説明します。

さまざまな言語での計測

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

Pythonはデータマイニングや機械学習の分野で特に人気の高い言語です。標準ライブラリのsocketモジュールを使えば、Pythonアプリケーションに簡単に計測を組み込めます。

import time
 
# 関数の処理時間を計測
start = time.process_time()
train_my_model()
training_time = time.process_time() - start
 
# statsdへ値を送信
import socket
 
UDP_IP = "127.0.0.1"
UDP_PORT = 8125
MESSAGE = b"model.training.time:" + bytes(str(training_time), 'utf-8') + b"|t"
 
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(MESSAGE, (UDP_IP, UDP_PORT))

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

byte[] buffer = "mybatch.exception.counter:1|c".getBytes();
InetAddress address = InetAddress.getByName("127.0.0.1");
DatagramPacket packet = new DatagramPacket(
    buffer, buffer.length, address, 8125
);
DatagramSocket datagramSocket = new DatagramSocket();
datagramSocket.send(packet);

PHPも非常に広く使われている言語のひとつです。socket_sendto関数でUDPパケットを送信できます。

$msg = "mywebsite.active_users:$ACTIVE_USERS|g";
$len = strlen($msg);
 
$sock = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP);
socket_sendto($sock, $msg, $len, 0, '127.0.0.1', 8125);
socket_close($sock);

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(Rails)向けAPM、Elixir APMとしてAppSignalを導入済みの場合は、自動計測されたその他のメトリクスについても、同様の手順でダッシュボードを追加できます。

まとめ

本記事では、AppSignalのスタンドアロンエージェントを使って、マシンや衛星的なコードを監視する方法を解説しました。内蔵のStatsDサーバーを活用すれば、任意のパフォーマンスデータを記録し、あらゆるプロセスを柔軟に計測できます。

スタンドアロンエージェントの詳細については、以下のリソースも参考にしてください。

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