The following three sections explain how ShiViz supports developers in the three key tasks that motivate our work: understanding the relative ordering of events in an execution (Section 4.1), querying for patterns of interaction between hosts in an execution (Section 4.2), and identifying structural similarities and differences between pairs of executions (Section 4.3). The reader may use the deployed version of ShiViz while reading this section at http://bestchai.bitbucket.io/shiviz/.

Exposing the Global Event Ordering

ShiViz displays two types of information: the log itself and the time-space diagram derived from it. By presenting the views simultaneously, ShiViz provides the developer with the familiar

ACM Transactions on Software Engineering and Methodology, Vol. 29, No. 2, Article 9. Pub. date: March 2020.

Visualizing Distributed System Executions

log-based view, as well as a view that conveys the partial ordering of what happened. Figure 2 shows a screenshot of the main ShiViz screen. This screen displays the logged execution in two ways: textually, as log lines, on the left, and graphically, as a time-space diagram, on the right.

In the time-space diagram, time flows from top to bottom. The boxes at the top represent hosts and the vertical lines below them are the host timelines. Circles on a host timeline represent events executed by that host. Edges connect events, representing the recorded happens-before relation: an event that is higher in the graph happened before an event positioned lower in the graph that it is connected to. The hosts are ordered from left to right in decreasing number of events executed; the developer may change this ordering.4

To reveal more log lines and events in the execution, the developer scrolls down. During scrolling, the host boxes remain in their positions at the top of the window to provide context.

The goal of the time-space diagram is to reveal ordering between events at different hosts, in- cluding likely chains of causality between such events. Such information is not easily discernible from manual inspection of logs. The execution graph reproduces the events and inter-host com- munication captured in the input log, but the graph makes the ordering information explicit in the visualization. For example, the developer in use case 1 in Section 2 wants to understand the context surrounding two contradictory messages. ShiViz exposes this context, including the ordering of events, the events themselves, as well as the corresponding log lines.

4.1.1 Relating the Time-space Diagram with Log Lines. Two views (log-based and the partial ordering) of the same execution can create confusion, since many tasks require using both types of information—what was logged and when it was logged. To help with this, ShiViz augments, not replaces, the log with an execution graph—the input log is always accessible in the left panel and is linked to the execution graph through visual cues. Hovering over an event or clicking on an event in the graph highlights the background of the corresponding log line in the left panel. This informative feedback supports the developer’s mental model that the execution graph is a more ➄ structured representation of the log. For example, the selected event in Figure 2 corresponds to the highlighted log line ➅ Closed, exiting. Likewise, clicking on a log line on the left highlights

The log lines are positioned to horizontally align with their corresponding events to strengthen the association. However, this also means that the log lines may appear in an order different from the order of log lines in the input log, but always one consistent with the partial order and one that could have been generated by the same execution.

4.1.2 Associating Log Lines with Hosts. To make it easy to spot the lines in the log associated with a specific host, each host in the execution graph is associated with a color that is used for its host box, event circles, and log lines. This color-coding works best when displaying few enough hosts to allow ShiViz not to reuse host colors.

4.1.3 Graph Transformations. The execution graph may contain a large number of events, in- cluding ones that are not relevant to a developer’s task. ShiViz includes three graph transforma- tions, shown in Figure 3, to help developers focus on relevant behavior in the execution. Transformation 1: collapse local events. ShiViz emphasizes ordering information and com- munication between processes. Series of local events that do not involve interactions with other processes are often less relevant to understanding the communication patterns in the system.

4.1.3 Graph Transformations. The execution graph may contain a large number of events, in- cluding ones that are not relevant to a developer’s task. ShiViz includes three graph transforma-

Transformation 1: collapse local events. ShiViz emphasizes ordering information and com- munication between processes. Series of local events that do not involve interactions with other processes are often less relevant to understanding the communication patterns in the system.

4ShiVizallowsuserstoorderthehostsinoneoffourways:(1)Orderhostsindescendingorderofthenumberofeventseach host generated in total. (2) Order hosts in ascending order of the number of events each host generated in total. (3) Order hosts in descending order of the line number where the host appeared in the log. (4) Order hosts in ascending order of the line number where the host appeared in the log.

ACM Transactions on Software Engineering and Methodology, Vol. 29, No. 2, Article 9. Pub. date: March 2020.



Fig. 3. (a) A collapse transformation collapses a series of local events on a host timeline. (b) A hide host timeline transformation removes a host timeline from view. (c) A filter by host transformation retains just those hosts and events that are relevant to communication with the specified host(s).