Session 03A — Active Discovery

Why this matters

Before LogicMonitor can collect metrics for individual nodes, it needs to know which nodes exist. Active Discovery creates those node instances and gives each one a stable identity. It does not collect performance data yet.

Import this first

Import module-scaffold.json using the shared import steps. It contains the Active Discovery script and a placeholder collection entry. You will finish the discovery output, then use the information it returns to decide which nodes should be monitored.

What to do

The /nodes endpoint returns a list of node records. The id identifies the node, while the other fields give us information to display or save with it:

[
  {"id":"fabric-node-01","name":"Fabric Node 01","role":"leaf","site":"training-east","status":"online"},
  {"id":"fabric-node-02","name":"Fabric Node 02","role":"spine","site":"training-east","status":"online"},
  {"id":"fabric-node-04","name":"Fabric Node 04","role":"leaf","site":"training-west","status":"offline"}
]

In the module settings, change AppliesTo from false() to:
```
hasCategory("Training_Fabric")
```
Look at the /nodes response and identify the node ID, display name, role, site, and status.
Complete the marked discovery output line. The node ID becomes LogicMonitor’s instance ID (called the wildvalue), and the node name becomes the friendly display name.
Add auto.role, auto.site, and auto.status as instance properties. These are extra details saved with each node.
In the Active Discovery filter settings, add auto.status Equal online. This keeps the offline node out of monitoring.

Choosing a filter depends on the module. This exercise filters offline nodes to demonstrate Active Discovery filtering. In other modules, you may want to keep previously discovered instances when they go offline so they remain in the portal and can still trigger alerts. The Automatically Delete Instances When Active Discovery determines an instance no longer exists option controls whether instances missing from discovery are deleted. With the default setting off, a node discovered while online remains in the portal when it later goes offline. A node that is already offline the first time discovery runs is filtered out and never becomes an instance. Choose the filter based on what the module needs to monitor; for example, you may want to delay onboarding a new node until it is fully online.
Run Active Discovery and review the instances that are created.

The collection script remains a basic return 0 placeholder. Collection is completed in Session 03B after the instances exist.

Check your result

The API returns four node records, but only the three online nodes become instances.
The instance IDs stay the same when discovery runs again.
The display names are easy to recognize.
auto.role, auto.site, and auto.status appear on each instance.
The offline node is excluded by the filter.

Discuss

Why should the instance ID stay stable even if someone changes the display name?

LogicMonitor uses the instance ID, or wildvalue, to match the same node across discovery runs and attach its collected data. A stable ID preserves that identity even when someone renames the node.

Which node details are useful to save with the instance?

Save details that help people identify, filter, or understand a node. In this exercise, role, site, and status are useful; the online status also lets the discovery filter exclude offline nodes.

Why is it helpful to test discovery separately from metric collection?

It lets you confirm that the right nodes and properties are created before troubleshooting metric requests. If discovery is wrong, you can fix instance identity or filtering without mixing in collection issues.

Key idea

Discovery answers “what exists?” and establishes the identity used by collection.

If you get stuck

Open scripts/reference.groovy and compare the discovery output line with the node fields returned by /nodes.