Dan Achin
04/23/2021, 9:35 PMtls_session_reuse: true
. Is that only for the logger perhaps? It's surprising to me that we have constant sessions up and down - this is currently 5000 per min and will go even more crazy as we scale.Juan Alvarez
04/23/2021, 9:36 PMDan Achin
04/23/2021, 9:36 PMzwass
04/23/2021, 9:39 PMStefano Bonicatti
04/23/2021, 9:45 PMSeshu
04/23/2021, 9:49 PMDan Achin
04/23/2021, 10:05 PMSeshu
04/23/2021, 10:13 PMDan Achin
04/23/2021, 10:21 PMSeshu
04/23/2021, 10:23 PMSeconds between polling for new queries (default 60)
. So this is the sleep duration between sending distributed_read requests.Dan Achin
04/23/2021, 10:29 PMSeshu
04/23/2021, 10:31 PM./dispatcher/distributed_runner.cpp: pause(std::chrono::seconds(FLAGS_distributed_interval));
--tls_dump
and see what is going on...Dan Achin
04/23/2021, 10:35 PMSeshu
04/23/2021, 10:37 PMConnection
header in request/response and also track netstat
connection churn from Osquery.Dan Achin
04/23/2021, 10:37 PM--distributed_interval=60
In seconds, the amount of time that osqueryd will wait between periodically checking in with a distributed query server to see if there are any queries to execute.
This is how I understood it. Your example above @Seshu says you set this to 0. That seems crazy. how can your clients check in without any interval between subsequent check-ins?Seshu
04/23/2021, 10:45 PMDan Achin
04/23/2021, 10:45 PMzwass
04/23/2021, 10:47 PMDan Achin
04/23/2021, 10:49 PMSeshu
04/23/2021, 10:56 PMzwass
04/23/2021, 10:56 PMDan Achin
04/23/2021, 10:58 PMzwass
04/23/2021, 11:00 PMSeshu
04/23/2021, 11:04 PMzwass
04/23/2021, 11:05 PMSeshu
04/23/2021, 11:06 PMzwass
04/23/2021, 11:07 PMStefano Bonicatti
04/23/2021, 11:08 PMzwass
04/23/2021, 11:13 PMDan Achin
04/23/2021, 11:13 PMdistributed_interval
is set to 10 seconds, so I'm guessing it won't be an issue with 0. I'll have to test this out.Stefano Bonicatti
04/23/2021, 11:22 PMdistributed_tls_max_attempts
) which means, 1 immediate, then if the previous failed, 1 after 1 second, 1 after 4 seconds. After this, the distributed_interval
kicks in.Dan Achin
04/23/2021, 11:24 PMzwass
04/23/2021, 11:26 PMDan Achin
04/23/2021, 11:29 PMzwass
04/23/2021, 11:30 PMDan Achin
04/23/2021, 11:34 PMzwass
04/23/2021, 11:36 PMDan Achin
04/23/2021, 11:37 PMzwass
04/23/2021, 11:41 PMtls_session_timeout
implementation? Would be good to file an issue with osquery if you can come up with a repro.Dan Achin
04/23/2021, 11:59 PMI might be wrong, but the timeout handler could be closing the connection after 16 seconds (hand-coded in tls.cpp). Which means keep-alive for distributed connections might not make any difference. Need to double check!!!
I've been tweaking tls_session_timeout
on our clients and I'm not seeing any difference with #s of connections opened / closed from that. The only thing I'm seeing that reduces connection churn from clients is to increase our distributed_interval
.
I'm thinking I'll open an osquery issue, but wondered if you confirmed a hard-coded timeout in tls.cpp.Seshu
04/27/2021, 5:01 PMDan Achin
04/27/2021, 5:04 PMSeshu
04/28/2021, 12:31 AMnew_client_options_
and client_options_.ssl_connection_ != ssl_connection
are true
for TLS loggerDan Achin
04/30/2021, 9:15 PM