Search the Community

Showing results for tags 'debug'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • LogicModule Exchange
    • LM Exchange
    • LM Staff Contributions
  • Product Announcements
    • LogicMonitor Notices
  • LogicMonitor Product Q&A
    • Feature Requests
    • Ask the Community
    • From the Front

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Found 6 results

  1. Please make the "go here" link in the "For more detailed troubleshooting recommendations, go here." message open in a new tab/window. If you accidentally click this it open in same window and we lose our command history! Add the debug help that appears on entering a debug console to the regular help content (if it's there I didn't find it) so that we can open the help panel and have the commands easily accessible from the Support Guide panel. The HTML version should be easier to read too. Finally, please add some blank lines between the built-in commands help to make it easier to read the green on black screen. HTML version in the Support Guide panel though, that's the way to go.
  2. Although a TEST step button is available in service checks (external and internal) this only shows the request made and the response output windows. Neither type gives you any kind of output from the post-processing of the response i.e. JSONPATH results. For the Internal service check that has the scripted option (rather than settings) this is even more noticeable as there is no obvious way to put any println or debug in your response script to make sure it is doing the write thing or work out why it is not doing the right thing. The addition of a stdout/output window that shows response (or request) script output would be really helpful. Also possibly the addition of a Test Script button for the response script that would run the script and show output as per datasources would also be great. I ran these ideas past support and they suggested raising a feature request so I have. They did also suggest I could test my scripts (request or response) in the console debug window which is possible but not obvious ways to mock LMRequest/LMResponse objects so that the script can run the same way as it would normally as a service check. If there are examples or ways to do this then this may be a good subject to create a support page explaining how to do it.
  3. rixter

    !tlist filtering

    Ability to filter !tlist output. Example, !tlist all data points not returning any data aka nan.
  4. We would like to build a nicer web UI for the debug commands so that we can enable our less technical staff to perform tests to verify things like SNMP comms. Please extend the REST API so that debug commands can be invoked and the response returned in the REST API call response.
  5. Please improve debugging of DataSources. All the "Debug" option does is open the debug interface. Intuitively, a user would expect the relevant command(s) to be executed also. For example, if I invoke "Debug" for the MySQL Global Stats DataSource or a Windows WMI DataSource, then the debug option should not open the Debug UI, but rather it should invoke the !tlist command, automatically determine the task ID and use it to then invoke the !tdetail command, and present back to the user the output of from the !tdetail command.
  6. Clement Law

    Debugging Information

    Currently, there's no clear cut way of debugging the creation of datasources. Let me explain: 1. You create a datasource that scrapes a webpage for some JSON 2. You attach the datasource to a device 3. For some reason, the device doesn't show your datasource after refresh 4. What is going on? The answer to bullet point 4 is pretty frustrating. There's no feedback as to what is going on. For my example, it was a case of having a collector on the wrong VLAN, causing it not to be able to access the web page API, but I came to this conclusion after lots of head thumping. All there needs to be is some kind of display that shows what the error message was. Presumably, an error was thrown somewhere in the collector, but that isn't shown in the GUI. I don't think the answer to this should be to use the debug console, or to look at the logs of the collector. I think they should clear and present on the GUI. For someone who comes from a development background, I find this sort of clicking around and watching spinning gifs really annoying. I'd just like to see some more feedback for what is going on. Thanks.