Project Final Report

Ron BuelerCS-7013 May 2001

System Monitoring Alarming Reporting & Tracking System

(SMARTS)

Ron Bueler, CS-701 UCCS2

Overview

Introduction Project summary Project evaluation Conclusion

Ron Bueler, CS-701 UCCS3

Introduction

Problem– Monitor a set of hosts & alarm on problems– Store performance data– Report on data collected

Solution– System Monitoring Alarming Reporting & Tracking

System (SMARTS)

Ron Bueler, CS-701 UCCS4

Project Summary

Design Goals Schedule Project Management Project Phases

Ron Bueler, CS-701 UCCS5

Design Goals

Flexibility Clonable components Standards based Non-proprietary solution Low system utilization Reliable data collection Heavily COTS based Role-based output

Ron Bueler, CS-701 UCCS6

Schedule

Ron Bueler, CS-701 UCCS7

Project Management

Web Page– Status– Schedule– Design– Provides

access to all project docs

Ron Bueler, CS-701 UCCS8

Development Approach

Ron Bueler, CS-701 UCCS9

Phases - Proposal/Initial Analysis

Hardware/software environment Collect

– System CPU, disk space, and memory utilization– Response time for each service– Number of concurrent connections for each service– Service availability times– Application specific data for each service– Alarm notification and escalation– Automatic response triggers

Comparison of similar systems

Ron Bueler, CS-701 UCCS10

Phases - Requirements

Narrative in nature High-level Alarm reporting Near real-time queries Standardized reports Management reports Non-functional Interfaces

Ron Bueler, CS-701 UCCS11

Phases - DesignCollector ProgramStep 1

Step 2

Step 4

Step 5

Transport Program

Stored Procedures

Report Generation Email/Web File

Collector Output File

Step 3 Database Loader

SMART Host

OracleTables

ProcessedTables

Collector Config File

Ron Bueler, CS-701 UCCS12

Design – Database Architecture

Message_Store

PK DTGPK,FK1,I1 Host

ConnectionsIn_MsgsOut_MsgsIn_MBsOut_MBs

Directory

PK DTGPK,FK1,I1 Host

ConnectionsAddsLookupsChangesDeletes

Alarms

PK DTGPK,FK1,I1 HostPK ClassPK Variable

OpThresholdAction

Systems

PK Host

SerialNumberPOCAddressCityStateZip

Networks

PK DTGPK,FK1,I1 HostPK Card

In_KBOut_KBBW%10

Disks

PK DTGPK,FK1,I1 HostPK Domain

TotalFreeUsed

Calendar

PK DTGPK,FK1,I1 Host

ConnectionsIn_MsgsOut_MsgsIn_MBsOut_MBs

Processes

PK DTGPK,FK1,I2 HostPK,I1 NamePK PID

CPU_Percentage

Instant_Messaging

PK DTGPK,FK1,I1 Host

ConnectionsIn_MsgsOut_MsgsIn_MBsOut_MBs

HW_Config

PK DTGPK,FK1,I1 Host

OS_VersionCPUsMemoryDisks

Relays

PK DTGPK,FK1,I1 Host

In_MsgsOut_MsgsIn_MBsOut_MBs

Memory

PK DTGPK,FK1,I1 Host

FreeSwapActiveInactiveWire

CPUs

PK DTGPK,FK1,I1 Host

UsersSystemIdleUtil

Responses

PK DTGPK,FK1,I1 HostPK Server

PortServiceResponse

Ron Bueler, CS-701 UCCS13

Phases – Implementation

CGI Build/configure

– Web server– Perl Graphics Device (GD) module– Perl DBI

Development environment– Perl 5.6– Compaq Unix Tru64– Oracle 8.1 RDBMS

Ron Bueler, CS-701 UCCS14

Phases - Implementation

CGI

End User's Browser

Direct ChartGeneration

CGI

Compaq Alpha Server

Oracle Tables

HTMLServer

OracleWebDB

Collectors RunningOn Network Hosts

Ron Bueler, CS-701 UCCS15

Phases - Implementation

Web Based Reports– Generated using Perl GD and PNG modules

Email Based Reports– Generated Daily and Monthly– By Subscription Only

Ron Bueler, CS-701 UCCS16

Phases - Test

I – inspection, D – demo, A – analysis, P – pass, F – fail, NI – not implementedH –high priority, M – medium priority, L – low priority

• SMARTS reporting was rated MARGINAL

Requirement Priority Test Method

Result

3.1 Alarm reporting      

3.1.1 SMARTS shall produce a report for alarming conditions. H D  

3.1.2 The alarming report shall contain a brief message describing the trigger with a unique date-time-group field name.

H D, A  

3.1.3 The alarming report shall contain the data triggering value. H D, A  

3.1.4 The alarming report shall contain the system hostname affected by the alarm condition.

H I  

3.1.5 The alarming report shall contain the service affected by the alarm condition.

M I  

3.1.6 The alarming report shall be sent via email to targeted end-users. H D  

Ron Bueler, CS-701 UCCS17

Project Evaluation

Findings Challenges Usefulness Future

Ron Bueler, CS-701 UCCS18

Project Evaluation - Findings

Schedule estimation difficult Conduct more risk analysis Perform more analysis on COTS Good initial proposal/analysis Watch out for “ripple effect” of design mods Schedule flexibility paramount to success

Ron Bueler, CS-701 UCCS19

Project Evaluation - Challenges

Developer dependencies Synchronization of schedules Off-the-shelf component limitations Perl coding skills Installation & configuration

– Oracle 8.1 DB server– Netscape Enterprise Web Server– Seagate Crystal Reports

Ron Bueler, CS-701 UCCS20

Project Evaluation – Usefullness

Met basic requirements Solves most design goals Basic functions currently in use Strength of non-proprietary solutions

Ron Bueler, CS-701 UCCS21

Project Evaluation – Future

Complete remaining requirements Deploy over more hosts Trend data store Implement userID/password protection Develop stored Oracle procedures to archive

SMARTS data

Ron Bueler, CS-701 UCCS22

Conclusion

Introduction Project summary Project evaluation

“Developed an alternative set of applications to monitor a set of hosts using software systems engineering practices and concepts learned during my Graduate Program at UCCS.”