feat: server monitoring metrics - #77
Conversation
- Create modular Caddy configuration with conf.d/sites/ directory - Add localhost-only monitoring endpoints (PHP-FPM status) - Enable PHP-FPM status page in pool configuration - Update demo-site to use new modular config structure - Improve code organization with better section headers
- Query Caddy admin API for version, uptime, requests, memory - Query PHP-FPM status endpoint for pool stats and performance metrics - Extract metrics using curl and text parsing (no jq dependency) - Output metrics in YAML format for server info command
- Display Caddy metrics: version, uptime, requests, memory - Display PHP-FPM metrics: pool, processes, queue, performance indicators - Add formatUptime helper for human-readable uptime display - Highlight warnings for queue backlog and performance issues
WalkthroughAdds server monitoring display for Caddy and PHP‑FPM in the PHP trait, introduces Caddy/PHP‑FPM metrics collection and YAML exposure, restructures demo-site provisioning with a dedicated Caddy site config, and significantly expands the server-install playbook with repository, package, Caddy/Bun, and deploy-user/key setup. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant SI as server-info.sh
participant C as Caddy
participant P as PHP-FPM
participant Y as DEPLOYER_OUTPUT_FILE (YAML)
SI->>C: get_caddy_metrics() (metrics endpoint / status)
C-->>SI: tab-separated metrics (version, uptime, requests, memory, sites, domains)
SI->>P: get_php_fpm_metrics() (status socket/http)
P-->>SI: tab-separated metrics (pool, uptime, accepted, queues, processes, slow)
SI->>Y: parse & write `caddy` and `php_fpm` fields
note over SI,Y: New YAML sections expose collected metrics
sequenceDiagram
autonumber
participant INSTALL as server-install.sh
participant PKG as apt/dpkg
participant REPO as repo servers
participant CADDY as Caddy setup
participant USER as deployer user & keys
INSTALL->>PKG: wait_for_dpkg_lock() / apt_get_with_retry()
INSTALL->>REPO: setup_repositories() (Caddy, PHP)
INSTALL->>PKG: install_all_packages() (PHP 8.4, PHP-FPM, Caddy deps)
INSTALL->>CADDY: setup_caddy_structure() (dirs, Caddyfile, status)
INSTALL->>USER: ensure_deployer_user(), setup_deploy_user(), setup_deploy_key()
INSTALL->>PKG: enable/start services (php-fpm, caddy)
note right of INSTALL: Tasks recorded in output YAML
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Key attention areas:
Possibly related PRs
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🔇 Additional comments (2)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
playbooks/demo-site.sh (1)
132-194: Hardcoded PHP version creates maintenance burden.Line 136 hardcodes the PHP-FPM socket path as
/run/php/php8.4-fpm.sock, tying the demo site to PHP 8.4 specifically. This same hardcoded version appears inplaybooks/server-install.shat line 372.If the PHP version changes (e.g., to 8.5), multiple files need updates.
Consider extracting the PHP version to a shared configuration or detecting it dynamically:
- local php_fpm_socket='/run/php/php8.4-fpm.sock' + # Detect installed PHP-FPM version + local php_version=$(php -r "echo PHP_MAJOR_VERSION.'.'.PHP_MINOR_VERSION;" 2>/dev/null || echo "8.4") + local php_fpm_socket="/run/php/php${php_version}-fpm.sock"playbooks/server-install.sh (1)
256-310: Hardcoded PHP 8.4 version throughout installation.Lines 258-293 install PHP 8.4 packages with hardcoded version numbers. This same hardcoded version also appears at:
- Line 372 in localhost.caddy socket path
- Line 438 in PHP-FPM restart logic
- And in
playbooks/demo-site.shline 136When upgrading to PHP 8.5 or later, all these locations require updates.
Consider parameterizing the PHP version or detecting it dynamically to reduce maintenance burden across multiple files.
app/Traits/ServersTrait.php (1)
291-314: Consider inlining single-use method.The
formatUptime()method is called only once (line 180), which conflicts with the coding guideline: "Eliminate single-use methods: inline if a method is called only once."As per coding guidelines, consider inlining the uptime formatting logic directly at line 180:
if (isset($info['caddy']['uptime_seconds'])) { /** @var int|string|float $rawUptime */ $rawUptime = $info['caddy']['uptime_seconds']; /** @var int $uptimeSeconds */ $uptimeSeconds = (int) $rawUptime; - $caddyItems[] = 'Uptime: '.$this->formatUptime($uptimeSeconds); + $uptime = match (true) { + $uptimeSeconds < 60 => "{$uptimeSeconds}s", + $uptimeSeconds < 3600 => floor($uptimeSeconds / 60) . 'm', + $uptimeSeconds < 86400 => floor($uptimeSeconds / 3600) . 'h ' . floor(($uptimeSeconds % 3600) / 60) . 'm', + default => floor($uptimeSeconds / 86400) . 'd ' . floor(($uptimeSeconds % 86400) / 3600) . 'h', + }; + $caddyItems[] = 'Uptime: ' . $uptime; }And remove the
formatUptime()method at lines 288-314.Based on coding guidelines.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
app/Traits/ServersTrait.php(1 hunks)playbooks/demo-site.sh(9 hunks)playbooks/server-info.sh(9 hunks)playbooks/server-install.sh(15 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.php
📄 CodeRabbit inference engine (.cursor/rules/00-main.mdc)
**/*.php: Eliminate single-use methods: inline if a method is called only once
Cache computed values: initialize expensive calculations in the constructor
Avoid method call overhead: prefer direct property access when appropriate
Files:
app/Traits/ServersTrait.php
🧬 Code graph analysis (3)
playbooks/demo-site.sh (1)
playbooks/server-install.sh (1)
run_cmd(49-55)
app/Traits/ServersTrait.php (1)
app/Services/IOService.php (2)
displayDeets(543-566)writeln(463-469)
playbooks/server-install.sh (1)
playbooks/demo-site.sh (1)
run_cmd(37-43)
🔇 Additional comments (8)
playbooks/server-info.sh (2)
281-328: LGTM: Simple and robust JSON parsing.The PHP-FPM metrics collection uses straightforward grep/sed patterns for JSON field extraction. The approach is appropriate given the simple field structure, and all fields have sensible fallback defaults.
350-369: LGTM: Clean metrics integration.The main execution properly integrates the new metrics functions with availability flags and fallback handling, ensuring consistent YAML output structure regardless of whether services are available.
playbooks/demo-site.sh (1)
56-66: LGTM: Robust prerequisite validation.The enhanced validation properly checks for both the deployer user and home directory existence, with clear error messages directing users to run server:install first.
playbooks/server-install.sh (4)
64-135: LGTM: Robust package manager lock handling.The lock detection and retry logic properly handles concurrent package manager operations with exponential backoff. The implementation checks multiple lock files and differentiates between lock-related errors (retryable) and other failures (fatal).
292-296: LGTM: Status page enablement supports monitoring.Enabling the PHP-FPM status page at
/fpm-statusis necessary for the metrics collection implemented inplaybooks/server-info.sh. The configuration correctly enables this endpoint for localhost-only access.
337-384: LGTM: Comprehensive Caddy configuration structure.The setup creates a clean configuration hierarchy with:
- Global settings for metrics and logging
- Localhost-only monitoring endpoints
- Dedicated sites directory for per-site configs
This structure properly supports the monitoring features and isolates internal endpoints from external access.
492-545: LGTM: Deploy key generation without passphrase.Generating an SSH deploy key without a passphrase (line 517 with
-N "") is appropriate for automated deployments. The key permissions are properly secured (600 for private, 644 for public).app/Traits/ServersTrait.php (1)
165-285: LGTM: Defensive metrics display with proper guards.The Caddy and PHP-FPM display blocks properly guard all data access with existence checks and type casts. The colored formatting for warnings (yellow) on queue depth, max children reached, and slow requests provides good visual feedback.
Replace configuration-dependent handler="vars" filter with sum across all handlers for caddy_http_requests_total metric. This makes the playbook robust across different Caddy configurations without assuming specific handler names exist.
1 participant
Summary by CodeRabbit
New Features
Improvements