cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 9

Unable to unmanage application using orion API

Hi All, I am trying to unmanage an application using orion API. I took python script to unmanage a node as a reference and modified it to also support for application.

Script was able to execute with no errors and exceptions but application didnt get unamanaged. I am kind of stuck here as don't have any errors to check and logs to find the root cause.

Please help if anyone has faced this issue before.

import requests

from orionsdk import SwisClient

from datetime import datetime, timedelta

def main():

    hostname = 'localhost'

    username = 'test'

    password = 'dadasdd'

    print("i am running")

    swis = SwisClient(hostname, username, password)

    results = swis.query('SELECT ApplicationID, ApplicationTemplateID FROM Orion.APM.Application WHERE ApplicationID = @ApplicationID', ApplicationID='28')

    if results['results']:

        ApplicationID = results['results'][0]['ApplicationID']

        ApplicationTemplateID = results['results'][0]['ApplicationTemplateID']

        netObjectId = 'AA:{}'.format(ApplicationID)

        now = datetime.utcnow()

      

        tomorrow = now + timedelta(days=1)

        response = swis.invoke('Orion.APM.Application', 'Unmanage', netObjectId, now, tomorrow, False)

        print('Done...{} will be Remanage until {}'.format(ApplicationID, tomorrow))

        print('Response - {} '.format(response))

    else:

        print("Device doesn't Exist")

requests.packages.urllib3.disable_warnings()

if __name__ == '__main__':

    main()

Thanks in advance for checking.

Regards

Devraj S

11 Replies
Level 14

I seem to be having the same issues.

I tried with your script and got the same results. As a second test, I did what you presumably did and took the Unmanage Node sample script from GitHub which works fine and altered it to do the same for applications and though it reports success it doesn't seem to do anything.

Response is NoneType in both cases, so I don't see a difference really in what's being invoked in from the script.

0 Kudos
Level 14

I tried pawelk's suggestion and I'm getting an error:

Parameters:

netObjectId (this is typo'd in the tool as netObjetId): AA:246

unmanageTime: 2019-01-18 14:45:16.681472

remanageTime: 2019-01-19 14:36:16.681472

isRelative: False

- <Fault xmlns="http://www.w3.org/2003/05/soap-envelope">

- <Code>

<Value>Sender</Value>

</Code>

- <Reason>

<Text xml:lang="en-US">Orion.APM.Application.Unmanage failed, check fault information. Verb Orion.APM.Application.Unmanage cannot unpackage parameter 1 of type System.DateTime</Text>

</Reason>

- <Detail>

- <InformationServiceFaultContract xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.solarwinds.com/2007/08/informationservice">

<Message>Verb Orion.APM.Application.Unmanage cannot unpackage parameter 1 of type System.DateTime</Message>

     </InformationServiceFaultContract>

     </Detail>

     </Fault>

          It doesn't like one of the Time entries, but I took the response from the script and just changed the hours/minutes so not sure what it wouldn't like.

          I checked the time entry format and updated to put a T instead of a space between date and time and then it was triggering on isRelative. When I changed from "False" to "false" it returned successfully, but still no joy.

<Return i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/SolarWinds.InformationService.Contract" xmlns:d1p1="http://schemas.datacontract.org/2004/07/System" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" />

I think I found it.

I checked the database and found that there are entries for UnManagedFrom and UnManagedUntil that match my specififcations, except they're 5 hours in the future (time zone offset is -5 from UTC). So it seems that Applications being unmanaged are shifting based on time zone.

I confirmed this with the SWQL studio by using the invoke for 14:00 - 5 and it unmanaged just fine.

Updated this in the script by changing the line to:

now = datetime.utcnow() + timedelta(hours=-5)

And confirmed it works now.

0 Kudos
Level 19

What about including the "Z" suffix on the date time string? This indicates that it should be interpreted as UTC.

0 Kudos
Level 14

Good call. That works from the SWQL Studio.

The script code between the Unmanage Nodes and Unmanage Applications is virtually the same though, right? So what would be the difference?

0 Kudos
Level 19

I went and looked at the code for the node Unmanage verb and the application Unmanage verb. They are pretty similar, but the application one includes a call to DateTime.ToUniversalTime() that the node verb does not. When you send a DateTime with no time zone suffix (either as an explicit offset like "-06:00" for central time or as the special "Z" suffix for UTC), then ToUniversalTime assumes that it must have been local time and applies the Orion server's time zone offset to convert it. The node verb is not doing any time zone adjustment, so it just takes whatever you send it as is. Specifying the Z suffix makes the effective behavior of these two verbs the same.

0 Kudos
Level 9

Thanks tdanner​ for the analysis but noth node and application script has call DateTime.ToUniversalTime().

Also, i went on to see the values scripts is sending as an argument to API by using some print statements. these time values being sent noware also the right values for UTC time.

pastedImage_0.png

this UTC translates to server time zone which is eastern time as 08:57 AM but database entries shows different values to unmanage an application.

pastedImage_1.png

Level 19

Suggestion: after attempting to unmanage and application from a script, try querying the UnmanageFrom/UnmanageUntil properties of that application and see if they match what the script tried to set them to. This might give a clue as to what is going on here.

Level 14

Yeah it looks like the script is working fine, but a time offset is being added. Can be overcome by a simple change, but not sure if that's the intended behavior or not. I think I like that it's trying to keep Time Zone in mind, but I'm not sure if that's consistent since the script works for nodes without the change.

0 Kudos
Level 9

Hi Devraj,

please double check that the prefix of netObejctId is correct for your case. 'AA' is a prefix for regular application monitors only, for AppInsights this can be different.

You can look it up in DetailsUrl field of Orion.APM.Application entity.

Regards

pawelk

0 Kudos
Level 9

Hi pawelk, i have checked it again and netobject prefix for application is "AA".

0 Kudos
Level 9

Hm, maybe you could try invoking the verb using SWQL Studio manually first.

In order to pass date-time, use ISO-8601 format: example: 2019-01-17T16:10:41.7382429Z

This way you could narrow down the problem to be either problem with Orion configuration or problem with the script.

0 Kudos