PDA: A Tool for Automated Problem Determination - … · 21st Large Installation System...

PDA: A Tool for AutomatedProblem Determination

Hai Huang, Raymond Jennings III, Yaoping Ruan, Ramendra Sahoo, Sambit Sahu, and AneesShaikh – IBM T. J. Watson Research Center

ABSTRACT

Problem determination remains one of the most expensive and time-consuming functions insystem management due to the difficulty in automating what is essentially a highly experience-de-pendent task. In this paper we study the characteristics of problem tickets in an enterprise IT infra-structure and observe that most of the tickets come from very few products and modules, and OSproblems present higher resolving duration. We propose PDA, a problem management tool thatprovides automated problem diagnosis capabilities to assist system administrators in solving real-world problems more efficiently. PDA uses a two-level approach of proactive, high-level systemhealth checks, coupled with rule-based ‘‘drill-down’’ probing to automatically collect detailed in-formation related to the problem. Our tool allows system administrators to author and customizeprobes and rules accordingly and share across the organization. We illustrate the usage and bene-fits of PDA with a number of UNIX problem scenarios that show PDA is able to quickly collectkey information through its rules to aid in problem determination.

Introduction

Computer system administrators (SAs) play anumber of important roles in managing enterprise ITinfrastructure, either as members of internal IT depart-ments, or with IT service providers who remotelymanage systems for customers. In addition to handlinginstallation, monitoring, maintenance, upgrades, andother tasks, one of the most important jobs of SAs isto diagnose and solve problems.

In IT services environments, the problem man-agement process (defined, for example, in ITIL [4])describes the steps through which computer problemsare reported, diagnosed, and solved. A typical se-quence is for a problem ticket to be opened by a call tothe customer helpdesk, or by an alert generated by amonitoring system. This is followed by some basic di-agnosis by first level support personnel based on, forexample, well-documented procedures. Simple issuessuch as password resets or file restoration can often behandled here without progressing further.

If the problem needs further investigation, it ispassed to second or third level personnel, who are typ-ically SAs with more advanced skills and knowledge.They often start with vague or incomplete descriptionsof problems (e.g., ‘‘application is running very slow-ly,’’ ‘‘mail isn’t working,’’ or ‘‘CPU threshold exceed-ed’’) which require significant investigation before thecause and solution are found. In the context of serversupport, administrators often consult monitoring toolsthat provide some specific system indicators, and thenlog in to the server to collect additional detailed infor-mation using system utilities. In the course of day-to-day problem management, this process is often themost time consuming and expensive task for SAs – it

is difficult to automate, and requires field experienceand expert knowledge.

Unlike the first level support personnel, there ishardly any well-documented procedure one can referto during this advanced problem management process.SAs usually rely on their own knowledge and experi-ence to diagnose the root cause of the problem. Be-cause of the complexity of the problems, it is a signifi-cant challenge to create a useful documentation aboutthis process which can be referred by others. Especial-ly in the environment where supporting teams areglobally distributed, how to creat and share thisknowledge is a big challenge.

In this paper we describe Problem DeterminationAdvisor (PDA), a system management tool for serversthat provides health indicators and automated problemdiagnosis capabilities to assist SAs in solving problems.PDA is intended to be used by second or third levelSAs who diagnose and address problems that cannot behandled by first level support (i.e., helpdesk). PDA usesa two-level approach that provides high-level healthmonitoring of key subsystems, and scoped probing thatcollects additional details in an on-demand, rule-basedfashion. This approach has the advantage of performingdetailed ‘‘drill-down’’ probing only when it is relevantto the problem at hand, hence avoiding the overhead ofcollecting such data all the time. Moreover, PDA’sprobes and problem determination rules are not deter-mined arbitrarily; they are crafted based on an exten-sive empirical study of real problems that occur in prac-tice and expert rules drawn from system administratorbest practices. The rules are also customizable to betterserve a particular environment or purpose. Our specificcontributions include:

21st Large Installation System Administration Conference (LISA ’07) 153

PDA: A Tool for Automated Problem Determination Huang, et al.

• Characterization of server support problems:using real problem tickets from a diverse groupof servers in a large enterprise, we study therelative frequency of various types of problems,and determine categories of commonly occur-ring problems based on their nature and fre-quency, and study the relative difficulty of re-solving different types problems.

• Problem determination rules for scoped probing:based on examination of actual problem descrip-tions and their solutions, tools and scripts usedby SAs in practice, and knowledge capture fromSAs, we develop a set of rules that determinehow probes should be dispatched to automatical-ly collect the information necessary to assist thediagnosis of various types of problems.

• Extensible PDA tool architecture: we codifyproblem determination rules and best practicesin a tool that can be expanded as new rules aredeveloped or as specific needs arise in differentIT environments.

The measure by which most system managementtools, and problem determination tools in particular,are judged is the reduction they enable in the time oreffort needed to solve problems. As such, we illustratethe usage and benefits of PDA with a number ofUNIX problem scenarios drawn from problem tickets,discussions with SAs, and system documentation. Inthese scenarios, SAs must know which information tocollect and how to collect it (manually) in order tosolve the problem. We show that PDA is able toquickly collect key information through its problemdetermination rules to aid in finding the cause, or insome cases pin-pointing the problem precisely. Thisallows expert SAs to solve problems more efficiently,and less experienced SAs to benefit from the diagnos-tic best practices codified in the tool.

Our current library of problem determination rulesand probes is geared toward system software problems,for example on commercial and open source UNIXplatforms. However, the general approach of PDA isapplicable to other problem areas, particularly applica-tions and middleware (which are a significant fractionof all problems). As we discuss in Section ProblemCharacterization, the bulk of reported problems are re-lated to a relatively small number of specific problemareas, and this holds across problems related to applica-tions, platform, networking, etc. Hence, developingrules based on best practices for the most commonlyencountered problems is quite feasible. However, weexpect that this model is more beneficial for IT servicesenvironment where similar platform and configurationco-exisit. For heterogeneous environement such as uni-versities, the best practices may vary from each other.

In the next section, we present the results of acharacterization study of problem tickets which we useto inform our choice of system probes and the design of

problem determination rules. Section PDA Design andImplementation follows with a description of the PDAtool design and implementation. In Section Problem de-termination experiences with PDA we evaluate PDA’sefficacy in the context of several specific problem sce-narios. Section Related work briefly discusses some ofthe related work. We conclude the paper in SectionSummary with a discussion of our ongoing work in theimplementation and evaluation of PDA.

Problem Characterization

