運用で困っていること
- インフラで発生するインシデント（メールが送られない、画面表示が遅いなど）が発生しても、即座の原因特定が難しい
- イベント（画面表示やデータ登録）ごとの発生頻度や利用時間帯がつかめない
- 時系列的に記録されたログでは、複数同時に来るリクエスト処理がごちゃごちゃに記録され、特定の関心のあるリクエストだけを追うのが難しい
- 処理が複数のサービスに分散されていると、関心のある処理を追いづらい
Datadog APMとは
- Datadog社が提供する、アプリケーションのパフォーマンスをリアルタイムで監視し、分析するためのツール（SaaS）
- ユーザーのリクエストがシステムを通過するパスを追跡し、各モジュールでの処理時間を把握できる
- アプリケーションのパフォーマンスを監視し、異常が発生した場合に検知
- 詳細なレポーティング
- 分散システムのサポート
実際に組み込んでみた
ソースコードでライブラリを組み込む必要がある（Goの場合）
// アプリケーション開始時
tracer.Start(tracer.WithServiceName(serviceName))
defer tracer.Stop()
// データベース接続時
sqltrace.Register("mysql", &mysql.MySQLDriver{}, sqltrace.WithServiceName(serviceName))
db, err := sqltrace.Open("mysql", "datadog_sample:password@tcp(db:3306)/db_test", sqltrace.WithServiceName(serviceName))
if err != nil {
logger.Error("failed to connect mysql", slog.Any("error", err))
return
}
defer db.Close()
それ以外にも、datadog-agentの設定でAPM有効化を行う必要がある
適用後に見られる画面
サマリ
リクエスト数、エラー数、レイテンシ、処理内訳が確認できた
トレース
適切に設定すれば、アプリケーションでかかった時間だけでなく、外部システム（DBやマイクロサービス）の呼び出し時間や処理内容もわかる。
メソッドごとの処理時間も、スパン（処理単位）を設定すればわかる。
ログ
適切に設定（span_idとtrace_idをログに出力しdatadogへ送信）すれば、リクエストごとに、紐づいたログを参照できる
今後の課題
- 本番環境への全体的な適用（ソースコード修正が必要）
Goだとcontext.Contextというパラメータに、APM設定用の情報を設定し、リクエストを受け付ける処理からDBやAWS操作処理まで引き回す必要がある
各サービスで修正する必要がある - 各イベントの時間帯ごとの発生頻度を出す方法は調査中
終わりに
この記事は2024年2月15日行われた「第３木曜LT会#2」で発表した内容に加筆したものです。
渋谷スクランブルスクエアWeWorkで毎月第３木曜日にLT会を行なっていますので、ぜひご参加お願いします！