Session 03B — Instance Collection

Why this matters

Now that discovery has created the node instances, the collection script needs to visit each one and report its metrics under the right instance. The instance ID from discovery is what keeps those values connected to the correct node.

Import this first

Import module-scaffold.json using the shared import steps. It carries forward the targeting rule and Active Discovery filter from Session 03A. The collection loop and API request are already supplied; you will complete the lines that report the metrics.

What to do

Once the script has an instance ID, it requests that node’s metrics. A response looks like this:

{
  "id": "fabric-node-01",
  "health": 1,
  "cpu_percent": 34.5,
  "memory_percent": 61.2,
  "interface_count": 48,
  "error_rate_percent": 0.2
}

Before editing the script, confirm the module’s AppliesTo rule is still hasCategory("Training_Fabric"). This setting carries forward from Session 03A.
Read through the instance loop. It visits each discovered node, and the instance ID tells the API which node to request.
Uncomment the five marked output lines. Each line should start with the current instance ID, followed by the metric name.
Match each output name to its datapoint in the module.
Confirm that the offline node is not present because the Active Discovery filter keeps only online nodes.

Check your result

Every discovered online node receives metrics.
Each metric appears under the correct node.
No values appear under an empty or incorrect instance ID.
Every output name has a matching datapoint.

Discuss

How does the collection script know which node to request?

LogicMonitor runs collection for each discovered instance and provides its wildvalue to the script. The script uses that ID in the API request URL to fetch the matching node’s metrics.

What would happen if the instance ID were missing from an output line?

The values would not be associated with the intended node instance. LogicMonitor could treat them as belonging to an empty or different instance, so every metric line must include the current instance ID.

Why is it useful to keep discovery and collection as separate steps?

Discovery determines which node instances exist; collection gathers metrics for those instances. Keeping them separate makes it easier to troubleshoot missing nodes independently from missing or incorrect metrics.

Key idea

Discovery creates the instances; collection reports the metrics for those same instances.

If you get stuck

Open scripts/reference.groovy and trace the same wildvalue through the request URL and every datapoint output.