Monitors¶
All monitoring activity in Argus is built upon the concept of Monitors. A single monitor can be checked from different locations simultaneously, only triggering a notifiable event if a certain amount of check locations agree upon that a monitor is not available or not responding in the desired way.
This is a significant difference in handling multi-location monitoring compared to other monitoring services which usually only checking from a second location if the primary location is reporting a check as failed. With Argus you not only get a second opinion on whether a monitor is down or not, but real-time parallel checks that are constantly evaluated against a defined quorum to determine whether a host is considered up or down.
Check Type¶
As of today, Argus is offering two different kinds of checks.
ICMP (Ping)¶
An ICMP check is the simplest form of a network availability check. It sends an ICMP packet to a target and expects a ICMP response packet within a defined time. If it doesn't receive the response within that time, the monitor is considered down.
Pitfall
ICMP traffic may get dropped with priority if a device becomes overloaded. ICMP traffic is known to not carry user payload and has its purpose in debugging, therefore, it gets treated as less important than network packets that carries actual data.
Depending on which target you're monitoring, you might cause false positive notifications with sending only one or two ICMP packets, hence Argus has a default of four ICMP packets of which only one needs to come back as response to consider the host available.
HTTP¶
An HTTP check involves sending an actual HTTP request to the target and evaluating an actual HTTP response to determine whether a host is up or down.
That kind of check can be fine-tuned with a lot of possible settings to tailor the HTTP request that is being sent (including request method, custom headers, custom payload in the body as well as instructions on what to do with redirects) as well as how to evaluate the HTTP response that's coming back to the Argus monitoring agent.
Customers use this kind of check for their web-based applications and services and often target specialised health check endpoints that return a certain HTTP status code depending on their health state. This makes it easy to determine whether a monitor should be considered available or not.
Monitoring Target¶
The target of a monitor can be provided either with an IP address or with a publicly resolvable hostname.
If a hostname is used, it will be resolved before each and every check. In case the DNS contains an IPv6 record for the hostname, that that record is preferred over an IPv4 record, as IPv6 is the more modern protocol.
In case you want to avoid that the check is happening via IPv6, you either need to provide a hostname that doesn't resolve to an IPv6 address or manually provide the IPv4 address instead of a hostname to skip resolution.
For HTTP checks, you need to provide the protocol (http:// or https://) as well to instruct the Argus monitoring agent whether it should attempt to build a secure connection for the check or not. The check will fail, if a TLS connection is being used with an invalid certificate or with a certificate from a CA that is not publicly trusted.
Monitoring Locations¶
For each monitor, you can choose one or many monitoring locations. Your monitoring target will be checked from all locations you choose for it simultaneously. The amount of selected monitoring locations is relevant for your quota calculation as Argus' quota and limitation enforcement doesn't work based on the amount of monitors, but rather on the amount of checks.
To learn more, please see our documentation on Billing & Quotas.
Check Interval¶
Feature Availability
Check intervals less than 60 seconds (sub-minute intervals) are a paid feature that is not available for every user. Access to more frequent intervals with up to one check every 10 seconds is available starting from the Essential plan.
The check interval for a monitor defines in which frequency the defined checks should be executed against a monitor target from all locations in parallel.
Pitfall
High frequency checks against websites that are prone to performance issues under load, might cause stress on the target. When configuring e.g. 9 check locations, it might happen that all 9 HTTP requests are being sent from all locations to the check target in the same second, although Argus of course tries to spread checks against the same target as good as possible over all enabled locations.
Quorum¶
The quorum is the most powerful setting in monitor configuration. It specifies how many of the selected check locations need to come to the same conclusion regarding the availability of a monitor to cause a notifiable event (a monitor going down after being up before and the other way round).
The minimum quorum is always 1, while the maximum quorum always equals the amount of selected check locations.
Example
You are configuring a monitor with 5 check locations. The smallest quorum is 1 location. The highest possible quorum is 5 locations.
When an Argus monitoring agent is reporting a status change for one of your monitors, our check engine is evaluating what the current stored status for your monitor is and whether the quorum is met to change that status. Only if as many check locations as defined in the quorum (or more) are returning the same check result, that result is considered valid.
Example
You are configuring a monitor with 5 check locations. With a quorum of 1 location, the status change of a single location is sufficient to let the monitor transition from e.g. up to down, causing a notifiable event. With a quorum of 5 locations, all configured locations need to simultanously agree upon the monitor being unavailable, before the status transition is being applied and a notifiable event is being created.
Setting the quorum to a smaller value, will increase the probability of false positive notifications and thus increase potential monitoring noise. Setting the quorum to a higher value, will increase the reliability of the check results and subsequently sent out notifications with the cost of possibly not detecting regional outages and unavailability.
Default Value
Unless you manually edit the quorum value for a monitor, it defaults to an amount of locations that comes as close as possible to 51% of the locations as it's highly desirable to have a majority of locations agree upon a status change. This is the sweet spot between avoiding false positive notifications and having a quick reaction time to potential monitoring events.
Check Settings¶
Depending on which check type you chose for your monitor, you can configure different check settings for its execution and response evaluation.
ICMP¶
Packet Count¶
This setting defines the amount of ICMP packets that should be sent to the monitoring target. You can not send less than 1 ICMP packet and no more than 10 ICMP packets towards the monitoring target.
Timeout¶
The timeout for each ICMP packet to be sent to the target is defined in milliseconds (1000 milliseconds equal 1 second). The smallest possible ICMP timeout is 100 ms and the highest ICMP timeout is dynamically calculated based on how many ICMP packets you send and which check interval you chose for your monitor to avoid overlapping checks.
Pitfall
The timeout is configured for each ICMP packet and not for the overall check execution.
If you're sending 4 ICMP packets with a timeout of 1000 ms each, the Argus monitoring agent will report your monitor as unavailable if any of the 4 ICMP responses it expects to receive from your monitoring target takes longer than 1000 ms.
Highest ICMP Timeout Example
Given an ICMP monitor with a check interval of 10 seconds and an ICMP packet count of 5 ICMP packets per execution cycle.
The highest possible ICMP timeout in milliseconds is calculated as (Check Interval * 1000 ms / ICMP Packet Count) - (ICMP Packet Count - 100 ms) = 1500 ms.
Mathematically it could be as high as 2000 ms, however we're considering 100 ms of grace time for each sent ICMP packet to make absolutely sure we don't get any overlapping checks, potentially causing confusing results for users.
HTTP¶
Request Method¶
By default, the HTTP request method is set to HEAD offering a quick and easy way to determine whether there's a webserver up and running behind the monitoring target's URL.
You can however choose the HTTP request method from the following list of possible methods:
HEADGETPOSTPUTDELETEOPTIONSPATCH
If you need to send a custom request body, you must set the HTTP request method to either POST, PUT or PATCH, as the other HTTP request methods don't support carrying an HTTP request body.
Request Timeout¶
The request timeout for the HTTP request defines the time in milliseconds (1000 milliseconds = 1 second) after which the Argus monitoring agent should stop awaiting a reply from the HTTP server, consider the request failed and thus, mark the monitor as unavailable from its point of view.
The timeout can not be set to less than a second (1000 ms) or more than 30 seconds (30,000 ms).
Pitfall
Setting this value too low will likely cause false positive notifications to be sent out for this monitor. Even when you expect the page to respond within a second, you should probably set it to a higher value to account for cases where the page is experience performance impacts. These performance KPIs should be monitored using other means of monitoring as Argus is primarily designed as availability monitoring tool and not to measure response or FCP times.
Follow Redirects¶
By default, the Argus monitoring agent will follow HTTP redirects (HTTP 3xx status code) and only evaluate the HTTP response at the end of the redirect. The amount of followable redirects is limited to 1 redirect.
Common Use Case
This behaviour can be disabled, if you e.g. want to evaluate the redirection target of a certain URL in which case you could match against the Location header's content in the response evaluation settings (see below).
Custom Request Headers¶
You can add up to 10 custom headers to the HTTP request that is being sent to your monitor's target.
Common Use Case
Custom request headers are commonly used for authentication, effectively checking against HTTP endpoints that are not publicly reachable. It's also a useful parameter to define which Content-Type is being sent when using custom request bodies or which kind of MIME to expect in the server's response (Accept header).
Pitfall
Any User-Agent header provided by the user will be ignored. The Argus monitoring agent will always send its own user agent, no matter what's defined in the custom request header section for a monitor.
Custom Request Body¶
You can add a custom request body of your choice to the HTTP request the Argus monitoring agent makes towards your monitoring target. If you're adding a body with a certain MIME type, you should consider adding a Content-Type header to your request as well to let the server know how to interpret your body.
The request body can not exceed 2048 characters.
Common Use Case
Custom request bodies are commonly used to check API endpoints that expect a certain payload and to then check for a certain response to see whether the API works as intended. Also, some endpoints might require authentication within the body instead of using headers for that purpose.
Expected Response Codes¶
In this section, you can configure at which HTTP status codes the Argus monitoring agent should consider your monitor up or down.
By default, all HTTP status codes starting with 2xx and 3xx are considered successful. You can however override this behaviour to tailor it to your specific needs.
Common Use Case
This feature is also used by customer to establish a negative monitoring by checking whether a page that shouldn't be publicly avaiable, properly returns an error code instead of delivering the actual page.
Expected Response Headers¶
As with the expected response codes, this setting can be used to define that you want a certain set of headers within the response to the Argus monitoring agent to consider the monitor to be available.
You can add up to 10 expected headers to a monitor.
If you define an expected value for an expected response header, this value is matched against the received string. The usage of regular expressions is currently not supported within that setting. If the response doesn't contain the expected header or its value doesn't exactly match the provided value, the check is considered failed.
If you leave the expected value for a header empty, only the presence of the header is verified, regardless its value. If the header's missing, the check is considered failed.
Expected Response Body¶
Finally, you can define an expected response body for the evaluation of the response the Argus monitoring agent receives from your monitored service.
When working with expected bodies, you can choose from two different evaluation modes. By default, response body evaluation is disabled as it requires specific configuration to match your needs and the monitored target.
Pitfall
Keep in mind that all evaluations are against the raw response body. This may include HTML or escaped characters that can not be matched properly. A รถ character may be returned as ö, depending on the encoding of the return content.
Keyword¶
If you provide a keyword (which is just a plain string), the raw response body will be scanned for the presence of that very string (including e.g. all whitespace provided within the keyword string).
Once the keyword is found for the first time in the output, response evaluation is stopped to reduce resource usage and the check is considered successful.
If the keyword can not be found within the response body, the check is considered failed, although this behaviour can be altered by making use of the inverted check mode (see below).
Regular Expression¶
If you provide a regular expression, the raw whole raw response body is evaluated against it. Using a regular expression allows a more fine-tuned check behaviour as you are able to utilise a broader feature set.
Regular Expressions
When building regular expressions for HTTP response evaluation, make sure you're using the Golang flavor. You should use tools like regex101 to check whether your regular expression is valid or not.
Inverted Check¶
In addition to the two evaluation modes described above, users have the possibility to invert the body evaluation logic.
By enabling this option, the check is considered failed, if the keyword or the regular expression is indeed present in the response body.
Common Use Case
This feature is commonly used to ensure that a website is e.g. not returning any errors. The presence of a certain error term may indicate that something is wrong with the monitored service.