cx-infra
Query Coralogix infrastructure resources with the `cx infra` CLI — discover monitored resource types, list resources, check per-resource data. Use when the user asks to "show resource types", "list infrastructure resources", "what resources of this kind are monitored", "list resources of this kind",
By coralogix · 848 installs
npx skills add coralogix/cx-cli --skill cx-infra
Source repository · Upstream listing
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.
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 which version came back, and can be passed back
as timestamp to get it again.
raw data: null means no document. That is not an error. version timestamp:
null with a document means the document has no version.
Configuration changes
Two steps: find out which resources changed, then see what changed.
config changes lists only resources that changed. Empty means nothing
changed. Don't retry with a wider window.
Rows are per resource and source. A resource with two collectors can give two
rows.
Some cloud and agent types report an update every collection cycle, so
config changes can flag them when nothing changed. Check with config diff
before telling the user something changed.
config diff has no row for a resource with no history in the 14 days before
from or inside the window. Read outcome before changes :
outcome meaning
changed the versions before and inside the window differ
unchanged they don't differ, or nothing happened inside the window
created the resource first appeared inside the window
priorStateUnavailable it changed, but no version exists in the 14 days before from . Not a failure. Move from earlier to reach an older version
comparisonUnavailable both versions exist, but one could not be read
before and after are raw JSON. null means the field was added or
removed. A new or removed subtree is one entry.
To look at a single change, narrow from and to around it.
Related Skills
Bridge with the resource name or its Service value:
cx telemetry querying : cx search fields "<name " s value finds the
log and span fields holding the name. cx logs "filter $l.subsystemname == '<service '"
gets its telemetry.
cx alerts : cx alerts list name "<name or service " .
cx dashboards : cx dashboards search "<name or service ..." . After
search fields s value , cx dashboards query search field <field finds
queries on that field.