New to LM: How do I refer to the local filesystem in an embedded PowerShell script of a DataSource?

I think you need a step back a bit a get a better understanding of how Script and BatchScript DataSources works. I suggest watching some of the videos in LM Academy like https://academy.logicmonitor.com/introduction-to-datasources and reading over the docs like https://www.logicmonitor.com/support/logicmodules/datasources/data-collection-methods/scripted-data-collection-overview and  https://www.logicmonitor.com/support/logicmodules/datasources/data-collection-methods/batchscript-data-collection and https://www.logicmonitor.com/support/logicmodules/datasources/data-collection-methods/scripted-data-collection-overview. Also highly suggest you look at existing DataSources to understand how it works like Microsoft_DHCP_IPv4Scopes. Look at the examples at https://www.logicmonitor.com/support/terminology-syntax/scripting-support/embedded-powershell-scripting

Suggest working out answers to questions like:

• What is the difference between a Script and BatchScript DataSource?
• How do I know what device/resource LogicMonitor wants data on?

For example LogicMonitor will tell you what device it wants information on, you don't tell it.

Here is an example of a BatchScript DataSource, if you wanted to implement getting disk usage of all the drives on a device.

ActiveDiscovery: Get the name of the device from LM by looking at ##SYSTEM.HOSTNAME## and sent a query to that device asking for the list of all drives. Output something like this:

C##C Drive
D##D Drive

Collection: Get the name of the device from LM by looking at ##SYSTEM.HOSTNAME## and send a query to that device asking for the list of all drives along with the usage information. Output something like this:

C.totalspace=1000
C.freespace=10
C.usedspace=900
D.totalspace=2000
D.freespace=50
D.usedspace=1950

When LM later on wants to get the information for the free space of the D: drive, it will set the ##WILDVALUE## to "D" and extract all the lines that start with "D." then pull the totalspace, freespace, and usedspace.

Your script should only provide output for the device that LM is requesting data on. You would get that information from a line like this:

#Get the hostname the LM wants data on
$Hostname = '##SYSTEM.HOSTNAME##';

Mike, you've been so helpful; I really appreciate it. Quick question about your last example, which relates to one of the two general questions I have below: What are the implications of having the DataSource setting "Use Wildvalue as Unique Identifier" enabled in the context of your example?

---

Two very general questions right now (keep in mind I only dove into all of this starting a few weeks ago; I didn't even know what a DataSource was, lol, but now I've built and re-built the one I'm working on several time, have complex datapoints going in this multi-instance DataSource, etc):

1. Regarding the DataSource setting "Use Wildvalue as Unique Identifier", I wish I could turn it off for this module, but I understand you cannot once it's enabled (due to dependencies or something?). I tried cloning the DataSource but I still couldn't disable it in the clone. But at this point, with the DataSource fairly developed, I cringe at the thought of having to recreate it from scratch just to change that one thing. What do people normally do in this situation?

2. I wonder what the mechanics are behind the WILDALIAS token not being available for use in custom alert messages? The list of available tokens is quite extensive, but WILDALIAS isn't one of them, which I discovered when I tried to use it but it always just came back as text "##WILDALIAS##".

Thanks, Mike. Yes, I may just have to have the old and new DataSource up in adjacent tabs and just bludgeon my way through it. Hey, I haven't tried using ##INSTANCE##, I will definitely investigate that! I've got it working in the meantime by populating the instance Description field in the Active Discovery script with the literal path (to the textfile) and then referencing ##DESCRIPTION## in the custom alert messages. But if I can you ##INSTANCE##, it seems less kludgy that using the description field for that.

For some reason I'm unable to start a new discussion right now, just says:

Cannot add message
Something went wrong, please try again,

But I've been stumped on the following issue and it's driving me nuts:

How do I read the values of instance-level properties in an embedded PowerShell DataSource Collection script? Or resource-level properties in an embedded PowerShell PropertySource? I understand how to write properties and their values in the Active Discovery script with something like 

Write-Host "<instanceID>##<instanceName>##<instanceDescription>####auto.AssignedCollectorDeviceName=$AssignedCollectorDeviceName"

I have an instance-level custom property "auto.AssignedCollectorDeviceName" on a resource instance that I would like to check the value of during Collection script execution, and create my key-value pair for script output based on that value. But I can't for the life of me figure out how to reference and check the host resource's properties while the script is running.  

Also, my first thought was to have the custom property ("AssignedCollectorDeviceName" in that case) at the resource level, and check it while the Collection scripts runs, but realized I (don't think) I can read a resource-level property in that case, only instance-level properties, but I can't even figure out how to do that (without using the API). So in addition to using the auto property at the instance-level, maybe a PropertySource would be better? I'd like to learn how to make and use one, but in its script I think I would have the same problem of reading the value of resource property in order to do the logic to form the script output.

Wow, it's really acting up. Maybe it will post my comment this time. I missed whatever answer you gave because it just showed up as "undefined" (like my previous attempt did a minute ago). I will say this, though:

I have it working with the ###auto.whateverproperty notation in Active Discovery and in reading property values (at the instance level). Even though I can't set a resource-level property when processing instances in the script, is it possible to read those properties' values?

But my bigger question right now is: Is there any way to manually create and populate an instance-level custom auto property on an existing instance prior to the script updating it, or (without API calls) can it only be created/updated from the Active Discovery script?

One HUGE unresolved question for me is, in a DataSource definition, when you set Active Discovery "Discovery Schedule" setting to "Only when host/DataSource added or changed", does "changed" mean when you run Manual Discovery on the resource ( my assumption) and NEVER anytime else? Or does "changed" mean that it can sense when the DataSource has been updated and that triggers it to run even in the Manual setting?