article Setting up a reporting instance

Related Documentation Version of up.time Affected Affected Platforms
7.x All

Article Contents

Overview

Large up.time deployments may achieve performance benefits by transferring up.time reporting functions to a dedicated reporting instance that only generates and serves reports.

System monitoring involves intensive insertion of data into the up.time DataStore and running reports over long date ranges and many systems can require a large number of DataStore requests. Most of the larger up.time deployments where this becomes a concern are already using an external database like SQLServer or Oracle, which provides plenty of capacity within the database. So by distributing uptime’s activity across two instances, we’re able to use more of this capacity then we could with a single instance.

If you are considering deploying an up.time reporting instance in your environment, please contact support beforehand. So that we can help assess if a remote reporting instance will help in your environment.

Reporting Instance Architecture

An up.time deployment with a reporting instance has 2 separate up.time installations:

  • The monitoring station, which handles all monitoring, administration, data archiving and report scheduling tasks.
  • The reporting instance, which only generates reports.

Both installations will connect to the same database backend.

The following graphic illustrates the relationship between the monitoring station and reporting instance:

How the monitoring and reporting instances co-exist

Note the following:

  • This article assumes that the monitoring station is running and collecting performance data from the systems in your environment, and that your uptime datastore is running in an external database like SQLServer or Oracle.
  • Users will not be able to login to the user interface of the reporting instance.
  • The reporting instance does not require a separate up.time license.
  • All reports will be saved to the GUI/published directory on the reporting instance.

Step 1 - Install the Reporting Instance

This step assumes that the monitoring station is already installed and collecting data. The reporting instance will be installed as a new copy of up.time on a separate server.

Before installing the reporting instance, ensure that the server that will host the reporting instance supports the minimum hardware and operating system requirements for an up.time monitoring station. For more information on sizing and installing a monitoring station, see Recommended Monitoring Station Hardware.

Note: The operating systems of the two hosts can be different. However, the up.time version must be the same for both the monitoring station and the reporting instance.

Step 2 - Configure the Reporting Instance Settings

To enable a separate up.time reporting instance, configuration settings must be changed on the monitoring station and additional configuration options must be added to the uptime.conf file on the reporting instance.

On the reporting instance, add the following entry to the uptime.conf file to disable all non-reporting functions:

reportingInstance=true

We also need to scale down the size of the connectionPoolMaximum in the uptime.conf from the default option of 100 to 50:

connectionPoolMaximum =50


Also refer to the Mail Server settings on your monitoring station and copy the settings into the uptime.conf file on the reporting instance to enable it to send reports via email:

smtpServer=mail.yourserver.com
smtpPort=25
smtpUser=username
smtpPassword=password
smtpSender="uptime Monitoring Station" 
smtpHeloString=yourserver.com

In the smtpSender entry, you can change uptime Monitoring Station to another value such as up.time Reports.

Login to the web interface of the monitoring station. In the navbar, click Config and then click Remote Reporting in the left side menu. Click the Edit Configuration button to open the following window:

Remote reporting instance configuration

Edit the following fields:

  • Reporting Instance Enabled: Check the box.
  • Remote Reporting Server: the server host name on which the reporting instance is running.
  • Remote Reporting Server Port: the port number on which the reporting instance is listening (default is 9996).

Step 3 - Verify the Monitoring Station can Access the Reporting Instance

After you have set up the monitoring station and reporting instance, verify that the two instances can communicate with each other:

  1. Login to the up.time web interface on the monitoring station.
  2. Click Config on the toolbar.
  3. Click Remote Reporting in the Tree panel.
  4. Click the Test Configuration button.

    A pop-up window will appear. If the reporting instance was configured properly, a message similar to Reporting is running on report_host:9996 will be displayed in the pop-up window. If an error message appears, check the configuration and try again.

Step 4 - Published Reports Folder changes

Now that the remote reporting instance has been successfully setup, and we’ve confirmed that the monitoring station is able to push report generation requests to the remote server. We need to make changes to accommodate the change in the ‘Published Reports’ folder. As mentioned in the Architecture section above, all published reports are now saved on the reporting server, instead of locally on the monitoring station like before.

That means we have two options for howto handle this change:

  1. Change the GUI/published/ directory into a mount point for a shared location in your environment that can be accessed from both the Monitoring Station & Remote Reporting Server.
  2. Add a custom tab on to the ‘My Portal’ tab within uptime to direct to the published reports folder on the reporting instance. This can be done by adding the following values in your ‘up.time configuration’ section on the Config tab.
    Note: make sure to replace remote-reports-server with the correct hostname for your reporting server, and you may also need to change tab2 to tab3 etc depending on how many tabs you already have setup for plugins etc.
    myportal.custom.tab2.enabled=true
    myportal.custom.tab2.name=Published Reports
    myportal.custom.tab2.URL=http://remote-reports-server:9999/published/
    

Additional Steps using the Bundled MySQL Datastore with Remote Reporting

The above steps for setting up a remote reporting instance were tailored for environments where the up.time datastore is running in an external database like Oracle or SQLServer. It is possible to setup a remote reporting instance that connects to the bundled mysql datastore service on the monitoring. The potential performance boost won’t be as large as compared to using an external database. The reason for this that the bundled mysql datastore still runs on the monitoring station, and shares resources with the main uptime instance.

Using an external database means that there is already a database user available with Read/Write access, as well as a larger database connection pool available. So in order to use the bundled mysql datastore with the reporting instance, we’ll need to take some additional steps to account for this.

  1. Grant the uptime database user the ability to connect from hosts other than the default option of localhost.
  2. Increase the size of the mysql database Connection Pool, as by default each uptime instance attempts to open 100 database connections, and the mysql database is set to accept a maximum of 110 connections.

Granting the uptime database user external access:

  1. On the uptime monitoring station, open a terminal or command prompt and navigate to the uptime directory <uptime_dir>.
  2. From within the <uptime_dir> navigate to the mysql/bin directory.
  3. Run the following command to connect to the uptime datastore as the root user:
    mysql –uroot –puptimerocks
  4. Once connected to the database run the below grant statement. This statement will allow the uptime user to connect to the database from any external host, so for additional security you can replace the % symbol with the ip address or hostname of the reporting instance.
    grant all privileges on uptime.* to "uptime"@"%" identified by "uptime";

Increasing the max_connections on the bundled mysql instance:

  1. On the monitoring station, navigate to the <uptime_dir>/mysql directory and open the my.ini file.
  2. Find the below line "max_connections=110" in the file and change it to:
    max_connections=160
  3. After saving these changes, restart the ‘uptime_datastore’ service to pick-up the changes made to the my.ini file.

Related Articles


Creating custom reports with Microsoft Reporting Service

RatingViews
article

Learn how to query data from an MS SQL Server DataStore and create reports with Microsoft Reporting Services.

By: uptime Support | Date Created: 1-3-2007 | Last Modified: 7-6-2011 | Index: 113

  8173

How to verify the Active Directory Domain Name setting

RatingViews
article

- Logon to a Windows system that is on the domain - Open up the command line (Start > Run > cmd) - Type the following: > net config workstation - Enter the value for "Logon Domain" into the uptime...

By: uptime Support | Date Created: 10-7-2009 | Last Modified: 8-13-2011 | Index: 388

  3040

ESX Instance Workload Data

RatingViews
article

This article outlines the metrics that up.time collects from the instances on ESX systems.

By: uptime Support | Date Created: 1-23-2007 | Last Modified: 7-4-2011 | Index: 120

  5540

ESX instance Percent Used > 100%

RatingViews
article

You may notice alerts from the ESX Workload monitor indicating that the Percent Used for a specific VM instance is greater than 100%. This is a valid scenario indicating that the instance is using...

By: uptime Support | Date Created: 6-26-2010 | Last Modified: 8-10-2011 | Index: 455

  1732

VM instance is consuming a license

RatingViews
article

There are several reasons a VMware instance may consume a license. 1) VMware tools are not installed on the target VM. 2) The VM is not running on an ESX server that is also monitored by up.time...

By: uptime Support | Date Created: 8-7-2010 | Last Modified: 5-4-2013 | Index: 470

  1736

User Comments



No comments have been posted.

Copyright © 2021 IDERA, Inc.   Legal   Privacy Statement