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.”