Harmonic Society
オンライン予約 お問い合わせ
監視・運用

OpenTelemetry監視設定の完全ガイド｜初心者でもわかる実践手順

kento_morota 14分で読めます

「システム障害が発生しても、原因の特定に何時間もかかってしまう」「複数のサービスが連携していて、どこで問題が起きているのかわからない」――分散システムの監視に課題を感じていませんか？

本記事では、システム監視の新しい標準であるOpenTelemetryの基本的な仕組みから、実際の設定手順、トラブルシューティングまで、中小企業のIT担当者が実践できる内容をわかりやすく解説します。

OpenTelemetryとは？システム監視の新しい標準

システム障害が発生した時、「どこで問題が起きているのか分からない」という経験はありませんか？複数のサービスが連携する現代のWebシステムでは、問題の発見と解決がますます困難になっています。

OpenTelemetryは、こうした課題を解決する標準化された監視フレームワークです。クラウドネイティブコンピューティング財団（CNCF）が支援するオープンソースプロジェクトで、Microsoft、Google、Amazon、Datadogなど主要企業が積極的にサポートしています。

最大の特徴はベンダーニュートラルな設計です。従来は監視ツールごとに専用のライブラリを組み込む必要があり、ツール変更時にはコードの大幅な書き換えが必要でした。OpenTelemetryなら一度実装するだけで、送信先のバックエンドは設定ファイルで自由に変更できます。

中小企業にとっても導入メリットは大きく、オープンソースのためライセンス費用が不要で、段階的な導入が可能です。小規模なWebアプリケーションなら、数時間から1日程度で基本的な監視設定を完了できます。

3つの監視項目で実現する包括的な可視化

OpenTelemetryは「オブザーバビリティの3本柱」と呼ばれる要素を統合的に扱います。

トレース（Traces）は、リクエストがシステム内をどう流れたかを追跡します。ユーザーが商品を購入する際、フロントエンド→APIサーバー→データベース→決済サービスという流れを可視化し、各処理時間を測定してボトルネックを特定できます。

メトリクス（Metrics）は、CPU使用率、メモリ使用量、リクエスト数などを継続的に記録します。時系列でパフォーマンスを監視し、異常な傾向を早期発見できます。

ログ（Logs）は、システムで発生したイベントを記録します。トレースIDと関連付けることで、より詳細な分析が可能になります。

これら3つを組み合わせることで、「何が起きたか」「どこで起きたか」「どのくらい影響があるか」を総合的に把握できます。

OpenTelemetry監視設定の全体像

OpenTelemetryのアーキテクチャは3つの層で構成されています。

  1. 計測層（SDK）: アプリケーション内でデータを収集
  2. 収集・処理層（Collector）: データを集約・変換・フィルタリング
  3. 保存・可視化層（Backend）: データを保存し、ダッシュボードで表示

この構造を理解することで、どこで何を設定すべきかが明確になります。

システム規模に応じた3つの構成パターン

パターン1: シンプル構成（小規模向け）
アプリケーション（SDK）から直接バックエンドに送信します。単一アプリケーション、月間1万PV以下に適しており、設定が簡単で管理も容易です。

パターン2: Collector経由構成（中規模向け）
アプリケーション（SDK）→Collector→バックエンドの流れでデータを処理します。複数アプリケーション、月間1万〜10万PVに適しており、データの集約・加工が可能でバックエンド変更も容易です。

パターン3: 分散Collector構成（大規模向け）
エージェントCollectorとゲートウェイCollectorを組み合わせます。マイクロサービス、月間10万PV以上に適していますが、構成が複雑になります。

まずはパターン1で始め、システムの成長に応じて段階的に移行することをお勧めします。

設定前の準備チェックリスト

スムーズな設定には事前準備が重要です。

環境情報：
- 使用するプログラミング言語とバージョン
- フレームワーク名とバージョン
- ホスティング環境（Azure App Service、AWS EC2など）

バックエンド情報：
- 使用する監視サービスの決定
- エンドポイントURLと認証情報（APIキー、接続文字列）

開発ツール：
- パッケージマネージャー（npm、pip、NuGetなど）
- バージョン管理システム（Git推奨）

よくある失敗パターンと対策

いきなり本番環境で設定：必ず開発環境で動作確認してから本番適用しましょう。

すべてのデータを送信：データ量が膨大になりコストが増大します。サンプリング率を適切に設定（開発環境100%、本番環境10-20%程度）してください。

エラーハンドリングの不足：監視システムの障害がアプリケーション全体に影響しないよう、送信エラーはログに記録するだけにします。

設定の属人化：設定内容をドキュメント化し、チームで共有しましょう。

【実践】OpenTelemetry SDKの基本設定

主要な環境での具体的な実装例を示します。

.NET環境での設定（Application Insights連携）

1. 必要なパッケージのインストール

dotnet add package OpenTelemetry.Extensions.Hosting
dotnet add package OpenTelemetry.Instrumentation.AspNetCore
dotnet add package Azure.Monitor.OpenTelemetry.AspNetCore

2. Program.csでの設定

using Azure.Monitor.OpenTelemetry.AspNetCore;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOpenTelemetry()
    .UseAzureMonitor(options =>
    {
        options.ConnectionString = builder.Configuration["ApplicationInsights:ConnectionString"];
    });

var app = builder.Build();
app.Run();

この設定だけで、HTTPリクエスト/レスポンスのトレース、依存関係、例外、パフォーマンスメトリクスが自動収集されます。

手動でスパンを追加する場合：

using System.Diagnostics;

public class OrderService
{
    private static readonly ActivitySource ActivitySource = new("MyApp.OrderService");

