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

* 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

(cherry picked from commit 6c0a5b121e)

Co-authored-by: Adam Simpson <adam@adamsimpson.net>
This commit is contained in:
Grot (@grafanabot)
2022-04-26 09:53:39 +02:00
committed by GitHub
co-authored by Adam Simpson
parent ec0ccc6b30
commit bdcfbce889
4 changed files with 13 additions and 4 deletions
@@ -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;
}
@@ -415,6 +415,7 @@ export class QueryEditorRow<TQuery extends DataQuery> extends PureComponent<Prop
<OperationRowHelp>
<DatasourceCheatsheet
onClickExample={(query) => this.onClickExample(query)}
query={this.props.query}
datasource={datasource}
/>
</OperationRowHelp>
@@ -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>
@@ -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.