LogShark Workbook - ART (Vizqlserver Activity and Resource Tracing)


In this section:

What is it?

The ART workbook is built from Vizqlserver Activity and Resource Tracing (ART) logging. The ART logging captures CPU and memory utilization for each vizqlserver activity as well as the sponsorship and depth of the activitties and additional contextual metadata about the activity.

Note: Many of the views in the workbook make use of additional fields that were added to the ART logging in the 2018.3 release. For Servers on versions prior to 2018.3 some functionality in the dashboards may be missing(Such as the ability to identify the different request Types

Glossary of Important Terms to Understand ART Workbook Data and Dashboards

When to use it?

Activity Naming Conventions

component-name.activity-name[.activity-name ...]

Memory Tracking

Activity memory tracking statistics include bytes allocated and deallocated, and the number of times allocations and deallocations occurred.

When an Activity begins, a MemoryScope object is pushed onto a stack of MemoryScopes in Thread-Local Storage (TLS). Memory allocations and deallocations on that thread will update values in the stack of MemoryScopes. When an Activity ends, its MemoryScope is popped out of TLS.

Accuracy

CPU Thread Time Tracking

CPU Thread Time tracking provides separate values for user and kernel time in Linux while Windows only uses User Time. Thread Time is reported in units of milliseconds, and includes a count of the number of threads involved. It represents the amount of time an Activity ran on a processor/core. Time units are normalized across different platforms/processors.

Dashboards

Memory Allocations

Views:

Quick Filters:

Selection Filters:

Notes: If you are investigating Vizqlserver high memory usage issues having the customer gather Perfmon data using the template on our ‘Perfmon for customers’ page will help narrow down to the specific time the memory spikes and allow you to narrow the timeframe you are looking at in the dashboard

Use Cases:

CPU Time

Views:

Quick Filters:

Selection Filters:

Notes:

Use Cases:

Compare Sessions

Views:

Parameter Selection:

Quick Filters:

Selection Filters:

Notes:

Use Cases:

Flamecharts

Views:

Sample Flamecharts Screenshot

Parameter Selection:

Quick Filters:

Selection Filters:

Use Cases:

Intermittent Slow Queries

Views:

Sample Intermittent Slow Queries Screenshot

Quick Filters:

Selection Filters:

Parameters:

Notes:

Use Cases:

Errors

Views:

Sample Errors Dashboard Screenshot

Quick Filters:

Notes:

Use Cases:

Resource Intensive Requests

Views:

Sample Resource Intensive Dashboard Screenshot

Quick Filters:

Actions:

Notes:

Use Cases:

Net New Memory

Views:

Sample Net New Memory Dashboard Screenshot

Quick Filters:

Actions:

Notes:

Use Cases:

Resource Utilization Overview

Views:

Sample Resource Utilization Overview Dashboard Screenshot

Use Cases:

ART Datasource Field Name Log Name Metric Description
  ts the timestamp when the event occurred (as opposed to when it was logged or emitted)
  process ID the process id
  Thread ID the Thread ID
  sev log severity leve (error, warn, info, debug, trace)
  req the request id. The meaning of request id will vary depending on the service. In vizqlserver it is the id assigned by apache tomcat to a /vizql request. All ART and log events that occur as part of a particular request will share the same request id.
  sess the session id. The meaning of session id will vary depending on the service. In vizqlserver it is the vizql session id. In dataserver, it is the dataserver session id. Generally speaking, a session is long-lived and many requests can happen for the same session.
  site the Tableau Server / Tableau Online site name.
  user Tableau Server / Tableau Online user name
  k event key. The event key specifies the event type. Some parts of a log event are optional. Whether or not these parts contain data – and what kind of data – is determined by the event type. In other words, the event key determines the event schema. For ART events, you can expect up to three different event keys for each kind of activity: the begin-activity event, the end-activity event, and the supp-activity event (for supplemental events).
  l location information. Only appears in depth=0 ART end events.<ul><li>env: The value of the vizqlserver.ServerEnvironment option, if set.</li><li>host: The hostname.</li>
  depth depth in the activity tree. In vizqlserver, the root activity is synonymous with the request and is at depth=0. If the root activity calls activity B and activity B calls activity C, B is at depth=1 and C is at depth=2.
  elapsed present in end events only. The activity duration in seconds.
  id the activity UUID. Each occurrence of an activity has a different UUID. The begin, end, and supplemental events for the occurrence of an activity share the same UUID.
  name the activity name, which consists of a component name part, and one or more activity name parts.
  req-desc the request description. Only present in depth=0 (request) activities. It is 1:1 with a user action in a client generating an HTTP request against the vizqlserver service. The value is more or less equivalent to the specific vizqlserver HTTP endpoint.
  Alloc memory allocation metrics<ul><li>e: bytes allocated for this activity excluding all sponsored activities</li><li>i: bytes allocated for this activity including descendent (sponsored) activities</li><li>peak: Max (as in high water mark) bytes allocated at some point, for this activity</li><li>ne: number of times allocations occurred for this activity excluding all sponsored activities</li><li>ni: number of times allocations occurred for this activity including descendant (sponsored) activities</li></ul>
  Free memory deallocation metrics<ul><li>e: bytes released for this activity excluding all sponsored activities</li><li>i: bytes released for this activity including descendent (sponsored) activities</li><li>ne: number of times release occurred for this activity excluding all sponsored activities</li><li>ni: number of times release occurred for this activity including descendent (sponsored) activities</li>
  KCPU kernel space cpu metrics. Note: on Windows we do not separately report kernel cpu (it is combined with user cpu as a user cpu).<ul><li>e: kernel cpu thread time for this activity excluding descendent (sponsored) activities. Units are ms.</li><li>i: kernel cpu thread time for this activity including all sponsored activities. Units are ms</li></ul>
  NTID number of threads the activity ran on
  UCPU user space cpu metrics. Note: on Windows kernel and user cpu is combined and reported as user cpu.<ul><li>e: user cpu thread time for this activity excluding descendent (sponsored) activities. Units are ms.</li><li>i: user cpu thread time for this activity including all sponsored activities. Units are ms.</li></ul>
  RK the result key, by default “ok”.
  RV the result value: a dictionary of key-value pairs which provide more information about the result.
  Root the UUID of the root activity. Not present on depth=0 activities.
  Sponsor the UUID of the activity that caused this activity.
  Type the type of activity event: begin, end, or supp (stands for supplemental). Begin and end are self-explanatory. Supplemental events are like regular log events except they are explicitly tied to a particular activity as identified by the activity UUID.
  CTX context attributes.<ul><li>vw: the name of the view associated with the request. A view can be a dashboard, storyboard, or worksheet. Keep in mind that if the request operates on a dashboard, individual activities might operate on worksheets in that dashboard, but the vw will be the same for all activities in the request tree.</li><li>wb: the name of the workbook associated with the request.</li></ul>
  V custom event attributes. This is a dictionary of key-value pairs. Which key-values are present depends on the event key (k).