We begin with a characterization of real-lifeproblems from a large, distributed commercial IT en-vironment. The problems are drawn from an analysisof about 3.5 million problem tickets managed througha problem tracking system over a nine-month period.These tickets contain rich amount of information in-cluding a problem description, indication of the affect-ed system, and metadata such as timestamps, severity,and identity of the SAs handling the tickets. In ouranalysis, we derive a number of statistical characteris-tics that allow us to better understand the different cate-gories and characteristics of common problems. Specif-ically, we focus on:

• which applications contribute to the majority ofthe problems, and in particular whether a fewapplications are responsible for most of the ob-served problems

• what are the most common causes of applica-tion problems

• what portion of problems arise due to applica-tion vs. operating system-level issues

• how much time is spent in resolving differenttypes of problems

Our objective in this section is to develop in-sights from the analysis of problem tickets in a realenterprise IT environment, and later use these insightsto develop tooling for improving the efficiency ofproblem diagnosis and resolution.

Fields in Problem Tickets

We examine a number of attributes of each ticketincluding both structured attributes with well-definedvalues, and unstructured attributes which are mostlyfree-text. Structured attributes contain information suchas a ticket’s open and close time, incident occurrencedate, SA user ID, and some enumerated problem char-acteristics such as problem type, product name, etc.Problem description and solution description are free-text. In this study, we are particularly interested in thefollowing data fields:

• product name: There are about 600 products ap-pearing in the tickets. Most of them are applica-tion names, while operating system or platform-related problems are categorized by generalterms such as AIX, HP-UX, Linux, Windows.

• product component: Each product is further bro-ken down into various predefined components.

154 21st Large Installation System Administration Conference (LISA ’07)

Huang, et al. PDA: A Tool for Automated Problem Determination

They give finer-grained information about theproblems. For example, components within theWi n d o w s product include bootup, explorer, systemerrors, password.

• product module: This is the finest-grain infor-mation available in the problem database – themodule identifies the system sub-componentthat is having the problem. For example, inWindows, the bootup component is divided intodifferent modules such as safe mode, unable toboot, inaccessible boot, and explorer contains navi-gation, move/copy Files, search.

• ticket type: When a ticket is first opened, it iscategorized into a type, for example: error, per-formance, information request, load request andothers. When studying common problems, wefocus on those tickets with type of error and per-formance because they usually require furtherdiagnosis to identify the root cause.

• cause code: This field has 34 values to describevarious problem causes. It is particularly usefulwhen other fields such as component and moduleare not specified. For example, all of the ticketsrelated to the Linux product name have softwareas the component field and OS for module.

Problem Characteristics Overview

To understand the problem tickets in the system,we start from statistical characteristics of the ticketsbased on the above-mentioned fields. We make thefollowing observations:

• Most of the problem tickets arise from a fewproducts.We examined all tickets according to the prod-uct name field. Among the 600 products, weobserve that 50 products, which are less than10% of the total products, account for 90% ofall tickets. Figure 1 shows a cumulative fre-quency graph of the number of products and thepercentage of the tickets with that product. Thisobservation is similar to the failure characteris-tics observed on Windows XP machines [5].Among the top 50 products with the most prob-lem tickets, the number one product is an enter-prise email system, followed by a virtual pri-vate network (VPN) application, and then apopular operating system. Figure 2 shows moredetail about the number of tickets and their dis-tribution, and Table 1 shows the top 10 prod-ucts and the number of tickets from each.

• Within each product, most of the problemscome from a few modules.Next, we analyze the top products which havethe most tickets by categorizing them accordingto product components and modules. Table 3lists the 18 modules which comprise 70% of thetickets reported for the mail system, while the to-tal number of modules defined for this product is

162. For the VPN application, we see an equallyskewed distribution: 70% of the tickets are fromsix modules, out of a total of 70 modules. Table2 lists these top six modules. Details of productcomponents are not listed here because they re-veal less information than the modules.

0

0.2

0.4

0.6

0.8

1

1 10 100 1000

% o

f tic

kets

# of products

Figure 1: Cumulative frequency of the tickets contrib-uted by the set of products.

0

100000

200000

300000

400000

500000

600000

700000

0 5 10 15 20 25 30 35 40 45 50

# of

Tic

kets

Product ID

Figure 2: Number of tickets from the top 10% prod-ucts with the most problem tickets.

These two observations together suggest that, byfocusing on problem determination for a relativelysmall number of products and corresponding modules,we are able to cover a large portion of problem tickets.However, it is also important to note that each modulemay in fact exhibit many problem symptoms and pos-sibly many root causes. This implies that a practicaltool should be highly customizable in order to addresssymptoms that might be unique to a particular envi-ronment.

Operating System ProblemsIn terms of quantity of problem tickets, operating

system (OS) problems are not as prominent (with theexception of Windows-related tickets, which consistof about 11% of the all tickets). However, system soft-ware or OS tickets are often the most diverse and re-quire significant effort to diagnose. Figure 3 illustrates



the distribution of time spent in resolving problemtickets for top applications and systems/OSes. Ouranalysis indicates that nearly an order of magnitudemore time is spent in the resolution of problems aris-ing from UNIX system issues, than on other types ofproblems. VPN and mail applications, both compris-ing a large number of application-related problemtickets, need considerably less time to resolve com-pared to UNIX system related problems.

CumulativeProduct name # of tickets % of tickets

Mail app 618575 18%VPN app 346812 28%Windows OS 331978 38%Mail app (prev version) 229415 45%PC hardware 171078 53%Network connectivity 170937 58%Software installer 92358 61%Mainframe local app 59314 63%Telephone 56396 64%Desktop security audit tool 46470 66%

Table 1: Top 10 products in the ticket database.


RESET 114477 38%LOOPING 23620 45%INTRANET APP 22045 53%INFO 20537 60%INTER/INTRA NET 14220 64%CLIENT 13409 69%UNABLETOCONNECT 13390 73%

Table 2: Product modules and the number of ticketsfrom these modules for the VPN application.

We also examine the top problem types for OSplatforms. Unfortunately, there are no OS componentsand modules defined except for Windows (perhapsdue to the complexity of OS problems). Instead, weuse the cause code field in analyzing OS tickets. Wecombine similar cause code values to arrive at a set ofbroader problem categories including: application, con-figuration, hardware, request/query (e.g., password re-set or howto questions), duplicate (i.e., multiple report-ed problem), storage, network, human error, unsupport-ed (i.e., out of scope for the support team). Note that‘‘ a p p l i c a t i o n ’’ in the OS tickets differs from applicationas standalone product – these are mostly system pro-cesses or services shipped with the OS such as Send-mail, NFS, Samba etc.

