[IRS][TRACE-X] 🌟🚀 Metrics Provision and Integration for IRS and Trace-X

[mkanal]

Overview

Explain the topic in 2 sentences

Collecting and providing IRS and Trace-X performance metrics to Prometheus where it could later be imported to e.g. Grafana to have a monitoring of the products regarding performance Metrics and KPIS.

What's the benefit?

Product provides performance metric which could be shown.

What are the Risks/Dependencies ?

• Nothing to report

Detailed explanation

The system should collect various operational metrics from IRS and Trace-X as specified, ensuring that these metrics are available through the Prometheus interface for monitoring and visualization in Grafana. These metrics should cover contract negotiation durations, twin synchronization, asset requests, and API orchestration flows, all of which are essential for the performance and reliability monitoring of the system.

Current implementation

IRS already provides metrics via Prometheus. This will be extended.
Trace-X doesn't provide metrics via Prometheus.

Proposed improvements

• EDC Contract Negotiation (Duration)

  • Metric: Duration per notification
  • Measurement Points:
    • Start: POST /management/v2/contractnegotiations
    • End: Endpoint response with codes 200, 400, 405, etc.
  • Metric Aggregation: Duration avg, max, min, peak of responses with different response codes.
  • Prometheus Integration: Metric data exposed to Prometheus.
  • Grafana Visualization: Displayed as time series with avg, max, min, peak.

• Sync Duration for Sync Total Amount of Twins in DTR

  • Metric: Duration in seconds per aasIdentifier
  • Measurement Points:
    • Start: /lookup-shells
    • End: 200 Requested Asset Administration Shell IDs
  • Metric Aggregation: Duration avg, max, min, peak of responses with different response codes.
  • Prometheus Integration: Metric data exposed to Prometheus.
  • Grafana Visualization: Time series chart displaying sync duration metrics.

• EDC Asset Requesting Flow (DTR)

  • Metric: Duration in seconds for EDC flow
  • Measurement Points:
    • Start: GET catalog with filter
    • End: Response received
  • Metric Aggregation: Duration avg, max, min, peak of responses.
  • Prometheus Integration: Metric data exposed to Prometheus.
  • Grafana Visualization: Displayed as time series with avg, max, min, peak.

• EDC Asset Requesting Flow (Asset)

  • Metric: Duration in seconds for EDC flow
  • Measurement Points:
    • Start: GET catalog with filter
    • End: POST /management/v2/transferprocesses
  • Metric Aggregation: Duration avg, max, min, peak of responses.
  • Prometheus Integration: Metric data exposed to Prometheus.
  • Grafana Visualization: Displayed as time series with avg, max, min, peak.

• EDC Twin Requesting Flow

  • Metric: Duration in seconds for transferring assets
  • Measurement Points:
    • Start: /management/v2/transferprocesses
    • End: Transfer process response received.
  • Metric Aggregation: Duration avg, max, min, peak of responses.
  • Prometheus Integration: Metric data exposed to Prometheus.
  • Grafana Visualization: Displayed as time series with avg, max, min, peak.

• Order API Orchestration Before Processing

  • Metric: Order processing organization duration
  • Measurement Points:
    • Start: POST /irs/orders
    • End: DTR GET /shell/descriptor/[aasIdentifier]
  • Metric Aggregation: Duration avg, max, min, peak of responses.
  • Prometheus Integration: Metric data exposed to Prometheus.
  • Grafana Visualization: Displayed as time series with avg, max, min, peak.

Feature Team

Contributor

• Cofinity-X @rogocof
• Cofinity-X @mkanal

Committer

• @ds-jhartmann
• @ds-mwesener
• @ds-lcapellino

---

User Story

As a team,
I want to collect and provide IRS and Trace-X metrics to Prometheus
So that they can, the team could monitor key performance indicators in Grafana.

Description:

The system should collect various operational metrics from IRS and Trace-X as specified, ensuring that these metrics are available through the Prometheus interface for monitoring and visualization in Grafana. These metrics should cover contract negotiation durations, twin synchronization, asset requests, and API orchestration flows, all of which are essential for the performance and reliability monitoring of the system.

Acceptance Critieria

• Metrics provided over Prometheus
• Metrics available in Grafana
• Metrics are implemented
• EDC Contract Negotiation (Duration)
• EDC Asset Requesting Flow (DTR)
• EDC Asset Requesting Flow (Asset)
• EDC Twin Requesting Flow
• Order API Orchestration Before Processing

---

Test Cases

Test Case 1

Steps

1. Do something
2. Click something
3. Add something

Expected Result

1. Expectation
2. Expectation
3. Expectation

Architectural Relevance

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

• 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)
  • 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: (Fill this out, if at least one of the checkboxes above cannot be ticked. Contact the Architecture Management Committee to get an approval for the justification)

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)

[stephanbcbauer]

Some hints from Release Management (@ther3sa) and Tractus-X Project Lead (@stephanbcbauer)

• Status currently in Backlog -> Since for Backlog some requirements are missing ... please update them
• Please add missing sections from the feature template, or fill them out
• Please add assignee (overall responsible person who drives the feature)

[mkanal]

@eckardg and @JSterthues
This feature will be moved from 25.3 to 25.3.
CC: @rogocof

[stephanbcbauer]

I deleted the milestone, since the milestone is set together in the open planning session. This means ⇾ commitment to work on the feature. THX

[stephanbcbauer]

was not presented in open planning. Nobody was available.