Skip to content
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

Courier Fetch: Bad Gateway #7455

Closed
pip00 opened this issue Jun 14, 2016 · 10 comments
Closed

Courier Fetch: Bad Gateway #7455

pip00 opened this issue Jun 14, 2016 · 10 comments

Comments

@pip00
Copy link

pip00 commented Jun 14, 2016

I been getting this error lately as soon as fire up Kibana. Any ideas why this is happening ?
As soon as I hit the Go Back button my queries would populate.

image

image

@epixa
Copy link
Contributor

epixa commented Jun 14, 2016

This will happen whenever Kibana receives a 502 error from Elasticsearch. Do you see any errors in your Elasticsearch logs?

@pip00
Copy link
Author

pip00 commented Jun 15, 2016

Here are my es logs

[2016-06-15 11:32:38,512][DEBUG][action.admin.cluster.node.stats] [elastic-kibana] failed to execute on node [Cr1WzqKXTAmtVy15adTRbg]
ReceiveTimeoutTransportException[[elasticsearch-1][192.168.1.102:9300][cluster:monitor/nodes/stats[n]] request_id [189677] timed out after [15099ms]]
at org.elasticsearch.transport.TransportService$TimeoutHandler.run(TransportService.java:679)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
[2016-06-15 11:32:38,899][DEBUG][action.admin.cluster.node.stats] [elastic-kibana] failed to execute on node [CIqJQI_SQlK0HbP4naWhkA]
ReceiveTimeoutTransportException[[elasticsearch-2][192.168.1.103:9300][cluster:monitor/nodes/stats[n]] request_id [189678] timed out after [15499ms]]
at org.elasticsearch.transport.TransportService$TimeoutHandler.run(TransportService.java:679)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
[2016-06-15 11:32:59,304][WARN ][transport ] [elastic-kibana] Received response for a request that has timed out, sent [35904ms] ago, timed out [20805ms] ago, action [cluster:monitor/nodes/stats[n]], node [{elasticsearch-1}{Cr1WzqKXTAmtVy15adTRbg}{192.168.1.102}{192.168.1.102:9300}{master=false}], id [189677]
[2016-06-15 11:33:10,304][WARN ][transport ] [elastic-kibana] Received response for a request that has timed out, sent [46904ms] ago, timed out [31405ms] ago, action [cluster:monitor/nodes/stats[n]], node [{elasticsearch-2}{CIqJQI_SQlK0HbP4naWhkA}{192.168.1.103}{192.168.1.103:9300}{master=false}], id [189678]

@epixa
Copy link
Contributor

epixa commented Jun 15, 2016

It looks like one of your Elasticsearch nodes is timing out on some requests. I'd recommend asking on the Elasticsearch forums or IRC channel, or opening an issue on https://github.com/elastic/elasticsearch

@jasontedor
Copy link
Member

This will happen whenever Kibana receives a 502 error from Elasticsearch.

Elasticsearch does not send 502s.

@epixa
Copy link
Contributor

epixa commented Jun 15, 2016

@jasontedor Any idea what's going on in those logs pasted above? It looks like ES is encountering a timeout, and it would be helpful to know what the behavior should be in that scenario, since it seems like the Kibana proxy isn't handling it correctly and thus just triggers a 502 (my best guess).

@jasontedor
Copy link
Member

jasontedor commented Jun 15, 2016

It looks like ES is encountering a timeout

@epixa Maybe the node is GCing or otherwise starved of resources, I don't know. Those are some massively long timeouts. I don't see an Elasticsearch bug here though, perhaps just a misconfiguration or under-provisioning of resources.

it seems like the Kibana proxy isn't handling it correctly and thus just triggers a 502 (my best guess).

That's what I think too.

@epixa
Copy link
Contributor

epixa commented Jun 15, 2016

