Xitoring Document

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:

  1. Log into Xitoring dashboard → Servers
  2. Click "Add Server" button (top-right)
  3. 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)
  4. 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:

  1. SSH into your server:

    ssh user@your-server-ip

  2. Run install command (from Step 1):

    curl -s https://download.xitogent.com/install-linux.sh | bash -s -- --key YOUR_UNIQUE_KEY --server-id 12345

  3. Wait for installation (~30-60 seconds):

    Installing Xitogent...
Downloading latest version...
Installing dependencies...
Starting Xitogent service...
✓ Xitogent installed successfully
✓ Service started
✓ Registration complete

  4. Verify agent running:

    sudo systemctl status xitogent

    Should show: Active: active (running)

Windows Installation:

  1. RDP into your Windows server
  2. Open install page in browser (link from Step 1)
  3. Download installer: xitogent-installer.exe
  4. Run installer as Administrator
  5. Follow install wizard:
    • Accept license
    • Installation automatically uses registration key from URL
    • Wait for installation completion
  6. Verify service running:
    Get-Service -Name Xitogent
    Should show: Status: 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:

  1. Return to Xitoring dashboard → Servers
  2. Find your server in list (should now show "Waiting for data" or data already arriving)
  3. Wait 2-5 minutes for first data batch

What you'll see:

TimelineExpected State
0-2 min after install"Waiting for data" (normal - agent collecting first batch)
2-5 minFirst metrics appear (CPU %, Memory %)
5-10 minGraphs start populating (10+ data points)
5-10 minAuto-Discovery scan completes
  1. Click on server name → Overview page
  2. 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:

  1. Server page → Open Server View
  2. Wait for scan completion (5-10 minutes after agent install)
  3. 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
  1. 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:

  1. From Server View, review detected services and recommendations
  2. 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
  1. Wait 5-10 minutes for integration metrics to populate
  2. 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:

  1. Server page → "Triggers" tab
  2. Review auto-created triggers (if Auto-Trigger enabled in Step 1):

Example auto-created triggers:

MetricThresholdFault ToleranceNotification Role
CPU Usage> 85%5 minutesDefault Role
Memory Usage> 90%5 minutesDefault Role
Disk Usage (/)> 85%10 minutesDefault Role
MySQL Connections> 1505 minutesDefault Role
Nginx Error Rate> 10 errors/min3 minutesDefault 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)
  1. 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:

  1. Dashboard → Notifications → Notification Roles

  2. Edit default role or create new role:

    • Click "Create Notification Role" or edit existing

  3. 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

  1. 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)

  2. Save notification role

  3. 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:

  1. Server → Triggers tab
  2. Select any trigger (e.g., "CPU Usage > 85%")
  3. Click "Test Trigger" button
  4. System simulates threshold violation
  5. 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:

  1. CPU usage spikes >85% (violates trigger threshold)
  2. Xitoring detects violation
  3. Waits for Fault Tolerance period (5 min)
  4. Creates incident if condition persists
  5. 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:

  1. Add more servers - Repeat this workflow for other servers
  2. Create uptime checks - Monitor external endpoints: Monitor an API Endpoint
  3. Set up escalation - Configure on-call rotation: Set Up Complete Alerting
  4. Build status page - Public service status: Status Pages
  5. 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:

  1. Verify agent status:

    # Linux
sudo systemctl status xitogent
sudo journalctl -u xitogent -n 50

# Windows
Get-Service -Name Xitogent

  2. Check agent logs:

    # Linux
sudo tail -100 /var/log/xitogent.log

# Windows
C:\ProgramData\Xitogent\logs\xitogent.log

  3. Test connectivity:

    curl -I https://api.xitoring.com
# Should return HTTP 200

  4. Restart 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:

  1. Increase threshold:

    • Edit trigger, change CPU >80% to >90%

  2. Increase Fault Tolerance:

    • Edit trigger, change FT from 5 min to 10 min

  3. Disable trigger if not useful:

    • Some metrics don't need alerts for your use case

  4. 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

Last Updated: