cx-infra

インフラストラクチャリソース

すべてのコマンドは cx infra resources 以下にあり、読み取り専用です。フラグを確認するには、 cx infra resources <command> --help を実行してください。

「このチームではインフラストラクチャの監視が有効になっていません」というメッセージは、チームにインフラストラクチャデータがないことを意味します。そこで停止し、その旨を伝えてください。再試行したり、フィルターを変更したりしないでください。

warning: ... could not verify that infrastructure monitoring is enabled で始まる stderr の行は情報メッセージです。有効化の確認自体に失敗しましたが、コマンドは実行されています。

コマンド	確認できる内容
types	存在する (category, type) の組み合わせ
filters	フィルター可能な属性と、指定可能な値
list	該当するリソースと、そのヘルスポリシー
health-history	リソースごとの日次ヘルス（古い順）
raw-data	現在または過去の時点における未加工のリソースドキュメント
config-changes	指定期間内に設定が変更されたリソース
config-diff	フィールドごとの変更内容

リソース ID

• list の resource_id から取得し、引用符で囲んだまま渡してください。
• health-history、config-changes、config-diff は、1 回の呼び出しで最大 100 個の ID を指定できます。ID ごとに呼び出すのではなく、すべてまとめて 1 回で渡してください。100 個を超えると、CLI は拒否します。複数のバッチに分割してください。
• ID は 1 つのチームに属するため、ID を受け取るコマンドで複数の -p を指定すると拒否されます。複数のプロファイルにまたがって処理するのは types、filters、list のみです。複数プロファイルの list の結果を使う場合は、照会対象のプロファイルを行の profile で選んでください。
• ID はこのスキル以外では意味を持ちません。他のスキルを利用する場合は、リソースの name または Service の値を使ってください。

リソースの検索

1. まず filters を実行してください。属性名と値はタイプごとに異なるため、決して推測しないでください。属性ごとに、kind（string は自由入力、status は固定の選択肢）、values（指定可能な値の一覧）、wildcard（* が使えるかどうか）が表示されます。
2. フィルターを指定して list を実行してください。
   • すべての --match-all に一致し、少なくとも 1 つの --match-any に一致する必要があります。2 つのグループは AND で結合されます。 --match-all OS=linux --match-any Health=Critical --match-any Region=eu-west-1 は、OS=linux AND (Health=Critical OR Region=eu-west-1) を意味します。
   • カンマを使うと、1 つの属性に複数の値を指定できます。--match-any では、いずれか 1 つに一致すれば該当します。--match-all では、すべてに一致する必要があるため、ワイルドカードを使う場合にのみ意味があります。 --match-all 'Name=*alert*,*processing*'
   • 属性は 1 つのフラグで 1 回だけ指定してください。同じ属性を繰り返すと拒否されます。
   • --category と --type は通常のフィルターであり、必須条件ではありません。また、属性でもありません（--match-all Category=... のようには指定できません）。フィルターまたはスコープのフラグを少なくとも 1 つ指定する必要があります。
   • 値の完全一致では大文字と小文字が区別されます（OS=linux は有効ですが、OS=Linux は無効です）。ワイルドカードでは区別されません。シェルが * をそのまま扱うよう、ワイルドカードは引用符で囲んでください。
   • --name-filter と --scope（service、environment、team）は旧式のフラグです。これらを使うには --category と --type の両方が必要で、--match-* とは併用できません。--match-all 'Name=*web*' は --name-filter web と同じ動作をします。
3. 結果が 0 行の場合も、それが回答です。再試行しないでください。属性名または値が誤っている場合は拒否され、指定可能な値が一覧表示されます。

list -o json は {total_count, returned_count, resources} という形式のラッパーを返します。他のコマンドは、配列またはオブジェクトをそのまま返します。

• 返されるのは 1 つのウィンドウで、デフォルトでは 0～100 行です（--start-row と、終端を含まない --end-row で指定します）。start_row + returned_count < total_count の間は、ページングを続けてください。
• 1 つのウィンドウで 10,000 行を超えて取得することはできません。結果が多すぎる場合は、クエリを絞り込んでください。
• 複数のプロファイルがある場合、各プロファイルはそれぞれの total_count に基づいてページングされます（counts_by_profile を参照してください）。

