Troubleshooters.Com Presents

July 1999 Troubleshooting Professional Magazine: Troubleshooting CGI

Copyright (C) 1999 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

<--The CGI Troubleshooting Toolkit   |  Contents   |   My Challenge to Marc-Henri Poget-->

Using Semantic Nets to Model Troubleshooting's Knowledge, part 1

By Marc-Henri Poget. Published with permission of the author.
As mentioned in The History of Troubleshooting (January 1999 TPM by Steve Litt), today's systems are highly complex and tough to troubleshoot. There is a strong need for Technologically Enhanced Troubleshooting tools (Era 4), especially when dealing with computer systems. Oriented towards the realization of such a tool, this article discusses semantic nets as a way to model the troubleshooting's knowledge.

EDITORS NOTE: Era 4 tools are expert systems whose foundation and work flow are based primarily on a valid troubleshooting process.

Semantic Nets

Semantic nets, also called mind maps by some authors, are graphs used to represent concepts and their relationships. The term mind maps, assumes that this model is quite similar to how we represent things in our minds. Concepts are the nodes of the net, graphically represented as labeled boxes. Relationships are links between the boxes, represented as labeled arrows.

For example, imagine typical concepts related to birds, these concepts can be: Birds, Feathers, Wings, Worms, Trees. These concepts by themselves don't give so much information. Additional information is contained in the following sentences:

All these sentences express a relationship between concepts. They can be graphically depicted by the semantic net below.

figure 1: Birds related concepts

Applying Semantic Nets to Troubleshooting

As an example, consider a typical Web application as depicted by the figure 2 system diagram. This application is accessed from a Web browser running on a client computer, communicating with the server using HTML and HTTP. On the server side, there are a Web server software, a CGI (Common Gateway Interface) program and a database. Since it contains many components, coming from different vendors, a broad knowledge is required to troubleshoot such an architecture. Problems may occur at the network, database, CGI program, Web server and client levels, therefore you need to know how these components are linked together and how to setup them to narrow down the problems.
 
example.gif (4804 octets)

figure 2: Web application with database.

Although the figure 2 presents the architecture of a typical CGI application, it lacks some information that may be useful when troubleshooting it. This figure doesn't show that the Web browser requires some dynamic link libraries (DLL) or that the CGI program is written in Perl. Semantic nets aren't restricted to an architectural view of the system, but they can show all the Web application related concepts and the relationships which express either dependancies between these concepts or the action of a component on another. Therefore, semantic nets allow to build better models than system diagrams do.

Semantic nets creation is an iterative process. First create a very simple semantic net that can be easily extended when new information about the system is gained. To create the semantic net for the Web application example depicted in figure 3, I followed these steps:


semnet.gif (5214 octets)

figure 3: Semantic net for troubleshooting the Web application.

As a troubleshooting's guide, this semantic net helps to see how things that may fail are related. Thus, it is a good tool to support the 6th step of the Universal Troubleshooting Process (Narrow it down to the root cause).

To navigate from one concept to another, the Troubleshooter must know which tests to do. For example, starting from Web application, one needs to know how to test whether the problem is on the Web browser or on the Web server side. This testing information may be associated to concepts and typical Web browser related tests may be: try accessing other pages, try using another browser. Assuming that all these tests run perfectly, one will conclude that the problem is located in the Web server.


EDITORS NOTE: The test described above is impossible given the preceding Semantic Net because the Web browser and Web server share http and TCP/IP on the preceding Semantic Net. Fortunately all that's required to make the test possible is to refine the preceding Semantic Net to break TCP/IP into components that can be put squarely on either the browser or the server side, probably with relationships connecting them. Those relationships can then be strongarmed to narrow the scope. This is very much like troubleshooting an audio amplifier with a feedback loop from output to input.  That feedback loop must be temporarily broken to draw meaningful information from strongarming the input and observing the output.
This illustrates the real power of Semantic Nets. It provides the Troubleshooter with a straightforward tool to improve insufficient Mental Models during the hot persuit of a solution.
To go further from the Web server concept, the semantic net shows that the problem may be related to the Web server configuration (Web server is configured by Configuration files), the CGI program (Web server launches CGI program) or the communication protocols (Web server communicates using HTTP. TCP/IP). A simple test like trying to access other static pages stored on the Web server immediately rules out a communication protocols problem. It also partially eliminates a configuration problem, since the Web server handles the static pages. Thus the Troubleshooter will have to perform additional checks in the Configuration files to make sure that the CGI program can be launched.

Depending on the problem description he's received, the Troubleshooter can start directly from the appropriate concept. Imagine that the problem description is: "I can't access the Web application from my browser, but I'm able to access any other page on this server.". Given this description, an experienced Troubleshooter will immediately suspect the CGI program and navigate in the semantic net from this concept. A less experienced Troubleshooter will have to start from another concept, like for instance the Web server . Navigation through the semantic net is the Troubleshooter's choice, he also can explore several paths in parallel. Thus the Troubleshooter's efficiency higly depends on the semantic net navigation capabilities. The navigation software shall provide this flexibility.

Conclusion

This article briefly introduced semantic nets, how to create them and how to use them for troubleshooting. Semantic nets are superior to system diagrams, because they can describe more than just an architectural view of the system. This make semantic nets good tools to support the troubleshooting process. The next articles will describe creation and navigation in more details.

EDITORS NOTE: Marc needs to go broader and deeper to fulfill the promise of his article. I have issued Marc a important series of challenges in the next article.

References Mentioned in this Article

Links to these resources can be found in the URL's section of this Troubleshooting Professional issue.
Marc-Henri Poget is a Swiss software engineer, working in a hospital computer department. His main interests are: network and Web applications, network management, and troubleshooting. He can be reached at mpoget@hospvd.ch.