Master Server Management Principles
Server management principles for production ops: process management, monitoring, logging, scaling, and health checks.
Maintainer of this project? Claim this page to edit the listing.
13.1.0Add to Favorites
Why it matters
Learn essential principles for robust production server management, focusing on process control, monitoring, logging, scaling, health checks, and security to ensure stable and efficient operations.
Outcomes
What it gets done
Implement effective process management with tools like PM2 and systemd.
Establish comprehensive monitoring and alerting strategies.
Configure structured logging and log rotation.
Understand scaling decisions and security best practices.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-server-management | bash Overview
Server Management
Teaches server management principles for production ops: process management, monitoring, logging, scaling, and health checks. Use when choosing process management or monitoring tools, deciding how to scale, or troubleshooting a server issue.
What it does
Teaches server management principles for production operations - focused on reasoning through decisions rather than memorizing specific commands - covering process management, monitoring, logging, scaling, health checks, security, and troubleshooting.
When to use - and when NOT to
Use this skill when choosing a process manager for a production app, deciding what to monitor and how to set alert severity, designing a log rotation and structuring strategy, deciding whether to scale vertically or horizontally, or troubleshooting a server issue systematically. Not a fit for tasks unrelated to production server operations.
Inputs and outputs
Process management maps scenarios to tools (PM2 for Node.js clustering and reload, systemd as the Linux-native option, Docker/Podman for containers, Kubernetes/Docker Swarm for orchestration) against four goals: restart on crash, zero-downtime reload, clustering across CPU cores, and persistence across reboots. Monitoring covers four categories (availability, performance, errors, resources) with a three-tier alert severity strategy (Critical: immediate action, Warning: investigate soon, Info: review daily) and tool options from PM2 metrics/htop up to Grafana/Datadog, Sentry for error tracking, and UptimeRobot/Pingdom for uptime.
Log management principles require rotating logs to prevent disk fill, structured JSON logging for parseability, appropriate severity levels, and never logging sensitive data. Scaling decisions map symptoms to solutions (high CPU to horizontal scaling, high memory to more RAM or a leak fix, slow response to profiling before scaling, traffic spikes to auto-scaling) and choose between vertical (quick fix, single instance), horizontal (sustainable, distributed), and auto-scaling (variable traffic) strategies. Health checks define what "healthy" means (HTTP 200, database connected, dependencies reachable, resources not exhausted) and choose between a simple 200-only check or a deep dependency check based on load balancer needs.
Security principles cover SSH-key-only access, minimal firewall exposure, regular patching, environment-variable secrets instead of files, and access/change auditing. A five-step troubleshooting priority runs: check if the process is running, check logs, check resources, check network, then check dependencies. Anti-patterns to avoid include running as root, ignoring logs, skipping monitoring, manual restarts instead of auto-restart config, and having no backup schedule.
Integrations
References PM2, systemd, Docker/Podman, and Kubernetes/Docker Swarm for process management; Grafana, Datadog, Sentry, UptimeRobot, and Pingdom for monitoring and error tracking.
Who it's for
Engineers and ops teams managing production servers who need a decision framework for tool selection and troubleshooting priority rather than a fixed command cheat sheet - the goal being, in the source's own words, "a well-managed server is boring."
Troubleshooting priority: process status -> logs -> resources -> network -> dependencies
Source README
Server Management
Server management principles for production operations.
Learn to THINK, not memorize commands.
1. Process Management Principles
Tool Selection
| Scenario | Tool |
|---|---|
| Node.js app | PM2 (clustering, reload) |
| Any app | systemd (Linux native) |
| Containers | Docker/Podman |
| Orchestration | Kubernetes, Docker Swarm |
Process Management Goals
| Goal | What It Means |
|---|---|
| Restart on crash | Auto-recovery |
| Zero-downtime reload | No service interruption |
| Clustering | Use all CPU cores |
| Persistence | Survive server reboot |
2. Monitoring Principles
What to Monitor
| Category | Key Metrics |
|---|---|
| Availability | Uptime, health checks |
| Performance | Response time, throughput |
| Errors | Error rate, types |
| Resources | CPU, memory, disk |
Alert Severity Strategy
| Level | Response |
|---|---|
| Critical | Immediate action |
| Warning | Investigate soon |
| Info | Review daily |
Monitoring Tool Selection
| Need | Options |
|---|---|
| Simple/Free | PM2 metrics, htop |
| Full observability | Grafana, Datadog |
| Error tracking | Sentry |
| Uptime | UptimeRobot, Pingdom |
3. Log Management Principles
Log Strategy
| Log Type | Purpose |
|---|---|
| Application logs | Debug, audit |
| Access logs | Traffic analysis |
| Error logs | Issue detection |
Log Principles
- Rotate logs to prevent disk fill
- Structured logging (JSON) for parsing
- Appropriate levels (error/warn/info/debug)
- No sensitive data in logs
4. Scaling Decisions
When to Scale
| Symptom | Solution |
|---|---|
| High CPU | Add instances (horizontal) |
| High memory | Increase RAM or fix leak |
| Slow response | Profile first, then scale |
| Traffic spikes | Auto-scaling |
Scaling Strategy
| Type | When to Use |
|---|---|
| Vertical | Quick fix, single instance |
| Horizontal | Sustainable, distributed |
| Auto | Variable traffic |
5. Health Check Principles
What Constitutes Healthy
| Check | Meaning |
|---|---|
| HTTP 200 | Service responding |
| Database connected | Data accessible |
| Dependencies OK | External services reachable |
| Resources OK | CPU/memory not exhausted |
Health Check Implementation
- Simple: Just return 200
- Deep: Check all dependencies
- Choose based on load balancer needs
6. Security Principles
| Area | Principle |
|---|---|
| Access | SSH keys only, no passwords |
| Firewall | Only needed ports open |
| Updates | Regular security patches |
| Secrets | Environment vars, not files |
| Audit | Log access and changes |
7. Troubleshooting Priority
When something's wrong:
- Check if running (process status)
- Check logs (error messages)
- Check resources (disk, memory, CPU)
- Check network (ports, DNS)
- Check dependencies (database, APIs)
8. Anti-Patterns
| ❌ Don't | ✅ Do |
|---|---|
| Run as root | Use non-root user |
| Ignore logs | Set up log rotation |
| Skip monitoring | Monitor from day one |
| Manual restarts | Auto-restart config |
| No backups | Regular backup schedule |
Remember: A well-managed server is boring. That's the goal.
When to Use
This skill is applicable to execute the workflow or actions described in the overview.
Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.