Provide a reason for not having an execution plan (MySQL) #9569
Conversation
Codecov Report
Flags with carried forward coverage won't be shown. Click here to find out more.
|
| except pymysql.err.DatabaseError as e: | ||
| if len(e.args) != 2: | ||
| raise | ||
| # we don't cache failed plan collection failures for specific queries because some queries in a schema | ||
| # can fail while others succeed. The failed collection will be cached for the specific query | ||
| # so we won't try to explain it again for the cache duration there. | ||
| db_explain_error, err = DBExplainError.database_error, e |
There was a problem hiding this comment.
I wonder if we should collect all of the errors, by strategy? The problem with this approach is that we'll only get the error for the last strategy, potentially hiding other setup issues.
Perhaps for mysql instead of just one (code, reason) we have a map of strategy -> (code, reason)? Maybe under a different key: collection_error_by_strategy
@justiniso what do you think?
There was a problem hiding this comment.
Discussed offline, but for context, there are cases where we wont have a strategy to make a mapping of strategy -> (code, msg) (i.e _can_explain()) so we were thinking, what if we simplify it to where we structure it as[{strategy, code, message}, ...] under collection_errors to be more universal?
There was a problem hiding this comment.
Decided to implement this approach, we can revert if necessary.
What does this PR do?
Provides a reason for not having a MySQL execution plan.
Motivation
Currently in Database Monitoring, the UX is lacking when it comes to execution plans. There are cases where it's impossible to collect or something failed, so we should indicate the reason it could not be collected and actions to fix it, if any.
Review checklist (to be filled by reviewers)
changelog/andintegration/labels attached