要点OpenTelemetry Collector を使用して、EC2 のシステムログを自動的に EC2 メタデータ (インスタンス ID、リージョン、AZ、インスタンスタイプ) でエンリッチし、ClickStack に収集・可視化します。デモデータセットとあらかじめ用意されたダッシュボードも含まれています。
既存のEC2インスタンスとのインテグレーション
ClickStack を同じEC2インスタンスで実行していますか?監視対象のログがあるEC2インスタンス上で ClickStack も実行している場合は、Generic Host Logs ガイド と同様のオールインワン構成を使用できます。
/var/log を ClickStack コンテナーにマウントし、カスタム設定に resourcedetection processor を追加すると、EC2メタデータを自動的に取得できます。このガイドでは、本番環境へのデプロイでより一般的な分散アーキテクチャに焦点を当てます。前提条件
- ClickStack インスタンスが稼働中であること (オンプレミス、クラウド、またはローカル環境のいずれでも可)
- EC2 インスタンスが稼働中であること (Ubuntu、Amazon Linux、またはその他の Linux ディストリビューション)
- EC2 インスタンスから ClickStack の OTLP エンドポイントにネットワーク接続できること (HTTP はポート 4318、gRPC は 4317)
- EC2 インスタンスメタデータサービスにアクセスできること (デフォルトで有効)
EC2メタデータにアクセスできることを確認する
EC2インスタンス上で、メタデータサービスにアクセスできることを確認します。- インスタンスメタデータサービスが有効になっている
- IMDSv2 がセキュリティグループまたはネットワーク ACL によってブロックされていない
- これらのコマンドを EC2 インスタンス自体で実行している
EC2 メタデータは、インスタンス内から
http://169.254.169.254 で利用できます。OpenTelemetry の resourcedetection プロセッサは、このエンドポイントを使用してログにクラウドのコンテキスト情報を自動的に付加します。collector configurationの作成
/etc/otelcol-contrib/config.yaml に OpenTelemetry Collector の設定ファイルを作成します:- モダンな Linux(Ubuntu 24.04+)
- レガシー Linux(Amazon Linux 2、RHEL、古い Ubuntu)
設定内の以下の項目を置き換えてください:
YOUR_CLICKSTACK_HOST: ClickStack が稼働しているホスト名または IP アドレス- ローカルでテストする場合は、SSH トンネルを使用できます (トラブルシューティング セクションを参照) 。
- 標準的な場所 (Ubuntu では
/var/log/syslog、Amazon Linux/RHEL では/var/log/messages) にあるシステムログファイルを読み取ります - syslog形式を解析し、構造化フィールド (タイムスタンプ、ホスト名、unit/service、PID、メッセージ) を抽出
- EC2 メタデータを自動的に検出して追加するには、
resourcedetectionプロセッサを使用します - 存在する場合は、必要に応じて EC2 タグ (Name、Environment、Team) も含まれます
- OTLP HTTP 経由でログを ClickStack に送信する
EC2メタデータの付加
resourcedetection プロセッサは、すべてのログに次の属性を自動的に追加します。cloud.provider: “aws”cloud.platform: “aws_ec2”cloud.region: AWSリージョン (例: “us-east-1”)cloud.availability_zone: AZ (例: “us-east-1a”)cloud.account.id: AWSアカウント IDhost.id: EC2 インスタンス ID (例: “i-1234567890abcdef0”)host.type: インスタンスタイプ (例: “t3.medium”)host.name: インスタンスのホスト名
collector を起動する
OpenTelemetry Collector を起動します。本番環境で使用する場合collector が systemd サービスとして実行されるように設定し、起動時に自動的に開始され、障害発生時に再起動されるようにします。詳細は、OpenTelemetry Collector documentationを参照してください。
HyperDX でログを確認する
collector が起動したら、HyperDX にログインし、EC2 メタデータ付きのログが流れていることを確認します。- Search view に移動します
- ログソースを
Logsに設定します source:ec2-host-logsで絞り込みます- ログエントリをクリックして展開します
- リソース属性に EC2 メタデータが表示されていることを確認します。
cloud.providercloud.regionhost.id(インスタンス ID)host.type(インスタンスタイプ)cloud.availability_zone
デモデータセット
サンプルデータセットをダウンロードする
サンプルのログファイルをダウンロードします:- システムの起動シーケンス
- SSH ログインのアクティビティ (成功した試行と失敗した試行)
- セキュリティインシデント (fail2ban による対応を伴うブルートフォース攻撃)
- 定期メンテナンス (cron ジョブ、anacron)
- サービスの再起動 (rsyslog)
- カーネルメッセージとファイアウォールのアクティビティ
- 通常の運用と特筆すべきイベントの混在
テスト用collectorの設定を作成する
以下の設定で、ec2-host-logs-demo.yaml という名前のファイルを作成します。デモ目的のため、ここでは
resource プロセッサを使用して EC2 メタデータを手動で追加しています。本番環境で実際の EC2 インスタンスを使用する場合は、EC2 メタデータ API を自動的に問い合わせる resourcedetection プロセッサを使用してください。HyperDX でログを確認する
collector が起動したら、次の手順を実行します。- HyperDX を開き、アカウントにログインします (必要に応じて先にアカウントを作成してください)
- 検索ビューに移動し、ログソースを
Logsに設定します - 時間範囲を 2025-11-10 00:00:00 - 2025-11-13 00:00:00 に設定します
source:ec2-demoで絞り込みます- ログエントリを展開し、リソース属性に含まれる EC2 メタデータを確認します
タイムゾーン表示HyperDX はタイムスタンプをブラウザーのローカルタイムゾーンで表示します。デモデータの期間は 2025-11-11 00:00:00 - 2025-11-12 00:00:00 (UTC) です。時間範囲を広めに設定しているため、どの地域からでもデモログを確認できます。ログが表示されたら、可視化を見やすくするために期間を 24 時間まで絞り込めます。
- インスタンス ID:
i-0abc123def456789 - リージョン:
us-east-1 - アベイラビリティーゾーン:
us-east-1a - インスタンスタイプ:
t3.medium
ダッシュボードと可視化
ダッシュボード設定
あらかじめ用意されたダッシュボードをインポートする
- HyperDX を開き、Dashboards セクションに移動します
- 右上の三点メニューから Import Dashboard をクリックします
host-logs-dashboard.jsonファイルをアップロードし、Finish Import をクリックします
ダッシュボードを表示する
ダッシュボードは、すべての可視化があらかじめ設定された状態で作成されます。ダッシュボードの可視化は、EC2 コンテキストで絞り込めます。cloud.region:us-east-1- 特定のリージョンのログを表示host.type:t3.medium- インスタンスタイプで絞り込みhost.id:i-0abc123def456- 特定のインスタンスのログ
デモデータセットでは、時間範囲を 2025-11-11 00:00:00 - 2025-11-12 00:00:00 (UTC) に設定してください (ローカルの timezone に応じて調整してください) 。インポートしたダッシュボードには、デフォルトでは時間範囲が指定されていません。
トラブルシューティング
ログにEC2メタデータが表示されない
- インスタンスメタデータサービスが有効になっていること
- IMDSv2 がセキュリティグループでブロックされていないこと
- collector を EC2 インスタンス上で実行していること
HyperDX にログが表示されない
ログが正しくパースされない
systemd サービスとして collector が起動しない
- 環境変数で API key が正しく設定されていない
- 設定ファイルの構文エラー
- ログファイルの読み取り権限の問題
次のステップ
- 重要なシステムイベント (サービス障害、認証の失敗、ディスク警告) に対するアラートを設定します
- EC2 メタデータ属性 (リージョン、インスタンスタイプ、インスタンス ID) で絞り込み、特定のリソースを監視します
- EC2 のホストログをアプリケーションログと相関付け、総合的なトラブルシューティングを行います
- セキュリティ監視 (SSH 接続の試行、sudo の使用、ファイアウォールによるブロック) 向けにカスタムダッシュボードを作成します