The most important part of setting up your monitoring is to ensure that all critical services that make up your online presence are monitored.  Fortunately, we make this process simple.

To get started, click on the "Servers" menu at the top of the control panel, then the "Add Server" link.  This brings up a window that walks you through the process of adding a server.  The steps are:

1. Server name and setup method. Enter your domain name or a fully qualified server name that you want to have monitored.  We recommend starting with the automatic service detection, which uses our proprietary algorithms to detect what services should be monitored.
2. Service selection. Here you see the results of our service detection.  Depending on your infrastructure, there may be quite a few services that impact your web presence.  You can enable or disable monitoring of each service by checking the checkbox.  Note, some of these servers might not be familiar to you - they were found by analyzing your website to see what third-party services are in use.
3. Server group selection. Servers are arranged into groups to allow reporting and management across servers.  Enter a name for the group that will contain your new server(s) or, if you've already created a group that you want to use select that from the list.
4. Monitoring location. We automatically analyze your server's locations to determine the closest monitoring location.  This is pre-selected, and should normally be used.  If you'd like another location, for example to add monitoring from a second location, feel free to change it.

That's all there is to it - your servers are now being monitored.  You can click on a group or server name in the Servers section and view statistics on the server's performance.  You'll also begin receiving regular availability reports - the first will show up in your mailbox tonight.

If you have more servers to add, you can repeat this process as many time as you need.

Setting up contacts is straightforward - just click on the "Users & Contacts" link in the control panel.

One user is created with your account.  You can create additional Users and Contacts by clicking the "Create User" or "Create Contact" links.  Once you've created them, you can add any number of email addresses and SMS/pager numbers.

When creating an email address, there are three types of messages:

• HTML - sends a fully formatted HTML email message
• Text - sends a plaintext email message
• Short-text - sends a very short plaintext email, useful for messages intended for a Blackberry, Treo or other mobile device

For SMS/pager numbers, you need to provide your country and the phone number.  Make sure to include the area code if relevant, but not the country code.

Users and Contacts are very similar, with one crucial difference - Users can login to the control panel to use the outage management tools, while Contacts cannot.  Both Contacts and Users can just be notified of outages and can be sent availability reports.

Notification schedules control who is alerted and when after an outage is detected.  To get started configuring your notification, click on "Notification Schedules" in the control panel.  This brings you to a page that lists all of your schedules.  We have created a basic schedule for you to get started - you can either edit the schedule by clicking on the schedule name or create additional schedules by clicking on the "Add Schedule" link.

There are to major components of a notification schedule: the timeline of actions that will be taken and the Servers/Server Groups that the schedule applies to.  Create your contacts before you configure your notification schedule  - see How do I set up contacts to notify in the event of an outage?.

To begin configuring the timeline click the "Create" button to create a new action.

1. First enter the time at which the action takes place, in hours:minutes:seconds after the outage is confirmed.
2. Add the contacts or contact groups that you want notified at this time.
3. Click the "Save Changes" button to save your action.

You can also click on any of the blue bars in the timeline to edit the contacts associated with that action.

To add a Server or Server Group to the notification schedule, simply select them from the drop down lists on the right side of the page and click the "Add" button.  Once this is done, any outage that is confirmed for one of these servers will begin notification using this timeline.

Note, a server can only have one notification schedule attached to it.  If a schedule is set explicitly for the server, that schedule is used.  If not, we look at the server's parent group(s) for a schedule to use.  If no schedule is found, no outage notices are sent out.

We can monitor any any application that has a remotely-accessible network interface.  At the very minimum, we can do basic port checks to ensure that the application is listening on a given port or ports.  More in-depth monitoring is possible, especially if it is a HTTP-like protocol using our standard HTTP check functionality.

More advanced checks can also be incorporated into our system by our engineers, and we are currently working on a monitoring extension API that will allow you to design and implement your own checking logic specific to your application.  Contact our Support Team if you are interested in pursuing this.

Yes, our rotating contact functionality lets you setup a contact with a calendar-based schedule that can be configured to notify different people at different times.  This lets you do things like load your on-call schedule into the system and we'll automatically contact the person that's on call at the time an outage occurs, no need to update configurations as the on-call contact changes, pass around shared phones/pagers, etc.

This also lets you setup contacts that are only notified during certain hours of the day, for example alerting developers of problems during business hours, or only paging admins after hours, etc.

For details on how to set this up, please see How do I setup rotating contacts?

