setting-up-cloudwatch-observability

CloudWatch Observability のセットアップ

対象範囲： 初めての CloudWatch Observability のセットアップを対象とします。対象は両方の製品です。CloudWatch Application Observability（Omni）Space の作成からトレースの送信開始まで、および従来の CloudWatch Application Signals へのサービスのオンボーディングを扱います。すでにセットアップ済みの環境での使用（クエリ、ダッシュボード、アラーム、Omni アラート、評価、ライブデバッグ）については、aws-observability を参照してください。

2 つの製品、2 つのリファレンスフォルダー

このスキルでは、CloudWatch の名前を共有していますが別々のサービスである 2 つの製品のセットアップを扱います。リファレンスが置かれているフォルダーが、どちらの製品に属するかを示します。これは aws-observability と同じ規則です。

フォルダー	製品	そこでのセットアップ内容
references/cloudwatch-omni/	CloudWatch Omni（Application / Agent Observability）	Domain → Space → grant → テレメトリの取り込み → 通常の ADOT SDK によるインストルメンテーション。アドオン、CloudWatch Agent の application_signals 設定、ポート 4316 は使用しません。
references/cloudwatch/	従来の CloudWatch	Application Signals へのサービスのオンボーディング：ADOT の自動インストルメンテーション、amazon-cloudwatch-observability EKS アドオン、CloudWatch Agent、監視対象サービス、ServiceEvents、CI/CD の Git／デプロイメタデータ、ポート 4316。

2 つのインストルメンテーション経路は、同じワークロードでは相互に排他的です。Omni 経路では Application Signals の環境変数とアドオンが明示的に禁止され、その逆も同様です。まず製品を決定し（以下のルーティングルール 1～4）、その後は該当するフォルダー内で作業してください。一方を有効にしても他方が置き換えられるわけではありません。アカウントによっては、異なるサービスで両方を実行できます。

次の環境で最適に動作します： AWS MCP サーバー — AWS CLI コマンドを直接実行できます。標準の AWS CLI アクセスでも、すべての手順を利用できます（Omni 経路では aws cloudwatchomni ...、Application Signals 経路では aws eks、aws iam、aws application-signals）。

概念 — Omni（references/cloudwatch-omni/）

これらは Omni のリソースです。Application Signals 経路には、これらのリソースは存在しません。 そちらには Domain、Space、grant、Dataset はなく、単位となるのは監視対象サービスで、アクセス制御には通常の IAM を使用します。Application Signals のオンボーディングを行うお客様に spaceId を尋ねないでください。

用語	内容
Domain	ID の境界です。認可プロバイダー（IAM または Identity Center）を持ち、お客様が Omni にアクセスする際のエンドポイント URL を管理します。アカウントごとに 1 つ、または AWS Organization 全体で 1 つ共有します。
Space	テレメトリを保持するワークスペースで、1 つのアカウントと 1 つのリージョンに属します。Domain の下に作成します。アカウントとリージョンの組み合わせごとに最大 1 つです。リージョンのルール：IAM のみの Domain では、Space を Domain とは別のリージョンに配置できます。Identity Center の Domain では、Space を Domain 自体のリージョンに配置する必要があります。複数のリージョンに Space を作成する Identity Center 環境では、組織スコープの Domain が必要です。
Access grant	プリンシパル（ユーザー、グループ、IAM アイデンティティ、または非同期ワークロード）を、権限レベルを指定して 1 つの Space に関連付けます。Space を通じてデータにアクセスする唯一の方法です。ただし、ソースとなる CloudWatch ロググループは制限しません。ロググループは引き続き、それぞれの IAM 設定に従って読み取り可能です。
Access Profile	人が介在しない非同期ワークロード（アラート、統合、エージェント）用の名前付き境界です。名前付きコンテナにすぎません。create-access-profile に渡すのは Space、名前、説明のみで、権限、アクション、スコープの入力はありません。プロファイルで可能な操作と、どのワークロードがそれを引き受けられるかという 2 つの独立した grant が設定され、さらにワークロードがそのプロファイルを指定して初めて機能します。
Dataset	クエリの実行対象です。テレメトリは CloudWatch OTLP エンドポイント経由で到着するか、すでに CloudWatch ロググループにあるデータを転送して取り込まれます。
何もない状態から Omni をセットアップする順序は、ドメイン → Space → 権限付与 → テレメトリの取り込み → 計装です。（Application Signals の場合はこれよりずっと短く、前提となるリソースもありません。アドオン／エージェント、IAM、続いてプラットフォームごとの有効化の変更を行います。詳しくは references/cloudwatch/application-signals-onboarding.md を参照してください。）「テレメトリの取り込み」（CloudWatch の OTLP エンドポイントにエクスポートするコレクターと、すでに CloudWatch にあるデータセットの転送）は、ワークロードの計装とは別の独立した手順です。アクセスプロファイルは条件付きであり、手順の一部ではありません。非同期ワークロード（アラート、インテグレーション、エージェント）を扱う場合に限り必要です。この順序を案内する際は必ず、Space が存在する前に計装や転送を開始すると、処理は成功したように見えても、顧客が確認できる場所にはテレメトリが届かないことも説明してください。先に Omni を確認した顧客は、正常に動作しているものの空の Space を、失敗と受け取ります。概念間の関係と全体の流れについては、references/cloudwatch-omni/app-basics.md を参照してください。

これはルーティングスキルです。ユーザーのセットアップリクエストを分類し、適切なリファレンスに委任します。Omni のリファレンスは references/cloudwatch-omni/ にあり、従来の CloudWatch（Application Signals）のリファレンスは references/cloudwatch/ にあります。

ユーザーの意図	リファレンス
Application Signals にサービスをオンボーディングする（自動計装、amazon-cloudwatch-observability EKS アドオン、CloudWatch Agent の IAM、監視対象サービス、テレメトリのレポート、ServiceEvents、2 つのオンボーディング階層）	references/cloudwatch/application-signals-onboarding.md
CI/CD を通じて ServiceEvents の Git／デプロイメタデータを伝播する（5 つの OTEL_AWS_SERVICE_EVENTS_* 変数、プロバイダーごとのパターン）	references/cloudwatch/application-signals-cicd-metadata.md
プラットフォームと言語が判明した後の、プラットフォーム × 言語ごとの Application Signals 有効化手順	該当する references/cloudwatch/appsignals-guides/<platform>-<language>.md（例：references/cloudwatch/appsignals-guides/eks-python.md）
オンボーディング時にサービスの Dynamic Instrumentation を有効にする（OTEL_AWS_DYNAMIC_INSTRUMENTATION_* 変数とその IAM）	references/cloudwatch/application-signals-onboarding.md（Step 5d）。デバッグに使用する方法は aws-observability を参照してください
Omni とは何か、その概念、または始め方を理解する	references/cloudwatch-omni/app-basics.md
AI エージェントを計装する（ADOT、OpenInference、フレームワークの検出、トレースの検証）、またはエージェントを本番環境にデプロイして CloudWatch にトレースを送信する — プラットフォームごとの環境変数（AgentCore、Lambda、または ECS／EC2／EKS などの他のプラットフォーム）、スパンのカスタムトレースロググループへのルーティング、必要な IAM 権限、ADOT のバージョン要件	references/cloudwatch-omni/omni-agents-instrumentation/omni-agents-instrumentation.md（デプロイの場合は § 本番環境へのデプロイ）
エージェントのフレームワークが判明した後の、フレームワークごとの OpenInference ガイド（LangChain、LangGraph、Strands、CrewAI、OpenAI Agents、Vercel AI）	references/cloudwatch-omni/omni-agents-instrumentation/openinference-framework-guide.md、続いて該当する references/cloudwatch-omni/omni-agents-instrumentation/instrument-<framework>.md
アプリケーションを計装する（EC2／ECS／EKS／Lambda 上の ADOT SDK — Python、Node.js、Java、.NET）	references/cloudwatch-omni/instrumentation/instrumentation.md
Omni でクエリできるように、カスタムアプリケーションメトリクスまたはエージェントメトリクスを送信する（PutMetricData／EMF ではなく OTLP を使う理由）	references/cloudwatch-omni/instrumentation/instrumentation.md（§ カスタムメトリクス）
アカウントスコープの Space または Domain を作成する	references/cloudwatch-omni/spaces-and-domains.md
Space を Domain とは異なるリージョンに配置できるか確認する	references/cloudwatch-omni/spaces-and-domains.md（前提条件 → リージョンのルール）
create-space で求められる AgentCore 評価ロールとは何か、作成が必要かを確認する	references/cloudwatch-omni/spaces-and-domains.md（Step 3 → AgentCore 評価ロールの確認も参照）
作成には成功したが、使用すると認可エラーが返される Space	references/cloudwatch-omni/spaces-and-domains.md（トラブルシューティング → Space は作成されたが使用できない場合） — アクセス許可の問題ではなく、Space アクセスロールの信頼ポリシーの問題です
AWS Organization 全体で共有する Domain を作成する	references/cloudwatch-omni/org-domains.md
ユーザー、IAM アイデンティティ、アラートのアクセス許可を設定する	references/cloudwatch-omni/access-grants.md
Access Profile でアラート、インテグレーション、エージェントを制限する	references/cloudwatch-omni/access-profiles.md
計装済みアプリのエクスポート先となる OTel Collector をデプロイする（EC2／ECS／EKS）— CloudWatch 独自のシグナルごとの OTLP エンドポイントにエクスポートします	references/cloudwatch-omni/instrumentation/collector.md
Transaction Search を有効にして、トレースを Space に送信する（有効にした後でのみ、スパンが aws/spans に保存されます — アカウントごと、リージョンごと）	references/cloudwatch-omni/instrumentation/collector.md（Step 1）
CloudWatch にすでにあるテレメトリをデータセットに転送する	references/cloudwatch-omni/data-forwarding-and-centralization.md
Azure からアプリケーション独自のテレメトリを送信する（サービスが出力するログ／メトリクス／トレースを、Azure VM／AKS 上の CloudWatch agent 経由で送信）	references/cloudwatch-omni/azure-ingestion/azure-ingestion.md（意図の切り分け）、続いて references/cloudwatch-omni/azure-ingestion/custom-telemetry.md（VM／AKS 上の CloudWatch agent を使う手順）
Slack を初めて Space に接続する	references/cloudwatch-omni/slack-integration.md
カスタム MCP ツールサーバーを登録できるか確認する（Omni にはありません）	references/cloudwatch-omni/custom-mcp-integration.md

Routing Rules

1. ユーザーが単一のセットアップ手順ではなく、Omni とは何か、Domain、Space、grant の意味、どこから始めるか、または何もない状態からの一連の手順の順序を尋ねている場合は、references/cloudwatch-omni/app-basics.md に案内し、「Setup order」セクションの順序に沿って回答してください（1つの手順を扱う collector.md などの単独の手順ファイルではありません）。このファイルには、aws-observabilityとの境界についても記載されています。Space と Domain の Region の関係や、create-space に必要なロールなど、1つの概念のルールに関する質問は、その概念に対応する手順ファイル（spaces-and-domains.md）に該当し、ルーティング表にも記載されています。
2. AI エージェントプロジェクトの計装（LangChain、LangGraph、Strands、CrewAI、OpenAI Agents、Vercel AI などのフレームワークへの OTel の追加）についての依頼は Omni です。references/cloudwatch-omni/omni-agents-instrumentation/omni-agents-instrumentation.md に案内してください。エージェントフレームワークに Application Signals を使う経路はありません。
3. 一般的なアプリケーションの計装（EC2、ECS、EKS、Lambda 上で動作する Python、Node.js、Java、.NET のサービス。AI エージェントフレームワークではありません）についての依頼では、手順ファイルを開く前にどちらの製品かを判断してください。同じワークロードに対して、2つの経路を併用することはできません。
   • Application Signals、ServiceEvents、「監視対象サービス」、サービスマップ、amazon-cloudwatch-observability アドオン、CloudWatch Agent、またはポート 4316 に言及している場合 → CloudWatch 経路：references/cloudwatch/application-signals-onboarding.md、続いて対応する references/cloudwatch/appsignals-guides/<platform>-<language>.md。
   • Omni、Application Observability、Space、Domain、Dataset に言及している場合、または Application Signals を明示的に除外している場合（「通常の OTel」、「アドオンなし」、「エージェントのサイドカーなし」）→ Omni 経路：references/cloudwatch-omni/instrumentation/instrumentation.md。
   • どちらにも言及していない場合 → ルール 4。
