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.