Metric framework decision

[lgblaumeiser]

WHAT

A decision record is created that describes, how metrics are created and provided within the connector. In addition, documentation describes that usage of the framework. Metrics are related to the domain level, i.e., business level metrics like number of contracts, number of exchange partners, transfer processes and on the other hand to a technical level to manage the operations like certain resource metrics.

WHY

As operator of a Tractus-X connector, it is crucial to get information on the status of the connector in order to manage the operation. As domain expert providing a certain use case, also information about certain activities are needed, e.g., to gete information relevant in certain audits. There should be a general approach how the metrics should be realized and how they are forwarded to backend systems, so that it can be processed further according to the reporting needs.

HOW

There are two potential solution proposals for now:

1. Provide metrics using a family of metrics endpoints
2. Use the OpenTelemetry infrastructure that is already included to provide the metrics

The decision record should outline the intended solution. A documentation should give insides on how to use the infrastructure to create metrics. If necessary, implementation tasks should be created that describe necessary actions to get to a realized framework for the metrics.

[ndr-brt]

Just as a quick comment, we should not suggest solution number 1 at all, because that's non optimal, putting application metrics endpoints on the application is not a good practice because:

• it puts load on the development as endpoints need to be maintained.
• it's not flexible because to apply a change or a fix on the way the data is built a deployment will be needed.
• potentially affects performance / causes outgages

I would add a solution:

• providing a way to grab application events that can then be consumed by external tools (like ELK stack, Grafana Loki or similar)

[ma3u]

There is an implementation task already:

• Implement Metrics in EDC and IdentityHub #1732

I already had a discussion with @ndr-brt the suggested best practice is the EDC eventing framework.

[ndr-brt]

There is an implementation task already:

• Implement Metrics in EDC #1732

I already had a discussion with @ndr-brt the suggested best practice is the EDC eventing framework.

That issue is already giving implementation details, but I think we should follow the standard process:
-> gather info/requirements -> produce DR -> come to an agreement -> implement

[lgblaumeiser]

That issue is already giving implementation details, but I think we should follow the standard process:
-> gather info/requirements -> produce DR -> come to an agreement -> implement

Right, that is why the issue is titled as decision and the result targeted is a decision record, that identifies how we want to move forward and what needs to be prepared prior to implementing metrics.

The proposals are explicitely stated as proposals, i.e., as starting points for the discussion. Your comment on the endpoints is absolutely valid, but therefore we have the issue to discuss that and to come up with additional solutions that lead to the final proposal for the decision record.

Concerning the #1732, we had a discussion in the C-X Next TAP 7.2, that it does not make sense to implement any metrics or kpi as long as there is no decision on which technology stack we use for the implementation. Therefore, #1732 is simply currently not possible before we have the decision record of this issue in place.

[kkotowiczz]

With initial conceptual agreement we'll try to provide flexible opentelemetry-collector as a metric's backend.

[vanto-tech49]

I want to add my thoughts to this topic.

EDC is a framework, not an application, meaning each operator is responsible for infrastructure metrics (CPU, memory, disk, etc.) and business internal related KPIs. However, the current logging and traceability could be improved to make troubleshooting within the organisation and even across multiple companies exchanging data more easy and enable the creation and visualization of company specific KPIs.

Proposal
Introduce structured logs with OpenTelemetry (OTEL) while maintaining stdout logging for compatibility. Logs should include:
traceID → Links logs across multiple organizations
spanID → Traces execution flow
eventID → Identifies business events (contract negotiation, data transfer, etc.)
Flexible log output: Logs can be sent to multiple backends, such as:
stdout (default for easy access)
OTEL Collector (supports Prometheus, Loki, ELK, etc.)
Other Observability Platforms (Datadog, New Relic, etc.)

Example Log Output

{
  "timestamp": "2025-02-21T12:00:00Z",
  "level": "ERROR",
  "message": "Contract negotiation failed",
  "traceID": "abc123",
  "spanID": "xyz789",
  "eventID": "contract-negotiation-456"
}

Why OpenTelemetry?

• Already partially integrated into EDC
• Enables cross-company debugging with traceable logs
• Flexible log routing → Works with stdout, OTEL Collector, and other backends
• Aligns with modern cloud-native observability standards

Key Benefits
Standardized logging → Improved traceability
Cross-company debugging → Faster troubleshooting

Would love to hear your feedback!