観察可能性(Observability) 2026: eBPFとOpenTelemetryによる革新

2014年: Linux 3.18に基本eBPF導入
2017年: 機能大幅拡張
2020年: 本番環境での使用開始
2023年: 標準化推進 (CNCF、Linux Foundation)
2026年: eBPFが標準的な観察可能性技術に

// すべてのネットワーク接続を追跡
#include <uapi/linux/ptrace.h>
#include <net/sock.h>
#include <bcc/proto.h>

BPF_HASH(ipv4_connections, u32, u32);

int trace_connect_entry(struct pt_regs *ctx, struct sock *sk) {
    if (sk->__sk_common.skc_family != AF_INET)
        return 0;

    u32 sip = sk->__sk_common.skc_rcv_saddr;
    u32 dip = sk->__sk_common.skc_daddr;

    u32 cnt = ipv4_connections.lookup_or_init(&sip, &0);
    ipv4_connections.update(&sip, &cnt + 1);

    return 0;
}

from bcc import BPF
import socket
import struct
import time

b = BPF(text=ebpf_code)
b.attach_kprobe(event="tcp_v4_connect", fn_name="trace_connect_entry")

print("追跡中... (Ctrl+Cで停止)")
try:
    while True:
        time.sleep(1)
except KeyboardInterrupt:
    pass

ipv4_connections = b["ipv4_connections"]
for k, v in ipv4_connections.items():
    print(f"送信元IP: {socket.inet_ntoa(struct.pack('I', k.value))}, "
          f"接続数: {v.value}")

1. ネットワークポリシー:
  - 従来のL3/L4ルール
  - L7ポリシー (HTTP、gRPC、Kafka)
  - ゼロオーバーヘッドのポリシー実行

2. 観察可能性:
  - 自動ネットワークフロー追跡
  - 計測不要
  - <1%のパフォーマンスオーバーヘッド

3. セキュリティ:
  - マイクロセグメンテーション
  - リアルタイム脅威検出
  - DDoS保護

4. パフォーマンス:
  - Kube-proxy比で30%ネットワーク性能向上
  - メモリ使用量50%削減

# Ciliumをインストール
helm repo add cilium https://helm.cilium.io
helm install cilium cilium/cilium --namespace kube-system

# Ciliumポッドを確認
kubectl get pods -n kube-system | grep cilium

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-to-db
spec:
  description: 'APIポッドのみデータベースにアクセス可能'
  endpointSelector:
    matchLabels:
      app: database
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: api-server
      toPorts:
        - ports:
            - port: '5432'
              protocol: TCP

---
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: http-api-policy
spec:
  description: 'HTTPAPIトラフィック制御 (L7)'
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: '8080'
              protocol: TCP
          rules:
            http:
              - method: 'GET'
                path: '/api/v1/.*'
              - method: 'POST'
                path: '/api/v1/users'

アプリケーション層:
├─ Traces (分散トレース)
├─ Metrics (メトリクス)
└─ Logs (ログ)
       ↓
OpenTelemetry SDKs
       ↓
OpenTelemetry Collector
       ↓
バックエンド (Datadog、New Relic、Jaeger、Prometheusなど)

from opentelemetry import trace, metrics
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.instrumentation.flask import FlaskInstrumentor
from opentelemetry.instrumentation.requests import RequestsInstrumentor
from opentelemetry.sdk.resources import SERVICE_NAME, Resource
from flask import Flask

# Jaegerエクスポーターを設定
jaeger_exporter = JaegerExporter(
    agent_host_name="localhost",
    agent_port=6831,
)

# Tracer Providerを設定
trace.set_tracer_provider(
    TracerProvider(
        resource=Resource.create({SERVICE_NAME: "payment-service"})
    )
)
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(jaeger_exporter)
)

# Flaskを自動計測 (コード変更不要!)
app = Flask(__name__)
FlaskInstrumentor().instrument_app(app)
RequestsInstrumentor().instrument()

@app.route("/api/v1/payments", methods=["POST"])
def create_payment():
    tracer = trace.get_tracer(__name__)

    with tracer.start_as_current_span("create_payment") as span:
        payment_id = process_payment()
        span.set_attribute("payment.id", payment_id)
        span.set_attribute("payment.amount", 100.00)
        return {"payment_id": payment_id}

if __name__ == "__main__":
    app.run(port=5000)

{
  "traceID": "8b37a91d27d4a3f5",
  "spans": [
    {
      "spanID": "8b37a91d27d4a3f5",
      "operationName": "POST /api/v1/payments",
      "duration": 150000,
      "tags": {
        "http.method": "POST",
        "http.status_code": 200
      }
    },
    {
      "spanID": "c2b5d8e9f1g6h2a1",
      "operationName": "query_database",
      "parentSpanID": "8b37a91d27d4a3f5",
      "duration": 45000,
      "tags": {
        "db.type": "postgresql"
      }
    }
  ]
}

# Tetragonをインストール
helm repo add cilium https://helm.cilium.io
helm install tetragon cilium/tetragon -n kube-system

