-
Notifications
You must be signed in to change notification settings - Fork 12.1k
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
Explore: Unification of logs/metrics/traces user interface #25890
Conversation
@@ -15,7 +15,7 @@ export enum LoadingState { | |||
Error = 'Error', | |||
} | |||
|
|||
export type PreferredVisualisationType = 'graph' | 'table'; | |||
export type PreferredVisualisationType = 'graph' | 'table' | 'logs' | 'trace'; |
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.
I think we can use this to figure out where to show the dataFrames. For data sources which won't use that we should just make sure the output is sensible (ie fallback to table table/graph)
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.
👍
@@ -332,7 +338,8 @@ export class Explore extends React.PureComponent<ExploreProps, ExploreState> { | |||
<SecondaryActions | |||
addQueryRowButtonDisabled={isLive} | |||
// We cannot show multiple traces at the same time right now so we do not show add query button. | |||
addQueryRowButtonHidden={mode === ExploreMode.Tracing} | |||
//TODO:unification | |||
// addQueryRowButtonHidden={mode === ExploreMode.Tracing} |
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.
I think we can just show one trace view per frame and deal with multiple traces that way.
We also need to check code like this one
|
this.tableFrames.push(frame); | ||
} | ||
} else { | ||
if (shouldShowInVisualisationType(frame, 'logs')) { |
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.
Do we need to nest these if/else-if statements inside the else statement starting at line 42 or can we just use all else-if statements instead?
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.
the thing is time series by default are shown in both graph and table. So they need to be separate, other types are sort of priority based in the sense that when we think something should be logs we won't try to match this to anything else.
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.
Also this assumes we will start using the meta attributes so may not work at the moment for all cases, but as I mentioned if we can do some sensible default that should be fine.
4b32042
to
ed8e95e
Compare
For me this is a lot of JS :-) If I am to review (some concepts maybe?) I think I would need some context or a summary. |
@kylebrandt seems like you ware added because the codeowners config and this touches some backend files. I think the automatic code owners assignment isn't that great in some cases, |
634baa1
to
b60e090
Compare
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.
Awesome 🚀
No blockers from my side.
Minor:
- Loki is missing the table result. Either add in this PR if simple, or add a comment TODO
- Elastic agg histogram from the datasource was nice. Is there no other way to reintroduce this?
@@ -47,6 +47,7 @@ export interface QueryResultMeta { | |||
searchWords?: string[]; // used by log models and loki | |||
limit?: number; // used by log models and loki | |||
json?: boolean; // used to keep track of old json doc values | |||
instant?: boolean; |
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.
This is a prometheus/loki thing, definitely needs a comment. Ideally it should be sub-field of custom
.
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.
Do we still need this? I thought that was solved by the preferredVis type?
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.
Yeah seems like it's not used anymore
@@ -58,6 +58,7 @@ import { getTimeZone } from '../profile/state/selectors'; | |||
import { ErrorContainer } from './ErrorContainer'; | |||
import { scanStopAction } from './state/actionTypes'; | |||
import { ExploreGraphPanel } from './ExploreGraphPanel'; | |||
//TODO:unification |
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.
What's left todo here?
@@ -334,7 +340,8 @@ export class Explore extends React.PureComponent<ExploreProps, ExploreState> { | |||
<SecondaryActions | |||
addQueryRowButtonDisabled={isLive} | |||
// We cannot show multiple traces at the same time right now so we do not show add query button. | |||
addQueryRowButtonHidden={mode === ExploreMode.Tracing} | |||
//TODO:unification |
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.
I guess this condition might need to be changed to depend on datasource types.
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.
My idea for simple solution would be to just show 1 trace view per each query. Would not be very practical from user perspective but would be easy to implement without any special casing here.
let QueryEditor; | ||
|
||
if (mode === ExploreMode.Metrics && datasourceInstance.components?.ExploreMetricsQueryField) { | ||
// TODO:unification |
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.
Looks like there is no other way than removing this field specialisation hand add a switcher to the field itself.
@@ -11,5 +10,4 @@ class ElasticAnnotationsQueryCtrl { | |||
export const plugin = new DataSourcePlugin(ElasticDatasource) | |||
.setQueryCtrl(ElasticQueryCtrl) | |||
.setConfigEditor(ConfigEditor) | |||
.setExploreLogsQueryField(ElasticsearchQueryField) |
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.
The component file could be removed?
@@ -16,5 +15,4 @@ export const plugin = new DataSourcePlugin(InfluxDatasource) | |||
.setConfigEditor(ConfigEditor) | |||
.setQueryCtrl(InfluxQueryCtrl) | |||
.setAnnotationQueryCtrl(InfluxAnnotationsQueryCtrl) | |||
.setExploreLogsQueryField(InfluxLogsQueryField) |
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.
Remove component?
@@ -49,6 +49,9 @@ export class JaegerDatasource extends DataSourceApi<JaegerQuery> { | |||
values: response?.data?.data || [], | |||
}, | |||
], | |||
meta: { | |||
preferredVisualisationType: 'trace', |
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.
I feel like these values should be constants from something in core grafana.
) | ||
); | ||
} | ||
filteredTargets.forEach(target => subQueries.push(this.runRangeQuery(target, options, filteredTargets.length))); |
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.
We're dropping the instant query here. Any way we can have it back for metric queries (or we just sent it anyway for logs and see what happens/deal with it in the response).
throw new Error('Metrics mode does not support logs. Use an aggregation or switch to Logs mode.'); | ||
return { | ||
data: [], | ||
key: `${target.refId}_instant`, |
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.
Unclear what's happening here. Also, the _instant
suffix suggests this has something to do with instant queries.
Failing right now as it depends on grafana/grafana-plugin-sdk-go#191 which needs to get merged first |
9eeabd6
to
863e763
Compare
d8ff252
to
0f09190
Compare
Removes "Metrics"/"Logs" mode switcher from Explore, allowing for both metrics and logs queries at the same time. Co-authored-by: kay delaney <kay@grafana.com> (cherry picked from commit 64bc859)
Removes "Metrics"/"Logs" mode switcher from Explore, allowing for both metrics and logs queries at the same time. Co-authored-by: kay delaney <kay@grafana.com> (cherry picked from commit 64bc859)
Is it intended that this design doc is private? |
Design doc: https://docs.google.com/document/d/1hZURlhvU5LVejMWXeQTaTMOLAC73FQjQR_EjgYtOV9c/edit#heading=h.sp7xjuf6unar