Update custom traces table with filters #2178
Conversation
Signed-off-by: Shenoy Pratik <sgguruda@amazon.com>
| }, | ||
| ]; | ||
|
|
||
| export const TRACE_TABLE_TYPE_KEY = 'TraceAnalyticsTraceTableType'; |
There was a problem hiding this comment.
ideally the constants are in common only if they are shared between client (public) and server. if they are only used on one side they can go directly there
There was a problem hiding this comment.
That makes sense. Will keep this one here for now. Will sort out this and others in common/constants during a mini refactor.
public/components/trace_analytics/components/traces/trace_table_helpers.tsx
Outdated
Show resolved
Hide resolved
public/components/trace_analytics/components/traces/traces_custom_indices_table.tsx
Outdated
Show resolved
Hide resolved
Signed-off-by: Shenoy Pratik <sgguruda@amazon.com>
Signed-off-by: Shenoy Pratik <sgguruda@amazon.com>
| should: [], | ||
| must_not: [], | ||
| }, | ||
| }, | ||
| ...(sort && { sort: [{ [sort.field]: { order: sort.direction } }] }), | ||
| track_total_hits: false, | ||
| }; | ||
|
|
||
| if (queryMode === 'trace_root_spans') { | ||
| dataPrepperQuery.query.bool.filter.push({ |
There was a problem hiding this comment.
Not Related: we should have used an opensource name instead of data prepper. Its actually open telemetry schema.
| { | ||
| label: TRACE_TABLE_TITLES.service_entry_spans, | ||
| key: 'service_entry_spans', | ||
| 'aria-describedby': 'The spans that mark start of server-side processing (SPAN_KIND_SERVER)', |
There was a problem hiding this comment.
I feel SPAN_KIND_SERVER is not needed. If required, bring in the exact description of SPAN_KIND_SERVER from open telemetry.
There was a problem hiding this comment.
Spans marking the start of server-side processing
??
| { | ||
| label: TRACE_TABLE_TITLES.traces, | ||
| key: 'traces', | ||
| 'aria-describedby': 'Aggregates all spans by traceId to show all traces', |
There was a problem hiding this comment.
Spans aggregated by traceId to show all traces
Maintaining consistency where we start all the descriptions by Spans.
Do we need to show all traces?
How is this different from first option?
There was a problem hiding this comment.
This table is the old way of showing just traces using the aggregation query. Kept this option if users still want aggregation and are not concerned about the wait time.
There was a problem hiding this comment.
This is the only table where we shows traces and not spans
| traces = 'Traces', | ||
| } | ||
|
|
||
| export const TRACE_TABLE_OPTIONS = [ |
There was a problem hiding this comment.
Users might ask for caching selected option.
There was a problem hiding this comment.
yes, for now I've added the selection in the session storage similar to how we store filters. So the table type selection is persisted in the session lifecycle.
| { | ||
| label: TRACE_TABLE_TITLES.all_spans, | ||
| key: 'all_spans', | ||
| 'aria-describedby': 'All spans from all traces', |
| { | ||
| label: TRACE_TABLE_TITLES.trace_root_spans, | ||
| key: 'trace_root_spans', | ||
| 'aria-describedby': 'The root spans which represent the starting point of a trace', |
There was a problem hiding this comment.
Root spans representing the starting point of each trace
Description
Sorting and Pagination push down won’t be part of this PR.
Update custom traces table with filters added below:
Functional updates:
Issues Resolved
Default table view
Table filter options
Table showing trace root spans
Table showing attributes
Demo Video
traces-table-filter.mov
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.