CloudWatch: prevent log groups from being removed on query change. (#47994)

* CloudWatch: prevent log groups from being removed on query change.

Previously when a query was changed the existing log groups for that query were "dropped". The fix is to combine the
new query with the existing query object in memory to preserve the log groups.

fixes #33626

* CloudWatch: fix typos in runWithRetry documentation

* chore: fix eslint issue
This commit is contained in:
Adam Simpson 2022-04-25 13:59:52 -04:00 committed by GitHub
parent 098563179b
commit 6c0a5b121e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 13 additions and 4 deletions

View File

@ -416,6 +416,7 @@ export type ExploreQueryFieldProps<
export interface QueryEditorHelpProps<TQuery extends DataQuery = DataQuery> {
datasource: DataSourceApi<TQuery>;
query: TQuery;
onClickExample: (query: TQuery) => void;
exploreId?: any;
}

View File

@ -416,6 +416,7 @@ export class QueryEditorRow<TQuery extends DataQuery> extends PureComponent<Prop
<OperationRowHelp>
<DatasourceCheatsheet
onClickExample={(query) => this.onClickExample(query)}
query={this.props.query}
datasource={datasource}
/>
</OperationRowHelp>

View File

@ -229,8 +229,15 @@ export default class LogsCheatSheet extends PureComponent<
<div
className="cheat-sheet-item__example"
key={expr}
onClick={(e) =>
this.onClickExample({ refId: 'A', expression: expr, queryMode: 'Logs', region: 'default', id: 'A' })
onClick={() =>
this.onClickExample({
refId: this.props.query.refId ?? 'A',
expression: expr,
queryMode: 'Logs',
region: this.props.query.region,
id: this.props.query.refId ?? 'A',
logGroupNames: 'logGroupNames' in this.props.query ? this.props.query.logGroupNames : [],
})
}
>
<pre>{renderHighlightedMarkup(expr, keyPrefix)}</pre>

View File

@ -10,9 +10,9 @@ type Result = { frames: DataFrameJSON[]; error?: string };
/**
* A retry strategy specifically for cloud watch logs query. Cloud watch logs queries need first starting the query
* and the polling for the results. The start query can fail because of the concurrent queries rate limit,
* and so we hove to retry the start query call if there is already lot of queries running.
* and so we have to retry the start query call if there is already lot of queries running.
*
* As we send multiple queries in single request some can fail and some can succeed and we have to also handle those
* As we send multiple queries in a single request some can fail and some can succeed and we have to also handle those
* cases by only retrying the failed queries. We retry the failed queries until we hit the time limit or all queries
* succeed and only then we pass the data forward. This means we wait longer but makes the code a bit simpler as we
* can treat starting the query and polling as steps in a pipeline.