Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

include tests for logs #3

Open
bossie opened this issue Nov 22, 2022 · 4 comments
Open

include tests for logs #3

bossie opened this issue Nov 22, 2022 · 4 comments

Comments

@bossie
Copy link
Collaborator

bossie commented Nov 22, 2022

Quite a bit of effort has been made to get centralized logging in place, of all components that make up our OpenEO back-ends, in Python and Java, in Spark drivers and executors, in web app and batch job contexts, with IDs such as user ID, request ID and job ID to correlate them.

Recently however, the logging infrastructure itself (filebeat, logstash etc) has been a bit unreliable for reasons not entirely known and logs were not visible in Kibana.

Maybe the current integration tests can be extended to make sure that our logging still behaves, both application-wise and infrastructure-wise.

For batch jobs, the /jobs/{job_id}/logs endpoint can be used.

For synchronous requests this is not so simple, because the request ID is not propagated to the client unless the request fails, in which case the request ID is returned in the error message. It is therefore not possible to look for logs that pertain to this particular request. Even if we always return this request ID in a response header, regardless of its outcome, a question that remains is: how will the openeo-python-client expose this request ID so we can fetch the corresponding logs?

@bossie
Copy link
Collaborator Author

bossie commented Nov 22, 2022

We might consider a pragmatic approach and say: this synchronous request that we started a minute ago, succeeded, and therefore the logs of the last minute should contain these log entries.

@soxofaan
Copy link
Member

some other quick ideas:

  • use a dedicated integration test user id and filter on that (too)
  • allow setting the request id from client side (with a header), instead of generating a random one back-end side

@bossie
Copy link
Collaborator Author

bossie commented Nov 25, 2022

How would you allow the client (programmer) to set the request header? Keep it in a global/per-connection variable or are there better ways?

@soxofaan
Copy link
Member

you can do both:

  • set an entry in the .default_headers dict on the connection object for "global" approach
  • pass headers arg (a dict) to con.get(), con.post(), ... for per request approach

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants