Prepare technology basis for metrics in the Tractus-X connector

[lgblaumeiser]

Overview

As part of C-X Next TAP 7.2, a set of metrics should be realized that allow to manage the operations of the connector both on a domain level as well as the technical level. In order to realize the metrics, a tech stack needs to be decided upon, which will be used consistently to create and provide measurements. Current technology stack alternatives are:

• A standard metrics endpoint family which provides the necessary information in the form of rest calls that are triggered from outside
• Using OpenTelemetry to create and forward the measurements using the OpenTelemetry mechanisms to provide the information to data sinks that process the information accordingly

What's the benefit?

A consistent technology stack to provide metrics information for management of operations of the connector

What are the Risks/Dependencies ?

Main dependency is, that it has to be possible to use standard tooling like Prometheus to manage the measurements and to provide the information in dashboards or to create alerts in certain situations.

Detailed explanation

Current situation is, that the connector contains OpenTelemetry, but logging and monitoring is not based on a common concept. With this feature in place, a general decision on a technology stack is available and a basic documentation describes how metrics should be realized in a consistent way.

Feature Team

Contributor

• C-X Next TAP 7.2 team

Committer

• @lgblaumeiser
• @rafaelmag110

User Stories

• Main issue: Metric framework decision tractusx-edc#1745
• Related: Implement Metrics in EDC and IdentityHub tractusx-edc#1732

Acceptance Criteria

• A decision record is processed, that documents the decision on the technology stack for metrics and the integration into the connector
• A documentation for metric creators exist that describes how metrics can be added to the framework

Test Cases

Test Case 1

A first metric is implemented as example implementation, the data is observable from a running connector

Architectural Relevance

The following items are ensured (answer: yes) after this issue is implemented.

In the context of the standards 126 and 127, typically only one is applicable, depending on the specific use case. Please cross out one of the two standards that does not apply.

• This feature aligns with our current architectural guidelines
  • Data Sovereignty: All data sharing activities across company boundaries follow the Catena-X Regulatory Framework, in particular the Data Exchange Governance, and the Dataspace Protocol via a compliant Connector (like the tractusx-edc or similar, see Connector KIT)
    • CX-0010 Business Partner Number
    • CX-0013 Identity of Member Companies
    • CX-0018 Data Space Connectivity (EDC)
    • CX-0049 DID Document Schema
    • CX-0050 Framework Agreement Credential
    • CX-0149 Verified Company Identity
  • Interoperability: Digital Twins are used (compliant to the Digital Twin KIT and the Industry Core KIT)
    • CX-0001 EDC Discovery API
    • CX-0002 Digital Twins in Catena-X
    • CX-0018 Data Space Connectivity (EDC)
    • CX-0126 Industry Core: Part Type 2.0.0
    • CX-0127 Industry Core: Part Instance 2.0.0
  • Data Format:
    • The data model is based on a published Semantic Model
• The impact on the overall system architecture has been assessed. The Feature does not require changes to the architecture or any existing standard? Please have a look here on the overarching architecture
• Potential risks or conflicts with existing architecture has been assessed

Justification: n/a

Additional information

• I am aware that my request may not be developed if no developer can be found for it. I'll try to contribute a developer (bring your own developer)