はじめに

こんにちは、Datadog Japan で Sales Engineer をしている AoTo です。

この投稿は AoTo Advent Calendar 2023 21日目の記事です。

2023/12/19に O’Reilly Japan から『入門 eBPF』の邦訳が発売されましたが、皆さんはもう手に入れましたか？私は手に入れました！

そんな eBPF に入門中の私ですが、Observability にも欠かせない技術となっている eBPF によって SRE を簡単に始めることができると知り、その概要と活用方法を紹介しようと思いました。

今回は Datadog Agent の一部であり、eBPF を利用した system-probe エージェントの機能から、Universal Service Monitoring(USM) のソリューションについてまとめています。

`system-probe` エージェント

Datadog は L4-L7 ネットワークのモニタリングソリューションとして system-probe を提供し始めました。当初は Network Performance Monitoring 用の機能のみを備えていましたが、eBPF を利用してさまざまな観点での監視テレメトリデータを収集するようになり、現在は以下の機能群を備えています。

system-probe エージェントは Datadog Agent(v6/7以上) と同様に Go 言語で書かれており、設定により必要となると Datadog Agent から起動され独自のプロセスとして実行されます。上記の機能を有効化しない限り動かないため、有効化されるとsystem_probe.pyによって自動ビルドされる形で Datadog Agent コンポーネントに含まれています。

Datadog はセキュリティ上の理由から、この system-probe が起動する際に最小限の権限を与えるように設計し、監視データを収集する際は Datadog Agent を介して Datadog のバックエンドに送信されます。system-probe そのものではありませんが、Datadog が想定する eBPF の監視ソリューションへの活用方法は以下のブログからもある程度読み取ることができます。²

Datadog は2022年に HTTP セッションの監視を応用して、eBPF によってアプリケーショントラフィックの監視を行う Universal Service Monitoring(USM) を一般提供(GA) しました。Datadog USM によって、アプリケーションレベルのトラフィックを監視するだけで、インフラストラクチャ内で実行されているすべてのサービスを検出できるようになっています。

USM をはじめる

前述の通り eBPF を活用してアプリケーショントラフックを監視するソリューションである Universal Service Monitoring(USM) は、その技術背景から当初は Linux での利用に限られていました。現在は Windows IIS など様々な技術を利用することで、以下のバージョンと互換性要件で提供されています。

互換性	バージョン
Datadog Agent	6.40, 7.40 以上
OS	Linux Kernel 4.14 以上 CentOS, RHEL 8.0 以上 Windows 2012 R2 以降の IIS
L7 プロトコル	HTTP, HTTPS(OpenSSL)

有効化の方法は単純で、system-probe.yamlファイルに下記の設定を追加するか、それに準ずる形で環境変数DD_SYSTEM_PROBE_SERVICE_MONITORING_ENABLEDにtrueを渡したりすることで有効化できます。

system-probe.yaml

service_monitoring_config:
  enabled: true

これにより先ほどの通り、system-probeが準備され、別プロセスとして eBPF を用いた HTTP セッションの監視が行われます。アプリケーションサービスとその依存関係は自動的に検出され、Service Catalog にマッピングされます。

USM メトリクスの活用

system-probeエージェントによって自動検出されたアプリケーションサービスは、Datadog Agent によって自動的にタグ付けされます。

USM によって生成される以下のメトリクスも、統合サービスタグ付けの恩恵を受けてタグが付与された状態で Datadog 上で可視化できます。

メトリクス名	単位	タイプ	説明
universal.http.client	秒	Distribution	アウトバウンドリクエストのレイテンシー、カウント、エラー、およびレート
universal.http.client.hits	Hits	カウント	アウトバウンドリクエストとエラーの合計数
universal.http.client.apdex	スコア	Gauge	アウトバウンドリクエストの Apdex スコア
universal.http.server	秒	Distribution	インバウンドリクエストのレイテンシー、カウント、エラー、およびレート
universal.http.server.hits	Hits	カウント	インバウンドリクエストとエラーの合計数
universal.http.server.apdex	スコア	Gauge	この Web サービスの Apdex スコア

また、エラーに関するメトリクス名は上記に共通しており、error:trueタグが付与されます。APM とメトリクス名は異なり、universal.http.client.*かuniversal.http.server.*のように命名されそれぞれアウトバウンドとインバウンドのトラフィックに基づくメトリクスを提供しています。

これらのメトリクスはデフォルトで、Service Page の Service Summary に表示され、リクエスト・エラー・レイテンシーの指標を可視化できます。

USM で SRE を始める

このように USM は SRE で重要とされる、システムの健全性を示す指標である４つのゴールデンシグナルのうち、R.E.D メトリクス の3つが自動的に可視化されます。飽和度を表すメトリクスはサービスのインフラストラクチャメトリクスから確認でき、USM で可視化された各メトリクスと同一のタグを持っているため、すぐに確認ができます。

レイテンシ - リクエスト処理時間
トラフィック - リクエスト量
エラー - リクエスト失敗率
飽和度 - リソース使用率

USM のこれらの指標は、Datadog Monitor と SLOs を利用して SRE の主目的である信頼性の指標を可視化することができます。

SRE の概念や各用語については、ちょうど今日素晴らしい記事が PagerDuty さんから出ていたので是非ご一読ください！

APM Monitor は Monitor の機能の一つですが、USM のメトリクスを含むアプリケーションメトリクスを Service Level Indicator(SLI) にの元の指標に定めて、閾値・異常検知で状態を監視することができます。

APM Monitor でメトリクスを選択し、閾値の値やその時間範囲あたりでの達成率を決めることで、Service Level Objective を定めることが出来ます。Monitor-based SLOs はここで設定したサービスのモニターの正常な動作を示した時間を掃除間で割ることで SLI と SLO が計算され定義できます。

他にも Time Slice SLOsを利用することで、95パーセンタイルのレイテンシーが1秒未満である時を正常な稼働時間として SLI を定義をして、SLO を定めることもできます。

このように、Datadog Agent の設定を1つ有効化するだけで、SRE を始める上では欠かせない指標が Datadog 上で自動的に可視化され、サービスの特性に応じてゴールデンシグナルから SLI, SLO を定めて実践を行うことが可能です。

おわりに

eBPF を活用したソリューションはアプリケーショントラフィックの監視だけではなく、もちろんネットワークトラフィックの可視化や脅威の検出やセキュリティの強化、動的なアプリケーションコンテキストのトレースのように幅広い用途で活用することが可能です。

今回ご紹介した Datadog Universal Service Monitoring(USM) はその中でも特に設定が簡単で有用な Observability データを取得できるソリューションです。

SRE を始めるにあたって、アプリケーションの指標を取得したいが実働環境への組み込むことが難しい場合や、商用パッケージアプリケーション(COTS: Commercial Off-The-Shelf Software)の可視化にも取り組みたいという場合には、USM をご検討ください！

以上、「eBPF を完全に理解した」AoToでした🐶

Cloud Workload Security(CWS) と言う名称から変更されました。一部のドキュメント・UI・コードの中に名称が残っている場合があります。 ↩
このブログのコードは Pixie Lab からインスピレーションを得て作成されています。 ↩