GitLab now enforces expiry dates on tokens that originally had no set expiration date. Those tokens were given an expiration date of one year later. Please review your personal access tokens, project access tokens, and group access tokens to ensure you are aware of upcoming expirations. Administrators of GitLab can find more information on how to identify and mitigate interruption in our documentation.
Admin message
Self sign-up has been disabled due to increased spam activity. If you want to get access, please send an email to a project owner (preferred) or at gitlab(at)nic(dot)cz. We apologize for the inconvenience.
Support for tracing query execution logs, added /trace endpoint
Currently there is a policy.QTRACE to print out messages relevant to matching policy filter.
This is nice for tracing specific names in the background, but not very useful for ad-hoc troubleshooting.
This MR adds support for per-request tracing of query execution, so it's possible to install a callback function
to the request structure, and it will get called for each log message (regardless of whether verbose logging to stdout is enabled or not). This by itself isn't super helpful in C modules. It also changes the way how verbose logging was done before, from:
WITH_VERBOSE{VERBOSE_MSG(qry,"hello");}
To:
WITH_VERBOSE(qry){VERBOSE_MSG(qry,"hello");}
The second part of the MR adds a new endpoint /trace to the HTTP module to trace execution of individual requests.
It looks sort of like this:
$ curl http://localhost:8080/trace/e.root-servers.net iter | 'e.root-servers.net.' type 'A' created outbound query, parent id 0 rc | => rank: 020, lowest 020, e.root-servers.net. A rc | => satisfied from cache iter | <= answer received: ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 14771 ;; Flags: qr aa QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0 ;; QUESTION SECTION e.root-servers.net. A ;; ANSWER SECTION e.root-servers.net. 3599821 A 192.203.230.10 iter | <= rcode: NOERROR resl | finished: 4, queries: 1, mempool: 81952 B
This is nice for troubleshooting problems with a specific resolver instance, or to generate test files (as it writes out answers received).
I'm planning to add more tracepoints next, more specifically to add a timeline of request processing events (function calls, or layer executions) to show where the time is spent for given request, but this will be more invasive, so it should probably be done in a separate set of patches.
Also added basic tests for this endpoint and the rest in the http module.
