Page tree
Skip to end of metadata
Go to start of metadata

The Sysadmin page provides statistics and tools for a number of system administration tasks. These tools are divided into the following tabs:

 

Sysadmin Tools


 

Background Task Daemon

Daemon is responsible for executing all background tasks such as:

  • Transactions
  • Backup takers
  • Billing stats updater
  • Cluster monitor
  • Compute resource monitor
  • Schedule runner

To operate the daemon, use the following buttons:

  • Reload daemon – restarts the tasks, and completes all running tasks if their PIDs still exist.
  • Stop daemon - completes any backups in progress, but prevents any more backups from starting; stops all tasks in progress.
  • Start daemon - starts up all the tasks.
  • Check status – shows PID of the task and its status. 

To get details on daemon processes activity, run the Track Daemon Process Activity tool.

 

Availability Check

Availability check enables to see the status of OnApp Services Monitoring Tool and perform the following functions:

  • Reload the OnApp Services Monitoring Tool

  • Disable the OnApp Services Monitoring Tool

  • Enable the OnApp Services Monitoring Tool

  • Check status the OnApp Services Monitoring Tool

 

CDN Check

The CDN section enables you to check the status of CDN API and CDN Sync Runner.

 

Running processes

This section displays the list of the running system processes:

  • Generate hourly stats - last time hourly statistics was aggregated.
  • Clean Redundant Instant Stat - last time redundant statistics was deleted.
  • SNMP stats runner - last time SNMP statistics was gathered from the compute resources and virtual servers running in the cloud.
    There are three levels of an SNMP statistics gathering:
    1. Level 1 - every 10 seconds. CP gets info about Compute resources uptime/virtual servers' statuses.

    2. Level 2 - every 60 seconds. CP gets info about the disk usage, network usage, CPU usage statistics and the list of virtual servers.

    3. Level 3 every 120 seconds. CP gets list of volume groups and logical volumes.

    The level values can be changed in the onapp.yml file. For details, see Advanced Configuration Settings section.

  • VMware stats - last time VMware statistics was gathered from the vCenter.
  • There are two levels of VMware statistics gathering:
    1. Level 1 - every 60 seconds. 

    2. Level 2 - every 180 seconds.

    For details, see Advanced Configuration Settings section.

  • CDN sync runner - last time CDN statistics was gathered.
  • Delete old stats - last time when the old SNMP has been deleted.
    • Last time started - the last time when the transaction started.
    • Last time finished - the last time when the transaction finished successfully. When the transaction has failed, the last time finished field will display the time of the last successful transaction, thus indicating the failure.

    Running processes time is always displayed in UTC format.

  • Solidfire Stats Level 1 - last time the statistics on disks situated on SolidFire data stores was gathered. This statistic is gathered every 2 minutes.
  • VCloud Stats - last time vCloud Director statistics was gathered from vCloud Director.
    There are two levels of vCloud Director statistics gathering:
    1. Level 1 - statuses of vApps and VSs. This statistic is gathered every 60 seconds.
    2. Level 2 - CPU statistics gathered every 180 seconds.

Services


 

Services Status

This tab shows the statuses of all the services for High Availability clusters. Click the Services Status button to load the page with the list of services, their PID number and the online/offline status.

 

Application errors


 

This tab provides the list of errors registered in your Control Panel. The OnApp error collector records the errors within a CP and aggregates an error list. After that, your Control Panel may send crash reports to OnApp in a form of an encrypted API call. You can enable the sending of the error list from your CP at Dashboard > Settings > Configuration > System tab.

Errors are displayed with the following details:

  • id - ID of the error
  • Class - the class of the error
  • Last detected - the last time the error was detected
  • Quantity - how many times the error has occurred
  • Reported - whether the error has been reported or not

Click the class of the error to view its details. This information will be sent to OnApp if you allow your CP to send crash reports:

  • Class - the class of the error
  • Last detected - the last time the error was detected
  • Quantity - how many times the error has occurred
  • Message - the message that will be sent with this error
  • Backtrace - the backtrace of the error

Activity Log


 

OnApp provides a possibility to trace back any user’s behavior in the cloud to prevent possible misconduct or damage from staying unrevealed.

This Activity Log covers the following actions:

  • DestroyVM

  • DestroyUser

  • DestroyBackup

  • DestroyDisk

  • Change Password

  • LoginAs

  • StopVirtualServer

  • BuildVM

  • Delete CDN Resource

  • Delete DNS Zone 

 

Activity Log registers actions with the following information:

  • id - ID of the User in the DB

  • username - name of the user

  • created at - when the user was created

  • action - what action was performed

  • dependent - id of the action on which the current one was depending

  • dependent type - type of the dependent

  • ip address - ip address from which the action was launched

  • user agent - description of the agent through which the cloud was accessed

 

Zabbix Setup


Starting with version 4.2, OnApp uses Zabbix for autoscaling. OnApp provides the automatic UI-based installation and configuration procedure for Zabbix on a server that you indicate. It can be either a physical server or a virtual server. 

Be aware, that OnApp supports 2.4.х Zabbix version.

 

We recommend the following configuration for the Zabbix server:

  • Server: a separate physical server or a virtual server
  • Operating system: Red Hat Enterprise Linux 5.x, Red Hat Enterprise Linux 6.x, CentOS 5.x, CentOS 6.x.
  • Network requirements: make sure that IP address of the zabbix server is available to the Control Panel server and all virtual servers. 
  • Memory: 128 MB of physical memory and 256 MB of free disk space are minimum requirements. However, the amount of required disk memory depends on the number of hosts that are being monitored. 

The examples of recommended configuration:

Deployment typePlatformCPU/MemoryDatabaseMonitored VSs
Medium Red Hat Enterprise Linux 5.x, Red Hat Enterprise Linux 6.x, CentOS 5.x, CentOS 6.x.2 CPU cores/2GBMySQL InnoDB500
Large Red Hat Enterprise Linux 5.x, Red Hat Enterprise Linux 6.x, CentOS 5.x, CentOS 6.x.4 CPU cores/8GBRAID10 MySQL InnoDB or PostgreSQL>1000

 

Monitis will be used for autoscaling of servers built using OnApp versions previous to 4.2 until you switch autoscaling off for such server(s). If you decide to switch autoscaling back on, autoscaling will be implemented using Zabbix. Zabbix will be also used for autoscaling of newly created VSs. Unless you deploy a Zabbix Server, Monitis will be used for autoscaling by default.

  • We strongly do not recommend installing Zabbix on the Control Panel server. You can use a separate server or a VS (if your network allows it) as the Zabbix server.
  • For successful configuration the Control Panel should have access to the Zabbix server without a password. Therefore, SSH keys should be added to the Zabbix server. To add the SSH keys run the following command:
bash#> ssh-copy-id -i /home/onapp/.ssh/id_rsa.pub root@ZABBIX_SERVER_HOST_IP

You need to indicate the IP of your Zabbix server in the command above. You will also be prompted to enter the password for the root user on the Zabbix server. After you enter the password the SSH keys will be added to /root/.ssh/authorized_keys.

Set Up a New Zabbix Server

  1. Go to your Control Panel Sysadmin menu.
  2. Switch to the Zabbix setup tab.
  3. Indicate the server IP address in the field provided on this tab and press Deploy zabbix server.  

    Please be aware that default administrator credentials "Admin"/"zabbix" are used during Zabbix server deployment. It is recommended to change the credentials due to security reasons.

OnApp will install and configure Zabbix on the server with that IP. Make sure you meet the hardware and software requirements before deploying a Zabbix server.

Add an Existing Zabbix Server to the Cloud

If you already have a Zabbix server, you can connect it to your cloud by using the following procedure:

  1. Fill in the following fields at Control Panel > Settings > Configuration > System tab
    • Zabbix host - the IP address of your Zabbix server

    • Zabbix url - the path to the Zabbix web-interface

    • Zabbix user - your Zabbix user

    • Zabbix password - your Zabbix password

    For more information, see Edit System Configuration
  2. Configure the existing Zabbix server by pressing the Reconfigure Existing Zabbix Server button at Control Panel > Sysadmin > Zabbix Setup tab. OnApp will take credentials data, provided in step 1, and schedule a transaction to reconfigure server.

Uninstall a Zabbix Server

Refer to a separate doc to uninstall a zabbix server if required. Pay attention that when you uninstall a Zabbix server, you won't be switched to Monitis service again. So that means that autoscaling will stop working.

 

Control Panel Maintenance


 

From this tab you can click Enable to switch on the maintenance for the CP. Control panel maintenance is a tool which enables administrators to block the CP. Administrators having permissions on managing Sysadmin Tools will have access to the Control Panel as usual. However, the CP will be blocked for all other users. Servers and services will remain running. 

The screenshot illustrates what users who do not have the necessary permissions will see when they try to access the CP.


Resource Diffs


To view changes that have been made during a transaction, you need to have the appropriate Resource Diff permissions enabled.

This tab contains the transactions that have caused a change in the distribution of resources. The list contains the transactions that change the amount of resources allocated to an existing entity, e.g. disk resize, as well as the transactions that add or delete entities, e.g. virtual server destruction. The list contains the following types of transactions:

  • Resize Disk - changes of the disk size
  • ResizeVirtualServer - changes to a VS's number of CPU cores, priority value and RAM size
  • ResizeContainerServer - changes to a container server's number of CPU cores, priority value and RAM size
  • ResizeApplicationServer - changes to an application server's number of CPU cores, priority value and RAM size
  • ResizeVirtualServerwithoutreboot - changes to a VS's number of CPU cores, priority value and RAM size performed without a reboot
  • ResizeApplicationServerwithoutreboot - changes to an application server's number of CPU cores, priority value and RAM size performed without a reboot
  • ResizeContainerServerwithoutreboot - changes to a container server's number of CPU cores, priority value and RAM size performed without a reboot
  • UpdateResourcePool - changes to the resource pool's resources
  • EditFirewallRule - changes to the firewalls
  • EditNATRule - changes to the NAT rules
  • EditIPSECVPNRule - changes to the IPSECVPN rules
  • the transactions that create or delete entities

Click the transaction to view its details. You will see the Before and After columns with the changed resources highlighted in red and green. The Before column will be empty if a transaction creates a new entity. Correspondingly, the After column will be empty if the transaction removes an entity. If you have Approvals permissions enabled, you will see the Approve and Decline buttons at the bottom of the screen in case the transaction is pending for approval. For more information refer to Transaction Approvals.

You can also view resource differences in the Control Panel's logs.