Klein
c1184eee91
Frontend-first status board with mock data for 16 vendors. Caddy configured on port 8443 with internal TLS, coexisting with an existing Caddy instance (admin on 2020, no HTTP redirects). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
78 lines
3.7 KiB
Markdown
78 lines
3.7 KiB
Markdown
# Infrastructure Monitoring Dashboard
|
|
|
|
## Project Overview
|
|
|
|
A web-based status feed aggregator for a K-12 school district IT department. Provides a single-pane-of-glass view of vendor service health, replacing the need to manually check multiple status pages during incidents.
|
|
|
|
## Target Vendors
|
|
|
|
| Vendor | Type | Status Source |
|
|
|---|---|---|
|
|
| Microsoft 365 | Productivity suite | Service Communications API (Graph API) |
|
|
| SpamTitan | Email security | TBD — likely status page scrape or synthetic check |
|
|
| PowerSchool | Student Information System | TBD — status page scrape |
|
|
| Classlink | SSO / Identity | TBD — status page or API |
|
|
| Apple | Device ecosystem | Apple System Status page (JSON feed) |
|
|
| DRC | Assessment / Testing | TBD — status page scrape |
|
|
| FinalSite | School website CMS | TBD — status page scrape or synthetic check |
|
|
| Google Workspace | Productivity suite | Google Workspace Status Dashboard (JSON feed) |
|
|
| Follett | Library management | TBD — status page scrape or synthetic check |
|
|
| EdInsight | Data analytics (Harris Education Solutions) | TBD — status page or synthetic check |
|
|
| Raptor | Visitor management | TBD — status page scrape |
|
|
| SchoolMessenger | Communication platform | TBD — status page scrape |
|
|
| McGraw Hill | Curriculum / assessment | status.mcgrawhill.com (JS-rendered status page) |
|
|
| Fortinet | Network security | TBD — FortiCloud API or status page |
|
|
| Local Infrastructure | On-prem hardware | Direct monitoring (SNMP, API, or synthetic checks) |
|
|
|
|
Note: Exchange Online is intentionally excluded — it is a component of M365 Service Health and would be redundant.
|
|
|
|
New vendors should be added incrementally, not speculatively.
|
|
|
|
## Hosting
|
|
|
|
- **Web server**: Caddy
|
|
- **URL**: https://status.nhsd.net:8443 (port 8443 to avoid conflict with existing Caddy instance on this machine)
|
|
- **Access**: Local network only (DNS A record points to the host machine)
|
|
- **TLS**: Caddy internal TLS (self-signed). IT staff only — browser cert warnings are acceptable.
|
|
|
|
## Architecture
|
|
|
|
- **Frontend**: HTML/CSS/JS dashboard — lightweight, no heavy framework. Designed to work on a wall-mounted monitor or quick browser check.
|
|
- **Backend**: Node.js service that polls vendor status on a schedule and caches results.
|
|
- **Web server**: Caddy reverse-proxies to the backend API and serves the static frontend.
|
|
- **Services**: NSSM runs both Caddy and the Node backend as Windows services.
|
|
- **Data flow**: Backend polls vendors → caches to local store → frontend fetches from backend API → auto-refreshes on interval.
|
|
|
|
## Directory Structure
|
|
|
|
```
|
|
infrastructure-monitoring-dashboard/
|
|
├── CLAUDE.md
|
|
├── .gitignore
|
|
├── bin/
|
|
│ ├── caddy/ # Drop caddy.exe here (git-ignored)
|
|
│ └── nssm/ # Drop nssm.exe here (git-ignored)
|
|
├── config/
|
|
│ └── Caddyfile # Caddy server configuration
|
|
├── frontend/
|
|
│ ├── index.html
|
|
│ ├── css/
|
|
│ └── js/
|
|
├── backend/
|
|
│ ├── package.json
|
|
│ ├── server.js
|
|
│ └── providers/ # One module per vendor
|
|
└── scripts/ # NSSM service install/uninstall helpers
|
|
```
|
|
|
|
## Development Approach
|
|
|
|
Frontend-first with mock data. Build the dashboard UI and layout with realistic fake data, then replace mocks with real vendor integrations one at a time.
|
|
|
|
## Design Principles
|
|
|
|
- Keep it simple. This is a status board, not a monitoring platform.
|
|
- Degrade gracefully — if a vendor check fails, show "unknown" rather than crashing.
|
|
- Each vendor integration should be a self-contained module so they can be added/removed independently.
|
|
- Optimize for glanceability — status should be obvious from across the room (color-coded, large indicators).
|