forked from ejpsoil/soildata-assimilation-guidance
-
Notifications
You must be signed in to change notification settings - Fork 0
/
QOS.qmd
51 lines (32 loc) · 4.47 KB
/
QOS.qmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
---
title: Overview Quality of Service
summary:
authors:
- Paul van Genuchten
date: 2022-11-10
---
# Overview Quality of Service
Via the quality of service conventions data providers report about the quality of their services. Aspects which are monitored are:
- Availability (% of the time that the service has been available)
- Performance and capacity (a period in which performance and capacity requirements are not met, is considered downtime)
- Usage (how much is the service used)
In each of the technical guidelines on [view](https://github.com/INSPIRE-MIF/technical-guidelines/blob/2022.2/services/view-wms/ViewServices.adoc#quality-of-services), [download](https://inspire.ec.europa.eu/documents/technical-guidance-implementation-inspire-download-services) and [discovery](https://inspire.ec.europa.eu/documents/Network_Services/TechnicalGuidance_DiscoveryServices_v3.1.pdf) services a chapter is dedicated to Quality of Service. It includes the aspects of:
Reporting about usage of the service is documented in the [monitoring guidelines](https://inspire.ec.europa.eu/documents/inspire-monitoring-indicators-%E2%80%93-guidelines-document-0) paragraph 1.7. As a data provider you may be requested to provide this data to the national contact point. The national contact point reports these numbers to Europe. Aside the reporting obligations, usage reports are interesting feedback to guide future developments.
Measuring and reporting about Quality of Service is an aspect of step `7) Soil Information User Consideration` in the [soil information workflow](https://www.isric.org/index.php/utilise/community-practice). Consult your IT department or hosting company if they have tools available to assess these aspects. Confirm with them on how to extend and/or share with you these measurements for the requested parameters.
## Availability monitoring
To assess the availability of a service, it requires to monitor the availability of the service at intervals. A basic availability-test every 5 minutes is sufficient. Many software exists for availability monitoring, such as [Zabbix](https://zabbix.com/), [Nagios](https://nagios.org/), [CheckMK](https://checkmk.com/), [pingdom](https://www.pingdom.com/). A special mention for the Python based [GeoHealthCheck](https://geohealthcheck.org/) package, which includes the capability on WMS/WFS services to drill down to the data level starting from the GetCapabilities operation.
| Cookbook | Software | Description |
| --- | --- | --- |
| [GeoHealthCheck](cookbook/geohealthcheck.qmd) | [GeoHealthCheck](https://geohealthcheck.org/) | A utility to report on availability of a service |
## Performance & Capacity testing
To know the capacity and performance of a service you can perform some load tests prior to moving to production. An alternative approach to evaluate performance is to extract the access logs of the service into an aggregation tool like [Kibana](https://www.elastic.co/kibana) and evaluate the number of requests exceeding the limits.
| Cookbook | Software | Description |
| --- | --- | --- |
| [Capacity tests with jmeter](cookbook/jmeter.qmd) | [jmeter](https://jmeter.apache.org/) | Utility for performance and capacity testing |
!!!note
A common challenge to service performance is the provision of a WMS service on a big vector dataset. When requesting that dataset on a national level, the server runs into problems drawing all the features at once. In such case consider to set up some cache/aggregation mechanism for larger areas. Setting proper min/max scale denominators may be a solution also.
## Usage monitoring
To capture the usage of a service you can extract the usage logs and import them in a tool like Kibana, [Splunk](https://www.splunk.com/) or [AW stats](https://awstats.sourceforge.io/). Defining rules to extract the requested layer name from a WMS request is useful. Mind that not all requests are GET requests, some WFS requests use POST, which may need some configuration on the webserver to enable POST parameter logging. Make sure the logging includes the 'Referer' and 'User-agent' parameters, which allows to differentiate types of uses. Finally consider there is a [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj) privacy aspect to collecting access logs. Consider to exclude the IP address of the user and define a maximal retention for access logs.
| Cookbook | Software | Description |
| --- | --- | --- |
| [AWStats](cookbook/awstats.qmd) | [AWStat](https://awstats.sourceforge.io/) | A utility to report on service usage |