On a busy orchestrator cluster that might be integrated into internal tooling API web requests may be made to orchestrator to monitor the state of members of a MySQL cluster/replication chain. Such requests may be later handled out of sequence of logging and thus any errors that may be logged by orchestrator do not necessarily report the request to which they were made. This makes debugging hard.
An example may be a call to orchestrator such as https://orchestrator.example.com/api/master/some-cluster-name and this may generate an error such as 500 Server Error: Internal Server Error. Ideally you'd like to be able to find the logging in orchestrator such as:
2025-07-23 10:16:07.431 | orchestrator.example.com [martini] Started GET /api/master/some-cluster-name for 127.0.0.1:42665 request-id: XXXXXXXX
and later in processes of logging if a request-id is available it is logged. I guess this could be provided in the context that generally shared around the code base.
Current logging might show:
2025-07-23 10:51:26.588 | orchestrator.example.com [martini] Completed 500 Internal Server Error in 11.869041ms
This is unhelpful as you have no idea which request triggered this. Adding the request-id would allow you to track possible issues like in the case above an invalid name or other such issues.
A change such as that suggested would make debugging issues much easier.
This might also be useful for situations such as failover handling which have multiple steps: the exact failover steps then would be easier to see independently of other things that are happening.
Also orchestrator should not generate "internal errors". That's some sort of unhandled situation. Ideally the code should catch the situation and report the problem it is seeing even if it can not resolve it.
On a busy orchestrator cluster that might be integrated into internal tooling API web requests may be made to orchestrator to monitor the state of members of a MySQL cluster/replication chain. Such requests may be later handled out of sequence of logging and thus any errors that may be logged by orchestrator do not necessarily report the request to which they were made. This makes debugging hard.
An example may be a call to orchestrator such as
https://orchestrator.example.com/api/master/some-cluster-nameand this may generate an error such as500 Server Error: Internal Server Error. Ideally you'd like to be able to find the logging in orchestrator such as:and later in processes of logging if a request-id is available it is logged. I guess this could be provided in the context that generally shared around the code base.
Current logging might show:
This is unhelpful as you have no idea which request triggered this. Adding the request-id would allow you to track possible issues like in the case above an invalid name or other such issues.
A change such as that suggested would make debugging issues much easier.
This might also be useful for situations such as failover handling which have multiple steps: the exact failover steps then would be easier to see independently of other things that are happening.
Also orchestrator should not generate "internal errors". That's some sort of unhandled situation. Ideally the code should catch the situation and report the problem it is seeing even if it can not resolve it.