4. 計装、ADOT、またはコレクターに関する依頼で、どちらの製品にも言及がない場合（Omni や Space、または Application Signals、ServiceEvents、amazon-cloudwatch-observability アドオンのいずれにも言及がない場合）は、経路を選ぶ前に、対象 Region に Space があるか確認してください。list-spaces はアカウント全体が対象です。--region フラグはエンドポイントを選択するだけで、応答にはアカウント内のすべての Space がそれぞれの region とともに一覧表示されるため、リストが空でないことだけで判断せず、対象 Region で絞り込んでください。aws cloudwatchomni list-spaces --region <region> --query "items[?region=='<region>']"。対象 Region に Space がある → Omni 経路、references/cloudwatch-omni/instrumentation/instrumentation.md。絞り込み後のリストが空 → その Region ではお客様は Omni を利用していないため、現在利用可能な製品は Application Signals です：references/cloudwatch/application-signals-onboarding.md。どちらの場合も依頼はこのスキルの対象です。この確認で決まるのはフォルダーであり、スキルではありません。確認時に不明なサービスというエラーが発生した場合、それは CLI モデルの問題であり、Omni が利用できないことを示す証拠ではありません。お客様の表現に基づいて判断し、それでも明確でない場合に限り質問してください。
5. Space／Domain の作成または設定に関する依頼は、対応するセットアップリファレンスに案内してください。作成したばかりの Space を使用した直後に発生する認証エラーもこれに該当します。これは Space のアクセスロールの信頼ポリシーの問題です（create-space は、そのロールを引き受けられるかどうかを検証しません）。アクセス許可に関するリファレンスではなく、references/cloudwatch-omni/spaces-and-domains.md の「If the Space was created but cannot be used」に案内してください。
6. テレメトリを宛先へ送る方法、つまりテレメトリがまだ CloudWatch に届いていない場合についての質問では、EC2／ECS／EKS に OTel Collector をデプロイし、計装済みワークロードが OTLP を送信できるようにして、アプリの OTEL_EXPORTER_OTLP_ENDPOINT を Collector に接続してください：references/cloudwatch-omni/instrumentation/collector.md。Collector は CloudWatch 独自のシグナルごとの OTLP エンドポイントに直接エクスポートします。一方、テレメトリがすでに CloudWatch のロググループにあり、Dataset への転送が必要な場合は、references/cloudwatch-omni/data-forwarding-and-centralization.md に案内してください。Collector の OTLP エクスポートと CloudWatch の OTLP エンドポイントはどちらも SigV4（AWS 認証情報）で認証します。これには、AWS 外のワークロード向けの OIDC フェデレーション認証情報も含まれます（references/cloudwatch-omni/azure-ingestion/custom-telemetry.md を参照）。AWS 認証情報をまったく取得できない送信元向けの、トークンベースのみの取り込み経路は、これらのスキルでは扱いません。独自の方法を考案せず、その旨を明確に伝えてください。
7. Azure のテレメトリを CloudWatch に取り込む方法についての依頼は、references/cloudwatch-omni/azure-ingestion/azure-ingestion.md に案内し、目的に応じて判断してください。お客様が独自のアプリケーションで生成するテレメトリ（コードからのログ／メトリクス／トレース）を希望している場合は、Azure VM または AKS クラスター上の CloudWatch agent を使ってサポートされます。リファレンスに従ってください。Azure リソースが独自に生成するテレメトリ（AWS の VPC フローログ／Route 53 ログに相当するもの）を希望している場合は、利用できません。その旨を伝え、セットアップを試みないでください。
8. Space で Slack を初めて接続、有効化、または認証する方法についての質問（オペレーターに使用権限を付与する方法を含む）は、references/cloudwatch-omni/slack-integration.md に案内してください。接続後に Slack を使う操作（チャンネルへの調査結果の投稿、アシスタントへのメンション、Slack の検索）は Slack とコンソールで行うものであり、これらのスキルでは扱いません。アラート通知先としての Slack は、aws-observability の Omni アラートに関するリファレンスで扱います。
9. Application Signals、ServiceEvents、Dynamic Instrumentation は CloudWatch の機能であり、セットアップと利用で分かれます。スキルで分かれるのではありません。 これらの機能がまだないサービスで有効化することはセットアップに該当し、ここで扱います。参照先は references/cloudwatch/ 以下の Application Signals オンボーディングと ServiceEvents については references/cloudwatch/application-signals-onboarding.md（CI/CD メタデータの連携については references/cloudwatch/application-signals-cicd-metadata.md）、計装時に Dynamic Instrumentation を有効にする手順については同じファイルのステップ 5d です。これらをOmniの計装変更に含めてはいけません。Omni では対象外であり、2つの経路の区別にはルール 3 を使ってください。サービスからデータが報告されるようになった後に利用する操作、つまりサービスマップの読み取り、Application Signals メトリクスへのアラーム設定、Dynamic Instrumentation を使ったブレークポイントの設置やスナップショットの読み取りは、日常的な運用です。ここでの対応を中止し、aws-observabilityに案内してください。
10. ユーザーがすでに稼働中の Space を使用している、またはサービスから Application Signals への報告がすでに行われていて、クエリ／ダッシュボード／アラーム／アラート／調査について尋ねている場合は、ここでの対応を中止し、aws-observabilityに案内してください。
11. ユーザーが独自の MCP ツールサーバーを登録する、カスタム MCP サーバーを接続する、または MCP 認証を設定する方法を尋ねている場合：CloudWatch Omni では、お客様がカスタム MCP サーバーを追加できません。 コンソール画面はなく、この統合タイプはお客様が利用できるよう有効化されていないため、依頼には対応できません。その旨を明確に伝えて終了してください。セットアップ方法を説明したり、代替案を提示したりしないでください。references/cloudwatch-omni/custom-mcp-integration.md を参照してください。
12. ユーザーがGitHub の接続、GitHub 組織またはリポジトリのリンク、ソースコードからのアプリケーションマップの拡充を求めている場合：CloudWatch Omni には GitHub 統合がありません。 その旨を明確に伝えて終了してください。セットアップ手順を案内しないでください。代替案も提示しないでください。Application Signals GitHub Action と CloudWatch Logs の GitHub 監査ログソースは、それぞれ独立した CloudWatch 機能であり、GitHub を Omni に接続する方法ではありません。また、カスタム MCP サーバーも GitHub 統合ではありません。公開ドキュメントに GitHub 関連機能が見つかったとしても、それは Omni に GitHub 統合がある証拠にはなりません。
13. 依頼でどちらの製品にも言及していない場合（「API にオブザーバビリティを追加したい」、「ワークロードの監視を始めるにはどうすればよいか」など、Omni、Space、Domain、CloudWatch の機能に触れていない場合）は、どちらかを決めつけないでください。お客様がセットアップしたい製品はお客様の意図であり、アカウントの現在の状態から推測するものではありません。そのため、製品を対比する形で質問してください。選択肢は、CloudWatch Omni（Application／Agent Observability — Domain、Space、grant、Dataset）または CloudWatch（ロググループ、アラーム、Log Insights、Application Signals）です。どちらの回答も、異なるリファレンスフォルダーから、ここで対応できます。したがって、これはどの製品をセットアップするかについての質問であり、どのスキルを使うかについての質問ではありません。また、依頼をaws-observabilityに引き継ぐ理由にもなりません。同じメッセージで、選択の参考として境界についても説明してください。境界はセットアップと利用の違いです。Domain、Space、grant、Access Profile の作成や設定、初回のテレメトリ送信、Omni 向けアプリケーションまたはエージェントの計装、Application Signals へのサービスのオンボーディングはすべて初回セットアップに該当し、ここで扱います。テレメトリのクエリ、ダッシュボードの作成、アラームや Omni アラートの設定、稼働中の問題の調査、Dynamic Instrumentation を使ったデバッグはすべて日常的な利用に該当し、aws-observabilityで扱います。どちらの製品か確認できるまでは、Domain／Space の作成や Application Signals のオンボーディングの手順に進まないでください。質問したら、そこでいったん止めて回答を待ってください。