check_es_system icon indicating copy to clipboard operation
check_es_system copied to clipboard

add filter to curl request to prevent oom exceptions

Open c-kr opened this issue 3 years ago • 5 comments

Sometimes the apis response gets very long because it logs every http requests by default. On our test machine the following grep cmd filled up the 24gb memory within seconds:

if [[ -n $user ]] || [[ -n $(echo $esstatus | grep -i authentication) ]] ; then

We were able to mitigate it by adding a filter to the api requests to include only those values which are needed. This probably needs some more testing before merging, we only tested the memory mode

c-kr avatar Apr 13 '22 09:04 c-kr

~~Lets give #42 a bit more time to rebase the PR, then adjust this PR and get a new version out.~~ Nevermind, we'll go ahead with this one first and then we can do #42. Very interesting that your Elasticsearch shows so much data though. Could it be a misconfigured ES at the cause? On which check type did you see the huge data in the API response?

Napsty avatar Apr 20 '22 13:04 Napsty

I am not an elastic guy but i don't think it is misconfigured, just heavily used which leads to logging of a lot open http connections in the api output. It only happens sometimes a day.

We see this huge data in all checks used by the getstatus() method with endpoint (/stats).

c-kr avatar Apr 28 '22 08:04 c-kr

Thanks for the info @c-kr

We see this huge data in all checks used by the getstatus() method with endpoint (/stats).

That is certainly strange. I will do some tests with my Elasticsearch instances and maybe I can reproduce this sometime. What kind of Elasticsearch did you see that on? Local self installed or a Cloud instance? Which version?

Nevertheless, I think your contribution makes sense and will be merged after tests. :+1:

Napsty avatar Apr 28 '22 13:04 Napsty

What kind of Elasticsearch did you see that on? Local self installed or a Cloud instance? Which version?

Self Installed Elasticsearch Version 7.17.1

Nevertheless, I think your contribution makes sense and will be merged after tests. 👍

Thanks

c-kr avatar Apr 30 '22 13:04 c-kr

disk check does not work anymore with that change.

Before PR:

$ ./check_es_system.sh -H myes.eu-central-1.aws.cloud.es.io -u monitoring -p secret -S -P 9243 -t disk
ES SYSTEM OK - Disk usage is at 9% (41 G from 450 G)|es_disk=44708304152B;386547056640;459024629760;0;483183820800

When applying the PR:

$ ./check_es_system.sh -H myes.eu-central-1.aws.cloud.es.io -u monitoring -p secret -S -P 9243 -t disk
expr: non-integer argument
expr: non-integer argument
expr: non-integer argument
expr: non-integer argument
./check_es_system.sh: line 390: [: 44708304152: unary operator expected
./check_es_system.sh: line 393: [: 44708304152: unary operator expected
ES SYSTEM OK - Disk usage is at % (41 G from  G)|es_disk=44708304152B;;;0;null

Maybe the filter needs to be adjusted. Can you check please?

Napsty avatar May 13 '22 12:05 Napsty