Monitor Your First Server
This workflow guides you through complete server monitoring setup in 20-30 minutes. By the end, you'll have metrics flowing, integrations enabled, and alerts configured.
Prerequisites
- A Linux or Windows server (cloud VM, bare metal, or local machine)
- SSH/RDP access to that server
- Basic command-line familiarity
Overview: What You'll Accomplish
End state: ✅ Xitogent installed and sending metrics
✅ Dashboard showing CPU, memory, disk, network graphs
✅ Auto-Discovery detected running services (databases, web servers, etc.)
✅ Integrations enabled for detected services
✅ Triggers created with intelligent thresholds
✅ Notification role configured (email/Slack/SMS)
✅ Test alert sent and received
Total time: 20-30 minutes
Step 1: Add Server to Xitoring Dashboard
Goal: Register server in Xitoring before installing agent.
Actions:
- Log into Xitoring dashboard → Servers
- Click "Add Server" button (top-right)
- Configure server details:
- Server Name:
production-web-01(or descriptive name) - Notification Role: Select default role or create new one (we'll configure this later in Step 7)
- Operating System: Select your OS (Ubuntu, CentOS, Windows, etc.)
- Options:
- ✅ Auto-Discovery: Keep enabled (detects services, creates uptime checks, shows recommendations)
- ✅ Auto-Update: Keep enabled (Xitogent automatically updates itself)
- ✅ Auto-Trigger: Keep enabled (create recommended triggers automatically)
- Checks: Keep all enabled (auto-create uptime checks if protocols detected)
- Server Name:
- Click "Add Server"
Result: Install command appears on screen.
Example install command (Linux):
curl -s https://download.xitogent.com/install-linux.sh | bash -s -- --key YOUR_UNIQUE_KEY --server-id 12345
What this does:
- Downloads Xitogent installer
- Registers agent with your Xitoring account
- Starts sending metrics immediately after install
Step 2: Install Xitogent on Your Server
Goal: Install monitoring agent that collects and sends metrics.
Linux Installation:
SSH into your server:
ssh user@your-server-ipRun install command (from Step 1):
curl -s https://download.xitogent.com/install-linux.sh | bash -s -- --key YOUR_UNIQUE_KEY --server-id 12345Wait for installation (~30-60 seconds):
Installing Xitogent... Downloading latest version... Installing dependencies... Starting Xitogent service... ✓ Xitogent installed successfully ✓ Service started ✓ Registration completeVerify agent running:
sudo systemctl status xitogentShould show:
Active: active (running)
Windows Installation:
- RDP into your Windows server
- Open install page in browser (link from Step 1)
- Download installer:
xitogent-installer.exe - Run installer as Administrator
- Follow install wizard:
- Accept license
- Installation automatically uses registration key from URL
- Wait for installation completion
- Verify service running:Should show:
Get-Service -Name XitogentStatus: Running
Troubleshooting: If installation fails, see FAQ: Agent installation troubleshooting
Step 3: Verify Data Arriving
Goal: Confirm metrics flowing from server to Xitoring dashboard.
Actions:
- Return to Xitoring dashboard → Servers
- Find your server in list (should now show "Waiting for data" or data already arriving)
- Wait 2-5 minutes for first data batch
What you'll see:
| Timeline | Expected State |
|---|---|
| 0-2 min after install | "Waiting for data" (normal - agent collecting first batch) |
| 2-5 min | First metrics appear (CPU %, Memory %) |
| 5-10 min | Graphs start populating (10+ data points) |
| 5-10 min | Auto-Discovery scan completes |
- Click on server name → Overview page
- Verify metrics cards populated:
- ✅ CPU usage: Shows percentage
- ✅ Memory usage: Shows used/total
- ✅ Disk usage: Shows used/total for each partition
- ✅ Network: Shows in/out traffic
If no data after 10 minutes: See Troubleshooting: Debug Why No Data Appearing
Step 4: Review Auto-Discovery Results
Goal: See what services Xitogent found running on your server.
Actions:
- Server page → Open Server View
- Wait for scan completion (5-10 minutes after agent install)
- Review detected services and recommendations:
Example results:
Detected Services (Auto-Discovery):
✓ Nginx (Port 80, 443) - Web server detected
✓ MySQL (Port 3306) - Database detected
✓ Redis (Port 6379) - Cache detected
✓ Docker (Process: dockerd) - Container runtime detected
- Verify accuracy:
- Do these services actually run on your server?
- Missing an expected service? (May need manual integration enable)
- False positive? (Service binary installed but not running)
Note: If your server is fresh/minimal (no services installed), Auto-Discovery may find nothing—that's normal. You'll enable integrations after installing services later.
Step 5: Enable Discovered Integrations
Goal: Turn on deep monitoring for detected services.
Actions:
- From Server View, review detected services and recommendations
- For each service you want deep monitoring on:
- Click "Enable Integration" next to the service
- Integration activates immediately (no configuration needed for most)
- Status changes from "Available" → "Enabled"
Example: Enable MySQL integration:
- Click "Enable Integration" next to "MySQL (Port 3306)"
- Integration starts collecting:
- Connections, queries/sec, slow queries, table stats
Which integrations to enable:
- ✅ Enable: Services critical to your application (databases, web servers, queues)
- ⏸️ Skip: Test/dev services, obsolete software, false positives
- Wait 5-10 minutes for integration metrics to populate
- Verify integration data:
- Server page → "Integrations" tab
- Click on enabled integration (e.g., "MySQL")
- Should see integration-specific graphs (connections, query rate, etc.)
Manual integration setup (if Auto-Discovery missed something):
- Server page → Integrations → "Enable Integration"
- Select integration type from list
- Configure connection details if needed (host, port, credentials)
- See integration-specific documentation: All Integrations
Step 6: Review Auto-Created Triggers
Goal: Understand what alerts are already configured.
Actions:
- Server page → "Triggers" tab
- Review auto-created triggers (if Auto-Trigger enabled in Step 1):
Example auto-created triggers:
| Metric | Threshold | Fault Tolerance | Notification Role |
|---|---|---|---|
| CPU Usage | > 85% | 5 minutes | Default Role |
| Memory Usage | > 90% | 5 minutes | Default Role |
| Disk Usage (/) | > 85% | 10 minutes | Default Role |
| MySQL Connections | > 150 | 5 minutes | Default Role |
| Nginx Error Rate | > 10 errors/min | 3 minutes | Default Role |
Understanding triggers:
- Threshold: Value that triggers alert (e.g., CPU > 85%)
- Fault Tolerance: Buffer before alerting (waits 5 min to see if issue persists)
- Notification Role: Who gets alerted (we'll configure this next)
- Decide if triggers make sense:
- ✅ Thresholds reasonable? (85% CPU is good starting point)
- ✅ Fault Tolerance appropriate? (5 min is standard)
- ❌ Too sensitive? (Getting false positives? Increase threshold or FT)
Customizing triggers:
- Click "Edit" on any trigger
- Adjust threshold, FT, or notification role
- Save changes
Creating additional triggers:
- Click "Create Trigger" button
- Select metric to monitor
- Set condition (>, <, =)
- Set threshold value
- Configure FT and notification role
See FAQ: What are Triggers for detailed explanation.
Step 7: Configure Notification Role
Goal: Set up how and where you receive alerts.
Actions:
Dashboard → Notifications → Notification Roles
Edit default role or create new role:
- Click "Create Notification Role" or edit existing
Configure notification channels:
Email notifications:
- Add email address(es)
- Enable: "Send email when incident created"
- Enable: "Send email when incident resolved"
Slack notifications (optional but recommended):
- Click "Add Slack Integration"
- Authorize Xitoring in your Slack workspace
- Select channel (e.g.,
#alerts,#monitoring) - Configure message format
SMS notifications (for critical alerts):
- Add phone number
- Configure when to send SMS:
- ✅ Critical incidents only (avoid SMS spam/costs)
- ❌ All incidents (gets expensive fast)
Webhook (for advanced integrations):
- Add webhook URL (PagerDuty, OpsGenie, custom endpoint)
- Configure payload format
Configure notification schedule:
- 24/7 notifications: Leave schedule as "Always"
- Business hours only: Set schedule (Mon-Fri, 9 AM - 5 PM)
- Quiet hours: Disable notifications overnight (10 PM - 7 AM)
Save notification role
Assign role to triggers:
- Return to Server → Triggers tab
- Edit each trigger
- Change "Notification Role" to the role you just configured
- Save
Testing notification delivery: We'll do this in Step 8.
See Notification Roles documentation for advanced configuration.
Step 8: Test Alerting System
Goal: Verify you receive alerts when thresholds violated.
Option A: Manual Trigger Test (Safe)
Use builtin test functionality:
- Server → Triggers tab
- Select any trigger (e.g., "CPU Usage > 85%")
- Click "Test Trigger" button
- System simulates threshold violation
- Sends test alert to configured notification role
Check your notification channels:
- ✅ Email received?
- ✅ Slack message posted?
- ✅ SMS received (if configured)?
If no notification received: See FAQ: Why are my notifications NOT arriving?
Option B: Real Threshold Violation (Advanced)
Actually trigger an alert by violating threshold:
CPU spike test:
# Linux: stress CPU for 2 minutes
yes > /dev/null & # Starts CPU-intensive process
sleep 120
kill %1 # Stops after 2 minutes
# Windows: Run CPU stress
# Download CPU Stress tool or run:
Start-Process powershell -ArgumentList "while(1){}"
# Wait 2 minutes, then close the new PowerShell window
What should happen:
- CPU usage spikes >85% (violates trigger threshold)
- Xitoring detects violation
- Waits for Fault Tolerance period (5 min)
- Creates incident if condition persists
- Sends notifications to configured channels
Timeline:
- 0:00 - CPU spike starts
- 0:00-5:00 - Fault Tolerance waiting period (no alert yet)
- 5:00 - Alert sent (if CPU still >85%)
- Or if CPU returns to normal before 5 min: No alert (FT prevented false positive)
After test:
- Check Incidents page: New incident created?
- Check notification channels: Alert received?
- Resolve incident: Mark as "Resolved" once confirmed working
Step 9: Explore Dashboard & Next Steps
Goal: Familiarize yourself with monitoring dashboard.
Dashboard Tour:
Server Overview:
- CPU/Memory/Disk/Network real-time stats
- Quick status of all metrics
- Recent incidents
Graphs:
- Historical metric trends (last 1 hour, 6 hours, 24 hours, 7 days)
- Zoom, pan, export graphs
- Overlay multiple metrics
Integrations:
- Integration-specific metrics (MySQL queries, Nginx requests, etc.)
- Deep-dive into service performance
Incidents:
- All historical incidents
- Resolution time, root cause
- Incident timeline and annotations
Triggers:
- All configured alert rules
- Edit, disable, create new
- See trigger violation history
You're Done! What's Next?
Immediate Next Steps:
- Add more servers - Repeat this workflow for other servers
- Create uptime checks - Monitor external endpoints: Monitor an API Endpoint
- Set up escalation - Configure on-call rotation: Set Up Complete Alerting
- Build status page - Public service status: Status Pages
- Custom dashboards - Executive/team views: Custom Dashboards
Optimization & Tuning:
After 7 days of monitoring:
- Review incident history (any false positives?)
- Adjust trigger thresholds (too sensitive? too lenient?)
- Fine-tune Fault Tolerance values
- Add custom triggers for specific scenarios
- Enable additional integrations as you install new services
After 30 days:
- Analyze metric trends (capacity planning)
- Create monthly reports
- Invite team members
- Set up sub-accounts for different teams/clients
Troubleshooting Common Issues
Server Showing "Waiting for Data" After 10+ Minutes
Possible causes:
- Agent not running
- Network connectivity issue
- Firewall blocking outbound HTTPS
Solutions:
Verify agent status:
# Linux sudo systemctl status xitogent sudo journalctl -u xitogent -n 50 # Windows Get-Service -Name XitogentCheck agent logs:
# Linux sudo tail -100 /var/log/xitogent.log # Windows C:\ProgramData\Xitogent\logs\xitogent.logTest connectivity:
curl -I https://api.xitoring.com # Should return HTTP 200Restart agent:
# Linux sudo systemctl restart xitogent # Windows Restart-Service -Name Xitogent
See FAQ: Agent troubleshooting for detailed debugging.
Auto-Discovery Found Nothing
This is normal if:
- Server is minimal/fresh (no services installed yet)
- Services use non-standard ports
- Services running in containers (detection limited)
Solution:
- Install service (e.g.,
sudo apt install nginx) - Manually trigger re-scan: Server → Server View → Auto-Discovery → "Run Discovery Again"
- Or manually enable integration: Server → Integrations → Enable Integration → Select service
Not Receiving Test Alerts
Checklist:
- ✅ Notification role configured with email/Slack/SMS
- ✅ Notification role assigned to trigger
- ✅ Test trigger actually executed (check Incidents page for test incident)
- ✅ Check spam folder (email)
- ✅ Verify Slack channel permissions (bot can post)
- ✅ Correct phone number format for SMS (+1234567890)
See FAQ: Notification troubleshooting
Trigger Fired But Shouldn't Have (False Positive)
Common causes:
- Threshold too sensitive (CPU 80% might be normal for your workload)
- Fault Tolerance too short (brief spike triggered alert)
- Metric genuinely briefly violated threshold (expected behavior)
Solutions:
Increase threshold:
- Edit trigger, change CPU >80% to >90%
Increase Fault Tolerance:
- Edit trigger, change FT from 5 min to 10 min
Disable trigger if not useful:
- Some metrics don't need alerts for your use case
Wait for Auto-Trigger re-tuning:
- Over time, Auto-Triggers learns better baselines
- May auto-adjust recommendations
See FAQ: Reduce unnecessary notifications
Summary: What You Accomplished
✅ Server registered in Xitoring dashboard
✅ Xitogent installed and running
✅ Metrics flowing - CPU, memory, disk, network graphs populated
✅ Auto-Discovery completed - Found running services
✅ Integrations enabled - Deep monitoring for databases/web servers/etc.
✅ Triggers configured - Auto-created intelligent alert thresholds
✅ Notifications set up - Email/Slack/SMS configured
✅ Alerting tested - Verified notification delivery
You now have complete server monitoring operational! 🎉
Continue with additional workflows as your monitoring needs grow. Return to Workflows Hub for more guides.
See Also
- Getting Started Overview - High-level onboarding concepts
- Xitogent Installation - Detailed agent installation docs
- Auto-Discovery - How service detection works
- Auto-Triggers - Understanding intelligent thresholds
- Notification Roles - Advanced notification routing
- FAQ: Server Monitoring - Common questions
- All Integrations - Deep-dive into integration setup