Endorsement request - Monitoring: Architecture and Interoperability Guidelines

Wolfgang Pempe (reviewer, not EIAC member)

John Shepherdson

A general comment, the current guideline is somewhat in the middle between a user guide and interoperability guideline. And to be a interoperability guideline it is I think missing some information. I think we need to find the right balance.

Kostas Koumantaros to address within the respdond and/or provide new version.

No clear actions suggested.

S4. The high-level architecture diagram provides an high-level overview of the monitoring service, but is missing the stakeholders and some of the interfaces on how the monitoring is actually executed on the external services. I think a high level diagram should focus more on the integration options with external stakeholders and services that should be monitored. I think this would be more helpful for providers who are willing to adopt the monitoring service.

Kostas Koumantaros to address within the respond and/or provide new version.

Updated the architecture diagram with a revised version.

S4.1 Definitions

In the section tenant, the URL provided are in the “ui.argo.grnet.gr” domain, should this not be in the eosc-portal.eu domain?

Kostas Koumantaros to address within the respdond and/or provide new version.

updated the links.

S7.1. Maybe add a reference where providers can find which Service Types are currently supported

Kostas Koumantaros to address within the respond and/or provide new version.

Added a footnote with a link to a list of service types supported

S7.2 Provide details on

• • How the Infrastructure Topology must be specified within the email
  • Definition on the Metric Profile
  • Definition on the Aggregation Profile

I think this are typical details which should be defined in the guidelines. If these profiles are used in multiple integration options, this can be defined as separate sections.

Kostas Koumantaros to address within the respond and/or provide new version.

This is too much detail for the scope of the guidelines 

more info on the topology and profiles is given at the documentation website.

S7.3

• The type of system used! Is any system OK, or is this limited to a few monitoring systems? If the latter, which ones?
• Some comments on Infrastructure Topology and Profiles as above!
• In the text box “define service {“ the host_name is defined as “grnet.gr”, is this an example or should it defined as “grnet.gr”? I assume this is an example, therefore explain the fields which should be defined with local information.
• In the first sentence in the section “Other monitoring systems”, there is a reference to “case 3.1”. I am not sure if this is the correct reference?
• In the section Other monitoring systems the following information ““The data should be stamped with their source and timestamp. Every metric should be prefixed with [source_type], following the metric naming best practises. Every metric is also labelled with the hostname and service description.” Is not clear, at least to me, in the example text box below this section.
• I the text box to define the metrics data a lot of information is request and needs to be defined. A description on the definitions needs to be provided, and an example is helpful.
• Kostas Koumantaros to address within the respond and/or provide new version.

revised the paragraph and removed a number of technical details as its was suggested.

S7.4: An example on what should be provided would be helpful.

Kostas Koumantaros to address within the respond and/or provide new version.

S7.5:

• An example on what should be provided to request this kind of access will be helpful.
• I would expect a description of the API definition to read information from the EOSC monitoring to be include in the guideline. Some information can be extracted from the example, but it would be nice to have first the definition and secondly an example.Kostas Koumantaros to address within the respond and/or provide new version.

Generally speaking I think the document reads well.

Kostas Koumantaros to address within the respond and/or provide new version.

Thanks for your feeback.

Is there some reference to the requirements of the monitoring service? It is unclear why some technical decision have been made, while others commonly found in a monitoring service are left out E.g.:

Kostas Koumantaros to address within the respond and/or provide new version.

No reference available for requirements.

• Section 4.2 seems to suggest only website with http(s) will be monitored, while I assume other protocols might be relevant as well. Are these not included into the monitoring?Kostas Koumantaros to address within the respond and/or provide new version.

Section 4.2 uses a website as an example but the metrics the Monitoring service uses are specialised to the service being monitored.

• Monitoring may also be used to prevent downtime, by e.g. checking validity of https certificates. Is that also in scope?
• Kostas Koumantaros to address within the respond and/or provide new version.

yes one can associate extra monitoring metrics to his/her service 

• Technical monitoring by itself is often not enough to determine if a service is "up" or not. Certain parts of the service might not be functioning, however this may not impact all users. Will the portal be able to support such business logic?
• Kostas Koumantaros to address within the respond and/or provide new version.

yes the metrics try to simulate the users actions on a service. It is therefore up to the service provided to provide the necessary probes. But this is too much technical details which is not described on purpose on this guidelines but reference documentation on how to provide probes.

Section 7.3: Should such a technical detailed configuration details really be part of the main text? I would suggest putting them in an annex or even on a technical documentation wiki?

Kostas Koumantaros to address within the respond and/or provide new version.

removed techical details and added reference to the documentation website.

   Page 15 seems to gave a layout issue "7.5.1 Example used:"

Kostas Koumantaros to address within the respond and/or provide new version.

fixed.

removed references to debian 8