15.2 Project Design and Planning

15.1. 15.2 Project Design and Planning#

15.1.1. Project Overview: Server Monitoring and Alert System#

15.1.1.1. System Architecture#

Our capstone project is a Server Monitoring and Alert System consisting of:

  1. Data Collection Layer - Gather system metrics and logs

  2. Processing Layer - Parse, analyze, and correlate data

  3. Alerting Layer - Trigger alerts based on rules

  4. Storage Layer - Persist metrics and alerts

  5. Reporting Layer - Generate dashboards and reports

15.1.1.2. Core Components#

15.1.1.3. Requirements Analysis#

Functional Requirements:

  • Collect metrics from /proc, systemd, and network interfaces

  • Monitor both local files and remote syslog servers

  • Support threshold-based and pattern-based alerting

  • Generate real-time and historical reports

  • Support email notifications and webhook alerts

Non-Functional Requirements:

  • Minimal performance impact (< 2% CPU usage)

  • Scalable to 50+ monitored hosts

  • Reliable error handling and graceful degradation

  • Production-grade code quality and testability

  • Clear logging and audit trails

15.1.1.4. Technology Stack#

  • Bash 4.4+ for core scripting

  • awk for log parsing and data transformation

  • sed for text substitution and filtering

  • systemd timers for scheduling (alternative: cron)

  • SQLite for metric storage

  • curl for webhook notifications

  • mutt or mail for email alerts

  • systemd journal for centralized logging

15.1.1.5. Project Structure#

monitoring-system/
├── src/
│   ├── metrics-collector.sh
│   ├── log-aggregator.sh
│   ├── alert-engine.sh
│   ├── report-generator.sh
│   ├── config-manager.sh
│   └── health-check.sh
├── lib/
│   ├── logging.sh
│   ├── arrays.sh
│   ├── string-utils.sh
│   └── db-functions.sh
├── config/
│   ├── monitoring-system.conf
│   ├── alert-rules.conf
│   └── thresholds.conf
├── tests/
│   ├── test-metrics-collector.sh
│   ├── test-log-aggregator.sh
│   └── integration-tests.sh
├── docs/
│   ├── INSTALL.md
│   ├── CONFIGURATION.md
│   └── TROUBLESHOOTING.md
├── systemd/
│   ├── monitoring-collector.service
│   └── monitoring-collector.timer
└── .gitignore

15.1.2. Design Decisions#

15.1.2.1. Why Bash for This Project?#

  • Direct OS access - Easy system metric collection

  • Simple deployment - Single language, minimal dependencies

  • Process integration - Natural piping and command composition

  • Cron/systemd compatibility - Native scheduling support

  • Lightweight - Low resource overhead

  • Maintainability - Team of Linux admins knows Bash

15.1.2.2. Data Storage Strategy#

Metrics Database:

  • SQLite for lightweight relational storage

  • One table per metric type (cpu, memory, disk)

  • Time-series data with hourly aggregation

  • Retention: 90 days raw data, 2 years hourly rollups

Log Processing:

  • Avoid storing raw logs (too large)

  • Parse into structured events with timestamps

  • Index by severity, source, and pattern

  • Retention: 30 days for recent alerts

15.1.2.3. Alert Strategy#

Three Alert Types:

  1. Threshold alerts - CPU > 85%, Memory > 90%, Disk > 95%

  2. Pattern alerts - “Failed login”, “Error”, “Critical”

  3. Anomaly alerts - Deviation from baseline (future enhancement)

Alert Routing:

  • Critical: Email + Slack webhook + PagerDuty

  • Warning: Email only

  • Info: Log to syslog only

15.1.2.4. Configuration Management#

  • Single source of truth - All config in /etc/monitoring-system/

  • Environment-specific - dev, staging, production profiles

  • Validated on startup - Health check verifies all settings

  • Runtime reloadable - No daemon restart needed for config changes

15.1.3. Next Steps#

In the following sections, we’ll:

  1. Implement the core collection and processing scripts

  2. Build the alerting and reporting systems

  3. Create comprehensive tests

  4. Package for production deployment

15.1.4. Design Document Template#