We support a range of different check types for all of the common services that we support.  At the most basic, we are checking to see if a service on a given port is listening for connections - this is referred to as a "port check" in the control panel.  For many of the most used services, including HTTP, HTTPS, IMAP, POP, SMTP and DNS, we also support more advanced types of checks where we, for example, download a full page from the webserver using a URL that you provide, or perform an IMAP login session with credentials you provide.

We also support arbitrary TCP/IP port checks on whatever ports you specify, as well as Ping checks.  If you have a specific application you need monitored, or are looking for more thorough checking for one of the services that we currently support, please contact our Support Team to discuss the specifics - we are continually expanding the portfolio of checks that we perform and most likely can accommodate your request.

Our normal monitoring service is restricted to only those services that are publicly visible to outside network access, but we do have a virtual monitoring device that can be deployed within your network to safely provide visibility to servers that are behind a firewall.  Contact our Sales Team if you are interested in more details and setting up a test.

Also, there are several ways to monitor backend services such as database indirectly without exposing them directly on the internet.  For some services, you might want to selectively open firewall access to our monitoring nodes - you can find a complete list of our source IP addresses on our website.

Another route is to setup diagnostic interfaces, such as simple web pages or web service interfaces that can be reached from the outside that provide more detailed application status information for us to pickup, for example a simple web page that shows the current database query volume.  We can then incorporate that information into your monitoring history and provide reports as well as alerts.  If you are interested in setting up something like this, contact our Support Team for assistance.

Many of the third-party servers that we find and monitor as part of your websites are either advertisement servers or visitor-tracking services that are embedded in your website either through Javascript or image inclusions.  While in most cases these aren't directly to your site's visitors, they do require loading by their browsers and can extend the overall page load time if the servers that host them are down or slow to respond.

In most cases you will not be able to directly respond to problems with these servers, so you might want to setup an alternate notification schedule for these third-party services.  While you don't want to be paged in the middle of the night for a problem you can't fix, it's important to know about the performance of these services so you can raise issues with your service provider and/or use this information when considering which providers to work with.

Panopta gives you lots of flexibility in tailoring your outage notifications to meet the needs of your team.  You can setup multiple notification schedules, each of which is a timeline for when outage alerts are sent.

It is often useful to setup different schedules for different classes of servers, for example a "critical servers" schedule which pages an on-call admin 60 seconds after confirmation of an outage and a "non-critical" schedule that has a more relaxed notification timeline.

The specifics of the schedule really depend on the makeup of your team and the specifics of what you are monitoring.  Panopta automatically sets up a basic schedule to get you started that you can edit through the control panel.  Feel free to contact our Support Team to help you assess your specific requirements and craft the best notification schedule to fit your needs.

Most mobile phone providers offer an email gateway that can be used to send email to your phone.  See the table below for many of the major carriers.

Note, you should use the "short text email" message type for outage alerts, and the message will be formatted for reading on a mobile phone or other display with limited viewing space.

The Panopta Monitoring Agent

The Panopta Agent is a local monitoring utility designed to run directly on your server. This allows Panopta to monitor your local resources, such as MySQL connections, CPU usage, and disk space, and report on their statuses using Panopta's notification infrastructure.

Monitoring Plugins

The following are the standard plugins that the agent supports, and the resource types that each can monitor.

• Apache
  • Percentage of worker threads used
  • Connections per second
  • MB transferred per second
• Bandwidth for a network device
  • Kb/s in and out
  • Number of packets in and out
• CPU load average
  • 1 minute average
  • 5 minute average
  • 15 minute average
• Disk usage
  • Percent used
  • Kb available
• File presence
  • If a specific file exists
  • If a specific file was created, modified, or accessed within a certain amount of time
• I/O stats
  • Percentage of CPU time during which I/O requests were issued to a device
• Memory usage
  • Percent of RAM free
  • Kb of RAM used
• MySQL
  • Percentage of query cache free
  • Kb of query cache free
  • Number of MySQL connections
  • Whether or not a slave server is replicating
  • Whether or not a slave server is connected to the master
  • The latency of the slave server to the master server
• Processes
  • Number of processes running

The agent is designed to support the development of custom plugins, so if you need support for additional resources that aren't listed here or want to build monitoring into your application, please contact support@panopta.com and we can discuss options.

Security

The Panopta Agent performs all of it's monitoring and reporting without opening any ports to the outside. When the Agent needs to report monitoring data to Panopta, a HTTPS call is initiated from the Agent to one of Panopta's secure servers,
the data is exchanged, and then the connection is closed. Futhermore, all traffic exchanged between the Agent and Panopta is encrypted with SSL to keep your monitoring data safe from prying eyes.

Installation

First you need to set up or pick a server that is going to have the remote agent. To create a new server, go to Panopta, and under the Servers tab, click "Create Server" and a creation dialog will open. Select "Local Panopta Agent" and finish creating your server as you normally would.

Next, you'll need to download the Panopta Agent from the following link: http://www.panopta.com/downloads/. Be sure to select the correct operating system and architecture for your server, then follow the instructions below corresponding to the version you downloaded.

LINUX (Debian, Ubuntu)

1. If you have an existing agent installed, remove it with "dpkg -r panopta-agent"
2. As root, run "dpkg -i panopta-agent_x.x.x-xx_all.deb"
3. Agree to install
4. Wait a minute for your remote agent to automatically sync with the central Panopta infrastructure.
5. Return to the Panopta.com "Servers" page.
6. If you haven't added the server for which you just installed the agent, click "Create Server" at the top of the page to add a new server. On the first input of the "Add Server" popup, enter your server's FQDN or IP address. The Panopta Agent running on your server will be able to sync itself automatically with the server created in the controlpanel using this value.
7. Once you have finished adding a new server (or selecting your existing server) take a look at the server overview page. You may now begin to add resources to monitor by clicking "Add Agent Resource" under the "Server Resource Configuration" section.
8. Continue adding Agent Resources until you're scheduled to monitor everything about that server you wish to check.As root, run "dpkg -i panopta-agent_x.x.x-xx_all.deb"

LINUX (Redhat, CentOS)

1. If you have an existing agent installed, remove it with "yum remove panopta-agent". If you have any trouble with this, try "rpm -e --noscripts panopta-agent"
2. As root, run "yum install panopta-agent-x.x.x-xx.xxxx.rpm --nogpgcheck"
3. Agree to install
4. Wait a minute for your remote agent to automatically sync with the central Panopta infrastructure.
5. Return to the Panopta.com "Servers" page.
6. If you haven't added the server for which you just installed the agent, click "Create Server" at the top of the page to add a new server. On the first input of the "Add Server" popup, enter your server's FQDN or IP address. The Panopta Agent running on your server will be able to sync itself automatically with the server created in the controlpanel using this value.
7. Once you have finished adding a new server (or selecting your existing server) take a look at the server overview page. You may now begin to add resources to monitor by clicking "Add Agent Resource" under the "Server Resource Configuration" section.
8. Continue adding Agent Resources until you're scheduled to monitor everything about that server you wish to check.

Windows

1. Download the agent from the downloads page onto your server
2. Double click on the MSI installer. Accept all the defaults for installation unless you would like to customize the install location
3. After the install completes, go to the C:Program FilesPanoptaAgent in Windows Explorer (Note: It may be called Program Files (x86) on some systems)
4. Double click on the agent_setup.bat file. This script will execute some commands to initialize the agent and add it to your scheduled tasks.
5. Enter the servery key from the Panopta control panel when asked
6. Enter the Administrator password when asked to authorize adding the task to scheduled tasks.
7. That's it! The Agent should now run in the background and report back to the central system with the metrics its collecting. You can find logs for both the synchronization process and the data collection process in C:PanoptaAgent

Troubleshooting

Q. How do I know the agent on my server synced correctly with the server reference in the Panopta control panel?

A. If you select your server reference in the Panopta control panel and look at the "Server Configuration" box in the upper left, you should see a field and value for "Agent Version" if your server was able to correctly sync. This field will not exist for servers that could not sync.

Q. My server won't sync with the server reference in the Panopta control panel.

A. It's possible that the agent was unable to locate your server reference on Panopta. Fortunately, there's a quick fix. In the Panopta control panel, select your server so that you can see the server overview. Under the "Server Configuration" box in the upper left, find the field "Server Key" and copy this value. Now go onto your server where you installed the agent and edit the file "/etc/panopta-agent.cfg" In this file, there will be a line that starts with "server_key". Make sure the entire line reads "server_key = theserverkeyyoucopied". This will give the Panopta Agent a explicit handle to the server reference in the Panopta control panel.

Q. I'm using yum/rpm and I'm unable to uninstall the agent.

A. First, make sure when you're removing the agent, you're specifying it by its package name, "panopta-agent", and not the name of the package file, "panopta-agent-x.x.x-xx.xxxx.rpm". If this doesn't work, and your packaging system claims that the agent is still installed, it's possible that the agent files have been uninstalled, but that it was unable to communicate this to the packaging system. Try removing it from rpm with "rpm -e --noscripts panopta-agent".

Q. I'm using yum/rpm and I'm unable to install the agent. My packaging system complains about the gpg signing key.

A. Due to a bug rpm/yum bug in certain versions, sometimes the packaging system fails when validating the signing key. To get around this, run the install with the option "--nogpgcheck".

If you have any other questions on the Agent installation or usage, please contact us at support@panopta.com and we'll be happy to help you solve them.

Our rotating contact functionality gives you the ability to configure notification contacts that change with time, to handle situations like on-call schedules that change from day-to-day or week-to-week, as well as setting up contacts that only get alerted during certain hours of the day.

To create an initial rotating contact:

1. Visit the Users & Contacts tab. Scroll to the bottom.
2. Click "Create Rotating Contact"
3. Fill out the name and optionally a description.

You'll be redirected to the main rotating contact interface:

The basic operation is to drag your colored contacts from the left onto the calendar on the right. Before you start, however, you should drag a contact up to the default contact red-dashed area. This will serve as the contact to use if no contacts are scheduled.

To add contacts to the calendar:

1. Drag the colored contacts from the left onto the calendar on the right.
2. Fill out the applicable fields in the modal popup that appears after you drop the contact onto the calendar.
3. Click Save.
4. Click the contact again to adjust any fields. You may also drag the contact onto different dates, resize the contact, or delete the contact by clicking the "[x]" on the contact's far right.

Once a contact is added, you can configure the timing and recurrence options for the contact:

We support a wide range of recurrence options to help you customize the contact to meet the way your operations team works.  If you have a scenario that you're not able to configure, please contact us at support@panopta.com and we'll be happy to help out.

Yes, we support both Google Chat and IRC - you can add contact types for each of these in the Users & Contacts page, and then add the contact to your notification schedules.

Chat notification supports some two-way functionality.  After the initial outage message, you can respond to request information about the outage or rely with a message to include in the outage log that is visible to other users on your account.

For example:

(12:08:33 PM) Jason: list
(12:08:34 PM) panoptaoutage@gmail.com: Active outages:
panoptademo.com (Panopta test server) started 3 minutes 19 seconds: Ping
(12:08:49 PM) Jason: log -h
(12:08:49 PM) panoptaoutage@gmail.com: usage: log [-h] [-o FQDN] message [message ...]

Logs a message to a specific outage or all active outages. If OUTAGE is "all" (default), all outages are logged to.

positional arguments:
message The message to write to the outage log

optional arguments:
-h, --help show this help message and exit
-o FQDN, --outage FQDN
The FQDN of the outage to log to (default: all)

(12:10:14 PM) Jason: log Checking to see what the problem is, might be a DNS issue.
(12:10:14 PM) panoptaoutage@gmail.com: Wrote "Checking to see what the problem is, might be a DNS issue." to the outage log.

Going forward, we will be adding more functionality that can be used through the chat interface.  If you have suggestions on additional ways to use this within your organization, please let us know.

Yes, we support two different notification options for Twitter - direct messages and public posts.

To get direct messages sent to your Twitter account, add a Twitter DM contact type to one of your users, then add that contact to your notification schedule.  Note, to get alerts via DM you must be following @Panopta.

You can also have posts made directly to your Twitter timeline to let your users and customers know about problems that Panopta is monitoring.  To do this, add a Twitter Post contact to your user and notification schedule.  This will take you through Twitter's authentication process to give our notification system the ability to post to your timeline.

Once this is finished, you'll be returned to the monitoring control panel and can configure the messages used for the outage and clear announcements.  These messages are templates that use the following variables, allowing you to customize the wording to fit your desired tone and level of detail:

• $fqdn - Fully qualified domain name of the server experiencing the outage/clear.
• $name - Name of the server experiencing the outage/clear.
• $timestamp - UTC timestamp of when the outage/clear occurred.
• $services - For service outages: services experiencing the outage/clear.
• $resource - For resource anomalies: resources experiencing the anomaly/clear.

From the edit dialog you can see previews of each message type.

Panopta's Postback URL Notification allows you to receive a HTTP request whenever your servers experience an outage or return from an outage. If you have multiple outages at the same time, you will receive a separate HTTP request per outage, as opposed to them being grouped together, like they are in other notification types.

The Postback can be setup by adding a HTTP POST contact to one of your users in the "Users & Contact" tab.  In the dialog window that comes up, give the contact a label, which will be used to refer to it on notification schedules, and the URL you wish to send the alert to.  Alerts can actually be sent via HTTP POST or GET operations, choose whichever your system is setup to receive.

Next, fill in the variables that will be used.  There are three rows of inputs for the variable name and value, and more can be added by clicking the button to add a row.  The values can be setup to include macros that expand to the actual details of the outage, for example including "$fqdn" in a value will get replaced with the actual domain name of the outage.  Details on all of the macros are shown at the top of the dialog window.