サーバーレス監視
AWS Lambda のように常駐ホストの無い実行環境を、関数の起動を単位に見張る監視です。Lambda Extension が関数の中からメトリクスとトレースとログを送り、Cloud Run や Azure のアプリも同じ枠で見ます。
何ができるか
AWS Lambda / Step Functions / Azure App Service / Azure Container Apps / Google Cloud Run を対象に、関数やコンテナからメトリクス、トレース、ログを集めて 1 画面に並べます。Lambda では Lambda Extension が関数と同じ実行環境で動き、コールドスタートなどの拡張メトリクスを秒粒度で出します。
どのような場面で使うか
「関数が 200 本あるが、どれが遅くて、どれがタイムアウトしているのか分からない」状態を抜けるときに使います。API Gateway からキュー、関数、データストアへ流れる 1 リクエストを 1 本のトレースで追う、コールドスタートの回数にアラートを掛ける、デプロイの前後で性能の変化を比べるといった使い方です。
身近な例え
月給の常駐スタッフ (ホスト) ではなく、呼ばれたときだけ来る臨時スタッフ (関数) の勤怠管理です。監視の費用も「その時間に実際に出勤していた人数の平均」で数えるため、名簿に 200 人いても、動いたのが 30 人なら 30 人分で済みます。
結論 - ホストの無い世界では「時間ごとに動いた関数の平均」が単位
監視の単位は、ふつうホストです。AWS Lambda にはその前提が無く、実行環境は起動のたびに現れて消えます。そこで Datadog は、1 時間ごとに「1 回以上実行され、かつ監視されていた関数の数」を記録し、月末にその時間平均を課金対象の関数数とする定義を置いています (2026 年 9 月時点・出典: Serverless Billing)。関数は ARN で一意に数え、Lambda@Edge はリージョンごとに別の関数です。課金は AWS Lambda の Workload Monitoring としてアクティブ関数あたりの月額で、年契約とオンデマンドで単価が変わります (出典: Datadog Pricing)。一覧に 200 本あっても、時間平均で 30 本しか動かなければ 30 本分という数え方が、ホストの世界との最大の違いです。本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。
Extension と Forwarder、2 つの経路で運ぶものが違う
Lambda から Datadog へ送る経路は 2 つあります。1 つは Datadog Lambda Extension で、関数と同じ実行環境で動き、カスタムメトリクス、トレース、ログを実行中に非同期で送ります。ログは Lambda Telemetry API から直接取るため、CloudWatch を経由しません (2026 年 9 月時点・出典: Serverless Monitoring for AWS Lambda)。もう 1 つは Datadog Forwarder で、ログからテレメトリを抽出して送ります。公式ドキュメントは Extension を推奨経路と位置づけています。ただし API Gateway、AppSync、Lambda@Edge など他の AWS サービスのログ収集には Forwarder が引き続き必要で、分担の関係です (出典: Deciding to migrate to the Datadog Lambda extension)。
| 観点 | Lambda Extension | Forwarder |
|---|---|---|
| 動く場所 | 関数と同じ Lambda 実行環境の中 | 別に配置する Lambda 関数 |
| 運ぶもの | 関数のカスタムメトリクス、拡張メトリクス、トレース、ログ | ログから抽出したテレメトリと、API Gateway や AppSync、Lambda@Edge など他 AWS サービスのログ |
| CloudWatch Logs の経由 | しない (Telemetry API から直接送る) | する (CloudWatch Logs と Forwarder 関数の費用が乗る) |
| 新しい関数を足したとき | Lambda レイヤーを追加する | ロググループごとにサブスクリプションフィルターを設定する |
| 公式の位置づけ | 関数のテレメトリ収集の推奨経路 | 他 AWS サービスのログ収集に必要 |
起動 1 回がトレースの 1 起動になる - 拡張メトリクスと APM の数え方
Extension 経由では aws.lambda.enhanced の接頭辞を持つ拡張メトリクスが秒粒度で届き、コールドスタート、推定 AWS コスト、タイムアウト、メモリ不足や使用量にアラートや SLO を設定できます (2026 年 9 月時点・出典: Serverless)。トレースは Python、Node.js、Ruby、Go、Java、.NET の SDK が対応し、API Gateway から関数、データストアへ流れる 1 リクエストを 1 本のトレースで追えます。課金は APM の取り込みスパンに結びついた Lambda 起動の月間合計で、請求対象の APM ホストは発生しません。単価はトレース済み 100 万起動を 1 単位とする月額で、1 起動 = 1 トップレベルスパンです (出典: Datadog Pricing)。索引スパンの超過分と Fargate との違いは APM 料金の解説と APM に譲ります。
Extension を入れると関数は遅くなるのか
代償もあります。1 つは、拡張の初期化が乗るためコールドスタートの初期化時間がわずかに増えることです。もう 1 つは、aws.lambda.duration などで報告される実行時間が増えて見えることです。増えた分は Extension が Datadog へ送り出す時間で、AWS が呼び出し元へレスポンスを返した後に行われるため、関数の応答は遅くなりません (2026 年 9 月時点・出典: Datadog Lambda Extension)。知らないと、導入直後に duration のグラフが上がったのを性能劣化と誤読し、ロールバックしてしまいます。送信は既定で毎起動の終わりですが、1 分に 1 回を超える頻度を検知すると複数起動分をまとめて定期的に送ります。Datadog サイトから遠いリージョンでは増分が大きくなるため、環境変数 DD_SERVERLESS_FLUSH_STRATEGY=periodically,60000 で送信間隔を 1 分へ広げて抑えられます。
デプロイの直後に壊れたのかを即答できるか
サーバーレスの障害調査で最初に知りたいのは「直近のデプロイが原因か」です。Deployment Tracking はコード、設定、デプロイの変更を関数のメトリクス、トレース、ログと突き合わせ、変更が健全性と性能にどう影響したかを追えるようにします (2026 年 9 月時点・出典: Serverless)。関数のバージョンが上がった時刻とエラー率の折れ線が同じ画面に並べば、「戻すか、待つか」の判断が推測ではなく比較になります。付加機能としては、Lambda 関数の中でボトルネックになっている行を特定する Continuous Profiler と、関数への脅威を扱う App and API Protection があります (出典: Serverless Monitoring for AWS Lambda)。起点を関数 1 本ではなく「その関数を含むスタック」に置き、キューやストリーム、データストアといったマネージドサービスの指標を同じ画面で見るのが Datadog の形です。
Step Functions や Fargate、Cloud Run はどう数えるか
Datadog がサーバーレス監視の対象として挙げるのは AWS Lambda、Azure App Service、Azure Container Apps、Google Cloud Run で、AWS Step Functions も同じ画面で扱います (2026 年 9 月時点・出典: Serverless)。Step Functions はログから実行トレースを生成し、ステートマシンの実行経路、各ステップの入出力、所要時間を追えます。拡張メトリクスは aws.states.enhanced の接頭辞で Datadog 側が生成します。Cloud Run と Azure Container Apps はクラウド連携に加えて、サーバーレス向けの Agent をアプリに組み込むとトレース、カスタムメトリクス、ログを直接集められます。Fargate などのアプリケーション監視は、5 分間隔で測ったアクティブなアプリインスタンスの平均が課金の単位です。
| 対象 | 数える単位 | 契約形態 | 主な注意点 |
|---|---|---|---|
| AWS Lambda の Workload Monitoring | アクティブ関数 (時間ごとの起動関数数の平均) | 年契約 / オンデマンド (年契約が低い) | 一覧の本数ではなく動いた本数の時間平均 |
| AWS Lambda の Functions APM | トレース済み 100 万起動 (1 起動 = 1 トップレベルスパン) | 年契約 / オンデマンド | APM ホストは発生しない |
| AWS Fargate ほかの Application Monitoring | アクティブアプリインスタンス (5 分間隔の平均) | 年契約 / オンデマンド | タスク数の増減がそのまま平均に効く |
| AWS Fargate ほかの Application APM | トレース済みアクティブインスタンス | 年契約 / オンデマンド | トレースを入れたインスタンスだけを数える |
関数 200 本のうち 30 本が動く構成で数え方を確かめる
仮定を置きます。関数は 200 本、そのうち 1 時間に 1 回以上動くのが時間平均で 30 本、月間起動は 500 万回で全てトレースする構成です。Workload Monitoring の請求は「時間平均で動いた関数数 × 関数単価」なので、対象は 200 本ではなく 30 本です。Functions APM の請求は「トレース済み起動の 100 万回単位 × 単位あたりの単価」なので、500 万起動なら 5 単位です。仮に関数単価を p、100 万起動あたりの単価を q とすると、月額は 30p + 5q で、200 本が毎時すべて動く構成なら Workload 側だけで 200p、つまり 30 本のときの 6.7 倍近くになります (単価は年契約とオンデマンドで異なる・出典: Datadog Pricing)。本数を数えるのではなく「時間平均で動いた本数」と「起動回数」の 2 軸で見積もるのがこの SKU の読み方で、夜間に止まるバッチ関数は分母を膨らませません。索引スパンの超過分と、Pro / Enterprise に同梱される課金関数あたり 5 個のカスタムメトリクスの枠 (出典: Serverless Billing) は別に確認します。料金の全体は料金の読み解きで扱っています。
- 仮定: 関数 200 本 / 時間平均で動く関数 30 本 / 月間起動 500 万回 (全てトレース)
- Workload Monitoring: 時間平均で動いた関数数 × 関数単価 = 30p (200 本ではない)
- Functions APM: 100 万起動単位の数 × 単価 = 5q
- 合計: 30p + 5q (年契約かオンデマンドかで p と q が変わる)
- 比較: 200 本が毎時すべて動くと Workload 側だけで 200p
境目は伸びるのが起動数か関数数か
判断で効くのは、構成がどちらの軸で伸びるかです。少数の関数にトラフィックが集まる構成では、Workload Monitoring 側は関数数で決まるため起動が 10 倍でも変わらず、伸びるのは 100 万起動単位の Functions APM 側だけです。逆に関数を細かく割る構成では、動いた関数の時間平均がそのまま Workload 側に乗ります。後者で効くのが監視対象の絞り込みで、AWS 連携の Metric Collection では key:value 形式のタグで監視する Lambda 関数を限定でき、! を先頭に付けたタグは除外として優先されます (2026 年 9 月時点・出典: Serverless Billing)。ただし Extension やライブラリで計装した関数は AWS 連携を無効にしても課金対象なので、絞り込みは連携側のタグと計装の両方で行います。連携はインテグレーション、関数のログの流量が別の請求になる点はログ管理の解説で扱っています。
注意点
- 本記事は 2026 年 9 月時点の公式ドキュメントの記載に基づいています。対応ランタイムや収集経路は変わり得るため、導入時は公式ドキュメントのインストール手順を優先してください。
- 本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。
- Lambda Extension やライブラリで計装した関数は、AWS 連携を無効にしていても課金対象のアクティブ関数として数えられます (2026 年 9 月時点)。監視対象を絞るときは連携側のタグフィルターと計装の有無の両方を確認してください。