Forum Discussion

FrankG's avatar
FrankG
3 years ago

Is there a way to use the API to export all PropertySources (like you can with DataSources)?

I'd like to take an occasional backup of all the PropertySources so we can track changes and be able to fail back easily.

Is there a way to do this via the API today?

Similar to this - https://www.logicmonitor.com/support/rest-api-developers-guide/v1/datasources/export-datasources-to-xml

Export All Datasources to XML

HTTP Method:GET

URI: /setting/datasources?format=xml


(I believe I already know the answer)

  • mnagel's avatar
    mnagel
    3 years ago

    Yes, they can be exported, but not AFAIK as XML.  We use a script to backup (and track via git) pretty much everything in LM including those.  Our script also has a check mode to validate various endpoints that otherwise fail silently (like busted widgets) and tend to otherwise show up in embarrassing situations, like review meetings with clients.

    This is the profile we use to get propertysources: 

        "/setting/propertyrules"            => { file => "propertysources",
                                             saveoptions => { mode => "oneperfile", format => "dumper" },
                                           },

     

    It might be an undocumented endpoint, not recalling at the moment :).

    Mark

7 Replies

Sort By
  • Mike_Rodrigues's avatar
    Mike_Rodrigues
    Icon for Product Manager rankProduct Manager
    3 years ago

    That API is not published but you can still use it with the standard caveat that it may change.

    PropertySources export as JSON because nobody likes XML and we never updated the DS Export file API to output JSON instead.


    @mnageldo you ever make edits in your git repo and push them back to LM? or is it backup only?

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

    Yes, they can be exported, but not AFAIK as XML.  We use a script to backup (and track via git) pretty much everything in LM including those.  Our script also has a check mode to validate various endpoints that otherwise fail silently (like busted widgets) and tend to otherwise show up in embarrassing situations, like review meetings with clients.

    This is the profile we use to get propertysources: 

        "/setting/propertyrules"            => { file => "propertysources",
                                             saveoptions => { mode => "oneperfile", format => "dumper" },
                                           },

     

    It might be an undocumented endpoint, not recalling at the moment :).

    Mark

  • FrankG's avatar
    FrankG
    3 years ago

    Mnagel! 

    "propertyrules" - I might have been looking in the wrong cave or I had my head up my ?.. Not sure which.

    Thanks for this.

     

  • mnagel's avatar
    mnagel
    Icon for Professor rankProfessor
    3 years ago
    53 minutes ago, Michael Rodrigues said:

    That API is not published but you can still use it with the standard caveat that it may change.

    PropertySources export as JSON because nobody likes XML and we never updated the DS Export file API to output JSON instead.


    @mnageldo you ever make edits in your git repo and push them back to LM? or is it backup only?

    It is for backup only.  Wrote it after an unfortunate bad script update to the alert rules that wiped out a lot of stuff.  Not trivial to then restore, but we at least have the changes on hand.  Seeing changes in somewhat realtime (we pull every 4 hours) is also helpful, though I have to filter out a bunch of ephemeral stuff to avoid constant commit messages :).  The check mode was bolted on later since I already had the scanning present and it was not hard to add a check function binding to specific endpoints.

  • mark_rowlands's avatar
    mark_rowlands
    3 years ago

    when i try this via powershell i get

    Invoke-RestMethod : HTTP Status 406 – Not Acceptable

    HTTP Status 406 – Not AcceptableType Status ReportMessage Not Acceptable Description

    The target resource does not have a current representation that would be acceptable to the user agent, according to the proactive negotiation header fields received in the request, and the server is
    unwilling to supply a default representation.LogicMonitor Technical Operations

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

    With most of the undocumented endpoints, you need to use API version 3, not 2.  I usually have to find this along with the endpoint in the browser developer mode (under the Network tab).  I have seen no updates in the API in a while, not sure who is in charge of it now after the last API developer left LM, I am sure it must be someone.

    Here is what we have in our API code currently:

            elsif ($path =~ m{^/setting/(oids|functions|configsources|eventsources|propertyrules|batchjobs|topologysources|registry|alert/(dependencyrules|rules)|companySetting)\b}) {
                $version = 3;
            }

    This kind of stuff is why I refuse to write API code in Groovy modules until LM supports code libraries within the system.