    public async Task<Order> ProcessOrder(int orderId)
    {
        using var activity = ActivitySource.StartActivity("ProcessOrder");
        activity?.SetTag("order.id", orderId);

        var order = await _repository.GetOrder(orderId);
        return order;
    }
}

Node.js・Python環境での設定

Node.js（Express）の場合：

const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http');

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: 'https://your-endpoint/v1/traces',
    headers: { 'x-api-key': process.env.OTEL_API_KEY }
  }),
  instrumentations: [getNodeAutoInstrumentations()],
  serviceName: 'my-node-service',
});

sdk.start();

Python（Flask）の場合：

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from opentelemetry.instrumentation.flask import FlaskInstrumentor

trace.set_tracer_provider(TracerProvider())
otlp_exporter = OTLPSpanExporter(
    endpoint="https://your-endpoint/v1/traces",
    headers={"x-api-key": os.environ.get("OTEL_API_KEY")}
)

trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(otlp_exporter)
)

app = Flask(__name__)
FlaskInstrumentor().instrument_app(app)

接続文字列の安全な管理

接続文字列は環境変数で管理し、ソースコードにハードコーディングしないことが重要です。

環境変数での設定：

# Linux/Mac
export APPLICATIONINSIGHTS_CONNECTION_STRING="InstrumentationKey=..."

# Windows（PowerShell）
$env:APPLICATIONINSIGHTS_CONNECTION_STRING="InstrumentationKey=..."

セキュリティのベストプラクティス：
- 接続文字列を.gitignoreに追加してGitにコミットしない
- Azure Key VaultやAWS Secrets Managerなどのシークレット管理サービスを活用
- 環境ごとに異なるリソースを使用

サンプリング設定の実装

サンプリング率の目安：

環境 推奨サンプリング率
開発環境 100%
本番環境（低トラフィック） 50-100%
本番環境（中トラフィック） 10-30%
本番環境（高トラフィック） 1-10%

.NETでの実装：

builder.Services.AddOpenTelemetry()
    .WithTracing(tracerProviderBuilder =>
    {
        tracerProviderBuilder
            .SetSampler(new TraceIdRatioBasedSampler(0.1)) // 10%サンプリング
            .AddAspNetCoreInstrumentation();
    });

Node.jsでの実装：

const { TraceIdRatioBasedSampler } = require('@opentelemetry/sdk-trace-base');

const sdk = new NodeSDK({
  sampler: new TraceIdRatioBasedSampler(0.1), // 10%サンプリング
});

OpenTelemetry Collectorの設定

Collectorは必須ではありませんが、複数アプリケーションの統合管理やデータの複数バックエンド送信が必要な場合に有用です。

基本的な設定ファイル

Collectorの設定はYAMLファイルで行います。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 10s
    send_batch_size: 1024

exporters:
  otlp:
    endpoint: "your-backend-endpoint:4317"
    headers:
      api-key: "${API_KEY}"

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

Dockerで起動：

docker run -v $(pwd)/config.yaml:/etc/otel/config.yaml \
  -p 4317:4317 -p 4318:4318 \
  otel/opentelemetry-collector:latest \
  --config=/etc/otel/config.yaml

監視データの活用と運用

トレースデータからの問題発見

トレースデータを活用することで、パフォーマンスのボトルネックやエラーの発生箇所を素早く特定できます。Application InsightsやJaegerなどのバックエンドで、リクエストの流れを可視化し、処理時間が長いスパンを特定しましょう。

アラート設定の基本

重要なメトリクスに対してアラートを設定します。エラー率が5%を超えた場合や、応答時間が3秒を超えた場合など、ビジネス影響の大きい指標を優先的に監視しましょう。

チーム内での情報共有

監視データはチーム全体で共有することが重要です。ダッシュボードのURLを共有し、定期的にパフォーマンスレビューを実施することで、継続的な改善につながります。

トラブルシューティング

データが送信されない時の確認ポイント

  1. 接続文字列の確認：環境変数が正しく設定されているか確認
  2. ネットワーク接続：ファイアウォールやプロキシ設定を確認
  3. ログの確認：アプリケーションログでエラーメッセージを確認
  4. バックエンドの状態：監視サービス側の障害がないか確認

パフォーマンスへの影響を最小化

OpenTelemetryのオーバーヘッドは通常1-5%程度ですが、以下の対策でさらに最小化できます。

  • サンプリング率を適切に設定
  • バッチ処理を有効化（デフォルトで有効）
  • 不要な自動計測を無効化
  • 非同期送信を使用（デフォルト）

OpenTelemetry監視を成功させるために

小さく始めて段階的に拡大

最初から完璧を目指さず、まずは1つのアプリケーションで基本的なトレース収集から始めましょう。動作確認ができたら、メトリクス、ログと段階的に拡大します。

限られたリソースでの運用体制

中小企業では専任の運用担当者を置くのは難しいため、以下のアプローチが有効です。

  • クラウドサービスのマネージド監視機能を活用
  • 重要なアラートのみに絞り込む
  • ドキュメント化して属人化を防ぐ
  • 定期的な見直しサイクルを設定（月1回程度）

外部パートナーへの相談タイミング

以下のような場合は、専門家への相談を検討しましょう。

  • 複雑なマイクロサービス環境の監視設計
  • 大量データの効率的な処理方法
  • カスタム計測の実装
  • パフォーマンスチューニング

OpenTelemetryは、標準化された監視フレームワークとして、システムの可視化と問題解決を強力にサポートします。この記事で紹介した手順に沿って、あなたの環境に最適な監視設定を実現してください。

#OpenTelemetry#監視#設定
共有:

ちょっとした業務の悩みも、気軽にご相談ください。

まずは話だけ聞いてもらう