How do I refer to the local filesystem in an embedded PowerShell script of a DataSource? The below works fine from a PowerShell session console on a Collector server, but fails when running embedded in LogicMonitor. The Active Directory LogicMonitor service account is in the local Administrators group on the Resource server (a LM Collector server in this), same as my admin account using the PowerShell session. It also has explicit NTFS "Full Control" rights on the folder in the path variable below. Do I have to use the Get-PSDrive cmndlet? Or is there a simple way to do it when running embedded in the LogicMonitor environment?$textFilePath = 'C:\ps\LM-custom_list.txt' $localList = Get-Content -Path $textFilePath-Steve

Yes, and you see it worked for me in my screenshot with a full path. The only thing I'm aware of that LM will do to a powershell script is do a search-and-replace of ##TOKEN## but I didn't see any of that in your code. Even your error message isn't show the path getting screwed up and it's powershell telling you the file doesn't exist there. I would 100% make sure the script is actually running on the server you think it's running on. Does "Write-Output $env:computername" show the name of the server with the file?

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

Mike_Moniz
Professor
5 months ago
Also verify that the collector assigned to the device you are testing against is the same one with the file. LM will let you monitor a collector device using a completely different collector, although you should never do that (it will throw the collector DSes off). But something that isn't hard to mistakenly do. I usually set the collector device to use 127.0.0.1 specifically to help catch that.

Aka if you have servers Collector01 and Collector02, make sure that the collector assigned to Collector01 is Collector01 (itself). LM will let you monitoring Collector01 using Collector02.
- SteveDahlberg
  Neophyte
  5 months ago
  Mike, Yeah, the textfile is on one of our Collector servers, and that is what we're using to monitor. Keep in mind, this all works fine in a PS session on the Collector server, it finds the local path, it all works. Just not in LogicMonitor, here are some screenshots below. In this case, the actual test of the textfile path and determination of the result happens in a function that attempts to find and read the contents of the file (a simple list of text, one per line). It's called from the main loop and passed the (previously-assigned) value of:
  $VM_FQDN_Path = 'C:\JCCC-Local_Text_Files\LM_FQDN-VM_list.txt'
  Here a screenshots (in order) of the function that attempts to read the textfile and load its contents, that function being called from the main script and the corresponding output (using Write-Host), and finally, the results in LogicMonitor from using Test Script on the Collection script:
  - SteveDahlberg
    Neophyte
    5 months ago
    Shoot, was hoping it would paste them in, not create download attachment links. Let me see if I can just paste them:
Mike_Moniz
Professor
5 months ago
I'm not clear where the text file you want to pull is. Is the file on the server running the collector software or on a different system?

Scripts will always run from the collector. So if the file is in another system, you would need to write your script to have it connect and pull the file. That might be using something like \\server\c$ or doing a Invoke-Command to run powershell commands on the remote system.

