-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TraceView - Optimization of queries #2349
Changes from all commits
d48fa7a
94cce78
8eebac5
183731a
89fff13
94a99a4
0fe0710
c9b0105
bb41c51
3af05bd
7057348
ce4dcb4
2d93ad3
e102bd1
555e00f
4df1abb
33f0b85
241adb4
85d6bba
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,61 @@ | ||
/* | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit. Should we consider moving this common folder one level up? It seems like each logical component should have its own common folder. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think having it on the same level as our helper_functions makes sense as this would be for constants shared between trace_analytics including both traces and services as we continue to refactor. |
||
* Copyright OpenSearch Contributors | ||
* SPDX-License-Identifier: Apache-2.0 | ||
*/ | ||
|
||
// Conversion factor for nanoseconds to milliseconds | ||
export const NANOS_TO_MS = 1e6; | ||
|
||
export const MILI_TO_SEC = 1000; | ||
|
||
export const pieChartColors = [ | ||
'#7492e7', | ||
'#c33d69', | ||
'#2ea597', | ||
'#8456ce', | ||
'#e07941', | ||
'#3759ce', | ||
'#ce567c', | ||
'#9469d6', | ||
'#4066df', | ||
'#da7596', | ||
]; | ||
|
||
export interface Span { | ||
traceId: string; | ||
spanId: string; | ||
traceState: string; | ||
parentSpanId: string; | ||
name: string; | ||
kind: string; | ||
startTime: string; | ||
endTime: string; | ||
durationInNanos: number; | ||
serviceName: string; | ||
events: any[]; | ||
links: any[]; | ||
droppedAttributesCount: number; | ||
droppedEventsCount: number; | ||
droppedLinksCount: number; | ||
traceGroup: string; | ||
traceGroupFields: { | ||
endTime: string; | ||
durationInNanos: number; | ||
statusCode: number; | ||
}; | ||
status: { | ||
code: number; | ||
}; | ||
instrumentationLibrary: { | ||
name: string; | ||
version: string; | ||
}; | ||
} | ||
|
||
export interface ParsedHit { | ||
_index: string; | ||
_id: string; | ||
_score: number; | ||
_source: Span; | ||
sort?: any[]; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: Do we have a reset mechanism for these setters? If we previously loaded data with an overview, but a new payload arrives without an overview for some reason, it seems like the overview wouldn't be updated here, potentially leaving it with stale data. Should we handle this case explicitly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That one specifically is for application analytics and the useEffect triggers on payload change. As long as it is a valid payload the overview will get the new information from it. If the payload is successful from handlePayloadRequest causing new data the overview will always be generated from that information.