General Questions about AlertSite Services
The AlertSite Monitoring Suite is designed to measure:
Web site performance and availability.
Web-based multi-step transaction performance and validity.
We notify you immediately if errors or significant slowdowns occur with any of your critical services.
AlertSite global locations currently use either Linux Debian (Lenny build) or Linux Ubuntu version 14.0.4 as an underlying operating system.
In your browser, go to https://www.alertsite.com/unsubscribe.shtml. Click the checkbox of the items from which you wish to unsubscribe, enter the email address, and click the Unsubscribe button. You will receive a confirmation email from firstname.lastname@example.org. In the email, click on the link as directed to complete the task.
Please consider remaining unsubscribed, though. We send out important system information that could affect your monitoring results.
AlertSite monitoring servers are located in over 70 geographic locations around the world. The monitoring stations you selected to check from will do a test of your web site or server on a specified interval based on the rate configured for that monitor. If an error is detected, an automatic recheck is triggered immediately to verify if the error persists. If the recheck does not detect an error, it is reported as a warning (highlighted in yellow in the Report Details section of the Detail Report) and no alert is sent. If the recheck detects the error, and the monitor has Recipients enabled and no blackout period in effect, an alert is sent to specified users configured to receive alerts. Specified users will continue to receive alerts until the configured number of consecutive errors reaches its limit, or until the error clears. The time stamp is highlighted in blue in the Report Details section when an alert was sent, and the Event Detail Report contains the alerts sent.
The type of monitoring (performance, availability, security, system) and monitoring mode (Primary, Round Robin, Global Notify, Global Verify, or SLA (MultiPOP)) determines when you are notified and for what reason.
To change the default monitoring locations for the Account:
In AlertSite 1.0, click on Account in the Control Menu to get to the Manage Account screen.
Click on the button in the upper right labeled Locations. This displays a table of our worldwide monitoring locations, sorted with the current account default Active locations at the top with the Primary location first.
Click the checkbox to deselect any locations you no longer wish to monitor from and click any unchecked box to select any new locations.
Click the Submit button at the upper right corner to save the changes.
If you have deselected any locations, a message will be displayed warning that you will no longer have access to the monitoring data from those locations for any monitor using default locations. If you want to continue, click Yes, I'm sure!.
|Note:||The new account default locations will be applied to all existing monitors that are using default monitoring locations as well as new monitors added thereafter. Monitors that have their monitoring locations manually changed (see below) will not be affected.|
To change the monitoring locations for an individual monitor:
On the AlertSite 1.0 Dashboard, on the Devices tab, click the "wrench" icon next to the monitor name you wish to change. This displays the monitor configuration page in a new window.
Click the Locations at the upper-right corner. This displays a table of our worldwide monitoring locations, sorted with your current Active locations at the top with the Primary location first.
Click the checkbox to deselect any locations you no longer wish to monitor from and click any unchecked box to select any new locations (only anActive location can be Primary so if you deselected the Primary location, click a different radio button to select a new Primary).
Click Submit in the upper right corner to save your changes as monitor-specific locations.
If you have deselected any locations, a message will be displayed warning that you will no longer have access to the monitoring data from those locations for that monitor. If you want to continue, click Yes, I'm sure!.
You can set the locations back to the account defaults by clicking the Reset to Default button.
|Note:||Deselecting a location will disconnect the logs for that location and the monitoring data for that monitor will no longer be available.|
Maybe. If you have selected Yes to Resolve DNS on the Manage Site form for the monitor in question, then the answer is no, since your IP address is resolved prior to every test that we conduct. Otherwise, we resolve your IP ahead of time in order to avoid repetitive DNS lookups. In this case, if your IP changes, you will need to update your site(s). Go to Configuration>Sites in the Control Menu, then click on the site name to bring up the Manage Site form, erase the IP Address field and click Submit. The current IP address should appear.
If it had been working previously, then your IP address may have changed. See the answer to My IP address changed. Do I need to do anything?.
It is possible that the route from our monitoring station to your site is having trouble while other routes are operating normally. This is the nature of the Internet. If you have a Full-Service account and we cannot reach your site, then we can generate a traceroute, which helps identify specifically where the disruption is occurring. Site errors may also be generated if you are doing fullpage monitoring and all the content did not load.
We have multiple DNS servers at each location, and each one caches the data at different times. Our servers are set to cache at 3-7 times the TTL (Time-To-Live) value the customer has it set to or one day, whichever is shorter.
We cannot flush the cache at any given moment. We auto-flush the DNS at 23:15 GMT.
Every server at each of our monitoring locations is its own dedicated recursive DNS server, and all are managed independently. To put it another way, they act as fully resolving DNS servers, running DNS as its own resolver. These servers all reference the main root servers on the Internet.
We support three methods: Content Change Detection, Keyword Verification, and Fullpage Content Change Detection. Content Change Detection looks first for HTTP header elements, and then for the actual size of the retrieved page to determine if a page has changed from the prior test. Keyword Verification looks for a particular keyword or phrase that you specify within the retrieved page and raises an alert if it cannot find the text. Either method may be selected by choosing Configuration>Sites from the Control Menu and clicking on the site name you want to configure.
Note that some pages are dynamic and cannot be effectively monitored by Content Change Detection since the size changes regularly. Your best option in this case would be to use only Keyword Verification.
The default value 999.999.999.999 is used for monitors that do not resolve to a single IP address, such as Round-Trip Email monitors that have IP addresses for both POP3 and SMTP hosts and for transactions that have multiple IP addresses.
The default timeout is 30 seconds. You can select from a range of 1 second to the maximum of 180 seconds in the Manage Site or Manage Transaction screen.
AlertSite supports FTP over SSL. Currently, AlertSite does not support FTP over open TLS or open SSH.
There are a few ways, depending on what traffic needs to be filtered:
Look for AlertSite in the user agent string.
Filter by domain *.alertsite.com.
Filter by monitoring location IP addresses. You can see them here.
If there are Google Analytics™ triggers in the web site that your transaction navigates through, use the DéjàClick URL Exclusion feature to prevent recording and playback of any *.google-analytics.com advertising requests. See URL Exclusion for instructions.
This is described in the DéjàClick FAQs.
The default browser preference value is always reset after the script execution completes. If you need further assistance or you do not have an XML editor, contact email@example.com if you would like us to do it.
There are several methods for identifying a latency problem in a particular monitoring location. Please see Troubleshooting Latencies from One Monitoring Location for details.
AlertSite will automatically disable monitoring after a certain threshold of consecutive errors has been observed.
The number of consecutive errors before being disabled is based on the monitoring interval:
4500 errors - 1 minute
2500 errors - 2, 3 or 4 minutes
1000 errors - 5 or more minutes
Monitors are disabled after too many consecutive errors for all Revenue based Trial and Active accounts.
Here is a summary of AlertSite NTLM support:
SoapUI/API monitoring supports NTLM v2.
Deja supports NTLM v1 (because Firefox supports it).
Non-Deja site monitoring do not support NTLM at all.
AlertSite has limited support for IPv6. See IPv6 Monitoring for details.
You can find them here. You can use these IP addresses to filter AlertSite from Analytics or to white-list AlertSite monitoring locations through your firewall or proxy server.
For our current list of network backbones, see Monitoring Locations.
Please see Database Timing and Latency Information for a detailed explanation of what can cause these delays.
Yes, you can change the contents of email, email-to-text, and AIM alerts by creating custom alert templates. You can assign different templates to different recipient groups or set your templates as default ones so that they are used for all alerts of the matching types.
Each monitor also has the Alert Note field for monitor-specific notes that can be included in alerts.
There are three options, two using alphanumeric pagers and one using numeric pagers. AlertSite recommends the use of alphanumeric pagers.
The simplest method is to use the email gateway provided with your alpha pager service. Just select Alphanumeric (text) pager from the Send a(n) dropdown on the Add Notifier form in the Notifiers Control Menu of AlertSite 1.0 and enter the email address provided by your service in the To field.
To have AlertSite send page requests directly to your alpha pager, we need the phone number of your paging company’s Central Office (CO) facility. We have a list of known paging companies. This list is also displayed in the Send alpha pager messages to dropdown that appears in the Configure Standard (Availability) Notifications section of the Add Notifier screen when you select the Alphanumeric (text) pager recipient type. If your CO facility is in the list, select it from the dropdown, and then enter your pager ID in the To field. If your service is not listed there, contact your service and request that information. Finally, send a request to AlertSite Support to complete the configuration.
If you have a numeric pager, then select Numeric pager (wait for quiet) or Numeric pager (pause after dial), depending on the pager call method, and enter the phone number of your pager in the To field.
The Alert Delivery Methods page has the formats for all recipient types.
Our servers use UCT (GMT) time. You can change the time that is displayed for your alerts and reports to use any time zone. Choose Account from the Control Menu and change the Timezone and Adjust for Daylight Savings Time fields as needed. For example, to use US EST (Eastern Standard Time) select GMT -5 hours. For Arizona, which is Mountain Time but does not use DST, select GMT -7 hours and do not adjust for Daylight Savings Time.
All AlertSite monitor types except Global Notify and Global Verify are designed to verify local connectivity problems. A Performance Advisor is available to answer any questions you may have about which strategy is best for your requirements.
Many customers opt for our Uptime ECT upgrade for Service Level Agreements (SLA) which supports correlation of errors in real-time so alerts are only issued when all locations detect an error simultaneously. Another solution would be to utilize alert escalation as follows:
Monitor your site every 5 minutes.
Create 2 recipients – 1 for email and 1 for an Alpha pager with an email gateway (most Alpha pagers can accept email).
Set the email option to notify after the first error and set the Pager to notify only after the second (or greater) error.
The email will tell you that there might be a problem and the pager will tell you that it is persisted for at least 10 minutes.
See the previous question for one possible application. Also, organizations with multiple parties responsible for a monitored site may wish to add recipients directed to different individuals. Depending upon the severity of the problem, alerts would be generated as appropriate. You would notify, for example, the Webmaster after one error, the Systems Administrator after two errors, and the Director of IS after three errors.
Yes. Under the Notifiers dropdown in the Control Menu, select Notifier Groups. From that page, you create the groups you need and select the recipients and monitors to assign to each group. The alert escalation (when to start notifying, when to stop, and so on) remains in effect. Bear in mind that groups are monitor-oriented, that is, if a monitor is in a group, only those recipients in that group will receive alerts for that monitor. If a monitor is not a member of any group, all enabled recipients will receive the alert, according to the configured escalation.
If you have a situation where you need to assure that only certain recipients get notified when only certain monitors are in error, all monitors must be in groups. In this case, all recipients must be assigned to a group or they would not get any alerts.
To add or change recipients for the Scheduled Reports follow these steps:
Login to your AlertSite account.
From the Control Menu, hover over Reports and select Scheduled Reports from the dropdown.
Click on the report name under Site/Device to display the Report Scheduler dialog.
Add or delete names and email addresses in the Distribution List. You may also disable email addresses to temporarily stop the report from being sent.
Click Save to save the changes.
If the regular monitoring interval and the fullpage monitoring interval are not the same, the number of fullpage checks will not equal the number of regular checks. With the Round Robin mode, the difference may be higher depending on how many locations you selected and how many locations you rotate through during each check. If you are an AlertSite Usage Based Monitoring customer, then all fullpage or regular monitoring intervals are the same so this will not be an issue.
The Fullpage Time Distribution tables, shown only for transactions with the Fullpage option applied, break down response times in 9 ranges from 0.0 to 30.0+ seconds.
Total Transaction Time displays the transaction response time as a percentage within each of those ranges, averaged over the report’s date selection. Transaction response time includes all network components and content download times for the whole transaction.
Individual Page Time displays the response time of each HTTP step as a percentage within each of those ranges, averaged over the report’s date selection.
For Site monitors with Fullpage enabled, only the Fullpage Time Distribution table is displayed.
This is the time it takes for the HTML content of the requested document to be downloaded, after the First Byte is received until the final byte of the HTML is received.
Status 82 does not involve network timeouts, but behind-the-scenes activities occurring inside the Firefox browser itself when a page is loading. Firefox informs DéjàClick about the progress of page loading with multiple notifications, for example:
Base (HTML) page is completely transferred.
All Objects have been transferred.
Ajax activity is in progress and so on.
DéjàClick then compares all these notifications (the "page loading pattern") with the ones encountered during the recording in order to determine if the page has finished loading.
If Firefox does not notify DéjàClick about this progress within the threshold specified in configured Browser timeout and HTTP step timeout values, DéjàClick reports it as
Status 82, Page took too long to load.
However, since our reports show network timings only, you might see response times displayed in the reports that are within the configured timeout thresholds even though
Status 82 is displayed.
Availability alerts are triggered and sent from the location directly as soon as an error occurs. Performance Alerts, however, have to be calculated at the core of AlertSite. The locations report data back to the core every few minutes. Once the data is at the core, the system determines if an Performance Threshold has been breached on the Performance Alert server. This can take several minutes as the data must propagate form the location to the core to the Performance Server before an breach is verified and triggered, and an alert is sent.
Private Node Server & InSite Questions
Security Scan Questions
The false positives are due to the fact that the remote server does not return HTTP code
404 for invalid (file-not-found) requests. Instead, it returns a custom error page with the
200 OK reply. This leads our Nessus scanner to believe the page is present, triggering the vulnerability. You can set the current results as false positive, but to prevent future false positives, configure the web server to return the HTTP
404 result code along with your custom error page.
The Nessus security scan runs against the Internet ports. If a port responds, it throws a range of possible vulnerabilities at it to see what could get in and reports on possible culprits, even if the specific program is not actually running on that port. Please see the solution at the end of the High Risk Vulnerability section of your vulnerability report. This is the standard recommendation from the Internet security community. There is a See also website referenced in the report that may provide further information to assist you. If you are certain that there is nothing making the port vulnerable, mark it as a false positive.
The AlertSite Standard scan runs checks against the ports defined by IANA (Internet Assigned Numbers Authority). All publicly available services will appear in this list. The list is updated frequently and can be found in the IANA Port Numbers List.
The IP address listed in the plugin output changes between runs, causing false alerts When plugins create report output, that output is used as a signature. That signature is what is used to determine if a vulnerability is new or recurring. Since the internal IP address is changing across runs, this is leading to this false alert (look for recurring IPs in the Security Scan Summary reports).
Recommendation: Mark this plugin false positive when it reappears on the edit security monitor page.
Got other questions?
Contact your AlertSite account manager. You can find the contact information in AlertSite 1.0, on the Support > Support Center screen.
To contact one of our Performance Advisors, email firstname.lastname@example.org or call 954-312-0188.