Common OS Problems

From the problem categories in Figure 4, we fur-ther examine ticket details in a few categories to

identify commonly occurring problems that occur ineach category. In particular, we focus on problem cate-gories related to systems software and application-re-lated issues on the UNIX platform, including: applica-tion, configuration, storage, and network. We use acombination of ticket clustering based on structuredattributes, and manual inspection of problem and solu-tion description text, to extract a set of typical prob-lems. We describe a few of these sample problems be-low.1 Recall that the problems are grouped by causecode values that are indications of the identified cause;this may be a different category than the original prob-lem description would initially indicate.


OPENING DB 54745 12%RESET 34816 20%FEATURES 32775 27%INSTALL/SETUP 25365 32%OSM/FILESIZE 23458 37%OPTIONS 17788 41%SETTNGS 17453 45%SEND/RECEIVE 17013 49%HELP 13785 52%TEMPLATE 13049 55%CHANGE 12229 57%SETUP 10631 60%CREATE ID 9348 62%SENDING 8786 64%OPTIONS/PREFS 8385 65%NOTRESPONDING 7086 67%GENINFO 7034 69%AUTHORIZATION 6452 70%

Table 3: Product modules and the number of ticketsfrom these modules for the mail application.

0

20

40

60

80

100

1 10 100 1000 10000 100000

Tim

e sp

ent i

n re

solv

ing

(Hou

rs)

# of problem ticket

UnixLinux

WindowsVPN AppMail App

Figure 3: Time spent in solving tickets in top twoproducts and in three OSes.

1Specific hostnames, directory names etc.have been anon-ymized in these samples.



Application

Configuration

Hardw

are

Req/Q

uery

Duplicate

Storage

Unsupported

Hum

an Error

Netw

orking

0

10

20

30

40

50

Nor

mal

ized

per

cent

age

of p

robl

em ti

cket

sLinuxUNIXWindows

Figure 4: Categorization of problem tickets for Linux,UNIX and Windows servers. We examined 4,598,42,998, and 331,978 tickets for each platform, re-spectively.

Configuration Problem Samples

• Multiple email messages from dissimilar do-mains appear to be blocked. The reason wasdue to a change in spam filtering mechanism/update.

• SSH failing after OS version upgrade. The so-lution of this problem was to change permis-sions on /dev/random and /dev/urandom to 644

• The following NFS filesystems did not mountafter miwsrv1 rebooted today:

efkxeastapps.abc.xyz.com:/u0efkxeastapps.abc:/u1efkxeastapps.abc.xyz.com:/u2efkxeastapps.abc.xyz.com:/u3efkxeastapps.abc.xyz.com:/u4

The reason of this problem was because the filesys-tem has been updated using another type. Solutionwas to mount the filesystem using that type name.

Application Problem Samples

• the databases will not start because of someTCPIP problem.The reason was because of port mapper down.

• 03:38 OPS received the following red alert onUNIX icon for abcdef03:

Host:named.my.ibm.comMsg:The percentage of available swapspace is low (20.12939453125 percent).

The solution was to stop unwanted processes.• SRM data is not getting retrieved from STI-

BACKUP due to the refusal of the SFTP con-nection. Symptoms suggest SSH is not running.The problem was solved by changing /usr/binlink to ssh and /etc/inetd.conf path then restart-ing ssh.

Storage

• Base_OS_Monitors critical 98.006800 Percentspace used (/var) This Critical Sentry2_0_disk

usedpct event was received by a monitoringserver at 3/6/2006 6:20 EST.Typical solutions to this space usage probleminclude removing old files, large files, expand-ing file system space, and compressing the oldfiles, etc.

• System backup failed for sx0000e0 on 18082006.More details could be found in the logfile /var/adm/mksysb.out.Reason for this problem was because sometemporary files were not found.

A summary of examples of top problems that wefound among problem tickets is shown in Table 4 inthe first column.

Implications From Problem Ticket AnalysisOur observations in characterizing problems in a

large IT environment has a number of implicationsthat guide the design of PDA. Recall that the first keyfinding was that a few products or applications are re-sponsible for the majority of problem tickets opened.The second observation was that the cause of theseproblems can be attributed to a relatively small set offunctional components of these products. These resultstogether imply that problem determination tooling thataddresses a finite and fairly small set of importantproblem types can in fact cover a significant portion ofproblem tickets that are observed in practice.

We also observed that, in terms of time spent onresolution, UNIX system related problems are rela-tively difficult to resolve. Therefore, this is an impor-tant problem area to consider. Improving diagnosis ef-ficiency for UNIX-related problem can potentiallyprovide a significant value in terms of reduced timeand effort.

These observations motivate our implementationof PDA, which addresses a number of key categoriesof system software or OS-related problems. While ourintention is to broaden the applicability of PDA to oth-er problem types (e.g., applications), our initial focuson OS problems on UNIX platforms is justified basedon the analysis presented above.

PDA Design and Implementation

In this section, we first describe the overall de-sign, architecture, and implementation of Problem De-termination Advisor. We also describe how knowledgegathered from problem tickets is incorporated in PDA’sautomated problem diagnosis capabilities. Details ofproblem determination rules and system probes, as wellas some realistic examples, are also illustrated below.

Design OverviewFrom the previous section, we have observed

that a large percentage of problem tickets are relatedto a small number of products, and within each, mostproblems have only a few primary causes. We use atwo-level approach that provides high-level healthmonitoring of key subsystems, and scoped probing



that collects additional system details. In Table 4, thesecond column lists some of the high-level monitorsthat are used in practice to identify the occurrence ofcommon problems, while the third column shows ex-amples of diagnostic probes that can help identify thecause of common problems in the corresponding cate-gory. The list of problems reported here represents asample of the problem scenarios we have examined,and is by no means complete. We are continuing to ex-pand the list of common problems and correspondingproblem determination probes as we examine addi-tional tickets and continue the knowledge capture ofSA best practices.

Category Typical Problems Health Monitors Diagnostic Probes

ConfigurationOS/App upgrades, changesto various configurationfiles, firewall, spam filtering

Track changes to upgrades,configuration files

File privilege, active users,file diff with backup

Application

App errors due resource ex-haustion (incl. CPU, memo-ry, filesystem), app prereq-uisites, path/setup, etc.

Check resource usage, errorlog, process status etc.

Processes having most ofthe CPU, mem, IO, etc.

Network Connectivity, performance Check DNS, firewall, rout-ing table, NIC

Traceroute, TCP dump, net-work options, NIC

StorageCapacity, data corruption,mount problem, perfor-mance, disk swap, etc.

