ContributionsMost RecentMost LikesSolutionsRe: Network diagram Our NOC dashboard just had a little popup saying that this feature was now in our portal. Sure enough, I refreshed my browser, and the Mapping tab is there! Thanks LogicMonitor for always giving us more value. Re: request for longer collection intervals I know my reply will momentarily revive an old thread, but I am just postingthis to close it out, so that future searches are more effective. Longer poll intervals were reintroduced in v.102: https://www.logicmonitor.com/release-notes/v-102-release/ Collection intervals can also be controlled on a per device basis: https://www.logicmonitor.com/support/devices/device-datasources-instances/can-i-customize-data-collection-intervals-for-a-device/ Re: HP Blade enclosure monitoring I realize that it's been 3.5 years since I submitted this request, but I hate unanswered threads. LogicMonitor nowhas full support for all things HP blade via these data sources: HP_OA_Fan- HP_OA_Fuses- HP_OA_Global_Enclosure- HP_OA_Manager- HP_OA_Power_Global- HP_OA_Power_Supplies- HP_OA_Temp- I don't see anything Active Discovered for Virtual Connect out there yet, but I am still testing my SNMP settings. Re: alert rule order changes mnagel, agreed, this would be a great feature. As we continue to grow and write more custom LogicModules, I am always concerned with an alert reorder causingunintended consequences. Cloning in the UI would make it easier for the less experienced folks on my team to handle rule building. Mosh, I love the idea of the priority being "under the hood", as in, just process them the order shown. Insert a new rule here or there, and the system handles the numbering behind the scenes. Re: bring back longer polling intervals (e.g. 12 hrs, 24 hrs) This is great news! Thanks for being a vendor that listens to it's customers needs and implements changes in a very timely fashion! Re: bring back longer polling intervals (e.g. 12 hrs, 24 hrs) Great question Matt Specific to our use cases, we actually use LogicMonitor to runPowerShell scripts against our monitored systems. We are a small, vertical market MSP (about 400 customers, of which we wholly manage about 25%of them.) We set things that you'd normally push with group policies, such as Windows update configuration, folder redirection and the like. However, we push those settings directly into the registry on the monitored device. I've also used it to install and remove software. I also do temp file cleanup and various file system maintenance. In all of these situations, I don't really have a need or want to run theseprocessesmore than once daily. I usually run it in the early AM, so at the top of my PowerShell script, I get the system time, then the entire rest of the script is contained in an if block that only runs if it matches the hour of the day that satisfies the if block. If it doesn't satisfy the if block, the script still exits gracefully with an exit code of 0. I am not sure that I have fully answered your question though. I've posted an exampleof my script below for reference. I comment code quite a bit so that anyone behind me can hopefully decode my mess. That logic sort of goes along with using long variable names that are named for their exact function. #gets the server name from LogicMonitor $Server = $args[0] #gets the current system date and time from the collector $CurrentSystemDateTime = Get-Date #if the current system time matches the hour in the if condition below, run the associated block of code If ($CurrentSystemDateTime.Hour -eq '4') { Get-ChildItem "\\$server\C$\Windows\Temp\*" -Force -Recurse | Remove-Item -Force -Recurse -Confirm:$false #deletes all contents of C:\Windows\Temp on the monitored host, but leaves the tempfolder in place } Re: bring back longer polling intervals (e.g. 12 hrs, 24 hrs) Forwhat it's worth, the longer durationswere removed due to the collector recycling at the eight hour mark. Longer intervals were found to be unreliable, as they had to survive collector reboots. Wewould still like to see 2, 4, 6, and 8 hour collection intervals, but as I noted above, we've gotten around it in all of our script by checking the time on the device and executing it at a given hour of the day. Re: Syslog "Cleared" = MEANINGLESS I am not sure there is a design problem to be solved here. In my opinion, the decision was brilliant to have consistent design, alert handling and escalation rules at the expense ofhaving to edit an escalationrule to stop syslog clears (or other clears you may not want). It allows all users of all skills to both navigate and configure the LogicMonitor web portal easily. You don't have to be an SME, but it's as usable for someone who is. Let's also not forget that syslog alerting is not a core strength for LogicMonitor. If a particular organization's troubleshooting methodology is primarily via syslog events, then I would propose that a dedicated syslog application is merited. LogicMonitor's strength is inperformance metrics and discovery of new items that now shouldbe monitored. My team's primary troubleshooting method is not syslog, but for those events that we don't want clears on, we simply disable them. Re: Removed acknowledged alerts from sidebar or at least honor existing filters Thanks for the update and great news, Annie! Re: Gathering the Windows Service Packs Agreed, I originally had this at the longest interval that LogicMonitor offered, which I think was once every 8 hours or once every 24 hours. When they changed the maximum polling interval a bit ago, the maximum is now 1 hour. LogicMonitor did this to overcome some minor reliability problems where a collector was having to hand off a running schedule to itself after a restart of the collector.
Top ContributionsRe: Exclude Scheduled Downtime from SLA ReportsDynamic host groups by data sourceRe: HP Blade enclosure monitoringHP Blade enclosure monitoringGathering the Windows Service PacksRe: Network diagramAdd "Test" functionality to Event SourcesCollector dynamic groupsRe: Legacy views ?Re: Services - Make ##SERVICERESPONSE## available to Overall alerts