-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Handle multiple upstreams in ingress-controller #21215
Conversation
Signed-off-by: chrismark <chrismarkou92@gmail.com>
Signed-off-by: chrismark <chrismarkou92@gmail.com>
Pinging @elastic/integrations-platforms (Team:Platforms) |
💔 Build FailedExpand to view the summary
Build stats
Test stats 🧪
Steps errorsExpand to view the steps failures
Log outputExpand to view the last 100 lines of log output
|
Signed-off-by: chrismark <chrismarkou92@gmail.com>
for (def item : ctx.nginx.ingress_controller.upstream.response.length_list) { | ||
length = length + Integer.parseInt(item); | ||
} | ||
ctx.nginx.ingress_controller.upstream.response.length = length; |
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.
Maybe change the name to indicate it's a total value?
ctx.nginx.ingress_controller.upstream.response.length = length; | |
ctx.nginx.ingress_controller.upstream.response.length_total = length; |
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.
Take into account that this is a breaking change as it changes an existing field. I would prefer to keep the original field.
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.
👍
Signed-off-by: chrismark <chrismarkou92@gmail.com>
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.
Arrays are problematic, for example here we might want to use arrays of objects, so we have single objects for the address, status code and response type for each endpoint. But I think you have made a good compromise.
@@ -11,6 +11,26 @@ | |||
Real source IP is restored to `source.ip`. | |||
|
|||
# ingress-controller specific fields | |||
- name: upstream_ip_list | |||
type: array |
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.
I think that type: array
only doesn't generate any mapping. This should be an array of keywords, or just keyword. Elasticsearch doesn't have a data type for arrays, but any field can have multiple values, see docs about arrays).
We could use just keyword:
type: array | |
type: keyword |
Or if we still want to indicate that this is intended to store multiple values:
type: array | |
type: array | |
object_type: keyword |
Same for the other lists.
(%{NUMBER:nginx.ingress_controller.upstream.response.status_code:long}|-) %{GREEDYDATA:nginx.ingress_controller.http.request.id} | ||
\[%{DATA:nginx.ingress_controller.upstream.alternative_name}\] (%{UPSTREAM_ADDRESS_LIST:nginx.ingress_controller.upstream_ip_list}|-) | ||
(%{UPSTREAM_RESPONSE_LENGTH_LIST:nginx.ingress_controller.upstream.response.length_list}|-) (%{UPSTREAM_RESPONSE_TIME_LIST:nginx.ingress_controller.upstream.response.time_list}|-) | ||
(%{UPSTREAM_RESPONSE_STATUS_CODE_LIST:nginx.ingress_controller.upstream.response.status_code_list}|-) %{GREEDYDATA:nginx.ingress_controller.http.request.id} | ||
pattern_definitions: | ||
NGINX_HOST: (?:%{IP:destination.ip}|%{NGINX_NOTSEPARATOR:destination.domain})(:%{NUMBER:destination.port})? | ||
NGINX_NOTSEPARATOR: "[^\t ,:]+" | ||
NGINX_ADDRESS_LIST: (?:%{IP}|%{WORD})("?,?\s*(?:%{IP}|%{WORD}))* | ||
UPSTREAM_ADDRESS: '%{IP:nginx.ingress_controller.upstream.ip}(:%{NUMBER:nginx.ingress_controller.upstream.port})?' |
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.
Not used now.
"nginx.ingress_controller.upstream.response.time_list": [ | ||
"0.000" | ||
], | ||
"nginx.ingress_controller.upstream_ip_list": [ |
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.
We are not storing ips in this field, maybe we can call it upstream_endpoint_list
, or upstream_address_list
.
} | ||
int length = 0; | ||
for (def item : ctx.nginx.ingress_controller.upstream.response.length_list) { | ||
length = length + Integer.parseInt(item); |
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.
Hmmm, does it make sense to sum up the response lengths? The client would only see the most recent response.
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.
That makes sense, I will go with it! Thanks!
Signed-off-by: chrismark <chrismarkou92@gmail.com>
(cherry picked from commit b65b123)
* upstream/master: feat: prepare release pipelines (elastic#21238) Add IP validation to Security module (elastic#21325) Fixes for new 7.10 rsa2elk datasets (elastic#21240) o365input: Restart after fatal error (elastic#21258) Fix panic in cgroups monitoring (elastic#21355) Handle multiple upstreams in ingress-controller (elastic#21215) [CI] Fix runbld when workspace does not exist (elastic#21350) [Filebeat] Fix checkpoint (elastic#21344) [CI] Archive build reasons (elastic#21347) Add dashboard for pubsub metricset in googlecloud module (elastic#21326) [Elastic Agent] Allow embedding of certificate (elastic#21179) Adds a default for failure_cache.min_ttl (elastic#21085) [libbeat] Disk queue implementation (elastic#21176)
What does this PR do?
This PR tunes
ingress-controller
's pipeline so as to handle multiple upstreams. We put the multiple lengths, times and status_codes inupstream.response.length_list
,upstream.response.time_list
andupstream.response.status_code_list
fields while we sum time under single fieldupstream.response.time
and we only store last response length inupstream.response.length
(with this we also preserve the existing dashboardsbeats/filebeat/module/nginx/_meta/kibana/7/dashboard/Filebeat-nginx-ingress-overview.json
Line 1007 in 54ea284
In addition, we preserve the multiple upstreams at
upstream_ip_list
and we only store the lastupstream.ip
andupstream.port
as well as the laststatus_code
.Sample log:
192.168.64.14 - - [07/Feb/2020:12:02:42 +0000] "GET /v2/some HTTP/1.1" 200 61 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:72.0) Gecko/20100101 Firefox/72.0" 348 0.001 [default-web2-8080] [] 172.17.0.6:8080, 172.17.0.7:8080 61, 100 0.100, 0.004 200, 203 835136ae24486dbb4156dcbe21f5d402
Sample event:
Why is it important?
So as to handle cases where nginx-ingress retries multiple upstreams.
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Related issues