How should we architect for case where 3rd party API itself provides metric details and unable to instrument for OpenTelemetry directly

[fvarga01]

New to OpenTelemetry

Scenario (simplified):

1. API_1(inhouse) calls API_2(owned by 3rd party we cannot configure for open telemetry - it provides metric info in json format for an application, APP_2).
2. Currently API_1 polls API_2 every few minutes with a GET request. The returned payload itself includes some metrics data about APP_2.

example:
{ "name":"app2"
"time":"20220328 01:00:00"
"cpu-usage":100}

3. Now we want to modify API1 to call other similar APIs, API_3, API_4 which themselves contain metric data for their respective apps.
4. Instead of creating various schema mapping, definitions for each new data source (At this point data sources are API calls, but that can change for other sources). I'd like to see if OpenTelemetry can solve this in a more reusable manner.

Question:
What is the recommended architectural pattern for the above scenario. Basically, we want to extract metrics data from various sources which we do not have permissions to instrument. Some thoughts:

1. Should we create an "open telemetry wrapper", say API_1B, it contains the calls to API_2, API_3 and then resends the extracted metric data using Open Telemetry SDKs?
2. Or should we do on-the-fly translation. So, as API_2 is called, the metric data is extracted, compared with a schema definition file and a mapping file, now persist this to some storage?

Thanks.

[tigrannajaryan]

One possible option is to implement this as a polling receiver in the Otel Collector (this is essentially how Prometheus receiver works). The receiver may be configurable/extensible to support various APIs to poll. Depending on how similar or dissimilar they are it may be possible to support new APIs purely via new runtime configuration or they may need a new code inside the polling receiver.