Idea #2883
Updated by Tom Clegg almost 10 years ago
The "log" link for a completed job should go to a (new) "log" tab on the "view job" page. (Perhaps @/jobs/{uuid}#Log@ just needs some generic javascript for "on page load, if location anchor is a tab, hit that tab")
The log tab should offer various views of the log data.
* Overview
** Obvious "N failed tasks" button (if any failed) that brings you to the "log messages" tab for all the failures
** "123 tasks completed in 1 hour 12 minutes, using 3 nodes"
** "3 hours 8 minutes of worker node usage, plus 28 minutes idle" ("idle" = node allocated but no tasks running there)
** Start time, finish time
** #complete, #incomplete, #failures. (complete+incomplete=total. E.g., a task can fail twice and then succeed on the third attempt.)
** For each category (completed task IDs / incomplete task IDs / failures), show category, min/max runtime.
* Time chart (lower priority)
** Perhaps like the chrome debug panel's view of network activity (attached screen shot), but more compact.
** Or, perhaps a vertical view with y=time(down), x=node -- i.e., idle nodes show up as empty areas.
* Messages from selected task(s)
** Just the setup/teardown/stderr messages relating to specified task(s)
** Sort by task qsequence, then log timestamp
** Drop-down to select "all tasks", or "all failures", "all successes", or a single task (show sequence, qsequence, and uuid in the drop-down items)
*** Showing 1000 task IDs in a drop-down won't work well. (Either limit the drop-down to the first hard-coded N tasks, or don't even offer the "specified task" option, or some other reasonable strategy.)
Parsing should probably happen on the client side. (First iteration should just deal with a static log file but future work will include updating this page as new logs arrive by websocket. And the raw log needs to show up on the client side anyway, so might as well do everything from there?)