Infrastructure Resources Skill

Find infrastructure resources and inspect them: what exists, whether it is healthy, what its source document holds, and what changed in its configuration.

Tools

All three are read-only. This skill covers the order to call them in and the rules that span them.

Workflow

Four steps, because each one gives the next the input it needs.

# 1. What is monitored? Types are per account, so never guess.
describe_infrastructure(aspect="types")

# 2. What can I filter that type on, and with which values?
describe_infrastructure(aspect="attributes", category="Hosts", resource_type="EC2_Instances")

# 3. Which resources match? This is where resource_id comes from.
list_infrastructure_resources(
    category="Hosts",
    resource_type="EC2_Instances",
    resource_filter={"match": {"field": "Health", "values": ["Critical"]}},
)

# 4. What is going on with them?
get_infrastructure_resource_details(
    resource_ids=["1001234:host_id=i-abc123"],
    aspect="health_history",
)

describe_infrastructure answers one aspect per call:

• types lists every category and type in the account. It takes no category or resource_type.
• attributes needs a category, a resource_type, or both. Scope it to the type you are about to list: accepted values can differ by type, and a type-level call returns that type's values.

Pass categories and types exactly as types lists them.

Skip step 1 when the category and type are already known from earlier in the conversation. Skip step 2 only when attributes already returned the attribute and its values for this type.

Filtering

A resource_filter is a tree. Every node is one of two shapes:

{"match": {"field": "<attribute>", "values": ["<value>", ...]}}
{"bool":  {"op": "AND" | "OR", "operands": [<node>, ...]}}

A match names one attribute. A bool holds more nodes, so the tree nests.

So OS=linux AND (Health=Critical OR Region=eu-west-1) is:

{"bool": {"op": "AND", "operands": [
  {"match": {"field": "OS", "values": ["linux"]}},
  {"bool": {"op": "OR", "operands": [
    {"match": {"field": "Health", "values": ["Critical"]}},
    {"match": {"field": "Region", "values": ["eu-west-1"]}}
  ]}}
]}}

• Values inside one match are alternatives (OR). "field": "Region", "values": ["eu-west-1", "us-east-1"] matches a resource in either region.
• To require two wildcard patterns on one attribute, use one match per pattern under an AND. A name containing both checkout and prod is Name=*checkout* AND Name=*prod*. Never do this with exact values: Region=eu-west-1 AND Region=us-east-1 matches nothing.
• Category and Type are not attributes. They have their own arguments, and a match on them is rejected.
• A * works only where describe_infrastructure reports wildcard: true.
• An exact value is case-sensitive, a wildcard one is not. OS=linux matches and OS=Linux does not, but Name=*checkout* and Name=*Checkout* are the same query. For free text, take the spelling from a row's columns or use a wildcard.
• An attribute from a category-only attributes call may not apply to the type you then pick. Each attribute carries types. One that does not apply returns 0 rows, which reads the same as no matches.
• 0 rows is an answer. A valid attribute that is simply unpopulated matches nothing. Do not retry or reword. A wrong attribute name or an out-of-set value is rejected outright, and the error says what is accepted.

Paging

total_count on the first call answers "how many". Do not page to count, and do not page to find one resource. Filter for it instead.

Page only when the user needs the rows themselves, such as an inventory or "list all...". Then:

• limit is 1 to 100 rows and defaults to 100.
• The next window starts at start_row + returned_count, with the same limit, filter, category and type.
• Stop when start_row + returned_count >= total_count.

If the first call's total_count is more than 500, do not page through it. Narrow the filter, or answer with the count and the first window and say which filter would narrow it.

The window cannot reach past row 10,000. total_count still reports the true size.

Aspects

One aspect per call. Each one takes different arguments and answers differently:

Passing an argument an aspect does not take is rejected.

• health_history gives one sample per day, oldest first. Statuses are Healthy, Critical and Unmonitored.
• raw_data gives the source document. Ask for a few resources at a time. Most documents are 2K to 10K chars of free-form payload. One past 10K chars comes back cut to a string, with truncated: true. The whole answer stops near 30K chars: the ids left out are reported through omitted_because: "result_size_limit", so ask for those again. Narrow with list_infrastructure_resources and health_history first, then come here for the handful you actually need to read. A wide sweep belongs on those two, not here.
• config_summary says which resources changed, and how often. A resource that did not change is absent, so a short answer means the rest were unchanged. Use it to pick who to look at.
• config_diff says what changed, field by field. Run it after the summary, on the resources the summary named.

Reading config_diff

Every valid requested resource gets a row. Read its outcome before its changes:

Inside changes, a null on one side means the field was added or removed. It is a value, not a missing one.

Key Principles

• Pass resource_id verbatim. Ids embed :, | and =. URL encoding is handled for you.
• Infra health is its own concept. Healthy, Critical and Unmonitored are computed by the infrastructure domain and are not Service Catalog health. Correlate them with telemetry signals. Do not treat them as interchangeable.

Related Skills

To look up the same resource using another skill, search for its display name or its Service value. Do not use the resource_id: it exists only in the infrastructure tools, so logs and metrics will not match it.

• Load the coralogix-metrics-query skill to match health against CPU and memory for the resource.