-
Notifications
You must be signed in to change notification settings - Fork 16.3k
Render structured logs in the new UI rather than showing raw JSON #46827
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
Conversation
|
This is failing it's static check and I don't know how to decipher the error: |
|
I have not tested this with an old/non-json Log, and I haven't fixed up the unit tests yet either. |
It's a bunch of typescript issues. Usually easier to read inline. We we weren't setting the types of the log parsing functions so that made typescript say every variable assignment in the function was unsafe. |
6171d88 to
b609dc3
Compare
527596d to
b609dc3
Compare
6c41902 to
4bc68d4
Compare
|
quick update on the current progress. core tests should already be fixed. some provider ones remaining.
|
dd1c677 to
a612ff7
Compare
|
just add compat code to providers. The tests should pass now... I think... |
|
didn't notice there're some others...
|
a612ff7 to
a416611
Compare
1495cfd to
ba1049e
Compare
There are multiple parts to this PR; First off: the log reader interface was _a mess_ There was some odd+old code do deal with reading from multiple hosts that made the message confusing. This was added for smart sensors (which went away in v2.4 or v2.5) but this mess remained, and reading from multiple hosts is handled differently now. This PR keeps the current "parse+interleave" behaviour (though it's debatable if the interleave feature is needed specifically, or if we could get away with a simpler concat instead. Future work there if anyone wants to think about and tackle this.) but changes the JSON resposne type from a single string (the value of which was previoulsy a mess of double encoded JSON and repr of a python tuple making it impossible to do anything but display at) to a list of either strings (when it can't be parsed) or a list of dicts/StructuredLogMessage. I have also done some cursory rendering/displaying of these structured log messages in the UI, but they could be greatly improved by adding colors to various components of the log. The current rendered HTML looks like this: ```html <p><span class="event">::group::Log message source details</span> <span class="log-key sources">sources=["/root/airflow/logs/dag_id=trigger_test/run_id=manual__2025-02-16T12:23:29.118614+00:00_gOTl0Qub/task_id=waiter/attempt=1.log","/root/airflow/logs/dag_id=trigger_test/run_id=manual__2025-02-16T12:23:29.118614+00:00_gOTl0Qub/task_id=waiter/attempt=1.log.trigger.14.log"]</span></p> <p><span class="event">::endgroup::</span></p> <p>[<time datetime="2025-02-16T12:23:30.033308">2025-02-16T12:23:30.033308</time>] <span class="log-level debug">DEBUG</span> - <span class="event">Hook impls: []</span> <span class="log-key logger">logger="airflow.listeners.listener"</span></p> ``` Although not used by the UI, the non-application/json content type is now updated to a) include the continuation token as a header, and to set the content type as application/x-ndjson
ba1049e to
d3e2dff
Compare
|
As the comments are resolved, I'll merge this one. Thanks all for your help! |
…ache#46827) * Render structured logs in the new UI rather than showing raw JSON There are multiple parts to this PR; First off: the log reader interface was _a mess_ There was some odd+old code do deal with reading from multiple hosts that made the message confusing. This was added for smart sensors (which went away in v2.4 or v2.5) but this mess remained, and reading from multiple hosts is handled differently now. This PR keeps the current "parse+interleave" behaviour (though it's debatable if the interleave feature is needed specifically, or if we could get away with a simpler concat instead. Future work there if anyone wants to think about and tackle this.) but changes the JSON resposne type from a single string (the value of which was previoulsy a mess of double encoded JSON and repr of a python tuple making it impossible to do anything but display at) to a list of either strings (when it can't be parsed) or a list of dicts/StructuredLogMessage. I have also done some cursory rendering/displaying of these structured log messages in the UI, but they could be greatly improved by adding colors to various components of the log. The current rendered HTML looks like this: ```html <p><span class="event">::group::Log message source details</span> <span class="log-key sources">sources=["/root/airflow/logs/dag_id=trigger_test/run_id=manual__2025-02-16T12:23:29.118614+00:00_gOTl0Qub/task_id=waiter/attempt=1.log","/root/airflow/logs/dag_id=trigger_test/run_id=manual__2025-02-16T12:23:29.118614+00:00_gOTl0Qub/task_id=waiter/attempt=1.log.trigger.14.log"]</span></p> <p><span class="event">::endgroup::</span></p> <p>[<time datetime="2025-02-16T12:23:30.033308">2025-02-16T12:23:30.033308</time>] <span class="log-level debug">DEBUG</span> - <span class="event">Hook impls: []</span> <span class="log-key logger">logger="airflow.listeners.listener"</span></p> ``` Although not used by the UI, the non-application/json content type is now updated to a) include the continuation token as a header, and to set the content type as application/x-ndjson * Fix typescript useLogs * style: group metadata pop * style: reduce if-else and directly use bool for assigning metadata["download_logs"] * style: improve type annotation * test(test_log_reader): fix existing unit tests * test(api_fastapi): fix existing test_log unit tests * feat(api_connexion/log): update v1 api to the latest log format * test(providers/elasticsearch): fix part of the existing unit test * test(providers/amazon): fix TestCloudwatchTaskHandler::test_read * feat(providers/amazon): add airflow 3 compat logic * feat(providers/google): add airflow 3 task handler log handling logic * feat(providers/elasticsearch): add airflow 3 task handler log handling logic * feat(providers/microsoft): add airflow 3 task handler log handling logic * feat(providers/redis): add airflow 3 task handler log handling logic * feat(providers/opensearch): add airflow 3 task handler log handling logic * test: ignore unneeded tests * test(log_handlers): fix pendulum.tz version imcompat * feat: force StructuredLogMessage check when initialing --------- Co-authored-by: Brent Bovenzi <brent.bovenzi@gmail.com> Co-authored-by: Wei Lee <weilee.rx@gmail.com>
…ache#46827) * Render structured logs in the new UI rather than showing raw JSON There are multiple parts to this PR; First off: the log reader interface was _a mess_ There was some odd+old code do deal with reading from multiple hosts that made the message confusing. This was added for smart sensors (which went away in v2.4 or v2.5) but this mess remained, and reading from multiple hosts is handled differently now. This PR keeps the current "parse+interleave" behaviour (though it's debatable if the interleave feature is needed specifically, or if we could get away with a simpler concat instead. Future work there if anyone wants to think about and tackle this.) but changes the JSON resposne type from a single string (the value of which was previoulsy a mess of double encoded JSON and repr of a python tuple making it impossible to do anything but display at) to a list of either strings (when it can't be parsed) or a list of dicts/StructuredLogMessage. I have also done some cursory rendering/displaying of these structured log messages in the UI, but they could be greatly improved by adding colors to various components of the log. The current rendered HTML looks like this: ```html <p><span class="event">::group::Log message source details</span> <span class="log-key sources">sources=["/root/airflow/logs/dag_id=trigger_test/run_id=manual__2025-02-16T12:23:29.118614+00:00_gOTl0Qub/task_id=waiter/attempt=1.log","/root/airflow/logs/dag_id=trigger_test/run_id=manual__2025-02-16T12:23:29.118614+00:00_gOTl0Qub/task_id=waiter/attempt=1.log.trigger.14.log"]</span></p> <p><span class="event">::endgroup::</span></p> <p>[<time datetime="2025-02-16T12:23:30.033308">2025-02-16T12:23:30.033308</time>] <span class="log-level debug">DEBUG</span> - <span class="event">Hook impls: []</span> <span class="log-key logger">logger="airflow.listeners.listener"</span></p> ``` Although not used by the UI, the non-application/json content type is now updated to a) include the continuation token as a header, and to set the content type as application/x-ndjson * Fix typescript useLogs * style: group metadata pop * style: reduce if-else and directly use bool for assigning metadata["download_logs"] * style: improve type annotation * test(test_log_reader): fix existing unit tests * test(api_fastapi): fix existing test_log unit tests * feat(api_connexion/log): update v1 api to the latest log format * test(providers/elasticsearch): fix part of the existing unit test * test(providers/amazon): fix TestCloudwatchTaskHandler::test_read * feat(providers/amazon): add airflow 3 compat logic * feat(providers/google): add airflow 3 task handler log handling logic * feat(providers/elasticsearch): add airflow 3 task handler log handling logic * feat(providers/microsoft): add airflow 3 task handler log handling logic * feat(providers/redis): add airflow 3 task handler log handling logic * feat(providers/opensearch): add airflow 3 task handler log handling logic * test: ignore unneeded tests * test(log_handlers): fix pendulum.tz version imcompat * feat: force StructuredLogMessage check when initialing --------- Co-authored-by: Brent Bovenzi <brent.bovenzi@gmail.com> Co-authored-by: Wei Lee <weilee.rx@gmail.com>
Closes #46657
There are multiple parts to this PR
First off: the log reader interface was a mess There was some odd+old code
do deal with reading from multiple hosts that made the message confusing. This
was added for smart sensors (which went away in v2.4 or v2.5) but this mess
remained, and reading from multiple hosts is handled differently now.
This PR keeps the current "parse+interleave" behaviour (though it's debatable
if the interleave feature is needed specifically, or if we could get away with
a simpler concat instead. Future work there if anyone wants to think about and
tackle this.) but changes the JSON resposne type from a single string (the
value of which was previoulsy a mess of double encoded JSON and repr of a
python tuple making it impossible to do anything but display at) to a list of
either strings (when it can't be parsed) or a list of
dicts/StructuredLogMessage.
I have also done some cursory rendering/displaying of these structured log
messages in the UI, but they could be greatly improved by adding colors to
various components of the log.
The current rendered HTML looks like this:
Although not used by the UI, the non-application/json content type is now
updated to a) include the continuation token as a header, and to set the
content type as application/x-ndjson
It's not the prettiest yet, I'll leave that to people more talented at that than me
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in newsfragments.