Management > Service Monitoring > Console User Guide
You can manage the services to monitor, the targets to propagate failures, and channels.
- Register monitoring and propagate / manage failure per service . To classify services logically for efficient management, a service tree is provided.
- Click the +Add button at the top of the service tree to add a service.
- Set the assignee who will receive the propagated failure.
- Only those who are registered as project members can be registered.
- First, register a group, and then select an owner of each group and a channel to receive the propagation information.
- When several propagation groups have been registered, if the first failure is detected,
- the failure is propagated to the first group only. User of the first group can select Propagate to the next group (additional failure propagation) or Stop propagation (not a failure) in the Propagation Status page.
If a failure is not handled within three hours, the failure is propagated to the next group.
When only one group has been registered
The failure is propagated to only one group and terminated.
When no group has been registered
- The failure is not propagated nor registered to the Propagation Status.
- Propagates a failure via email based on the ID registered in the member profile.
- Propagates a failure via SMS when a mobile phone number has been registered in the member profile.
- Provides a webhook function which calls the HTTP API on failure. The HTTP API should be registered according to the user's request (e.g. registration of GitHub issues and slack link). Information related to the detected failure, such as detection details, service name, and scenario name, is substituted to the pre-defined variables and used in the URL, header, and request data. The information is substituted and sent in case of failure propagation.
- In the editor where URL, webhook header, and request data are entered, you can view or use pre-defined variables using the AutoComplete (Ctrl + Space) function.
- You can check the history of detected and propagated failures.
- You can use a function that propagates failure to the next group or stops propagation.
You can monitor all web services which serve via HTTP and HTTPS.
- API Type
- Monitors REST API.
- You can register a scenario at every 30 seconds or higher.
- Virtual browser type
- Monitors the web page with a virtual browser.
- Module-type scenario can be included; if a module-type scenario is included, it is executed first sequentially and then the other scenarios are executed. Sessions and cookies of the module and the virtual browser scenarios are shared. With those, you can test whether or not the page is working after logging in.
- You can register a scenario at every 60 seconds or higher.
- Module Type
- Provides common features (such as login) for several scenarios.
- The module type cannot operate by itself; it only operates as part of the virtual browser type.
Scenario is verified in the following way.
||HTTP response code verification
||Verifies until the response time after request
||Verifies whether or not a specific text exists on the response data (screen)
||JsonPath and XPath supported
||Verifies whether an image exists on the response screen and it is downloadable or not.
||Only module and virtual browser types are supported
|Propagation Exception Verification
||No failure is propagated when a specific text exists in the response data (screen).
||Used for maintenance
Function Support of Array Data for JsonPath Text Verification
||Minimum Value of Array Data
||Maximum Value of Array Data
||Sum of Array Data
||Average Value of Array Data
||Standard Deviation of Array Data
||Array Data Count
|> Functions are available only for such sequence data that are included to a response body
You can use TCP, UDP, and ICMP protocols for monitoring.
Unlike web monitoring and TCP monitoring, this batch monitoring does not try monitoring directly from the Service Monitoring. Users call the API provided by Service Monitoring and then Service Monitoring verifies API data to determine a failure state.
- Contents Verification
- Determines whether failure occurred or not by comparing user-registered scenario in advance with data which are actually sent by users.
Compares scenario data with actual data using - JsonPath (https://goessner.net/articles/JsonPath/).
- Count Verification
- Determines whether failure occurred or not by comparing the count of user requests with the user-specified count during a specific period of time.
- A build result from the build server can be sent to the batch monitoring server to monitor the result.
- Executes the daily batch and then calls the batch monitoring API to monitor whether or not the daily batch has been successfully operated.
- Stop Propagation Temporarily is a function that does not consider known failures (such as distribution) as failures even if this kind of failure occurs.
- Stop Propagation Temporarily can be set for each monitoring.
- You can set the start and end time. After the specified period, the failure is propagated to the specified propagation group.