Servers

Support Guide: Adding a New Server

Adding a new server is a straightforward process. This guide walks you through the steps to set up and monitor a server in your dashboard. Step-by-Step Instructions 1. Navigate to the Servers Page - From the dashboard, go to the Servers page, which lists all currently monitored servers. 2. Click on "Add Server" - At the top of the page, click the "New" or "Add Server" button to open the server configuration modal. 3. Fill Out the Add Server Form - Complete the fields in the modal: - Server Name: Enter a name that helps you identify the server (e.g., "Main Web Server"). - Ping Address: Provide an IP address or domain name for the server to ping. This address will be used to monitor connectivity from the server you are adding. - Process List: - Select one of the following options: - None: Do not include any processes. - Top Ten: The system automatically selects the top ten processes based on resource usage (e.g., CPU, disk, or memory utilization). - All: Includes all running processes. - Important: If you plan to set up alerts for monitoring whether a specific process is running, you must select All. 4. Save the Server - Once all fields are filled, click "Add" or "Save" to complete the setup. The server will now appear in the Servers table. Installing the Monitoring Agent 1. Open the Server Details - Click on the newly added server in the Servers table. This opens the server details page. 2. Run the Installation Commands - An Install Agent box will automatically pop up, displaying the commands you need to install the monitoring agent on your server. - Copy and paste one of the provided commands into your server’s terminal: - wget: For environments where wget is available. - curl: For environments where curl is the preferred option. 3. Follow the Installation Steps - The installation process will set up the monitoring agent on your server. - If you encounter issues, refer to the Installation Troubleshooting Guide for detailed help. Verify Installation and Wait for Data 1. Wait for Data Collection - After installation, it may take approximately 1 minute for the monitoring agent to collect and send the first set of data to the dashboard. 2. Refresh the Dashboard - After 1 minute, refresh the Servers page to view the server's performance metrics and status. Important Notes - Ping Address: This monitors connectivity from the newly added server to the specified address. Ensure the address is reliable for accurate monitoring. - Process List: - Selecting All is required if you plan to create alerts for processes (e.g., monitoring if a service like nginx stops running). - The Top Ten option selects processes based on resource usage heuristics (e.g., high CPU, disk, or memory consumption). - Installation Issues: If you encounter any problems during the agent installation, detailed help is available in the Troubleshooting Guide linked in the installation box.

Configuring and Understanding Server Alerts

Alerts are a critical feature of your server monitoring system, ensuring that you are notified promptly when conditions on your servers require attention. This guide will help you understand how alerts work, how to configure them, and what each alert type means. How Alerts Work - Triggering Conditions: Alerts are triggered when specific conditions, defined in the alert configuration, are met and persist for a set period (in minutes). For example, setting "5 minutes" means the condition must be true for five consecutive minutes before the alert is triggered. - Group-Based Notifications: - Alerts are associated with server groups. - Every user or integration linked to that group will receive notifications based on their individual preferences (e.g., SMS, email, Slack). - Notification settings are displayed in the Notifications box within the alerting tab. - Escalations: Alerts are only sent if the condition persists, preventing unnecessary notifications for transient issues. Setting Up Alerts Alerts are configured using a simple modal form. Here’s a step-by-step guide: 1. Choose Alert Type: - Select the condition you want to monitor (e.g., CPU usage, memory usage, or process status). 2. Set the Condition: - Specify how the alert will trigger (e.g., "greater than" a certain threshold or "equal to" a specific value). 3. Define the Threshold: - Set the exact value that will trigger the alert. For example: - CPU Usage > 90% - Memory Usage > 80% - Process = nginx 4. Set Duration: - Choose how long the condition must persist (in minutes) before triggering an alert. A value of 5 means the alert triggers if the condition is sustained for 5 consecutive minutes. Alert Types and Their Meaning Here are the available alert types, with detailed explanations: 1. CPU Usage - Triggers when the server’s CPU usage exceeds the defined threshold for the specified duration. - Example: Alert if CPU usage is >90% for 5 minutes. - Use Case: High CPU usage can indicate resource exhaustion or inefficient processes. 2. Memory Usage - Triggers when the memory usage (RAM) exceeds the specified percentage. - Example: Alert if memory usage is >85% for 3 minutes. - Use Case: High memory usage can cause performance degradation and application crashes. 3. Disk Usage - Triggers when disk usage exceeds the specified threshold. - Example: Alert if disk usage >90% for 5 minutes. - Use Case: A nearly full disk can cause system errors or service disruptions. 4. Disk IO - Triggers when disk read/write operations exceed the set threshold. - Example: Alert if disk IO >500 MB/s for 10 minutes. - Use Case: High disk IO could indicate heavy database operations or backup processes. 5. Network Traffic - Triggers when network traffic exceeds a specified rate. - Example: Alert if outbound traffic >100 Mbps for 5 minutes. - Use Case: Unusually high network traffic might indicate a DDoS attack or data leak. 6. Process Not Running - Triggers when a specific process is not running. - Important Configuration Notes: - Condition: Must be set to "equals" (==). - Threshold: Enter the exact process name as it appears in the "Process" tab under the cmd column (e.g., nginx or apache2). - Example: Alert if nginx is not running for 2 minutes. - Use Case: Ensures critical services (e.g., web servers, databases) are always operational. 7. Linux Load Average - Triggers when the load average exceeds the specified threshold. - Example: Alert if load average >4 for 5 minutes. - Use Case: High load averages indicate that the server’s processing capacity is under strain. 8. Custom Metric (if applicable) - Allows users to define custom alert conditions based on available metrics. - Example: Alert if a specific application metric exceeds a user-defined threshold. Understanding Notifications - Who Gets Notified: - Alerts are sent to all users and integrations associated with the server group. - Individual notification preferences determine how alerts are received (e.g., Email, SMS, Slack). - Notifications Box: - The Notifications section on the alerting tab shows: - Recipients of the alerts. - Notification types for each recipient. Common Scenarios and Tips - Scenario 1: High CPU Usage on a Web Server - Configure an alert for CPU usage >85% for 5 minutes. - Investigate spikes by checking active processes and web traffic. - Scenario 2: Disk Space Running Out - Set an alert for Disk Usage >90% for 5 minutes. - Proactively delete unused files or increase storage. - Scenario 3: Critical Process Stopped - Create an alert for Process = nginx to ensure your web server is always running. - Use the exact process name from the Process tab. FAQs 1. Why does my alert trigger after the set duration (e.g., 5 minutes)? - Alerts are designed to trigger only if the condition persists for the specified duration. This helps prevent false alarms for transient issues. 2. Why can’t I see alerts for my process? - Ensure you’ve entered the exact process name as it appears in the Process tab under the cmd column. Also, verify that the condition is set to "equals" (==). 3. Can I send alerts to multiple recipients? - Yes, alerts are sent to all users and integrations in the server group. Each recipient will receive alerts according to their preferred notification method. 4. What if I don’t receive alerts? - Check your notification settings and ensure your preferred method (e.g., Email, SMS) is enabled. Use the Send Test Notification feature to verify. 5. Can I change how long a condition must persist before triggering an alert? - Yes, during setup, you can adjust the duration (in minutes) in the alert configuration modal. 6. How do I test an alert setup? - Use the Send Test Notification feature on the Notifications tab to confirm that alerts are properly configured. Best Practices for Alerts - Set Realistic Thresholds: Avoid overly sensitive alerts that may lead to alert fatigue. - Use Duration to Filter Noise: Set longer durations (e.g., 10 minutes) for less critical conditions to minimize false positives. - Test Regularly: Use the test notification feature to ensure recipients are correctly configured. - Monitor Critical Processes: Always set up alerts for essential services like web servers and databases. With these guidelines, you can effectively configure alerts to ensure your server operations run smoothly. For further assistance, feel free to contact support!

Understanding the Server Dashboard

The Server Dashboard provides a comprehensive overview of your server's health and performance. Each section offers vital metrics, visualizations, and diagnostic data to help you monitor and optimize your server operations. This guide explains every tab, key terms, and features so you can make the most of this page. Page Overview - Purpose: Monitor your server's critical performance metrics such as CPU usage, memory consumption, and disk health. - Tabs and Metrics: Organized by category to provide a clear view of specific server components. - Time Zone: All data is displayed in UTC for consistency. - Real-Time Updates: Data refreshes at regular intervals to reflect the latest server status. Tabs and Metrics 1. Overview The default tab provides a summary of the server's key metrics: - CPU Usage: Shows the current and average utilization of your server's CPU. - Linux Load Average: A key metric for Linux servers, this shows the number of processes waiting for CPU resources. A load average of "1.0" on a single-core server indicates full utilization. - Memory Usage: Displays the amount of RAM used vs. available. - Disk Usage: Includes total, used, and free disk space. - Network Traffic: Visualizes incoming and outgoing data transfer rates. 2. CPU Detailed metrics related to CPU performance: - Usage Per Core: Breaks down CPU usage by individual cores. - Temperature (if available): Monitors CPU temperature. - Important: This metric may not be available on VPS environments, as virtualization typically does not expose hardware-level data. - Processes: Lists top resource-consuming processes. 3. Memory Tracks how your server’s memory is being utilized: - Used vs. Available: Shows how much memory is actively in use. - Cache/Buffers: Indicates memory allocated for caching operations. - Swap Usage: Swap memory is used when physical RAM is fully utilized. High swap usage can indicate performance bottlenecks. 4. Disk Provides insights into your server's storage: - Disk IO (if available): Measures read/write operations on the disk. - SMART Monitoring: Self-Monitoring, Analysis, and Reporting Technology is used to predict potential disk failures. - Note: SMART data is typically unavailable for VPS environments or cloud-hosted servers due to the lack of direct hardware access. - RAID Status: For servers with RAID configurations, this shows the health and performance of the RAID array. - Note: Like SMART, RAID status may not be accessible on virtualized environments. 5. Network Monitors network activity: - Upload/Download Rates: Visualized in a graph showing trends over time. - Active Connections: Displays the number of open network connections, useful for identifying unusual activity. - Ports: Highlights open and listening ports on your server. 6. Web Workers - What Are Web Workers? Web Workers refer to concurrent processes running to handle web requests. - Worker Count: Displays the number of active workers. - Requests Per Second (RPS): Measures how many requests your server processes every second. A spike here might indicate high traffic or potential DDoS activity. - Queue Depth: Shows the number of requests waiting to be processed. What Customers Should Know About Specific Metrics - Linux Load Average: - Represents the number of processes waiting for CPU time. A high load average relative to the server's core count can indicate overutilization. - For example: - A load average of 4.0 on a 4-core system is considered optimal. - A load average of 6.0 or higher may suggest the server is under strain. - SMART Monitoring: - SMART provides early warnings for potential disk failures. - On dedicated servers, SMART data is invaluable for proactive maintenance. - VPS users won’t typically see SMART data because they do not have direct hardware access. - CPU Temperature: - Critical for ensuring hardware longevity. High temperatures can indicate inadequate cooling or overutilization. - Note: Often unavailable on VPS environments. - Disk IO: - High Disk IO indicates heavy read/write operations, which could lead to slower performance for other processes. - Web Workers: - Essential for web servers, these represent the number of concurrent threads serving client requests. - Insufficient web workers can cause delays, while too many might consume unnecessary resources. Why Certain Metrics Might Not Be Available - VPS Limitations: - Virtualized environments like VPS or cloud servers often lack hardware-level data such as SMART, RAID, CPU temperature, or disk IO. - Insufficient Permissions: - Ensure your monitoring agent has the required permissions to gather data. - Unsupported Configurations: - Some features, like RAID status, require specific setups or hardware configurations. FAQs 1. Why is my Linux load average high? - A high load average suggests your server is overutilized. Check processes and consider upgrading CPU resources. 2. Why don’t I see SMART or RAID status on my VPS? - VPS environments don’t provide direct hardware access, so these metrics are unavailable. 3. What should I do if swap usage is high? - High swap usage can indicate that your server is running out of physical RAM. Consider increasing your RAM or optimizing applications. 4. How do I interpret the disk IO graph? - Spikes in disk IO may indicate heavy read/write operations, such as backups or database queries. Consistently high values can lead to performance degradation. 5. What does the Web Workers tab mean for me? - The Web Workers tab is crucial for web servers. It shows how efficiently your server is processing client requests. High queue depths or low RPS may indicate bottlenecks. 6. Why are some metrics missing for my server? - Metrics like CPU temperature, SMART, and RAID status are often unavailable on virtualized environments. Contact support if you believe this is an error. Tips for Effective Server Monitoring - Focus on Key Metrics: Prioritize monitoring CPU, memory, and disk usage for a quick health check. - Understand the Environment: VPS users should focus on software metrics like CPU usage and processes, as hardware data is limited. - Investigate Spikes: Use trends in the graphs to identify and investigate anomalies, such as traffic surges or resource overutilization. If you have additional questions or need help interpreting the data on your Server Dashboard, our support team is here to assist!

Linux: Manual install and config client app

Automated Installation For an easy installation, we provide an auto-install Bash script. You can find it at the top of the server dashboard by pressing the Install Client button. This script simplifies the setup process and ensures that all necessary dependencies are installed. Manual Installation If you prefer to install PingMoni manually, follow the steps below: System Requirements - The system must have Linux Kernel 4.18+. - Most supported Linux distributions will work *****OpenSUSE is known to be incompatible. Dependencies Ensure the following dependencies are installed: Smart Tools, Tar Debian/Ubuntu: sudo apt update && sudo apt install -y smartmontools tar RHEL/CentOS: sudo yum install -y smartmontools tar Download and Extract Download the latest PingMoni client from our website and extract the archive. The exact download link is not currently available, so please refer to the server dashboard for updates. tar -xvf pingmoni-latest.tar.gz Choosing the Correct Binary Inside the extracted folder, you will find three architecture-specific subfolders: - x86 for standard 64-bit systems - arm32 for 32-bit ARM devices - arm64 for 64-bit ARM devices Navigate to the appropriate folder and locate the following binaries: - pingmoni-client - pingmoni-updater Installation Steps 1. Move the binaries to the default installation directory: sudo mkdir -p /opt/pingmoni sudo mv pingmoni-client pingmoni-updater /opt/pingmoni/ 2. Grant execution permissions: sudo chmod +x /opt/pingmoni/pingmoni-client /opt/pingmoni/pingmoni-updater 3. Run the configuration setup: cd /opt/pingmoni ./pingmoni-client -create-config 4. During configuration, you will be prompted to enter your server key and enable/disable auto-update. If enabling auto-update, ensure pingmoni-updater is present. 5. The configuration file will be created at: /opt/pingmoni/config.json Verifying Configuration After installation, you can check the setup with: /opt/pingmoni/pingmoni-client -check-config /opt/pingmoni/pingmoni-client -check-connection Running PingMoni as a System Service To run PingMoni persistently, set it up as a service. While various init systems can be used, here's an example using systemd: sudo nano /etc/systemd/system/pingmoni.service Paste the following configuration: [Unit] Description=PingMoni Client After=network.target [Service] Type=simple ExecStart=/opt/pingmoni/pingmoni-client Restart=on-failure RestartSec=60 User=root Group=root StandardOutput=journal StandardError=journal SyslogIdentifier=pingmoni WorkingDirectory=/opt/pingmoni/ [Install] WantedBy=multi-user.target Save the file and reload systemd: sudo systemctl daemon-reload sudo systemctl enable --now pingmoni.service Setting Up Auto-Update If you enabled auto-update, you need to schedule the updater to run periodically. Create a service for the updater: sudo nano /etc/systemd/system/pingmoni-updater.service Paste the following: [Unit] Description=PingMoni Updater Service After=network.target [Service] Type=oneshot ExecStart=/opt/pingmoni/pingmoni-updater User=root Group=root StandardOutput=journal StandardError=journal SyslogIdentifier=pingmoni-updater Save and close the file. Next, create a timer to run the updater daily: sudo nano /etc/systemd/system/pingmoni-updater.timer Paste the following: [Unit] Description=Runs PingMoni Updater Daily [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target Save and close the file, then enable the timer: sudo systemctl daemon-reload sudo systemctl enable --now pingmoni-updater.timer Final Verification After starting PingMoni, wait one minute and refresh the dashboard to confirm the client is working correctly. This completes the installation and setup of the PingMoni client. If you encounter any issues, refer to the server dashboard for troubleshooting assistance.