Frequently Asked Questions (FAQs)

Q: How does bello network monitoring calculate the uptime/downtime values?

A: When you generate a graph for a sensor or receive a report email bello network monitoring calculates two uptime/downtime monitoring values: One value is the time in hours/minutes and the other is the number of good and failed requests. Both values can be different because of the way bello network monitoring calculates these values. If a request for a previously available sensor fails for the first time bello network monitoring immediately sends out the next request instead of waiting for the configured interval. If the second request also fails the sensor is regarded to be unresponsive and will be monitored using the configured interval again. These good and failed requests are counted for the graph. When calculating the uptime value bello network monitoring reads the monitoring data from the activity database and sums up the time steps between all UP events for the "UP" time. An interval between an UP and a DOWN event is counted as UP and an interval between a DOWN and an UP event is counted as DOWN. Times without monitoring data (e.g. when bello network monitoring does not run or the program is restarted or a sensor was inactive due to a schedule) are not counted at all.

Q: What does a DOWN state for a sensor mean?

A: There are several reasons why a sensor fails and bello network monitoring reports a "down" state. A common problem is related to faulty hardware -- a malfunctioning connection -- but if this possibility has been eliminated, a reason associated with the software can be tricky to track.

Here is a quick checklist to keep on hand of what to go through if bello network monitoring reports a sensor failure:

PING Sensor: The most common reason for a PING sensor to fail is that the sent packet did not reach the server, or the returning packet was not delivered back to the machine running bello network monitoring. Check the firewall between the server and the monitoring machine -- the firewall program may be rejecting packets because PINGs are not allowed under its rules. (When monitoring a remote server, a small amount of lost PINGs (1-2%) is usually considered not harmful.)

PORT Sensor: A down port sensor indicates a hardware or a server process issue. Check the connection and the service.

HTTP Sensor:Look for internal server errors ("error code 50x") and carefully check for incorrect URL addresses.

HTTP Advanced Sensor: Unfortunately, there are numerous possibilities. To locate the specific problem, it is best to examine the result string.

HTTP Transaction Sensor: Look for failed single requests, or timeouts for a single request or the complete sequence.

DNS Sensor: Four possibilities: 1) The DNS server cannot be reached because it is down. 2) The DNS server did not respond according to the protocol. 3) The domain name is invalid and could not be resolved. 4) The optional IP address is different from the IP resolved by the server.

SMTP Sensor: Check to see if the sensor's settings comply to the SMTP protocol, if it has been set to refuse email from a given domain/address, or if it simply has been set to refuse email. See the result string for more details.

POP3 Sensor: Check to see if the sensor has been set to comply to the POP3 protocol, if it has been set to not accept the login of a specific user, or if a user is not permitted to request a number of available mails. See the result string for more details.

FTP Sensor: The sensor does not comply with the FTP protocol or does not accept the login of the given user. See the result string for more details.

How do I set up an HTTP Transaction Sensor?

A: Using HTTP Transaction Sensors you can monitor a sequence of URLs on a webserver. This is useful to make sure that putting products into a shopping cart and then passing the checkout actually works. The HTTP Transaction sensor simulates the HTTP requests that are sent to a server by a user visiting a sequence of webpages. For this simulation you must feed the URLs and their POSTDATA (for POST requests only) into the HTTP Transaction sensor. Now figuring out the URLs is pretty simple, because you can simply copy the URLs from the URL edit field of our web browser. But getting a hand on the POSTDATA is not so easy.

By using Paessler URL Recorder you can get the POSTDATAs with a few mouseclicks also. This programs helps to find out the URLs and the POSTDATA strings that a user sends to a web server while surfing a sequence of URLs. (Paessler URL Recorder Download)

Simply download, install and run the software. It works like a standard web browser where you can enter a URL at the top and click "Go". Then you can use the mouse etc. to surf through the sequence you want to record. While you are accessing one page after the other the URL and - if you submit a POST request - the POSTDATAs are stored in the list at the bottom of the windows. When you are done you can use the URL lists's context menu to save the list of URLs to CSV and HTML, copy the list to the clipboard, and copy individual URLs or POSTDATA to the clipboard. If you need additional analysis features please also have a look at our product Site Inspector.