/cx-infra

name: cx-infra
description: >
  Query Coralogix infrastructure resources with the `cx infra` CLI: resource
  types, filterable attributes, resource lists, health, raw data and
  configuration changes. Use when the user asks to "show resource types",
  "list infrastructure resources", "what resources of this kind are monitored",
  "is this resource healthy", "why is this resource critical",
  "which health policy is failing", "when did this resource go critical",
  "get raw resource data", "find resources by name",
  "filter resources by service or environment", "critical hosts in a region",
  "what can I filter resources by", "resources in this cluster or namespace",
  "which resources changed recently", "what changed in this resource",
  "configuration drift", "did anything change before the incident",
  "what was this config last week", or wants to explore infrastructure resources.
metadata:
  version: "0.2.0"

Infrastructure Resources

All commands live under `cx infra resources` and are read-only. Run `cx infra resources <command> --help` for flags.

"Infrastructure monitoring is not enabled for this team" means the team has no infrastructure data. Stop and say so. Do not retry or change filters.

A stderr line starting `warning: ... could not verify that infrastructure monitoring is enabled` is informational: the enablement check itself failed and the command still ran.

| Command | Answers | |------------------|----------------------------------------------------------------| | `types` | which `(category, type)` pairs exist | | `filters` | which attributes can be filtered on, and their accepted values | | `list` | which resources match, with their health policies | | `health-history` | daily health per resource, oldest first | | `raw-data` | the raw resource document, now or at a past time | | `config-changes` | which resources changed configuration in a window | | `config-diff` | what changed, field by field |

Resource ids

• Take them from `list` (`resource_id`) and pass them as-is, quoted.
• `health-history`, `config-changes` and `config-diff` take up to 100 ids per

call. Pass them all in one call, not one call each. Over 100, the CLI refuses. Split into batches.

• An id belongs to one team, so the id commands refuse more than one `-p`.

Only `types`, `filters` and `list` fan out across profiles. From a multi-profile `list`, use the row's `profile` to pick the one to query.

• Ids mean nothing outside this skill. To reach other skills, use the resource

`name` or its `Service` value.

Finding resources

1. `filters` first. Attribute names and values differ per type, so never guess. Per attribute: `kind` (`string` is free text, `status` a fixed set), `values` (the accepted set) and `wildcard` (whether `*` works). 2. `list` with the filters:

• Every `--match-all` must match, at least one `--match-any` must match, and

the two groups are ANDed. `--match-all OS=linux --match-any Health=Critical --match-any Region=eu-west-1` means `OS=linux AND (Health=Critical OR Region=eu-west-1)`.

• Commas give one attribute several values. In `--match-any` any one

matches. In `--match-all` all must, which only makes sense for wildcards: `--match-all 'Name=*alert*,*processing*'`.

• Name an attribute once, in one flag. A repeat is refused.
• `--category` and `--type` are plain filters, not requirements, and are not

attributes (no `--match-all Category=...`). At least one filter or scope flag is required.

• Exact values are case-sensitive (`OS=linux`, not `OS=Linux`). Wildcards

are not. Quote wildcards so the shell leaves `*` alone.

• `--name-filter` and `--scope` (`service`, `environment`, `team`) are legacy

flags. They need both `--category` and `--type`, and cannot mix with `--match-*`. `--match-all 'Name=*web*'` does what `--name-filter web` does. 3. Zero rows is an answer. Don't retry. A wrong attribute or value is refused with the accepted ones listed.

`list -o json` is an envelope: `{total_count, returned_count, resources}`. The other commands return plain arrays or objects.

• It returns one window, rows 0 to 100 by default (`--start-row`, and

`--end-row` which is exclusive). Keep paging while `start_row + returned_count < total_count`.

• A window cannot pass row 10,000. For bigger results, narrow the query.
• With several profiles, each one pages against its own `total_count` (see

`counts_by_profile`).

Health

• `list` rows carry `health_policies: [{id, name, status}]` with `status` one of

`healthy`, `critical` or `pending` (not evaluated yet). A critical policy says why a resource is critical. No extra call needed.

• `health-history` returns `[{resource_id, health_history: [{timestamp, status}]}]`

with `status` one of `Healthy`, `Critical` or `Unmonitored`. The two sets of statuses have different casing.

• Ids that don't parse, and repeats, are dropped. A shorter answer is normal and

stderr gives the count. Returned ids are normalized, so they may not string-match the ones sent.

• Infra health is not Service Catalog health. Correlate it with telemetry

rather than treating the two as the same.

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

`raw-data -o json` returns `{version_timestamp, raw_data}`.

• `--timestamp` (`now-7d` or ISO-8601) gets the newest version at or before that

time. `version_timestamp` says whi