Check available space, I/Orate, error logs

Mount options IO history,big files

Table 4: Examples of common problem symptoms and corresponding monitors and probes used to identify theseproblems.

If the full complement of monitors and probesare always active (e.g., executing periodically), theywould likely impose a noticeable overhead on produc-tion systems. Hence, the two-level probing approachuses (i) periodic, low-overhead monitoring to providea high-level health view of key subsystems, and (ii)detailed diagnostic probes when a problem is detected.This is similar to the way SAs tackle problems – thedifference being that PDA tries to collect the relevantproblem details automatically.

The knowledge of which diagnostic probes shouldbe run when a problem is detected is encoded in prob-lem determination rules. These rules are represented ina decision tree structure in which the traversed paththrough the tree dictates the series of diagnosticprobes that are executed. At each node, the output ofone or more diagnostic probes is evaluated againstspecified conditions to decide how to proceed in thetraversal. In our implementation, diagnostic probesgenerally use available utilities on the platform direct-ly to retrieve the needed information.

Problem Determination RulesFigure 5 shows a sample rule tree which can diag-

nose problems related to the network connectivity of amanaged server. The corresponding health monitor con-siders the system’s network connection to be availableif it is able to reach (e.g., ping, or retrieve a Web page)

several specified hosts outside of its subnet. Thesecould be other servers it depends on, or well-knownservers on the Internet, for example. If a disconnectionis detected by the health monitor, scoped probing usingdiagnostic probes will be invoked to gather informationto help determine the root cause of the problem. Ac-cording to the rule tree, the first diagnostic probeshould check the network stack by pinging the loop-back address. If no problem is found, the next node inthe rule tree will dispatch another diagnostic probe tocheck that a default gateway is defined in the localrouting table, and that it is reachable. If it is unreach-able, the problem might be with the local subnet ornetwork interface card. Otherwise, potential DNS-re-lated problems are checked, for example verifying that/etc/resolv.conf exists, and that it contains DNS serverentries (that are reachable). Clearly some diagnosticprobes have dependencies (e.g., check /etc/resolv.confexists before checking that a DNS server is reachable)and have to be executed in a certain order. In the ab-sence of dependencies, probes could be ordered differ-ently, perhaps tailored to the likelihood of certaintypes of failures in a given environment.

ibm.com

reachable?Health

Monitor

Diagnostic

Probes &

Conditions

ping 127.0.0.1

TCP/IP kernel

problemroute table ok?

Fix route tabledefault gateway

reachable?

check network

interface adaptor

check

/etc/resolv.conf file

DNS server

reachable?… … …

yes

yes

yes

yes

Check TCP stack

Check local router

Check DNS

Check NIC

Figure 5: Sample rule for network-related problems.



Our problem determination rules are primarilyderived from inspection of problem tickets and bycapturing best practices from SAs (i.e., through dis-cussions, reviewing their custom scripts and proce-dures, etc.). In the case of problem tickets we extractrules by examining the steps through which a problemwas diagnosed and resolved. When the detailed stepsare available, creating a corresponding rule tree is fair-ly straightforward. Some of the tickets, however, donot have much detail beyond the original problem de-scription and perhaps a few high-level actions takenby the SA. In such cases, we must manually infer theprobes needed to collect the appropriate diagnosisdata. In our rule extraction process, we use a combina-tion of data mining tools to categorize problem ticketsand identify distinguishing keywords, followed byvarying degrees of manual inspection to better com-prehend the problem and solution description text. Thedata mining tools are not described in detail here. Ourexperience with problem tickets so far leads us to be-lieve that some amount of manual inspection is neces-sary to derive corresponding rules, however we con-tinue to investigate automated techniques to assist therule derivation process.

hardware memory

CPU

filesystem

networking

errlog

config

application

probe collection probe scheduler

CPU util

memory

system svcs

connectivity

. . .

PD rules library

pda server

managed servers web-based interface

p5

xSeries 365

0

1

2

3

4

5

xSeries 365

0

1

2

3

4

5

p5

probeD

probeDhistory DB

analytics• rule execution• probe processing• authoring• probe data analysis

probe controller

UI services

management station

hardware memory

CPU

filesystem

networking

errlog

config

application

probe collection probe scheduler

CPU util

memory

system svcs

connectivity

. . .

probe scheduler

CPU util

memory

system svcs

connectivity

. . .

PD rules library

pda server

managed servers web-based interface

p5

xSeries 365

0

1

2

3

4

5

xSeries 365

0

1

2

3

4

5

p5

probeD

probeDhistory DB

analytics• rule execution• probe processing• authoring• probe data analysis

probe controller

UI services

probe controller

UI services

management station

Figure 6: PDA architecture.

System Architecture

We have implemented a fully functional prototypeof PDA, including the probing and data collectionmechanisms, rule execution, and a Web-based interface.Figure 6 shows the overall architecture of PDA, whichcontains three major components: probe daemon, PDA

server, and the user interface. Our probe daemon is im-plemented in C for performance consideration and foreasy deployment. PDA server is implemented in Javaand our current user interface backend uses IBM Web-Sphere Portal Server. We use MySQL as our databasestorage.

Web User InterfaceThe Web UI allows SAs to perform various tasks

from a single interface accessible from any worksta-tion. It gives SAs an at-a-glance health overview of allof the servers being managed by clearly highlightingsystems and components that have problems or arepredicted to have problems in the near future. Whetheror not an indicator implies a problem is determined bythe corresponding rule, as discussed further below. Inaddition to showing the current health view of man-aged servers, we also allow SAs to look at the statusof the servers at earlier points in time. This feature isuseful when a reported problem is not currently evi-dent on the system, but may be apparent when view-ing system vitals collected earlier. It also is crucial forobserving trends in certain metrics. Based on our dis-cussions with SAs supporting commercial accounts,this feature is particularly useful to them in gaining abetter understanding of the behavior of the managedsystems.

Besides monitoring, the Web UI allows SAs toperform some simple administrative tasks such asadding another server to be monitored, updating a us-er ’s access privilege (as a root SA), adding or removing



probes on a managed server, etc. The Web UI also pro-vides an interface for SAs to author probes and con-struct rules from new and existing probes. Rules andprobes constructed using this interface are stored inXML to facilitate sharing with other SAs or reusingthem across multiple platforms. This feature is dis-cussed in more detail in Rule Sharing Section.

We are also in the process of implementing aWeb based secure login mechanism so that SAs canquickly switch from a shell from one machine to an-other using pre-defined credentials. This allows SAsto better visualize monitored data using the graphicalinterface, while still having access to a low-level com-mand line interface from a single tool.

