Add logs to OpenAPI spec and client

[nyza99]

What?

This PR adds support for logs API routes to OpenAPI spec for the Observatorium API and generated client.

Why?

The current OpenAPI is missing support for the observatorium/api logs API. This make writing client code (e.g. in obsctl) error-prone and cumbersome. In addition the logs api remains as such undocumented as per OpenAPI spec can be used to generate user-friendly documentation (See observatorium/observatorium#483)

How?

Added support for the following logs API routes in the OpenAPI spec:

POST /api/logs/v1/<tenant>/loki/api/v1/push
GET /api/logs/v1/<tenant>/loki/api/v1/labels
GET /api/logs/v1/<tenant>/loki/api/v1/label/<name>/values/
GET /api/logs/v1/<tenant>/loki/api/v1/series
GET /api/logs/v1/<tenant>/loki/api/v1/query_range
GET /api/logs/v1/<tenant>/loki/api/v1/query
GET /api/logs/v1/<tenant>/loki/api/v1/tail

Testing?

For testing run make test-interactive

This command spins up a full setup for Observatorium API with all dependent services. It is intended for short-lived manual testing on your local environment.

Run Curl commands to make API calls against Observatorium API to test manually.

example:

curl --insecure -X POST -v -H “Content-Type: application/json” -H “Accept: application/json” -H 'Authorization: Bearer <API TOKEN> "https://127.0.0.1:<observatorium API port>/api/logs/v1/<tenant>/loki/api/v1/push” -d '{"streams": [{ "stream": { "foo": "bar1" }, "values": [[ "1570818238000000000", "fizzbuzz"]]}]}'

curl --insecure -G -v -H "Content-Type: application/json" -H 'Authorization: Bearer <API TOKEN> ' "https://127.0.0.1:<observatorium API port>/api/logs/v1/<tenant>/loki/api/v1/query" --data-urlencode 'query=count_over_time({_id="test"}[1000m])'

Anything Else?

• To generate API documentation for spec.yaml run redocly preview-docs spec.yaml
• Facing TLS difficulties on MacOS with observatorium API check this out

[periklis]

In general it looks so far in a good shape. I added a couple of comments to correct wrong links and typos here and there. Besides these my only concern is if re-using the responses (e.g. QueryResponse or InstantQueryResponse) is the correct approach here. Maybe we should consider keeping the response objects for logs separately from metrics (cc @saswatamcode WDYT?)

[saswatamcode]

I agree! Let's keep the objects separate for now! 🙂

[periklis]

@nyza99 Can you push your commits addressing the review comments above which you see "fixed"?

[nyza99]

@nyza99 Can you push your commits addressing the review comments above which you see "fixed"?

Pushed all the changes!

[periklis]

Looks good to me, besides one small issue

[periklis]

Yippie!!!

[periklis]

Needs a rebase plus client code regeneration and imho we are set to go.

[periklis]

Cool stuff!

[nyza99]

Cool stuff!

[periklis]

@saswatamcode Any opinion on how to use the tags correctly to make a visual distinction for paths for logs and metrics. Looking at this feels like we have two labelsv1 paths etc. One needs to look on the right panel to see if they use the metrics or the logs endpoints

Should we add a prefix to the tags likes metrics/labelsv1 and logs/labelsv1? Do you have any better option?

cc @nyza99

[saswatamcode]

Ah yes. I was wondering if this would happen. I think adding metrics and logs prefixes to the tags would make it distinct! 🙂

[nyza99]

@saswatamcode Any opinion on how to use the tags correctly to make a visual distinction for paths for logs and metrics. Looking at this feels like we have two labelsv1 paths etc. One needs to look on the right panel to see if they use the metrics or the logs endpoints

Should we add a prefix to the tags likes metrics/labelsv1 and logs/labelsv1? Do you have any better option?

cc @nyza99

yes, that would be nice to distinct different endpoints. I'll update it!