Occasional Bad Request with API to PATCH users
I have a user suspension script that I prefer to run instead of using the "Suspend user after X days of inactivity on LM portal" option in the UI, because of some custom logic. I set up a script ages ago and havent touched the code, but recently on a subset of users, I get a Bad Request (400) error. But whats weird is that all I'm doing is using /setting/admins/ with ?changePassword=false&validationOnly=false and building a minimalistic patching map of the required fields from the model, plus status is set to "suspended". It used to work 100% of the time, but weirdly when I coded it, there were only 3 required fields in the model: roles, password, email. And of course I'd set status in my map, convert to json, do all the stuff, no problem. But I noticed it was failing recently (I never set up alerts on fails) and assumed it was failing 100% of the time at first, reviewed the model and noticed they added "username" as required also, so I added that, expecting it to work, it didnt, so I took that out. THEN I discovered that on some users the old code works, but unlike before, there is a subset that I get a Bad Request on, using the exact same code. No idea why. I also later discovered, when a user came up for suspension that ended up working, that "roles" is not actually required because I removed that for a bit doing some testing, had a real suspend happen to come up, and the code worked without the "required"(??!!) field of "roles" not being in my patch object. This is SUPER FRUSTRATING that the API can change, and that the required fields may or may not be required. :) I made a full "every field" export api to csv script to output every user, looking for something like a property or a setting or something in the raw data that might distinguish a user that the script runs on versus one it wont. Heck I even have logs of the same user that the script had suspended last year (user asked to be reinstated) and it doesnt work on them now. I almost suspect it has something to do with the password, since I havent seen any SSO users the script fails on, and I cant see those. But when I look at every single property that comes back with a GET on the users, I'll have 2 local accounts with the same external group that have nothing different on fields like enabling 2FA or EULA or even the roles they are in or view permissions, there are 35 or so fields ...and nothing stands out. Everything seems like it should work for one user that works for another in these cases. And yet .... Bad Request. Sometimes. Driving me wild over here. At this point I've literally got the original code in place (never committed any changes during testing) and sometimes it works, sometimes it doesnt, but used to be 100% success last year. Stumped. Oh here is an example of the error: I guess I'm not really expecting any silver bullets for this issue, but just on the off chance this is a known issue, I figured I would double check. I wish there were some change log to the Swagger docs. Maybe there is, I'm UI-challenged. If there were API update history changelogs then it might be worth it to pin down when this issue started. Thanks!
Logic.Monitor (Release Updates) - v7.0
I am thrilled to announce the release of version 7.0 of the Logic.Monitor PowerShell module, our community-driven tool designed to streamline interactions with the LogicMonitor REST API. This major update introduces several key enhancements aimed at improving usability and functionality. What's New in Version 7.0 Comprehensive Documentation Overhaul We've launched a new, comprehensive documentation site to serve as your go-to resource for all things related to the Logic.Monitor module. The site features: Detailed Command References: In-depth information on each cmdlet, including syntax, parameters, and examples. Code Examples and Snippets: Practical examples to help you understand and implement various functionalities. Best Practices Guides: Recommendations and strategies to optimize your use of the module. Explore the new documentation here: Logic.Monitor PowerShell Module Documentation. Introducing the Filter Wizard Version 7.0 introduces the Filter Wizard, an interactive tool designed to simplify the creation of complex filters. Key features include: Visual Filter Construction: Build filters using an intuitive, user-friendly interface. Support for All Filter Operators: Utilize a comprehensive set of operators to refine your queries. Real-Time Filter Preview: Instantly see the results of your filter criteria as you build them. You can access the Filter Wizard through the Build-LMFilter cmdlet or by using the -FilterWizard parameter with compatible cmdlets: # Use the standalone filter builder Build-LMFilter # Use built-in filter wizard parameter Get-LMDeviceGroup -FilterWizard Community Collaboration The Logic.Monitor PowerShell module is a testament to the power of community collaboration. Developed and maintained by LogicMonitor employees & users, it embodies the collective expertise and dedication of our community. While not an official LogicMonitor product, this open-source project thrives on user contributions. We warmly invite you to participate by reporting issues, suggesting enhancements, or contributing code via our GitHub repository: Logic.Monitor GitHub Repository. Getting Started To install or update to the latest version of the Logic.Monitor module, use the following PowerShell command: Install-Module -Name "Logic.Monitor" -Force Authentication Before using any module commands, you need to connect to your LogicMonitor portal. You have two options for authentication: Direct Connection (LMv1|BearerToken) Connect-LMAccount -AccessId "your_access_id" -AccessKey "your_access_key" -AccountName "your_portal" Connect-LMAccount -BearerToken "your_bearer_token" -AccountName "your_portal" Using Cached Credentials The Logic.Monitor module includes built-in credential caching to simplify managing multiple portal connections. Using Microsoft’s SecretManagement module, you can securely store and access your LogicMonitor credentials without repeatedly entering them. How It Works When you first use the credential caching feature, you’ll be prompted to set up a secure local vault by creating a password. This vault safely stores your LogicMonitor portal credentials, allowing quick and secure access across multiple sessions. First, cache your credentials: New-LMCachedAccount -AccessId "your_access_id" -AccessKey "your_access_key" -AccountName "your_portal" Then connect using cached credentials: Connect-LMAccount -UseCachedCredential # Select from multiple cached portals Enter the number for the cached credential you wish to use: 0) production-portal 1) staging-portal This approach: Securely stores multiple portal credentials Eliminates the need to handle sensitive information in scripts Provides a simple selection interface for multiple portals Leverages industry-standard encryption via SecretManagement We are committed to continually enhancing the Logic.Monitor module and its documentation. Your feedback is invaluable to us; please share your thoughts and suggestions through our GitHub repository. Thank you all for your ongoing support and contributions to the Logic.Monitor community.Logic.Monitor (PowerShell) module
If you're a LogicMonitor user looking to streamline your workflows and automate repetitive tasks, you'll be pleased to know that there's is a PowerShell module available to help you do just that. As a longtime Windows administrator, I've relied on PowerShell as my go-to tool for automating and managing my infrastructure. I've found that the ability to automate tasks through PowerShell not only saves time, but also reduces errors and ensures consistency across the environment. Developed by myself originally as a personal side project, this module provides a range of cmdlets that can be used to interact with the LogicMonitor API, making it easier than ever to manage your monitoring setup directly from the command line. Whether you're looking to retrieve information about your monitored devices, update alert thresholds, or perform other administrative tasks, this module has you covered. In this post, we'll take a closer look at the features and capabilities of this module, and show you how to get started with using it in your own automation scripts. This project is published in the PowerShell Gallery at https://www.powershellgallery.com/packages/Logic.Monitor/. Installation From PowerShell Gallery: Install-Module -Name "Logic.Monitor" Upgrading: #New releases are published often, to ensure you have the latest version you can run: Update-Module -Name "Logic.Monitor" General Usage: Before you can use on module commands you will need to be connected to a LM portal. To connect your LM portal use the Connect-LMAccount command: Connect-LMAccount -AccessId "lm_access_id" -AccessKey "lm_access_key" -AccountName "lm_portal_prefix_name" Once connected you can then run an appropriate command, a full list of commands available can be found using: Get-Command -Module "Logic.Monitor" To disconnect from an account simply run the Disconnect-LMAccount command: Disconnect-LMAccount Examples: Most Get commands can pull info by id or name to allow for easier retrieval without needing to know the specific resource id. The name parameters in get commands can also accept wildcard values. Get list of devices: #Get all devices Get-LMDevice #Get device via id Get-LMDevice -Id 1 #Get device via hostname Get-LMDevice -Name device.example.com #Get device via displayname/wildcard Get-LMDevice -DisplayName "corp*" Modify a device: #Change device Name,DisplayName,Descrition,Link and set collector assignment Set-LMDevice -Id 1 -DisplayName "New Device Name" -NewName "device.example.com" -Description "Critical Device" -Link "http://device.example.com" -PreferredCollectorId 1 #Add/Update custom properties to a resource and disable alerting Set-LMDevice -Id 1 -Properties @{propname1="value1";propname2="value2"} -DisableAlerting $true ***Using the Name parameter to target a resource during a Set/Remove command will perform an initial get request for you automatically to retrieve the required id. When performing a large amount of changes using id is the preferred method to avoid excessive lookups and avoid any potential API throttling. Remove a device: #Remove device by hostname Remove-LMDevice -Name "device.example.com" -HardDelete $false Send a LM Log Message: Send-LMLogMessage -Message "Hello World!" -resourceMapping @{"system.displayname"="LM-COLL"} -Metadata @{"extra-data"="value";"extra-data2"="value2"} Add a new user to LogicMonitor: New-LMUser -RoleNames @("administrator") -Password "changeme" -FirstName John -LastName Doe -Email jdoe@example.com -Username jdoe@example.com -ForcePasswordChange $true -Phone "5558675309" There are over ~200 cmdlets exposed as part of this module and more are being added each week as I receive feedback internally and from customers. For more details and other examples/code snippets or to contribute you can visit the github repo where this is hosted. Source Repository: https://github.com/logicmonitor/lm-powershell-module Additional Documentation: https://logicmonitor.github.io/lm-powershell-module-docs/ Note: This PowerShell module is an open-source project created and maintained by LogicMonitor users. While not an official LogicMonitor product, it's designed by people who use and understand the platform. The module is freely available for everyone to use, modify, and improve. We welcome your feedback and contributions! If you have ideas or encounter any issues, please share them through GitHub issues or pull requests. Many community members rely on this module in their daily operations. Though we can't offer formal support guarantees, our collaborative community strives to address questions and continuously enhance functionality. We hope you find this tool valuable for your LogicMonitor workflows!
Help Needed: API to Move Discovered Instances of Device Data Source to Default Group
Hi, I have a Python script to move discovered instances of a Device Data Source to a default group. I tried using the PATCH /device/devices/{deviceId}/devicedatasources/{hdsId}/instances/{id} endpoint but wasn't successful. Which REST API should I be using for this? Code snippet: import logicmonitor_sdk from logicmonitor_sdk.rest import ApiException # Configure API client configuration = logicmonitor_sdk.Configuration() configuration.company = 'your_company' configuration.access_id = 'your_access_id' configuration.access_key = 'your_access_key' api_instance = logicmonitor_sdk.LMApi(logicmonitor_sdk.ApiClient(configuration)) # Set up parameters device_id = 3242 device_datasource_id = 353463564 instance_id = 13543752 device_datasource_default_group_id = 16343007 # Fetch the current instance details try: instance = api_instance.get_device_datasource_instance_by_id(device_id, device_datasource_id, instance_id) print(f"Before Instance Update:\n {instance}") # Update group information updated_instance_body = logicmonitor_sdk.models.DeviceDataSourceInstance( wild_value=instance.wild_value, display_name=instance.display_name, group_id=device_datasource_default_group_id, group_name='@default' ) # Update the instance with new group information api_response = api_instance.patch_device_datasource_instance_by_id(device_id, device_datasource_id, instance_id, updated_instance_body) print(f"After Instance Update:\n {api_response}") except ApiException as e: print(f"Exception when calling LogicMonitor API: {e}")LM API
Interesting in hearing some use cases you guys have for the LM API? I have a few scripts setup for mass device manipulation in the case of a change, mass auto discovery, automatically add a Windows server based off AD group, and automated internal ping scans based off a few parameters. Curious to see use cases you guys are using.
LogicMonitor Python API | Gather Stats
Hi All, I am looking into gathering stats from various devices (CPU usage, Memory usage, interface specific stats etc) programatically with Python. I am specifically using the LogicMonitor SDK for Python and have been wondering if anyone has had any luck gathering those types of stats from the API? Documentation I am following: LM API SDK What I have been doing: get_device_list. From this I am able to get the necessary deviceIDs get_device_datasource_list. Here I can see the data sources and their IDs. However, when I try to get_device_datasource_data_by_id with the IDs gathered in step 2, I get this error HTTP response body: {"errorMessage":"DeviceDataSource<13084642> is not found","errorCode":1404,"errorDetail":null} Is there an easier way to get these stats that I am not seeing?Updates for LogicMonitor REST API v1, v2, and v3
Hello LM Community! It’s been a little while since we last shared an update on LogicMonitor API, so we wanted to touch base, and provide you with the latest news. To catch you up to speed, in 2022, LogicMonitor began supporting LogicMonitor REST API version 3 (also known as API v3). Our goal has always been to improve our API experience. Since v3’s introduction in 2022, enhancements and fixes have solely been made to API v3 (not v1 and v2). During planning for the sunsetting of LogicMonitor REST API v1 and v2, we have had many discussions with our customers in order to better understand the various scenarios and challenges that might be faced throughout that sunsetting process. While we continue to encourage all of our customers to migrate to the upgraded API v3, we are temporarily pausing on the actual sunsetting of API v1 and v2. We will keep you updated on those sunsetting plans as they are finalized. Please continue to plan your migrations to API v3, and below you’ll find just a few of the reasons (benefits) for doing so: API v3 is an upgraded version of API v2, and it has all of the latest features and patches Any future enhancements and defect fixes will only be completed for API v3 API v3 has in-depth support documentation for you to reference For more information on LogicMonitor REST API v3, please refer to the below documentation: Using LogicMonitor’s REST API LogicMonitor REST API v3 Swagger Documentation LogicMonitor v3 SDKs Best Practices for Migrating to LogicMonitor v3 SDK LogicMonitor REST API v3 Basic filters LogicMonitor REST API v3 Advanced filters Bearer Token If you have any questions, please contact our Technical Support Team.How IT administrators can streamline operations using the LogicMonitor API
In this article, we’re going to review how LogicMonitor administrators can maximize efficiency and transform their IT operations using LogicMonitor’s REST API and PowerShell. We will cover the following use cases: Device onboarding/offboarding User management Retrieving dataFeature Request: Website Properties
Two requests: 1. Website Inherited Properties Please could the website entity have an “inheritedProperties” field added, much like resources do. This will not require any additional UI, but saves a lot of API round trips. 2. Website Custom Properties Please could the website entity have an “customProperties” field added, much like resources do. This WILL require additional UI on the Website Create/Edit Dialog. Happy if this is UIv4 only.
Enhanced API v3 Experience with Delta on device\device endpoint
Try out the feature today and let us know how it enhances your API Journey Getting the difference between APIs, often referred to as "diffing" or "delta comparison," involves comparing two versions of data or resources to identify the changes that have occurred. Time-based diffing is particularly useful when you want to understand how data has evolved or when you need to apply updates to a dataset based on changes that occurred between two timestamps. Our Customers Ask is …. ensure our data is accurate, reliable, within the rate limits, & lessen effort examining the data elements, fields, or attributes, LM Delta V3 API is a one-stop feature to identify the latest changes that can be used to craft a dashboard, or send it across integration, and granular refinement by leveraging advanced filtering on Delta API. Below are the endpoints: GET /santaba/rest/device/devices/delta – Registers delta request and generates a new delta Id. It also returns all devices that match the filter criteria. GET /santaba/rest/device/devices/delta/<DELTAID> – Returns devices that have any delta between the last and the current API call. Don't miss out on the advantages of the feature….. Stay Tuned