Probe DaemonThe probe daemon is a small program that is runs

on managed servers whose primary functions are toschedule the execution of probes according to the fre-quency set by the SA, and to interface with the PDAserver. The PDA server sends command to start a newprobe, stop an existing probe, change the periodicityof a probe, etc. When starting a new probe, the probedaemon can download the probe from a central proberepository if the probe does not exist or is not up-to-date locally. After probes have finished executing, theprobe daemon is also responsible to send probe resultsback to the PDA server.

PDA Server and Rule LibraryMost of the information exchange and process-

ing is handled by the PDA server. Periodically it re-ceives probe results from the probe daemon, stores theresults in a history database, and triggers rule execu-tion if there is a corresponding rule for a particularprobe. The history database stores collected data andalso serves as a repository for important configurationfiles that are tracked by PDA.

The rule execution engine is the most importantpart of the PDA server. It parses rules, each defined in aseparate XML file located in the database, and convertsthem to an in-memory representation for evaluation.There are two ways to evaluate a rule. Typically, a ruleis triggered by a periodic probe which is defined to bethe root node of the rule tree. The trigger can be athreshold violation, change in a key configuration file,or other detected problem. As a second method, an SAcan execute a rule to initiate it manually, to proactivelycollect information related to specific subsystem.

In both cases, as the rule tree is traversed, a com-mand is sent to the probe daemon to execute the re-quired probe and return the result. The result is used tomake a decision to continue collecting more informa-tion or stop the rule execution. Some rules also usehistorical data to decide what should be collected next,or what should be displayed to the SA.

Since PDA supports management of multiplegroups of servers (e.g., for different customers), thePDA server also keeps track of which servers are

managed by which SAs. This also implies that eachserver or group can have different active rules andprobes; PDA supports this notion of multi-tenancy inthe rules library and rule execution engine.

Rules and Probes

A probe is usually implemented as a script (e.g.,Perl, shell, etc.) that either executes native commandsavailable in the system or interfaces with other moni-toring tools deployed in the environment. The probeparses and aggregates the output of the commands,and returns the results as an XML document. In orderto make it easy to add new probes to PDA, the schemais a simple and generic key-value pair representation.When interfacing with other monitoring tools to col-lect data, we write adapters to convert their output tothe XML format for the PDA server.

Figure 7 is an example output from a probe thatmonitors Ethernet interfaces.

Rules are triggered automatically by a monitor-ing probe which appears as the first node of the ruletrue. For example, Figure 8 shows a sample rulechk_interface. It will be triggered by a probe calledchk_eth. In this rule, the first step tests if the numberof collisions is beyond a certain threshold. If thethreshold is exceeded, the next probe, chk_switch, isexecuted to collect some information about the net-work switch, for example related to the firmware ver-sion. This type of scoped probing minimizes monitor-ing overhead and expedites the problem determinationprocess. In the case where the probe in the first nodedoes not present, or the problem is reported by otherchannels, such as problem ticket, a rule can be execut-ed manually by the SAs.

<results probename="chk_eth"><result>

<key> INTERFACE </key><value> eth1 </value>

</result><result>

<key> ERRORS </key><value> 0 </value>

</result><result>

<key> DROPPED </key><value> 0 </value>

</result><result>

<key> COLLISIONS </key><value> 50234 </value>

</result></results>

Figure 7: A sample probe output.

Probe and Rule Authoring

Given the heterogeneity of enterprise systemsand applications, it is unrealistic to expect a singlelibrary of rules and probes to work in all IT environ-ments. For this reason, PDA is designed to be



extensible to allow authoring of probes and rules,either from scratch or, more commonly, based on ex-isting content. We provide templates for writing newdiagnostic probes, and a way to logically group rulesand their associated probes (e.g., based on a particulartarget application). Being able to quickly construct arule for an observed problem from a set of existingprobes can be very helpful to save SAs precious time.

<rule rulename="chk_interface"><node probename="chk_eth" id="0">

<condition> COLLISIONS > 500 </condition><true-branch> id="1" </true-branch>

</node><node probename="chk_switch" id="1">

<condition> MANUFACTURER == LINKSYS &&MODEL == ETHERFAST &&FIRMWARE_VERSION <= 2.3.1

</condition><true-branch>

alert("upgrade firmware")</true-branch><false-branch> id="2" </false-branch>

</node><node ...>...

</rule>

Figure 8: A sample rule file.

We have implemented a Web-based probe andrule authoring interface. We validate the input of re-stricted fields and perform some simple checks (e.g.,for duplicated names in the repository). Validation ofthe probe code is similarly simple, comprising checksthat the probe runs successfully and implements thenecessary rule output formatting. Newly created rulesrequire slightly more involved validation. For exam-ple, we validate that each node in the rule tree has thecorresponding probe(s) available, and that the condi-tions being checked are supported by the probe.

Once a new probe is authored, its data fields arecreated and stored directly in the corresponding tablesin the database, and the PDA server is notified of thenew probe name. If the probe is periodic and needs tobe activated for monitoring, the probe daemon is con-tacted by the PDA server automatically to schedulethe probe. If the probe is for diagnostics (i.e., a ‘‘one-time’’ probe vs. periodic), it will be downloaded to themanaged server when it is invoked by a rule. Rules arestored similarly, along with the XML representation ofthe tree structure.

Since our probes are mostly scripts which will berunning on managed servers, they pose a potential se-curity threat to the system if probes are malicious.Currently we rely on user authentication and out-of-band change approval for new probe and rule author-ing. It may also be feasible to use compilation tech-niques to perform some checks on the semantics of thescripts, for example to see if a probe is writing to a

restricted part of the filesystem. We are investigatingthis in our ongoing work on PDA.Rule Sharing

In our discussions with SAs, we found that shar-ing knowledge and experience between them is a con-siderable challenge. One potentially significant benefitof rule and probe authoring in PDA is the opportunityto share them with other SAs managing the same envi-ronment, or even those working in very different envi-ronments.

Guaranteeing that rules and probes authored byone SA are applicable to problem resolution on othersystems poses a number of difficulties. The primaryone is the wide variety of platforms, operating sys-tems, and software. Most rules are largely platform-in-dependent as the information can be extracted on mostOSes. However, the probes that actually collect the in-formation can be quite different on various platforms.Even on machines with the same OS, different patchlevels or software configurations can very easily breakprobes. To make sharing of rules and probes moreseamless to SAs, we annotate them with dependencyinformation that indicates the platform and version onwhich they have been deployed or tested.