# トレーシングルールを定義
kubectl apply -f - <<'EOF'
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "network-security"
spec:
  rules:
  # すべてのネットワーク接続を追跡
  - call: "trace_tcp_connect_entry"
    syscall: "connect"
    args:
    - index: 0
      type: "sock_addr"

  # すべてのファイルアクセスを追跡
  - call: "trace_open_entry"
    syscall: "openat"
    args:
    - index: 1
      type: "const_char_buf"

  # すべてのプロセス実行を追跡
  - call: "trace_execve"
    syscall: "execve"
    args:
    - index: 0
      type: "const_char_buf"
EOF

# リアルタイムログを表示
kubectl logs -f -n kube-system -l app.kubernetes.io/name=tetragon

class AutomatedRootCauseAnalyzer:
    """
    メトリクス、トレース、ログを分析して
    根本原因を自動的に識別
    """

    def analyze_incident(self, incident_id):
        """
        ステップ1: 症状を収集
        """
        anomalies = self.detect_metric_anomalies(
            metrics=['latency', 'error_rate', 'cpu_usage'],
            duration='last_5_minutes'
        )

        error_patterns = self.find_error_patterns_in_logs(
            filters={'service': 'payment-service', 'severity': 'ERROR'}
        )

        slow_spans = self.find_slow_spans(min_duration_ms=500)

        """
        ステップ2: 相関分析
        """
        correlations = self.find_correlations({
            'anomalies': anomalies,
            'errors': error_patterns,
            'slow_spans': slow_spans
        })

        """
        ステップ3: AI駆動の根本原因推論
        """
        root_cause = self.llm_infer_root_cause({
            'correlations': correlations,
            'similar_incidents': self.get_similar_incidents(incident_id),
            'system_topology': self.get_topology()
        })

        return {
            'root_cause': root_cause['description'],
            'confidence': root_cause['confidence'],
            'affected_services': self.get_affected_services(root_cause),
            'remediation': self.get_remediation_actions(root_cause)
        }

    def example_result(self):
        return {
            'incident_id': 'INC-2026-03-16-001',
            'root_cause': {
                'type': 'db_connection_pool_exhaustion',
                'confidence': 0.94,
                'evidence': [
                    'DBコネクションエラー急増',
                    'APIレイテンシー5倍増加',
                    'メモリ使用率85%'
                ]
            },
            'recommended_actions': [
                {
                    'action': 'DBコネクションプールサイズを増加',
                    'recovery_time': '2分',
                    'priority': 'critical'
                }
            ]
        }

最適化レイヤー:

1. 収集最適化:
   - eBPFゼロ計測 (SDKを削除)
   - インテリジェントサンプリング
   - クライアント側フィルタリング
   削減: 50-60%

2. 送信最適化:
   - エッジ処理
   - 圧縮とバッチ処理
   - ローカルバッファリング
   削減: 20-30%

3. ストレージ最適化:
   - 時系列データベース
   - ライフサイクル管理
   - ホット/コールドストレージ階層化
   削減: 30-40%

4. クエリ最適化:
   - 戦略的インデックス
   - キャッシング層
   - 事前計算集約
   削減: 20-25%

組織: 500人の開発者、200マイクロサービス

導入前 (従来型):
- Datadog/New Relic: 50万ドル/年
- エンジニア時間: 30万ドル/年
- ネットワークコスト: 10万ドル/年
- 合計: 90万ドル/年

導入後 (eBPF + OTel + OSS):
- 軽量SaaS: 15万ドル/年
- エンジニア時間: 8万ドル/年
- ネットワーク: 2万ドル/年
- 自己ホスト (AWS): 5万ドル/年
- 合計: 30万ドル/年

削減: 66% (60万ドル/年)

収集層:
├─ eBPF (Cilium Hubble、Tetragon)
├─ OpenTelemetry Collector
└─ 軽量エージェント

処理層:
├─ Datadog、New Relic (SaaS)
├─ Grafana Loki (ログ)
├─ Prometheus (メトリクス)
└─ Jaeger (トレース)

分析層:
├─ AI/ML駆動RCA
├─ 異常検出
└─ 相関分析

アクション層:
├─ 自動修復
└─ アラート

# Cilium + Hubbleをインストール
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

# 自動ポリシー学習を有効化
kubectl apply -f - <<'EOF'
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: auto-policy-learning
spec:
  policies:
    - auto-generate: true
EOF

# OpenTelemetry Collectorをデプロイ
apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-config
data:
  config.yaml: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
          http:
            endpoint: 0.0.0.0:4318

    processors:
      batch:
        send_batch_size: 1024
        timeout: 10s

    exporters:
      otlp:
        endpoint: datadog-collector:4317
      logging:
        loglevel: debug

    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [batch]
          exporters: [otlp, logging]

System diagram showing eBPF layer at kernel level intercepting system calls and network traffic, feeding data to OpenTelemetry Collector which aggregates metrics, traces, and logs, then flowing to multiple backends (Datadog, Prometheus, Jaeger). Show AI/ML component analyzing data for root cause analysis. Include visualization of network topology with service dependencies and health indicators. Modern tech illustration with layered architecture visualization.