@jasontedor Based on the little we know from those logs, do you have any idea what behavior the consumer would encounter with ES when those GC issues happen? I'd like to get Kibana to handle this better so it's at least not obfuscated by an erroneous 502, but I don't know the behavior Kibana is encountering in the first place. Perhaps there's just not enough to go on at this point.

@jasontedor
Copy link
Member

Perhaps there's just not enough to go on at this point.

@epixa It's not clear to me exactly what is happening here from the client perspective. This is because these log messages are from timing out while collecting node-level responses during a node stats request. Yet, even when that happens, Elasticsearch returns a status code 200 with the response body containing the node-level exceptions, if any.

@epixa
Copy link
Contributor

epixa commented Jun 15, 2016

Alright, thanks.

@Bargs
Copy link
Contributor

Bargs commented Jun 16, 2016

Is there a proxy between Kibana and ES?

cee-chen added a commit that referenced this issue Jan 24, 2024
`v92.0.0-backport.0`⏩ `v92.1.1`

---

## [`v92.1.1`](https://github.com/elastic/eui/releases/v92.1.1)

**Bug fixes**

- Minor `EuiDataGrid` cell performance fixes
([#7465](elastic/eui#7465))

## [`v92.1.0`](https://github.com/elastic/eui/releases/v92.1.0)

- Updated `EuiResizableButton` to allow customizing the `indicator`
style with either `handle` (default) or `border`
([#7455](elastic/eui#7455))
- Enhanced `EuiResizableContainer` to preserve the drag/resize event
when the user's mouse leaves the parent container and re-enters
([#7456](elastic/eui#7456))

**Bug fixes**

- Fixed an `EuiTreeView` JSX Typescript error
([#7452](elastic/eui#7452))
- Fixed a color console warning being generated by disabled `EuiStep`s
([#7454](elastic/eui#7454))

**Accessibility**

- `EuiDataGrid`'s keyboard/screenreader experience has been tweaked to
be more consistent for varying complex data:
([#7448](elastic/eui#7448))
- Headers are now always navigable by arrow key, regardless of whether
the header cells contain interactive content
- Non-expandable cells containing any amount of interactive content now
must be entered via Enter or F2 keypress
  - Expandable cells continue to be toggled via Enter or F2 keypress
- `EuiDataGrid` now provides a direct screen reader hint for Enter key
behavior for expandable & interactive cells
([#7448](elastic/eui#7448))
CoenWarmer pushed a commit to CoenWarmer/kibana that referenced this issue Feb 15, 2024
`v92.0.0-backport.0`⏩ `v92.1.1`

---

## [`v92.1.1`](https://github.com/elastic/eui/releases/v92.1.1)

**Bug fixes**

- Minor `EuiDataGrid` cell performance fixes
([elastic#7465](elastic/eui#7465))

## [`v92.1.0`](https://github.com/elastic/eui/releases/v92.1.0)

- Updated `EuiResizableButton` to allow customizing the `indicator`
style with either `handle` (default) or `border`
([elastic#7455](elastic/eui#7455))
- Enhanced `EuiResizableContainer` to preserve the drag/resize event
when the user's mouse leaves the parent container and re-enters
([elastic#7456](elastic/eui#7456))

**Bug fixes**

- Fixed an `EuiTreeView` JSX Typescript error
([elastic#7452](elastic/eui#7452))
- Fixed a color console warning being generated by disabled `EuiStep`s
([elastic#7454](elastic/eui#7454))

**Accessibility**

- `EuiDataGrid`'s keyboard/screenreader experience has been tweaked to
be more consistent for varying complex data:
([elastic#7448](elastic/eui#7448))
- Headers are now always navigable by arrow key, regardless of whether
the header cells contain interactive content
- Non-expandable cells containing any amount of interactive content now
must be entered via Enter or F2 keypress
  - Expandable cells continue to be toggled via Enter or F2 keypress
- `EuiDataGrid` now provides a direct screen reader hint for Enter key
behavior for expandable & interactive cells
([elastic#7448](elastic/eui#7448))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants