Advanced Alerting Configuration
      Back to home
      1. ProTop Knowledge Base
      2. Advanced Alerting Configuration

      Virtual host names and ProTop

      I have a database and other resources that can run on more than one server, think HA, DR, etc. How do I make ProTop handle this correctly?

      In the end, we want to see server trend data for the same database, in the same place in the portal no matter which server happens to be communicating with the portal at the moment.  

      Scenario:

      • I run myDB on server1 behind the virtual hostname myProdServer for 4 weeks
      • Then I unmount the disks containing myDB from server1 and mount them to server2
      • I switch myProdServer to point to server2 and run the database there for 4 weeks
      • I do my maintenance on server1 and the cycle continues

      How do I configure ProTop to reflect this so that all of my resource metrics are monitored, tracked, and alerted in a consistent manner?


      Ordinarily, ProTop starts agents only for resources in etc/dblist.cfg whose server matches the current hostname.  By setting PTSERVER=myProdServer in bin/localenv[.bat] we can tell ProTop to start agents for resources in etc/dblist.cfg whose server matches the value of PTSERVER instead of the current hostname. This allows ProTop to communicate a consistent server name to the portal for this resource, no matter which server the resource happens to be running on.

      NOTE: This is not to say you can run an agent on this server for a resource currently running on a different server. All we are doing is allowing for the use of the same virtual hostname for the more-than-one server that a resource can run on in this scenario.

      Configuration:  On both server1 and server2

      1. If it is not already there, copy bin/localenv.x [.batx) to bin/localenv[.bat].  
      2. Edit your localenv[.bat], and uncomment the line containing PTSERVER.
      3. Assign your virtual hostname to the PTSERVER variable e.g. export [set] PTSERVER=myProdServer.  Save and exit.
      4. Log into the ProTop Portal, edit your resources, and replace the current server name with your PTSERVER value. Save and exit.  CAUTION:  Changing the server name for a resource already listed in the portal will permanently disconnect all previous server data from that resource.
      5. Restart ProTop on both servers (remove tmp/*.flg files, and the service will restart on its own).

      When ProTop sends metrics and alerts to the ProTop portal, it uses myProdServer instead of the local hostname for the server name.

      What you see in the ProTop Portal

      When you log into the ProTop Portal and click the name of the database resource in this scenario to see trend data, then select Server from the dashboard dropdown, you see server data for each server the resource ran on as sampled over time. So, if you ran the database on server1 in January and server2 in February, the server data you see in the charts for January was provided by server1 and the data you see for February was sent by server2.  

      NOTE:  You will see the actual hostname of the server currently sending myProdServer data to the portal in the OS Info bar near the top of the Main Dashboard:

      And in the pop-up when you hover over the resource name in the Resources Window in the Alerts Dashboard:


      You will see the virtual hostname in the Server Name column in Resource Maintenance: 

      Which of course, matches etc/dblist.cfg:

      mb117sports|/data/mb117/db/mb117sports|myProdServer|yes|/usr/dlc117|
      myappsrv|-1|protoptest|yes||
      sports2000|/data/mb117/bigsports/sports2000|myProdServer|yes|/usr/dlc117|

      Virtual hostname planning - pre-ProTop install

      1. Server1: Download and install ProTop. Provide your known customer id or request a new one. If you request a new custid it will be provided in the email sent once the installation is complete. Be sure to skip database discovery. 
      2. Server2: Install ProTop and provide your known custid or the custid provided during the installation on Server1. And again, skip database discovery.
      3. Server1 and Server2: set PTSERVER=yourVirtualHostname in bin/localenv for both hosts.
      4. Log into the ProTop Portal and add your resource. Enter yourVirtualHostname into the Server Name field, fill in the remaining details and save the resource.
      5. Server1 and Server2: Restart ProTop, cd $PROTOP/tmp and delete *.flg. ProTop will restart shortly. The resource(s) you defined in the portal will now be synced with each of your etc/dblist.cfg files.
      6. Metric data and alerts should now be flowing to the portal for this resource from the server it is currently running on.

      Virtual hostnames, ProTop, and OE Replication

      You have two servers, server1 runs the source database and server2 runs the target database. You regularly swap the roles of these two servers so server2 runs the source and server1 runs the target.  We are monitoring both source and target.  How does ProTop handle this?

      Given etc/dblist.cfg on both servers:

      prodDB | dbdir/db | myHost ...

      prodDB_T | dbdir/db | myHost_T ...

      State 1: Virtual host: myHost ==> myHost1 

      myHost1 - prodDB source

      PTSERVER=myHost 

      myHost2 - prodDB target

      PTSERVER=myHost_T

      State 2: Virtual host: myHost ==> myHost2

      myHost1 - prodDB target

      PTSERVER=myHost_T

      myHost2 - prodDB source

      PTSERVER=myHost

      For this to work:

      1. shut the databases down
      2. perform your normal OE Replication transition process and restart the databases
      3. set PTSERVER=myHost on the server running source and restart ProTop
      4. set PTSERVER=myHost_T on the server running target and restart ProTop
      5. in DNS point myHost to the server running source

      Need help? Use the links at the top of this page to contact us.  We will do our best to reply within one business day.