Initially, we expect to deploy our tools in a fairlyhomogeneous environment, e.g., with mostly UNIXmachines. We expect most dependency issues in suchan environment to be solved relatively easily, for ex-ample by using a different binary/utility to obtain thesame information. This technique can be carried overto managing other flavors of UNIX or Linux. As moreusers contribute rule and probe content over time, theywill likely cover a more comprehensive set of plat-forms and provide a valuable way to accumulate andcodify system management knowledge.PDA Usage Model

The design of PDA is largely motivated by ourexperience in IT service provider environments, in



which globally distributed support teams manage theinfrastructure belonging to a large enterprises. In theseenvironments, creating, communicating, and adheringto best practices for systems architecture and manage-ment is a significant challenge. Global support teamsoften consist of administrators with greatly varyingamounts of experience and knowledge – providing theability to capture and operationalize problem determi-nation procedures for the whole team is very valuable.In addition to improving efficiency through automatedcollection of relevant information, it also allows SAsto follow similar procedures which could be designedby the most experienced team members. At the sametime, PDA allows customization of problem determi-nation rules to account for different customer environ-ments or priorities. A PDA installation could include astandard set of problem determinations rules and asso-ciated probes that handle common or general problems(e.g., networking problems, excessive resource con-sumption, etc.). These could be supplemented withnew content that is available from a central repository,or through local modifications of existing content.

This usage model is particularly applicable for ITservice providers who manage many customer infra-structures in a number of industries, since it is likelythat there is a lot of similarity at the system softwarelevel. Furthermore, when the service provider has per-formed some degree of transformation in the customerenvironment, for example to move to preferred plat-forms and tools, the possibility for sharing and reuseincreases. In IT environments belonging to universi-ties and industry research labs, we observe more het-erogeneity in OS platforms, applications, and usage,which makes it more difficult to develop problem de-termination best practices that are widely applicable.Nevertheless, the automation and extensibility featuresof PDA are still useful in these situations.

Problem Determination Experiences With PDA

This section describes some of our experiencesin constructing rules and probes to diagnose practicalproblems with PDA. The rules we built based on prob-lem tickets and best practices from interviewing SAsare not comprehensive, but they address commonlyoccurring problems in realistic settings and can be ex-panded and enhanced by communities of users or ad-ministrators.

Experience with NFS ProblemsNFS allows files to be accessed across a network

with high performance, and its relatively easy configu-ration process has made it very popular in large andsmall computing environments alike. However, whenproblems occur, finding the root cause can take a sig-nificant amount of time due to NFS’s many dependen-cies. Most of the NFS-related problem tickets we ob-served are straight-forward to solve, but some havesymptoms that are difficult to connect with their finalsolution. This often results in tickets being forwarded

multiple times to different support groups, sometimesincorrectly, before they are finally resolved. We foundthat most of these problems can be diagnosed with afew simple systematic steps.

$raw = ‘lssrc -a‘;$lines = split(" ", $raw);

# Omitted code for error-checking# executing lssrc

# Parses lssrc output: 3 possible# output formats# 1. Subsystem Status# 2. Subsystem Group Status# 3. Subsystem Group PID Status

foreach $line (@lines)$line =˜ s/ˆs+|s+$//g;@lineElem = split(/s+/, $line);$numLineElem = scalar(@lineElem);$match = $lineElem[0] eq $ARGV[0];if ($numLineElem == 4)

if ($match &&$lineElem[3] eq "active")

$foundActive = 1;elsif ($numLineElem == 3)

if ($match &&$lineElem[2] eq "inoperative")

$foundButNotActive = 1;elsif ($numLineElem == 2)

if ($match &&$lineElem[1] eq "inoperative")

$foundButNotActive = 1;

# Format output and dump to stdoutif (defined($foundActive))

&PDAFormatOutput(...);elsif (defined($foundButNotActive))

&PDAFormatOutput(...);else

&PDAFormatOutput(...);

Figure 9: A simple probe that checks if a system ser-vice is currently running.

The rule to determine NFS-related problems isshown in Figure 10 as a tree. The rule tree is traversedby information gathered from dispatching a series ofprobes. Some rules are intuitive – check for livenessof all NFS service daemons, e.g., nfsd, mountd, statd,and lockd, and check if these services are properly reg-istered with the portmapper. In Figure 9, we show anexample probe that checks if a system service hasbeen started and is currently running. As each probedoes something very specific, it can be quickly andeasily implemented and maintain. We used Perl to im-plement this probe, but probes can be written in anylanguage as long as their output format matches thepre-defined format. There are also other more esotericrules – statd should always start before mountd, or theexname option can only be used if the nfsroot option isspecified in /etc/exports. However, we have seen that amajority of problem tickets can be addressed by thesimpler checks, e.g., looking for a missing /etc/exportsfile, non-existent mount points, etc. Some probes areuseful to exercise periodically to help SAs maintain a



healthy NFS service (e.g., check for hung daemons orabnormal RPC activities). Some can be run whenchanges are made to configuration files to check forpotential problems caused by a recent change. Somecan even be triggered manually in response to client-reported problems.

The benefits of PDA’s automated problem deter-mination capability are best illustrated by consideringa specific problem scenario. Consider the problem of amisconfigured system that starts nfsd before portmap-per. The misconfigured system will not allow users toaccess remote NFS partitions and the resultant prob-lem ticket has a correspondingly vague problem de-scription. In the absence of PDA, the SA must manu-ally narrow down the problem cause, starting for ex-ample, by logging into the affected systems, checkingnetwork connectivity, verifying firewall rules, etc. tomake sure the NFS problem is not a side effect of an-other problem in the system. Having done that, the SAmay then check /etc/exports for possible permissionproblems, see if all the defined mount points exist andrun the ps command to confirm that all NFS-relatedservices are running. He or she might need to runmore diagnostic tools before finally discovering thatnfsd was not correctly registered with the portmapper.Using PDA however, this misconfiguration problemcan be discovered quickly by examining the results ofthe automated rule execution.

Potential

NFS Problem

Check NFS

Services

nfsd

Check NFS

Configuration

rpc.mountd

rpc.statd

rpc.lockd

-Check if running

-Check if registered with portmapper

-Check if accessible from portmapper

-Check registered versions

… … …

……

…

/etc/exports

-Check if file exists

-Check if export directories exist

-Check if permission is granted correctly

-Check for syntax errors

… … …

Check NIS if Configured

…

…

…

Check Portmapper

Check Kerberos

…

…

Related

Services

Figure 10: NFS problem determination rule tree.

Experience With Storage ProblemsWe were surprised that a large percentage (90%)

