TraceEventFormat-GoogleDocs.pdf_traceeventformat

format

需积分: 50 13 浏览量更新于2023-03-16 评论收藏 273KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

Trace  Event  Format   
Last  updated:  October  2016    
nduca@,  dsinclair@    
  
Introduction    
JSON  Format    
JSON  Array  Format    
JSON  Object  Format    
Event  Descriptions    
Phases    
Duration  Events    
Stack  Traces  on  Duration  Events    
Complete  Events    
Instant  Events    
Counter  Events    
Async  Events    
Flow  Events    
Sample  Events  (deprecated)    
Object  Events    
Snapshots    
Snapshot  category  override    
Snapshot  base_type  override    
References    
Metadata  Events    
Memory  Dump  Events    
Mark  Events    
Clock  Sync  Event    
Context  Events    
Linking  IDs    
More  about  IDs    
StackFrames  Dictionary    
Global  Samples    
Linux  Debug  Format    
  
Introduction   
The  Trace  Event  Format  is  the  trace  data  representation  that  is  processed  by  the  Trace  Viewer    
1
application.  Trace  Viewer  recognizes  four  input  variations.    
● Two  are  representations  of  the  JSON  format:    
a. A  string  dump  of  a  JSON  array.    
b. A  JSON  object.    
● Two  are  representations  of  the  Linux  ftrace  data:    
1
  https://github.com/catapult-project/catapult/tree/master/tracing    
1    

a. Text dump starting with # tracer: .

b. An Android systrace HTML dump.

This document describes the JSON input format and provides links for more information on the Linux

ftrace functionality.

JSON Format 

The JSON events can be provided in two slightly different structures.

JSON Array Format 

The simplest format accepted by the trace viewer is the JSON array format. Essentially, an array of event

objects. The events do not have to be in timestamp-sorted order.

[ { "name" : "Asub" , "cat" : "PERF" , "ph" : "B" , "pid" : 22630 , "tid" : 22630 , "ts" : 829 },

{ "name" : "Asub" , "cat" : "PERF" , "ph" : "E" , "pid" : 22630 , "tid" : 22630 , "ts" : 833 }

]

JSON Array Format

When provided as a string to the importer the ] at the end of the JSON Array Format is optional. The

Trace Viewer importer will automatically add a ] if needed to turn the string into valid JSON.. This is to

support tracing systems that can not cleanly finish writing the trace. For example, when tracing the exit of

a program.

JSON Object Format 

The JSON Object Format allows for more flexibility in the data passed to Trace Viewer. There is one

required property, traceEvents , and some optional properties. The events do not have to be in

timestamp-sorted order.

{

"traceEvents" : [

{ "name" : "Asub" , "cat" : "PERF" , "ph" : "B" , "pid" : 22630 , "tid" : 22630 , "ts" :

829 },

{ "name" : "Asub" , "cat" : "PERF" , "ph" : "E" , "pid" : 22630 , "tid" : 22630 , "ts" :

833 }

"displayTimeUnit" : "ns" ,

"systemTraceEvents" : "SystemTraceData" ,

"otherData" : {

"version" : "My Application v1.0 "

"stackFrames": {...}

"samples": [...],

}

JSON Object Format

If provided displayTimeUnit is a string that specifies in which unit timestamps should be displayed. This

supports values of “ms” or “ns” . By default this is value is “ms” .

If provided systemTraceEvents is a string of Linux ftrace data or Windows ETW trace data. This data

must start with # tracer: and adhere to the Linux ftrace format or adhere to Windows ETW format.

If provided, powerTraceAsString is a string of BattOr power data.

If provided, the stackFrames field is a dictionary of stack frames, their ids, and their parents that allows

compact representation of stack traces throughout the rest of the trace file. It is optional but sometimes

very useful in shrinking file sizes.

The samples array is used to store sampling profiler data from a OS level profiler. It stores samples that

are different from trace event samples, and is meant to augment the traceEvent data with lower level

information. It is OK to have a trace event file with just sample data, but in that case traceEvents must

still be provided and set to []. For more information on sample data, refer to the global samples section .

If provided, controllerTraceDataKey is a string that specifies which trace data comes from tracing

controller. Its value should be the key for that specific trace data. For example, {...,

"controllerTraceDataKey": "traceEvents"} means the data for traceEvents comes from the tracing

controller. This is mainly for the purpose of clock synchronization.

Any other properties seen in the object, in this case otherData are assumed to be metadata for the trace.

They will be collected and stored in an array in the trace model. This metadata is accessible through the

Metadata button in Trace Viewer.

Event Descriptions 

There are a common set of fields for each of the events.

{

"name" : "myName" ,

"cat" : "category,list" ,

"ph" : "B" ,

"ts" : 12345 ,

"pid" : 123 ,

"tid" : 456 ,

"args" : {

"someArg" : 1 ,

"anotherArg" : {

"value" : "my value"

}

General Event Structure

● name: The name of the event, as displayed in Trace Viewer

● cat : The event categories. This is a comma separated list of categories for the event. The

categories can be used to hide events in the Trace Viewer UI.

● ph: The event type. This is a single character which changes depending on the type of event

being output. The valid values are listed in the table below . We will discuss each phase type

below.

● ts: The tracing clock timestamp of the event. The timestamps are provided at microsecond

granularity.

● tts: Optional. The thread clock timestamp of the event. The timestamps are provided at

microsecond granularity.

● pid : The process ID for the process that output this event.

● tid : The thread ID for the thread that output this event.

● args: Any arguments provided for the event. Some of the event types have required argument

fields, otherwise, you can put any information you wish in here. The arguments are displayed in

Trace Viewer when you view an event in the analysis section.

Optional

● cname: A fixed color name to associate with the event. If provided, cname must be one of the

names listed in trace-viewer's base color scheme's reserved color names list

Phases 

The following table lists all event types and their associated phases:

Event type

Event phases

Duration Events

B (begin), E (end)

Complete Events

Instant Events

Deprecated

Counter Events

Async Events

b (nestable start), n (nestable instant), e (nestable end)

Deprecated

S (start), T (step into), p (step past), F (end)

Flow Events

s (start), t (step), f (end)

Sample Events

剩余18页未读，继续阅读

wang.wenchao

粉丝: 36
资源: 30

会员权益专享

Trace Event Format - Google Docs.pdf

评论0

会员权益专享

最新资源

Trace Event Format - Google Docs.pdf

评论0

GoogleNews-vectors-negative300网盘下载地址.txt

GoogleNews-vectors-negative300.bin 压缩包1/3

GoogleNews-vectors-negative300网盘地址.txt

vue-cli 3.x中的开发调试技巧与工具

基于UML的OMEGA组件模型及其扩展 2004形式计算机科学电子笔记25-49.

Trace-cmd工具及其在内核追踪中的应用

Pin Trace vs. Signal Trace: 有什么区别？

cachesim -c cfg.txt -t is.trace [-o is.trace.out]

python detect.py --weights best.pt --conf 0.5 --img-size 640 --source 3.mp4 --no-trace

linux内核有哪些debug技术？推荐100个

strace -f -o trace.log

ExperimentalWarning: The Fetch API is an experimental feature. This feature could change at any time (Use node --trace-warnings ... to show where the warning was created)怎么解决

DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066. This will be ignored in a future version. (Use `node --trace-deprecation ...` to show where the warning was created)

(node:14300) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead. (Use `node --trace-deprecation ...` to show where the warning was created)

To see the full stack trace of the errors, re-run Maven with the -e switch.

会员权益专享

最新资源