Reading System Health Data

Reading system status data is pretty straightforward; all we need to do is call two methods: one to retrieve readings about hardware and memory status, and another to check the total HTTP and HTTPS requests served by our load balancer.

So as we can see from Table 2-1, we will be calling the statsystem and statprotocolhttp methods. Neither of these methods requires any input parameters. Listing 2-20 shows a simplified version of the statistics gathering method in our NSStatApi class.

Listing 2-20. Obtaining system health data def system_health_check(self): results = {} [...]

req = self.module.statsystem() res = self.soap.statsystem(req)._return results['temp'] = res._List[0]._internaltemp results['cpu'] = res._List[0]._rescpuusage results['mem'] = res._List[0]._memusagepcnt [...]

req = self.module.statprotocolhttp()

res = self.soap.statprotocolhttp(req)._return results['http_req_rate'] = res._List[0]._httprequestsrate [...]

return results

This looks very similar to the login request we performed earlier; however, there is one important thing to notice. This time we need to use the _List variable to access the details we are interested in. The reason for this is that all response _return objects contain two required and one optional variable: _rc, _message, and _List. We already know that _rc and _message contain a request return code and a message that provides more details about the request status.

_List is optional and is an array that may contain one or more instances of the return object(s). Even if the method will always return a single instance, it is still contained in the array. This is one of the options to provide a standard way of communication: every request is always going to return the same set of variables, so if we needed to, we could write a standard SOAP request dispatcher/response handler.

How do we find out what structure objects are returned in the list? This is very simple. First you need to look for the methodname response class in the NSStat_services_types. py module that contains all datatypes used in SOAP communication. So in our case we would be searching for statsystemResult_Def class.

Once we have found it, we need to look for the type definition, similar to the following:

TClist = [ZSI.TCnumbers.IunsignedInt(pname="rc", aname="_rc", minOccurs=1, maxOccurs=1, nillable=False, typed=False, encoded=kw.get("encoded")), ZSI.TC.String(pname="message", aname="_message", minOccurs=1, maxOccurs=1, nillable=False, typed=False, encoded=kw.get("encoded")), GTD("urn:NSConfig","systemstatsList",lazy=False)(pname="List", aname="_List", minOccurs=0, maxOccurs=1, nillable=False, typed=False, encoded=kw.get("encoded"))]

Now we will look for the systemstatsList class definition, shown in Listing 2-21.

Listing 2-21. The systemstatsList class definition class systemstatsList_Def(ZSI.TC.Array, TypeDefinition): #complexType/complexContent base="SOAP-ENC:Array" schema = "urn:NSConfig" type = (schema, "systemstatsList")

def __init__(self, pname, ofwhat=(), extend=False, restrict=False, attributes=None, **kw): ofwhat = ns0.systemstats_Def(None, typed=False) atype = (u'urn:NSConfig', u'systemstats[]')

ZSI.TCcompound.Array.__init__(self, atype, ofwhat, pname=pname, childnames='item', **kw)

In this class definition we are going to find a reference to the actual class, which is going to contain all the variables we will receive in the response from SOAP.

So finally, in Listing 2-22, we search for systemstats_Def class, where the subclass Holder contains all available variables.

Listing 2-22. The definition of the systemstats return type class systemstats_Def(ZSI.TCcompound.ComplexType, TypeDefinition): [...]

class Holder:

# pyclass self._rescpuusage = None self._memusagepcnt = None self._internaltemp = None [...]

This may look really complicated, but for automated systems it is always the same pattern in accessing the information, which helps to simplify the process.

Was this article helpful?

0 0

Post a comment