ヘルス

• list の行には health_policies: [{id, name, status}] が含まれ、status は healthy、critical、pending（まだ評価されていない）のいずれかです。ポリシーが重大な状態の場合、そのリソースが重大である理由が示されます。追加の呼び出しは必要ありません。
• health-history は [{resource_id, health_history: [{timestamp, status}]}] を返し、status は Healthy、Critical、Unmonitored のいずれかです。2 つのステータス群では大文字と小文字の使い方が異なります。
• 解析できない ID と重複した ID は除外されます。結果が少なくなるのは通常のことで、件数は stderr に出力されます。返される ID は正規化されるため、送信した ID と文字列として一致しないことがあります。
• インフラのヘルスは Service Catalog のヘルスとは異なります。両者を同じものとして扱わず、テレメトリと照合してください。

cx infra resources list --match-all Health=Critical -o json \
  | jq '.resources[] | {name, failing: [.health_policies[] | select(.status == "critical") | .name]}'

cx infra resources health-history "1001234:host_id=i-abc" "1001234:host_id=i-def" -o json \
  | jq '.[] | {resource_id, critical: [.health_history[] | select(.status == "Critical") | .timestamp]}'

生データ

raw-data -o json は {version_timestamp, raw_data} を返します。

• --timestamp（now-7d または ISO-8601）を指定すると、その時刻以前の最新バージョンを取得します。返されたバージョンは version_timestamp で確認でき、これを --timestamp に渡せば同じバージョンを再取得できます。
• raw_data: null はドキュメントがないことを意味します。これはエラーではありません。ドキュメントがあるのに version_timestamp: null の場合、そのドキュメントにはバージョンがありません。

構成の変更

2 つの手順で行います。まず変更されたリソースを確認し、次に何が変わったかを確認します。

cx infra resources config-changes --resource-id "1001234:host_id=i-abc" \
  --resource-id "1001234:host_id=i-def" --from now-24h -o json

cx infra resources config-diff --resource-id "1001234:host_id=i-abc" --from now-24h -o json \
  | jq '.[] | select(.outcome == "changed") | .changes[] | {field, before, after}'

• config-changes は変更されたリソースのみを一覧表示します。結果が空の場合、変更はありません。より広い期間を指定して再試行しないでください。
• 行はリソースとソースの組み合わせごとに表示されます。2 つのコレクターがあるリソースは、2 行表示されることがあります。
• 一部のクラウドやエージェントの種類は、変更がなくてもコレクションのたびに更新を報告します。そのため、config-changes は何も変わっていないときに変更を示すことがあります。ユーザーに変更があったと伝える前に、config-diff で確認してください。
• --from より前の 14 日間または期間内に履歴がないリソースについては、config-diff に行が表示されません。changes より先に outcome を確認してください。

outcome	意味
changed	期間前と期間内のバージョンが異なります
unchanged	バージョンが異ならないか、期間内に何も起きませんでした
created	リソースが期間内に初めて出現しました
priorStateUnavailable	変更はありましたが、--from より前の 14 日間にバージョンがありません。失敗ではありません。古いバージョンを取得できるよう、--from をさらに前に設定してください
comparisonUnavailable	両方のバージョンが存在しますが、一方を読み取れませんでした

• before と after は生の JSON です。null はフィールドが追加または削除されたことを意味します。サブツリー全体の追加または削除は、1 つのエントリーとして扱われます。
• 個別の変更を確認するには、その変更を含むように --from と --to の範囲を狭めてください。

関連スキル

リソース名またはその Service の値を使って連携します。

• cx-telemetry-querying：cx search-fields "<name>" -s value を使うと、その名前を含むログおよびスパンのフィールドを見つけられます。cx logs "filter $l.subsystemname == '<service>'" を使うと、そのテレメトリを取得できます。
• cx-alerts：cx alerts list --name "<name-or-service>"。
• cx-dashboards：cx dashboards search "<name-or-service> ..."。search-fields -s value の後に cx dashboards query-search --field <field> を実行すると、そのフィールドを使うクエリを見つけられます。