This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

'Discovery' tables dissappear with 10.2 release of Solarwinds

FormerMember
FormerMember

Hi All,

It would seem that the DiscoveryNodes, DiscoveryEndPoints and DiscoveryLinks  tables (entities) have dissappeared from the API with the latest release of Solarwinds. Does this always happen with new releases? The SDK documentation states that one of the reason for using the API to to isolate from database schema changes. :-(

 

kind regards,

John

  • Were you looking for the Network Topology information, or just Network Discovery?

    In 10.2 we changed how the Topology was gathered and moved it from the Network Discovery to the Rediscovery interval of the Node. This is to simplify the process of discovering connections.

    To see what Nodes and Interfaces are connected to, please use the TopologyData Table. This table did exist in 10.1 and has not changed.

  • FormerMember
    0 FormerMember in reply to sean.martinez

    Thanks Sean! That very helpful!

    We are a 3D visualisation company that picks up Topo data to show it in 3D. So we need the nodes, interfaces as you describe (as well as the performance data to hang off the picture)

    Regards,

    John

  • Hi Sean,

    I have a question about the Network Discovery tables themselves:

    Where can I find the contents of the DiscoveryProfileSearchRanges table?  I was using the SDK to modify the BeingAddress and EndAddress Properties.  I see that information in an xml string contained in the pluginconfigurations field in the DiscoveryProfiles table, but unfortunately that field cannot be modified using the SDK.

     

    Thanks!

  • I am afraid PluginConfigurations column in DiscoveryProfiles table is only place where you get all information (since version 10.2).

    We did big changes in Discovery in version 10.2 and this is one of them. Storing configuration in XML allow us to be more flexible (we need it because discovery is now pluggable).

  • Thanks Tomas.  I was hoping to avoid directly modifying the database.  What does it mean that discovery is now "pluggable"?

  • Previous discovery was implemented only in Orion Core and modules had no possibility to extend it easily. Now modules can write own plugins for discovery and that gives them good way how to extend discovery and bring new features into it in the future releases.

  • Previous discovery was implemented only in Orion Core and modules had no possibility to extend it easily. Now modules can write own plugins for discovery and that gives them good way how to extend discovery and bring new features into it in the future releases.

    Thanks for the quick reply!

    I have a few questions:

    1. Are there any other aspects of the SDK that no longer work with the 10.2 release?
    2. SDK Direction:  Are there plans to support the SDK for customers with current service contracts, or to integrate it into Orion?
    3. What's the risk (outside of directly modifying the database in general), of modifying the pluginsconfiguration field in the DiscoveryProfiles table?

    Thanks very much for your help!

     

    Chris

  • 1. The "Adding a Node for Monitoring" section of Orion SDK.pdf, the names of pollers (like "Poller_RT", "Poller_CR", etc.) are given. The poller names to use have changed in 10.2. We're working on updating that document to reflect the new names.

    2. Right now we don't have any plans to offer formal support for SDK users. I have brought this thread to the attention of our product managers.

    3. For scheduled discoveries, I don't think direct modifications to the discovery configuration would take effect. Those configurations (along with scheduling information, credentials, and some other stuff) get turned into an internal scheduled job. When you edit the discovery through the website, it will update that schedule job as well.

  • Right now we consider using the SDK as "supported". Using the SDK does not put your system in a broken state and you can call support if there is a problem un-related to the SDK. However, our support department will not assist with building scripts, helping with the integration or other aspects of the SDK. We currently have no plans to provide this level of support for the SDK.

    Mav