If it is local to the collector server, what does the Test Button/Poll Now show? What kinda LM script is this? Part of a ConfigSource? DataSource?
- SteveDahlberg
  Neophyte
  5 months ago
  I believe most of that is answered in my post. But to be clear, the .txt textfile is (for now anyway) at the absolute path "C:\JCCC-Local_Text_Files\my_testfile.txt" on one of our collector servers where I've been developing the script. It works fine from a PowerShell session on the collector server. But so far, I can't get it to see the file (so I can read from it in the script, like I do when the same script runs in PS session on the collector server). This is in a DataSource.
  I use `Test-Path $textFilePath` in the script to make sure it's there, works fine, but when running embedded in LM, it always reports that it can't find it at that absolute path location. I even tried copying it to "C:\Program Files\LogicMonitor\Agent\bin\JCCC-Local_Text_Files" but that didn't work, then I tried just the text file itself at that location (rather than the containing folder), but no joy. The LogicMonitor service account is in the local admins group on this Windows server, and has "Full Control" explicitly granted on the folder in question, although it shouldn't need it I wouldn't think.
  I'm relatively new to this, and it feels like I'm missing the proper way to refer to the local filesystem (if it's different than what I showed above with Test-Path above. I'm totally stuck.
  -Steve
Mike_Moniz
Professor
5 months ago
Shouldn't need to do anything special to reference local system. I'm not able to replicate the issue myself. Can you get a screenshot of a minimum script and Test output like my working test below?
SteveDahlberg
Neophyte
5 months ago
Also, I just additionally inserted the below 2 lines of code right at the beginning of the function to get a direct output with the layer of error reporting, and here is a screen shot of the Test Collection Script - do my absolute paths look okay? Anything else provide a clue?
Mike_Moniz
Professor
5 months ago
I suggest simplifying the problem to the smallest you can and also do some sanity checks. For example just have the script only Write-Output $env:computername and make sure the script is running on the computer you think it's running on. Then use gc c:\ to see if it can list the JCCC folder. Then gc C:\JCC-Local_Text_Files\ to see files in that folder. If that is all good, then simplify the script. Try just Test-Path "C:\JCC-Local_Text_Files\LM-VM_FQDN_List.txt" and see what that returns. Basically debug the script a part at a time, within LM using the Test button.
SteveDahlberg
Neophyte
5 months ago
That's funny, I was doing something similar for other environmental variables, just to confirm it was indeed running as our LogicMonitor service account, and what the working directory was. But I will try those things. I will point that your last suggestion "Try just Test-Path "C:\JCC-Local_Text_Files\LM-VM_FQDN_List.txt" and see what that returns" - that's exactly what I did to generate that last screenshot of Test Collection Script. And you can see the PowerShell error that's captured on stdError - it lists the path and says it can't find it.
Let me absolutely confirm that using an absolute path like "C:\JCCC-Local_Text_Files\LM-VM_FQDN_list.txt" should be sufficient in an embedded Collection script to reference a local resource like this? Again, it works perfectly as is from a PS session on that collector server.
Mike_Moniz
Professor
5 months ago
Yes, and you see it worked for me in my screenshot with a full path. The only thing I'm aware of that LM will do to a powershell script is do a search-and-replace of ##TOKEN## but I didn't see any of that in your code. Even your error message isn't show the path getting screwed up and it's powershell telling you the file doesn't exist there.

I would 100% make sure the script is actually running on the server you think it's running on. Does "Write-Output $env:computername" show the name of the server with the file?
SteveDahlberg
Neophyte
5 months ago
That was exactly it: The script is actually running on a different Collector server, so for now anyway, I dropped that textfile folder there and it works. Thank you.
But now I'm confused, because as I looked at some of the Collector servers, they were all being monitored by other Collector servers, and that makes me think that you don't want a Collector monitoring its own server, because if the server goes down, so does the Collector that's reporting on it. On the other hand, I (think) you were saying that it's actually best practice to have them be the same, so I'm having trouble reconciling those two. But then again, I'm relatively new to LM, and especially new to this aspect of it. What do you think about this setup?
-Steve
- Mike_Moniz
  Professor
  5 months ago
  So the Collector DataSources (like Collector Heartbeat, Collector JVM Status, etc) all assume they are running on the same collector as the device itself. It will report on the same system if the collector it not monitoring itself:
  
  "Note: Collector DataSources only monitor the device’s preferred Collector (as established in the device’s configurations). The preferred Collector should be the Collector that is installed on that device. Otherwise, the Collector’s metrics will display on the wrong host. For example, if you attempt to monitor Collector A using Collector B (installed on a separate host), then Collector B’s metrics will display in lieu of Collector A’s on Collector A’s host."
  
  https://www.logicmonitor.com/support/collectors/collector-management/monitoring-your-collector
  
  Personally, I would suggest making sure collector are monitoring itself. If the collector does go down, you will get a separate Collector Down (LMA#) alert so you will still know if there is an issue.
  
  If you follow the normal wizard way of adding a collector device by checking the "Monitor the device on which the collector is installed" that should automatically set the Collector device to use itself as the collector. But if you add the collector device in other ways that might cause it to be monitored by another collector, or there might be other factors.
  - Mike_Moniz
    Professor
    5 months ago
    I mean "It will report on the wrong system if the collector it not monitoring itself"
SteveDahlberg
Neophyte
5 months ago
Wow. Thank you. I'm still trying to get used to that aspect of it. I didn't even realize that collectors are just DataSources (I just assumed it was a service running on collector servers or on the LM platform somehow). Three quick questions:
How would I go about checking if a device is being monitored by its own collector, and if not, which one is monitoring it?
Conversely, how do I tell which other collector devices a given collector is monitoring?
Finally, where does the configuration take place that defines these arrangements between collectors and collector servers?
- Mike_Moniz
  Professor
  5 months ago
  Sorry, I might be confusing things a bit. They are windows services.
  
  So the Collector is Java-based software that is running as a Windows Service on a Windows Server. (there is a linux version also)
  
  The server itself that is running this software is frequently also called "The Collector" as a short way of referring to the server host that is running the collector software.
  
  By "Collector device", I'm referring to LogicMonitor monitoring the server that is running the collector software. As it shows on the Resources page in LM. This is optional but you should always do. You don't actually have to monitor the host the collector software is running on.
  
  By "Collector DataSources", I'm referring to the data that LM is gathering regarding the performance of the Collector software. Just like you can gather performance data on say a MSSQL server, you can gather performance data on the collector software itself.
  
  You can check which collector is being used for any device/resource by checking the "system.collectordesc" or "system.collectorid" property on the INFO tab of the device. Collectordesc/id is the collector actively being used.
  
  You can also look at Settings > Collectors, and each collector will have a Resources tab which will show you what devices/resources that collector is handling. You can also do bulk moving of devices between collectors from here.
  
  P.S. In LM, "Devices" and "Resources" are the same thing. LM changed the name "Devices" to a more appropriate "Resources" sorta recently, so we tend to use them interchangeably.
SteveDahlberg
Neophyte
5 months ago
Thank you so much! I will check these out. Lots to learn on the fly. Was pulled in mainly to write the embedded PS script and get it working properly, but it's gotten more involved, which is fine, because it takes a project my teammate's plate and I've suddenly had a deep dive into certain aspects of LogicMonitor.