-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
migrationsv2: handle 413 errors and log the request details for unexpected ES failures #108213
Conversation
Pinging @elastic/kibana-core (Team:Core) |
const req = getRequestDebugMeta(e.meta); | ||
const failedRequestMessage = `Unexpected Elasticsearch ResponseError: statusCode: ${ | ||
req.statusCode | ||
}, error: ${getErrorMessage(e)}, method: ${req.method}, url: ${req.url}`; |
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.
Shouldn't we change the order to align with the error message in ES client: statusCode, method, URL, error message
kibana/src/core/server/elasticsearch/client/configure_client.test.ts
Lines 311 to 313 in 2a3113f
"500 | |
GET /foo?hello=dolly | |
{\\"seq_no_primary_term\\":true,\\"query\\":{\\"term\\":{\\"user\\":\\"kimchy\\"}}} [internal server error]: internal server error", |
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 good point, I initially included the body and because the body might easily be large enough to cause the log line to truncate I wanted to put the error in the front of the log line. But after I removed the body for security reasons it makes sense to keep the same order.
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
…ected ES failures (elastic#108213) * Log the failing request and response code when an action throws a response error * Provide useful log message when migrations fail due to ES 413 Request Entity Too Large * Don't log request body for unexpected ES request failures * Fix types * CR feedback: fix order of ES request debug log Co-authored-by: Kibana Machine <[email protected]> # Conflicts: # src/core/server/elasticsearch/client/configure_client.ts # src/core/server/elasticsearch/index.ts
…ected ES failures (#108213) (#108650) * Log the failing request and response code when an action throws a response error * Provide useful log message when migrations fail due to ES 413 Request Entity Too Large * Don't log request body for unexpected ES request failures * Fix types * CR feedback: fix order of ES request debug log Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Kibana Machine <[email protected]>
…ected ES failures (#108213) (#108658) * Log the failing request and response code when an action throws a response error * Provide useful log message when migrations fail due to ES 413 Request Entity Too Large * Don't log request body for unexpected ES request failures * Fix types * CR feedback: fix order of ES request debug log Co-authored-by: Kibana Machine <[email protected]> # Conflicts: # src/core/server/elasticsearch/client/configure_client.ts # src/core/server/elasticsearch/index.ts
Summary
Fixes #107288
This doesn't fix the problem that a too large batch size causes migrations to fail, it only provides a log message with instructions that users can act on to fix the problem. Although long term I think we should be more dynamic and automatically adjust the batch size lower, we've only had such a large request payload fail migrations on a single cluster.
I didn't add release notes since we're not really addressing the problem.
Checklist
Delete any items that are not applicable to this PR.
Risk Matrix
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
For maintainers