Overview of failed Services and/or their Elements

SigritSiht commented 2 years ago

AS A Service Manager I WANT TO have an overview of failed Services and/or their Elements SO THAT I could enforce the technical team to get them fixed

https://www.figma.com/file/yF3ywx7OaufCTXlQNpJ1ub/B%C3%BCrokratt-Service-module-2023.03?node-id=286-32213

Logs deep-dive is done by using appropriate (DevOps and/or Service Managers) tools The Analytics Module also covers finding buggy Services (among others)

The scope of this issue is to give a near real-time overview of Services / Elements that are currently not working in test and production

Based on: Triggering a Service

Acceptance Criteria

[ ] Group by Services / Elements / both
[ ] Faulty Services with their details are shown in a pop-up in a human-readable format
[ ] Only the Services / Elements that are currently not working are shown
[ ] If all the Services are working correctly, this sub-page is empty
[ ] No historical view of previously failed Services / Elements is shown on this sub-page
[ ] All of the above applies to both test and production environments
[ ] Replace mock data with live data reported from bot

GUI

[x] Use existing filtering components to filter values by column
[ ] Environment where the problem occurs, is clearly stated in a separate filterable column
[ ] REST endpoint /overview/services-detailed/nok is used to fetch a list of faults

ETL pipelines

ETL pipelines are out of the scope of this issue and will be done internally by Bürokratt

[ ] Ruuter logs are transported to an appropriate OpenSearch index

DSL

[ ] REST endpoint /overview/services/nok to fetch a list of currently faulty Services
[ ] REST endpoint /overview/elements/nok to fetch a list of currently faulty Elements

The above endpoints will be used and merged by

[ ] REST endpoint /overview/services-detailed/nok to fetch a list of currently faulty Services with details about the Elements causing the problems, covering Elements and count for the total times the error has occurred
[ ] #91 is used as input for the endpoints above

Opensearch

[ ] Index schema
[ ] REST endpoints to populate index schema with mock data for initial testing
[ ] Fetch data based on a specific Ruuter request ID
[ ] Fetch data based on business-level AC requirements

turnerrainer commented 1 year ago

@SigritSiht we have developments planned for that done within another procurement (CentOps).

But this issue still makes sense as these are Service Module-specific requirements. Links to GUI to guide to proper CentOps dashboards should be created.

turnerrainer commented 1 year ago

@SigritSiht ...

[ ] log files' export to file created

[ ] log files' export files can be downloaded

These ACs will be defined by CentOps;
Most likely, CentOps will set restrictions to exporting logs to prevent potential security risks (in production).

SigritSiht commented 1 year ago

Previously mentioned AC's deleted because they were not important and didn't add much to the project.

baha-a commented 1 year ago

Most of the functionality should belong to the Analytics Module

Should be part of the Analytics Module

Hi @turnerrainer, What exactly do these mean? Does it imply that the code for this issue should be included within the Analytics Module repository? Or is it sufficient for the related page to only appear under the Analytics Module section in the user interface?

SigritSiht commented 1 year ago

https://github.com/buerokratt/Ruuter/pull/45

turnerrainer commented 1 year ago

This task for previously called "Service's feedback based on Ruuter logs"