Create a formal design document for your project:

# Design Document: [Project Name]

## 1. Overview
- Problem statement
- Solution approach
- Intended users/audience

## 2. Architecture
- System components diagram
- Data flow between components
- External dependencies and APIs

## 3. Data Model
- Data structures (arrays, databases)
- File formats and schemas
- Storage and retention policies

## 4. Components
### Component 1: [Name]
- Purpose
- Inputs and outputs
- Key algorithms or logic

### Component 2: [Name]
- [Details...]

## 5. Configuration
- Configuration file format
- Required vs. optional settings
- Environment-specific variations

## 6. Error Handling
- Expected failure modes
- Recovery strategies
- Logging requirements

## 7. Testing Strategy
- Unit tests to implement
- Integration test scenarios
- System test procedures

## 8. Deployment
- Installation steps
- Prerequisites
- Post-install validation

## 9. Future Enhancements
- Possible improvements
- Scalability considerations
- Technology upgrades

15.1.5. Iterative Development Process#

Plan your implementation in phases:

Phase 1: Foundation (Week 1)

  • Create directory structure

  • Initialize Git repository

  • Write installation script skeleton

  • Define configuration file format

  • Create library functions (logging, validation)

Phase 2: Core Implementation (Weeks 2-3)

  • Implement main scripts one at a time

  • Add configuration loading

  • Implement error handling

  • Create test fixtures and mock data

  • Write unit tests as you go

Phase 3: Integration (Week 4)

  • Test components working together

  • Implement data flow between components

  • Add logging and debugging support

  • Create integration tests

  • Performance tuning if needed

Phase 4: Polish (Week 5)

  • Complete documentation

  • Test error scenarios

  • Create installation/uninstallation scripts

  • Tag release version

  • Create distribution package

Phase 5: Reflection (Week 6)

  • Write reflection essay

  • Code review and cleanup

  • Final documentation pass

  • Package for submission

#!/bin/bash
# Example: Project planning checklist template

# Define your project scope
PROJECT_NAME="monitoring-system"
PROJECT_VERSION="1.0.0"
PROJECT_DESCRIPTION="Server monitoring with alerting and reporting"

# Core components
declare -a COMPONENTS=(
  "metrics-collector.sh"
  "log-aggregator.sh"
  "alert-engine.sh"
  "report-generator.sh"
  "health-check.sh"
)

# Dependencies to check
declare -a DEPENDENCIES=(
  "bash:4.4"
  "sqlite3"
  "awk"
  "curl"
)

# Define milestones
declare -a MILESTONES=(
  "Design: Architecture and data model"
  "Implement: Core data collection"
  "Implement: Processing and alerting"
  "Test: Unit and integration tests"
  "Document: Installation and usage"
  "Package: Create release artifacts"
)

# List components
echo "Project: $PROJECT_NAME v$PROJECT_VERSION"
echo "Components:"
for comp in "${COMPONENTS[@]}"; do
  echo "  - $comp"
done

echo
echo "Dependencies:"
for dep in "${DEPENDENCIES[@]}"; do
  echo "  - $dep"
done

echo
echo "Milestones:"
for ((i=0; i<${#MILESTONES[@]}; i++)); do
  echo "  $((i+1)). ${MILESTONES[$i]}"
done

  Cell In[1], line 10
    declare -a COMPONENTS=(
               ^
SyntaxError: invalid syntax

15.1.6. Capstone Project Scope and Requirements#

Your capstone project should be a real-world automation system combining multiple concepts from the course. The monitoring system outlined above is just one example—you can choose any project that interests you.

Essential Requirements for Any Project:

  1. Collect data from system or application

  2. Process and analyze that data

  3. Generate output (reports, alerts, metrics)

  4. Store state/history

  5. Include error handling and logging

  6. Have configuration management

  7. Include tests and documentation

  8. Use Git for version control

Technical Skills Required:

  • Bash scripting with functions and error handling

  • Array operations for data structure

  • Text processing with awk/sed

  • Process management and scheduling

  • File I/O and data persistence

  • Testing and debugging practices

  • Git workflow and documentation

Contents