Forum Discussion

Will_Holland's avatar
Will_Holland
3 years ago

LogicMonitor API Datasource shows No Instances but Returns Data

I seem to be having a weird issue with the LogicMonitor API and I'm not quite sure why this would be happening. My goal is to go through all servers and get the CPU Usage for each one, and I'm at the stage where I have all of the deviceIDs, and all I have to do is choose the right datasourceID for the metric matching CPU Usage. 

What's strange is that in my request to get datasource information, I noticed that some of the datasources have the instanceNumber field being 0. I figured I wouldn't be able to get any data from these datasources so I partitioned the datasources for each server into two groups: datasources with an instanceNumber > 0, and datasources with the instanceNumber being 0. 

The problem with this is the metric (CPU Usage) appears to have zero instances for one of the servers I need to grab data from despite that exact same datasource showing in the browser view of LogicMonitor. I tried requesting data from it with "/device/devices/{deviceID}/devicedatasources/{datasourceID}/data" and it returned the data I was expecting, but this isn't consistent behavior, and sometimes the API won't give any data for the same API request.

Am I supposed to be able to get data from datasources that have no instances? Is there a way to get CPU Usage reliably through the API? Is there something that would need to be configured within the LogicMonitor instance to help me with my issue (I have no admin permissions and only have read access through the API and browser so I have no clue about admin settings)? 

Thanks

  • mnagel's avatar
    mnagel
    Icon for Professor rankProfessor
    3 years ago

    Not all datasources use instances.  For CPU, sometimes is is a global device attribute (e.g., Windows CPU) and for others (e.g., most other devices) it is a per-CPU or per-core attribute -- only the latter would have instances.  Anything DS you see under a device without a submenu is going to lack instances, but should certainly produce data.

  • Will_Holland's avatar
    Will_Holland
    3 years ago

    Okay, that makes sense. I guess I'm not sure on how I could know whether a certain datasource is available for getting data from or not without actually trying to request data from it. The fields returned from "/device/devices/{deviceID}/devicedatasources" don't seem to reveal that information.

    Am I missing something that would do what I'm looking for? I want to automate as much of this process as possible so I don't have to maintain a list of datasources for each server.

  • mnagel's avatar
    mnagel
    Icon for Professor rankProfessor
    3 years ago
    5 minutes ago, Will Holland said:

    Okay, that makes sense. I guess I'm not sure on how I could know whether a certain datasource is available for getting data from or not without actually trying to request data from it. The fields returned from "/device/devices/{deviceID}/devicedatasources" don't seem to reveal that information.

    Am I missing something that would do what I'm looking for? I want to automate as much of this process as possible so I don't have to maintain a list of datasources for each server.

    Looking at our backup repo, I see a datasource field labeled 'hasMultiInstances' -- this is returned as a JSON boolean value.  It is tough to know if that is an "unsupported" field reference since little of that is documented.  I think it is safe to rely on it at least for the current API version.

  • Will_Holland's avatar
    Will_Holland
    3 years ago
    7 minutes ago, mnagel said:

    I think it is safe to rely on it at least for the current API version.

    Would that be V2 of the API? I've been working on V1 and haven't seen that field.

  • mnagel's avatar
    mnagel
    Icon for Professor rankProfessor
    3 years ago
    1 minute ago, Will Holland said:

    Would that be V2 of the API? I've been working on V1 and haven't seen that field.

    Yes. v1 is pretty old and you definitely get a restricted view of the returned objects.  Our API library uses v2 as default with a few older endpoints still at v1 (devices and services mainly), then newer endpoints require v3. You can tell what is used/needed with web developer tools in Firefox or Chrome by examining request headers.

  • Will_Holland's avatar
    Will_Holland
    3 years ago
    1 minute ago, mnagel said:

    Yes. v1 is pretty old and you definitely get a restricted view of the returned objects.  Our API library uses v2 as default with a few older endpoints still at v1 (devices and services mainly), then newer endpoints require v3. You can tell what is used/needed with web developer tools in Firefox or Chrome by examining request headers.

    Awesome. I'll try to dig around a newer version. I was unaware that there was a big difference between the versions. Thank you for your help!

  • Anonymous's avatar
    Anonymous
    3 years ago
    18 hours ago, Will Holland said:

    Would that be V2 of the API? I've been working on V1 and haven't seen that field.

    Def need to be using v2 of the API.

    v1 will probably be deprecated "soon" as it still supports basic authentication, which is not acceptable for certain security certifications. There have been rumors that it would happen very soon for a long time now.

    There are some significant advantages to using v2. For one, the SDK uses v2. For another, the responses all use a single format (the data is in an object called "items" always). The error codes are also more verbose in v2.