はじめに: 分散システムにおける可観測性
L'可観測性 複雑なシステムの内部状態を理解する能力 外部に向けて生成される信号を分析します。従来の監視とは異なり、応答します。 事前に定義された質問 (「サーバーはアクティブですか?」、「CPU は 80% を超えていますか?」) に対して、可観測性により、 探検する 未知の質問: このリクエストに 3 秒かかったのはなぜですか?どこではい 12 個のマイクロサービスを通過するフローのボトルネックを検証しましたか?
マイクロサービス、コンテナ、クラウドネイティブ アーキテクチャに基づく最新のシステムでは、従来の監視 それはもう十分ではありません。単一のユーザー リクエストは、数十のサービス、メッセージ キュー、および 完了する前にデータベース。可観測性がなければ、これらの環境での問題の診断は困難になります 推測の練習。
このシリーズでは、 12件の記事、現代の可観測性を探ります。 オープンテレメトリー (OTel)、テレメトリ収集を統合するオープンソース標準。 基礎から始めて、Jaeger、Prometheus、Grafana を使用した実稼働グレードの実装まで進めていきます。
この記事で学べること
- モニタリングとオブザーバビリティの根本的な違い
- 可観測性の 3 つの柱: メトリクス、ログ、トレース
- カーディナリティの概念とコストへの影響
- テレメトリ信号が互いにどのように関係するか
- 最新の可観測性ツールの展望
- OpenTelemetry がデファクトスタンダードになりつつあるため
モニタリングと可観測性: 基本的な違い
Il 監視 事前定義されたメトリクスを収集する確立されたプラクティス そしてそれらを確立されたしきい値と比較します。メトリックがしきい値を超えると、アラートがトリガーされます。これ このアプローチは、障害モードが既知で予測可能なモノリシック システムに適しています。
L'可観測性ただし、分散システムには障害モードが存在するという前提から始まります。 それらは予測不可能です。まだ発生していることがわかっていない問題についてのアラートを作成することはできません。可観測性 できるようにします 探検する リアルタイムのシステムの動作、質問 利用可能な信号に基づいてアドホックに動作します。
実際のモニタリングと可観測性
| 待ってます | 監視 | 可観測性 |
|---|---|---|
| アプローチ | リアクティブ (しきい値アラート) | 探索的 (アドホック クエリ) |
| リクエスト | プリセットとメモ | 未知でダイナミックな |
| データ | 集計メトリクス | 関連するメトリック、ログ、トレース |
| デバッグ | 「何が壊れたの？」 | 「なぜ壊れたのですか？」 |
| スケーラビリティ | 静的ダッシュボード | インタラクティブな探索 |
有益な例え: モニタリングは、事前に定義されたライト (温度、オイル、 ガソリン）。可観測性は、分析を可能にする完全な診断システムのようなものです。 チェックする必要があるとは知らなかったものも含め、あらゆるエンジンパラメータをリアルタイムで確認できます。
可観測性の 3 つの柱
可観測性は、と呼ばれる 3 つの基本タイプのテレメトリ信号に基づいています。 3つの柱: メトリクス、ログ、トレース。それぞれが異なる視点を提供します システムの動作を統合し、完全なビューを提供します。
1. メトリクス: 数値データの集計
Le メトリクス それらは時間の経過とともに測定された数値です。それらはシステムの状態を表します 集約形式であり、ストレージとクエリの点で最も効率的なタイプのテレメトリです。 メトリクスは次の質問に答えます。 "いくら？"
# Esempio: definire metriche con OpenTelemetry Python SDK
from opentelemetry import metrics
meter = metrics.get_meter("my-service")
# Counter: valori che solo aumentano
request_counter = meter.create_counter(
name="http.server.request.count",
description="Numero totale di richieste HTTP",
unit="1"
)
# Histogram: distribuzione di valori
latency_histogram = meter.create_histogram(
name="http.server.request.duration",
description="Durata delle richieste HTTP",
unit="ms"
)
# UpDownCounter: valori che possono aumentare o diminuire
active_connections = meter.create_up_down_counter(
name="http.server.active_connections",
description="Connessioni attive correnti"
)
# Registrare valori
request_counter.add(1, {"http.method": "GET", "http.route": "/api/users"})
latency_histogram.record(45.2, {"http.method": "GET", "http.status_code": "200"})
active_connections.add(1)
メトリクスは、ダッシュボード、アラート、傾向分析に最適です。固定のストレージコストがかかります トラフィック量に依存しないため、長期監視に最適です。
2. ログ: コンテキストのある個別のイベント
I ログ タイムスタンプとテキストまたは構造化されたペイロードを含む個別のイベント レコードです。 これらは開発者にとって最も馴染みのあるテレメトリ信号であり、次の質問に答えます。 "どうしたの？"
import logging
import json
# Log strutturato con contesto di tracing
logger = logging.getLogger("order-service")
def process_order(order_id, user_id):
logger.info(json.dumps({
"event": "order.processing.started",
"order_id": order_id,
"user_id": user_id,
"timestamp": "2026-02-17T10:30:00Z",
"trace_id": "abc123def456",
"span_id": "span789",
"service": "order-service",
"environment": "production"
}))
# ... logica di business ...
logger.info(json.dumps({
"event": "order.processing.completed",
"order_id": order_id,
"duration_ms": 234,
"trace_id": "abc123def456",
"span_id": "span789"
}))
構造化ログ (JSON) は効率的なクエリを可能にするため、テキスト ログよりも推奨されます。
トレースおよびメトリクスとの自動相関。重要なパターンは、常に含めることです。
trace_id e span_id ログ内で相関関係を有効にします。
3. トレース: リクエスト パス
Le 痕跡 (分散トレース) リクエストの完全なパスを表します 分散システムを通じて。各トラックは以下で構成されています スパン、すべてのスパン サービス内の操作を表します。トラックは次の質問に答えます。 "それはどこで起きましたか？"
from opentelemetry import trace
tracer = trace.get_tracer("order-service")
def handle_order_request(request):
# Span root: rappresenta l'intera operazione
with tracer.start_as_current_span("process-order") as span:
span.set_attribute("order.id", request.order_id)
span.set_attribute("user.id", request.user_id)
# Span figlio: validazione
with tracer.start_as_current_span("validate-order") as child:
child.set_attribute("validation.rules_count", 5)
validate(request)
# Span figlio: pagamento
with tracer.start_as_current_span("process-payment") as child:
child.set_attribute("payment.method", "credit_card")
child.set_attribute("payment.amount", request.total)
charge_payment(request)
# Span figlio: notifica
with tracer.start_as_current_span("send-notification") as child:
child.set_attribute("notification.type", "email")
notify_user(request.user_id)
トレースは、分散システムでのデバッグにとって重要です。閲覧できるようになります 正確にどこで時間が費やされたか、どのサービスがエラーを引き起こしたか、そして操作がどのように行われたか それらは依存関係グラフを通じて相互に関係します。
信号相関: 可観測性の真の力
3 本の柱が真に強力になるのは、 関連している 彼らの間で。トレースID そのリクエスト中に生成されたログにトレースを接続します。サービスラベル付きのメトリクス トレースに表示されるのと同じサービスのデータを集約できます。この相関関係 分離されたデータをに変換します 運用上のコンテキスト.
相関信号を使用したデバッグ フロー
1. メトリクスによるアラート: 「/checkout エンドポイント P99 レイテンシーが 2 秒を超えています」
2. トラックにドリルダウンします。: 遅延が 2 秒を超えるエンドポイント /チェックアウトをフィルターすると、支払いゲートウェイのスパンに 1.8 秒かかることがわかります。
3. ログの調査: Trace_id を使用すると、支払いゲートウェイのログで外部プロバイダーへのタイムアウトが見つかります。
4. 根本原因: 支払いプロバイダーにネットワークの問題があり、再試行が発生し、全体的な遅延が増加します。
カルディナリータ: 沈黙の敵
La カーディナリティ およびラベル/属性が持つ値の一意の組み合わせの数 メトリクスは取ることができます。これは可観測性において最も重要な概念の 1 つです。 ストレージコスト、クエリパフォーマンス、システムのスケーラビリティに直接関係します。
たとえば、メトリクス http_requests_total ラベル付き method (4 つの値)、
status (5 つの値) e endpoint (20 個の値) は 4 x 5 x 20 = 400 セットになります。
雷雨。しかし、追加すると user_id ユーザーが 100,000 人であれば、シリーズ数は 4,000 万にまで爆発します。
この現象はと呼ばれます カーディナリティの爆発.
カーディナリティの黄金律
- 一度もない ユーザー ID、セッション ID、またはリクエスト ID をメトリック ラベルとして使用します
- 使用 低いカーディナリティ値: メソッド、ステータスコード、サービス名、環境
- 動く トレース (スパン属性) またはログ内のカーディナリティの高いデータ
- モニター メトリクス バックエンド内のアクティブな時系列の数
- 限界 制限された値を持つメトリックあたり最大 5 ～ 7 個のラベル
可観測性ツールの状況
可観測性ツールの市場は豊富であり、常に進化しています。それらを分類できます 3 つの主要なカテゴリに分類されます。
商用SaaSソリューション
のようなプラットフォーム データドッグ, ニューレリック, ダイナトレース e スプランク 統合されたメトリクス、ログ、トレース、プロファイリング、APM を備えたオールインワン ソリューションを提供します。 導入は簡単ですが、大量のテレメトリを使用するとコストが高くなる可能性があります。
オープンソーススタック
最も一般的なオープンソース スタックの組み合わせ プロメテウス (メトリクス)、 イェーガー o 時間 (痕跡)、 ロキ (ログ) e グラファナ （ビュー）。 最大限の制御とゼロのライセンスコストを提供しますが、導入には運用の専門知識が必要です そしてメンテナンス。
OpenTelemetry: 統一標準
オープンテレメトリー これは可観測性バックエンドではありませんが、 収集基準 およびテレメトリのエクスポート。各言語のSDK、ルーティング用コレクターを提供 属性名を標準化するためのデータおよびセマンティック規則の変更。 OTel とベンダー中立: できること コードを一度インストルメントし、互換性のあるバックエンドにデータを送信します。
OpenTelemetry が未来である理由
OpenTelemetry は、世界で 2 番目に活発なプロジェクトです。 クラウド ネイティブ コンピューティング財団 (CNCF) Kubernetesの後。 1,000 人を超える貢献者とすべての主要な可観測性ベンダーからのサポートにより、 OTel はテレメトリの事実上の標準になりつつあります。現在、OTel を使用してインスツルメンテーションを行うということは、 明日、アプリケーションコードを変更せずにバックエンドを自由に変更できます。
可観測性の主要な指標
選択したツールに関係なく、すべてのシステムが必要とする重要な指標があります。 モニター。枠組み RED (レート、エラー、期間) であり、サービスに最もよく使用されます。 一方、フレームワーク 使用 (使用率、飽和、エラー) はリソースに適用されます インフラ。
# Esempio: alert rules basate su RED method (Prometheus)
groups:
- name: red-alerts
rules:
# Rate: richieste al secondo
- alert: HighRequestRate
expr: rate(http_requests_total[5m]) > 1000
for: 5m
labels:
severity: warning
annotations:
summary: "Tasso di richieste elevato"
# Errors: tasso di errori
- alert: HighErrorRate
expr: |
rate(http_requests_total{status_code=~"5.."}[5m])
/ rate(http_requests_total[5m]) > 0.05
for: 2m
labels:
severity: critical
annotations:
summary: "Tasso di errori superiore al 5%"
# Duration: latenza P99
- alert: HighLatency
expr: |
histogram_quantile(0.99,
rate(http_request_duration_seconds_bucket[5m])
) > 2
for: 5m
labels:
severity: warning
annotations:
summary: "Latenza P99 superiore a 2 secondi"
結論と次のステップ
可観測性は購入する製品ではなく、 システムプロパティ それはそうです 正確な計測と信号相関を通じて構築されます。 3 つの柱 (指標、 ログ、トレース）は、診断を可能にする 3 つの相補的な観点を提供します。 分散システムにおけるあらゆる問題。
効果的な可観測性の鍵は、 相関: メトリクス、ログ、および 共有識別子 (トレース ID、サービス名) を使用してトレースをスムーズにナビゲートできるようにする アラートからトレースへ、トレースから関連ログへ、そしてその逆。
次の記事ではさらに詳しく掘り下げていきます オープンテレメトリーそのアーキテクチャを分析し、 API と SDK の区別、OTLP プロトコル、およびそれらが標準化するセマンティック規約 テレメトリーの命名法。