of the storage-related problem tickets we observedwere related to simple capacity issues, e.g., disk parti-tions used for storing temporary files or logs beingclose to or completely full, thus hampering normal op-erations in the system. Given the large volume of suchtickets, early detection and resolution of storage ca-pacity problems can potentially eliminate a large num-ber of tickets. In many environments, managementtools monitor filesystems and raise an alert if the

utilization crosses a specified threshold. This approachhas the disadvantage of potential false alarms if for ex-ample, a filesystem is normally highly utilized (e.g.,an application scratch area). In PDA, we use a low-overhead profiler that periodically samples disk usagefor each partition being monitored and have the profil-er raise an alert if a partition’s usage (within a time in-terval N) has an upward trend that is projected to becompletely filled within the next 24 hours. A 24-hourperiod is chosen to allow an SA enough time to con-firm a problem and take action. An example illustrat-ing how the profiler is able to find storage capacityproblems is shown in Figure 11. In this example, sim-ple linear regression is used for trending, which willdetect that in interval 3 this partition will be full with-in a day and raise an alert. More complex regressionmethods can be used to further suppress false alarms.

As an example similar to what we described inSection 2.4, consider the actual problem ticket withthis description: Ops received the following alert onhost:$<$hostname$>$ ‘‘Percent space used (/var/log)greater than 95% – currently 100%.’’. This problemticket was opened by the operations team after an alertwas raised by a monitoring tool. Even though theproblem may be easy to solve, by the time the SA re-ceives this ticket, the system may already be havingproblems for an extended time, disrupting its normaloperations. Using the profiler, such problems can beaccurately predicted and notifications can be providedto SAs earlier.

Experience with Application ProblemsApplication problems are the most frequently en-

countered category of problems (as shown in Figure4), and also the most varied due to the myriad applica-tions running in enterprise environments. Some appli-cation problems can be detected with periodic probessimilar to the way we diagnose NFS-related problems.These can check, for example, for the liveness of ap-plication processes, whether specific application ports



are open, or for the presence of certain applicationfiles. The extensibility of PDA can be leveraged tohandle other types of application problems, such asnewly discovered security vulnerabilities. A commu-nity of users can devise and distribute new probes andassociated rules to detect new vulnerabilities, whichcan shorten the system exposure time and save SAstime in evaluating whether their systems are affected.

One application for which we observed a signifi-cant number of problem tickets was the widely de-ployed mail server application, Sendmail. Traditional-ly, Sendmail configuration has been considered verycomplex and we expected the problems to be relatedprimarily to setup issues or misconfiguration. Howev-er, again, most of the problems were actually caused byrelatively simple issues – a congested mail queue, adead Sendmail process, a newly discovered securityvulnerability, etc. An example problem ticket related toSendmail had the following description: Ops receivedthe following alerts for <hostname> advising: ‘‘Totalmail queue is greater than 15000 – currently 56345.Sendmail server <hostname> is not responding toSMTP connection on port 25.’’. Using a periodic live-ness probe and a profiler (similar to the one for filesys-tems described above), the SA can be notified of apending problem well before a critical level is reached.In the current implementation, PDA incorporates rulesto check some Sendmail-related parameters, includingprocess liveness and mail queue length.

0

20

40

60

80

100

120

0Time

Dis

kU

sa

ge

(%)

Interval 0 Interval 1 Interval 2 Interval 3

Interval 0 Regression Line

Inte

rval 3

Regre

ssion

Line

24 hours

24 hours

Raise Alert

X

Figure 11: Using profiler to find storage capacityproblems. The time axis is not drawn to scale.

Related Work

Though in certain cases, problems can be solvedby fixing the underlying systems. However, a largequantity of problems addressed by SAs are not systembugs, instead, they are configuration problems, com-patibility issues, usage mistakes, etc. Much of the pri-or work on system problem determination has cen-tered on system monitoring. While monitoring isclearly important for PDA, it is not a primary focus ofour work. We designed PDA to be able to use data col-lected from any monitoring tool. Our analysis of theticket data helps us choosing which part of the system

should be monitored, but not how to implement moni-toring probes. Our focus is instead on creating rulesthat help in diagnosing a problem once the monitoringsystem detects an issue.

Recently, researchers have been building problemmonitoring and analysis tools using system events andsystem logs. Redstone, et al. [8] propose a vision of anautomated problem diagnosis system by observingsymptoms and matching them against problem database.Wo r k s such as PeerPressure [11], Strider [12], and others[7] [6] address misconfiguration problems in Windowssystems by building and identifying signatures of normaland abnormal Windows Registry entries. Magpie [2],FDR [10], and others [13, 3] improve system manage-ment by using fine-grained system event-tracing mecha-nisms and analysis. We have similar goals to theseworks but our approach is to bring more expert knowl-edge in diagnosing problems and allow for a dynamical-ly changing set of collected events.

While most problem determination systems havea fixed set of events to collect, few use online mea-surements as a basis for taking further actions. Rish, etal. [9] propose an approach called active probing fornetwork problem determination, and Banga [1] de-scribes a similar system on built for Network Appli-ance storage devices. Our system bears some resem-blance to these approaches but is more generalizedand has tighter link with observed problems, for exam-ple through IT problem tracking systems. In makingdecisions about what additional information needs tobe probed, we use expert knowledge and indicatorscollected from real tickets as opposed to using proba-bilistic inference.

Our rules are conceptually similar to procedures,however, they are fundamentally different. Our rulecombines knowledge and execution environment. Therule execution has intelligence to identify what is thenext step and to execute the right diagnostic probes.Moreover, it is important to catch the system statuswhen the problem just occurs. In current practice, SAsoften need to reproduce a problem but the environ-ment may have changed. So performing diagnosisright after the problem occurs not only saves time, butalso could be the only way to catch the root cause.

Discussion and Ongoing Work

In our design of PDA, we were able to use prob-lem ticket information as a guideline for the design ofproblem determination rules and associated probes.However, deriving rules from tickets still involvesmanual effort. We are investigating approaches tomake this process more automated, but the varyingquality of the free-text descriptions will be a continu-ing challenge. We are also investigating better modelsfor the structured data which can more precisely cap-ture problem signatures.

We use structured fields such as ticket type andcause code to categorize problem tickets and pick the



common problems as described in Section CommonOS problems. Qualitatively speaking, our rules areable to address these common problems, but a morequantitative notion of ‘‘problem coverage’’ is re-quired. One approach we plan to pursue to this end isto extract distinguishing attributes of a small set oftickets in the categories that are covered by our rules.The attributes can include a combination of structuredfields as well as keywords from the unstructured text.Using these distinguishing attributes, we can examinea much larger set of tickets and looks for matchingtickets automatically to calculate the fraction of ticketsthat we expect to be similarly covered by the problemdetermination rules.

