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.