The first step of fault diagnosis is parsing the information provided in a diagnostic request to construct a component graph. This involves identifying the components and properties described in the body of the request and correctly setting observations, beliefs, and relation-
ship properties for each component. An agent also adds any new dependency knowledge to its knowledge base. In addition, an agent retrieves component class and property definitions for any new components and properties.
Agents parse diagnostic messages to update two data structures: a component informa- tion base of known component individuals and diagnostic test results, and the associated beliefs of the component properties; and a dependency knowledge base containing proba- bilistic dependency information for each component and diagnostic test class. Using these two data structures, an agent can perform probabilistic inference to infer the status of com- ponents in the component model.
The procedure for parsing messages is as follows: 1. An agent receives a message.
2. The agent decodes the message according to the diagnostic message format. That is, it parses the XML message to determine whether it is a diagnostic request, a notification, or a diagnostic response. The agent then extracts the headers and body according to the message definition.
3. The agent determines whether it has the capability to answer the message, or if the message is malformed, expired, or if for some other reason the agent cannot return a response. If the agent cannot respond to the request, it returns an error message. 4. The agent parses the body of the message, extracting observations, beliefs and like-
lihoods, and knowledge, as well as the input component if it exists. 5. For each observation:
(a) First, determine whether it describes a component or a test result based on the element name inside the observation. Suppose it is a component.
(b) Next check eachclasselement inside thecomponentelement. If a class defini- tion is not in the agent’s class definition table, the agent retrieves the component class definition using the URI for the class.
(c) The agent parses each property of the component. If the property definition for any of the properties is not in the agent’s property definition table, it retrieves the appropriate definition using the URI of the property.
(d) The agent checks its component graph to determine whether this component is already in its component graph based on the component’s identifying properties or based on the component ID.
(e) The agent adds or updates the information in its component graph as necessary based on the metadata associated with the observation. Note that it may need to make two passes: one pass to create all the components described in the message, and another pass to make the proper assignments to the component relationship properties. If an agent has multiple observations of the same com- ponent, it may keep multiple conflicting observations or it may discard one or more observations based on its local conflict resolution policy.
6. For each belief or likelihood:
(a) Extract the metadata for the belief or likelihood.
(b) Identify the component individual specified in the subject using either its iden- tifying properties or its component ID. If the agent’s component model does not contain the specified individual, then create the individual and set its properties accordingly.
(c) Identify the property of the component specified in the belief or likelihood. (d) Identify the evidence on which the belief or likelihood is based.
(e) Beliefs and likelihoods are expressed as probability tables. Parse the distribu- tion or likelihood table to produce a probability table. Associate this table with the component property in the component graph. In case of multiple conflicting observations, beliefs, or likelihoods for the same property, the agent decides which to use or discard based on the metadata. An agent may choose to keep multiple conflicting beliefs or it may discard one or more beliefs or likelihoods based on its local conflict resolution policy.
7. For each piece of dependency knowledge: (a) Extract the metadata from the knowledge.
(b) Identify the component class specified in the subject. If the agent’s knowledge base does not contain the specified class, then create a new entry for the class. (c) Identify the property of the component specified in the knowledge.
(d) Identify the parent paths for the knowledge.
(e) Parse the CPT. First, identify the parent properties. Use theparentVal,value, and p elements to construct a CPT. Store this CPT in the agent’s knowledge base indexed by the component class (from step (b)), property (from step (c)), and parent paths. In case of multiple conflicting CPTs for the same component class, property, and parents, the agent may keep multiple CPTs or it may decide to discard one or more CPTs based on its local conflict resolution policy. For example, it may choose to keep only the most recent piece of knowledge. This procedure allows agents to combine information from multiple sources into a sin- gle component graph. For example, consider a regional diagnostic agent that receives two observations from different sources. First it receives an observation in a diagnostic request from a user agent about an HTTP Connection and its associated Local Network and DNS Lookup components. Next the regional agent requests additional observations from a DNS lookup test specialist agent. The DNS lookup test agent provides the regional agent with an observation describing the results of a DNS Lookup Test for a DNS Lookup component. Figure 7-2 illustrates the information in these two observations. Using the procedure for parsing diagnostic information, an agent identifies components that are the same and com- bines these observations into a single component graph, illustrated in Figure 7-3. This example illustrates a relatively straightforward case of unifying information from multiple
sources in which the observations share only one component in common and there are no conflicts, but in general there may be more overlapping components and conflicting obser- vations.
HTTP Connection localNet Local Network
DNS Lookup dnsLookup destHost: www.example.com connTime: 1172181867190 srcIP: 18.26.0.100 status: FAIL elapsedTime: 438 ipAddr: 18.26.0.100 hostname: www.example.com ipAddrs: (None)
DNS Lookup Verify DNS Lookup Test
verifyDNSLookupTest hostname: www.example.com ipAddrs: (None) hostname: www.example.com dnsLookupResult: LOOKUP_ERROR_CONFIRMED
Figure 7-2: An agent obtains diagnostic observations from two different sources. Note that both observations refer to the same DNS Lookup component.
Note that an agent can disambiguate multiple components of the same class using re- lationship properties and property paths. For example, consider a DNS Lookup component D with two relationship properties, primaryDNSServerandsecondaryDNSServer, each referring to a different DNS Server component. Suppose that agent A has an observation of DNS Lookup component D in its component graph but does not know the identity of the two DNS Servers referred to by the primaryDNSServer and secondaryDNSServer relationship properties. Agent A wishes to request an observation of the status of the primaryDNSServercomponent from another agent B. Using property path notation, agent A requests an observation of primaryDNSServer.status, providing the DNS Lookup component D as the input component. Agent B returns a response indicating that the DNS Server component to which the primaryDNSServer relationship property of component D refers has status OK. Thus when agent A receives the observation from agent B, it can unambiguously determine which DNS Server component the observation refers to.