Although our experience with PDA shows prom-ise that it can reduce time or effort for diagnosingproblems, a more comprehensive study is needed togain a sense of how much time or effort can be saved.We are making PDA available to system administra-tors who support a variety of customer environmentsin order to collect additional experiences, and ideallysome quantitative data on the savings. We also expectto further validate and expand our problem determina-tion rules through usage by SAs. Since there is no ef-fective way to document problem resolution experi-ence, our rule and authoring mechanism are good can-didate for such a purpose.

Summary

This paper describes the Problem DeterminationAdvisor, a tool for automating the problem determina-tion process. Based on a study of problem tickets froma large enterprise IT support organization, we identi-fied commonly occurring server problems and devel-oped a set of problem determination rules to aid intheir diagnosis. We implement these rules in the PDAtool using a two-level approach in which high-levelsystem health monitors trigger lower-level diagnosticprobes to collect relevant details when a problem isdetected. We demonstrated the effectiveness of PDAin problem diagnosis using a number of actual prob-lem scenarios.

Acknowledgments

We are grateful to our anonymous reviewers fortheir thoughtful and valuable feedback. We also wantto thank our shepherd, Chad Verbowski, for his collab-oration in improving the paper.

Author Biographies

Hai Huang is a Research Staff Member at IBMT. J. Watson Research Center. He worked on numer-ous power-management projects in the past, and hiscurrent interest is in system and application manage-ment and how to make the process more autonomous.He received his Ph.D. degree in Computer Scienceand Engineering from the University of Michigan. Hecan be reached at [email protected] .

Raymond B. Jennings, III is an advisory engineerat the IBM T. J. Watson Research Center, YorktownHeights, New York. He works in the area of networksystem software and enterprise networking. He re-ceived his BS in Electrical Engineering from WesternNew England College and his MS in Computer Engi-neering from Manhattan College. He may be reachedat [email protected] .

Yaoping Ruan is a Research Staff Member atIBM T. J. Watson Research Center. His research inter-ests include system management, performance analy-sis and optimization, and server applications. He re-ceived his Ph.D. degree in Computer Science fromPrinceton University. He can be reached at yaoping.ru-an@us. ibm.com .

Ramendra Sahoo belongs to Systems and Net-work Services Group at IBM T. J. Watson ResearchCenter. His research interests include business processmanagement, distributed and fault-tolerant computing,numerical and parallel algorithms and data mining. Heearned his B.E. (honors) from the National Institute ofTechnology, Durgapur, M.S. and Ph.D. from IndianInstitute of Technology, Chennai and State Universityof New York at Stony Brook respectively. He can bereached at [email protected] .

Sambit Sahu is a Research Staff Member at IBMT. J. Watson Research Center. His interests includenetwork and system management, performance analy-sis, network measurement, and Internet services. Heearned his Ph.D. in Computer Science from the Univer-sity of Massachusetts. He may be reached at [email protected] .

Anees Shaikh manages the Systems and NetworkServices group at the IBM TJ Watson Research Cen-ter. His interests are in network and systems manage-ment, Internet services, and network measurement. Heearned B.S. and M.S. degrees in Electrical Engineer-ing from the University of Virginia, and a Ph.D. inComputer Science and Engineering from the Universi-ty of Michigan. He may be reached at [email protected] .

Bibliography

[1] Banga, Gaurav, ‘‘Auto-Diagnosis of Field Prob-lems in an Appliance Operating System,’’ UsenixAnnual Technical Conference, 2000.

[2] Barham, Paul, Austin Donnelly, Rebecca Isaacsand Richard Mortier, ‘‘Using magpie For RequestExtraction and Workload Modelling,’’ Proceed-ings of the 6th USENIX Symposium on OperatingSystems Design and Implementation, San Francis-co, CA, Dec. 2004.

[3] Cohen, Ira, et al., ‘‘Capturing, Indexing, Cluster-ing, and Retrieving System History,’’ Symposiumon Operating Systems Principles, 2005.

[4] Rudd, Colin, ‘‘An Introductory Overview of ITIL,’’IT Service Management Forum, April, 2004, http://www.itsmfusa.org .



[5] Ganapathi, Archana, Viji Ganapathi, and DavidPatterson, ‘‘Windows XP Kernel Crash Analy-sis,’’ 20th Large Installation System Administra-tion Conference, 2006.

[6] Ganapathi, Archana, Yi-Min Wang, Ni Lao, andJi-Rong Wen, ‘‘Why PCs Are Fragile and WhatWe Can Do About It: A Study Of Windows Reg-istry Problems,’’ International Conference on De-pendable Systems and Networks, 2004.

[7] Lao, Ni, et al., ‘‘Combining High Level SymptomDescriptions and Low Level State Information ForConfiguration Fault Diagnosis,´’ 19th Large In-stallation System Administration Conference (LISA’04), Atlanta, GA, Nov., 2004.

[8] Redstone, Joshua, Michael M. Swift and Brian N.Bershad, ‘‘Using Computers to Diagnose Com-puter Problems,’’ 9th Workshop on Hot Topics inOperating Systems (HotOS IX), Lihue, HI, May2004.

[9] Rish, Irina, et al., ‘‘Real-Time Problem Determi-nation in Distributed Systems Using Active Prob-ing,’’ IEEE/IFIP Network Operations and Man-agement Symposium, pp. 133-146, Seoul, Korea,April 2004.

[10] Verbowski, Chad, et al., ‘‘Flight Data Recorder:Monitoring Persistent-state interactions To Im-prove Systems Management,’’ Proceedings of the7th USENIX Symposium on Operating SystemsDesign and Implementation, Seattle, WA, Nov.,2006.

[11] Wang, Helen, et al., ‘‘Automatic Misconfigura-tion Troubleshooting With Peerpressure,’’ Pro-ceedings of the 6th USENIX Symposium on Oper-ating Systems Design and Implementation, SanFrancisco, CA, Dec., 2004.

[12] Wang, Yi-Min, et al., ‘‘Strider: A Black-Box,State-Based Approach to Change and Configura-tion Management and Support,’’ 17th Large Instal-lation System Administration Conference, 2003.

[13] Yuan, Chun, et al., ‘‘Automated Known ProblemDiagnosis with Event Traces,’’ EuroSys, 2006.


PDA: A Tool for Automated Problem Determination - … · 21st Large Installation System...

Documents

Transcript of PDA: A Tool for Automated Problem Determination - … · 21st Large Installation System...