PRTG provides the /api/table.xml?content=sensortree endpoint for retrieving a basic outline of the structure of PRTG. If you want the full information on objects that is returned from API calls like content=groups however you basically need to recurse the tree yourself. In theory, it's simply a matter of recursively iterating over each group that's returned and retrieving any child groups that may be a member of it.
e.g. you first retrieve the child groups of the group 1001, returning groups, 2001 and 2002. You then retrieve the child groups of groups 2001, 2002, and then the child groups of those child groups, and so on. In order to make the recursion easier you would simply wrap your recursion logic up in a function that keeps iteratively calling itself to retrieve more records.
You can kind of get an idea as to how PrtgAPI does it by looking a the source code here.
You can see that we recurse between the methods
1. GetAdditionalGroupRecordsInternal, which then calls
2. ProcessChilrenAndMaybeRecurseGroupRecords ,which then calls
3. MaybeRecurseGroupRecordsInternal, which then descends even deeper into
1. GetAdditionalGroupRecordsInternal again, and it just keeps going deeper until we stop finding child groups
Obviously, in PrtgAPI's case this is wayyy more complicated than it will need to be for you (PrtgAPI's code needs to be modular, and needs to support traversing a group hierarchy for finding sensors, devices or groups).
While PrtgAPI makes writing this sort of logic fairly easy by having deserialized the XML or JSON response to a structured type, you can still achieve the same thing by using the raw API and writing a whole bunch of logic to execute additional API calls as required.
As to why PRTG doesn't support retrieving the entire hierarchy in one go, the answer they gave in a KB post was they think calculating the object tree would have "poor performance" (whether or not that is true or not is up for debate, but either way that's the current situation)
Add comment