X-pack 5.4.1 monitoring clashing with ROR 1.16.4

(Nan008) #1

Another problem arise today for us. We have x-pack monitoring on.

xpack.graph.enabled: false
xpack.ml.enabled: false
xpack.monitoring.enabled: true
xpack.security.enabled: false
xpack.watcher.enabled: false

On its own it is working ok. The same with ROR/KBN plugins on its own they are working perfectly when combine together, there are issues starting to happen, like after a while when trying to restart elasticsearch it hangs and we need to kill -9 ES_pid to be able to get the ES going.

I noticed that x-pack plugin is changed a lot lately, as in testing env I reintalled it couple of times in last two days, they added Machine Learning tab to Kibana (which is greyout for me). So question now - will you at some stage be working on monitoring feature as most people are using only this feature of x-pack and using different plugins for security. Or will you develop ROR further to be able to work with x-pack monitoring?

(Simone Scarduzio) #2

There’s an access auditing screen in the roadmap with ROR specific information (user names, indices, etc), but ideally ROR should not interfere with xpack monitoring, as it provides more generic information and it’s already a useful free tool.

I will test it and see where it fails.

(Simone Scarduzio) #3

I made it work, use the Kibana plugin 0.1.5 and the ES plugin 1.16.5-pre1

https://readonlyrest-data.s3-eu-west-1.amazonaws.com/build/1.16.5-pre1/readonlyrest-1.16.5-pre1_es5.4.1.zip?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJEKIPNTOTIVGQ4EQ/20170612/eu-west-1/s3/aws4_request&X-Amz-Date=20170612T095818Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=b1c7bb063f6a4fb2b4c76544055430b2d6ed0a3de09c4c6cdebf0d60e92720f1

(Nan008) #4

Hey, I tried it and it doesn’t work BUT I found the problem with x-pack ML plugin.

I opened the ticket with the ES on their forum as the stuck ES on stopping is an issue regardless of ROR and KBN being installed or not in my env.

We will probably remove x-pack and stay with ROR/KBN only.

Thank you for all your hard work, we really appreciate it.

I still think you should think about monitoring plugin - x-pack has too much in one package, they made mistake putting it all in one.

(Simone Scarduzio) #5

Well, I made it work for monitoring alone. I also updated the instructions to reflect that (sorry I didn’t point you immediately to the updated instructions)

(Simone Scarduzio) #6

BTW I appreciate a lot your feedback about making ROR take care of monitoring aspects too. Would you care formalizing the proposal in a new topic under “New Feature Ideas” including the poll, so people can vote and expand ini the comments?

(Nan008) #7

I will open the New Feature ticket no problem. They changed the x-pack on friday without changing the version number and no notification whatsoever. My testing env changed the kibana a little bit adding the Machine Learning tab. if you testing ROR/KBN with the monitoring on the older version of x-pack pre 9th of June, it is working perfectly as we checked that on our old env (we are migrating from 3 nodes to 15 nodes env).

The problem is that they added ML to x-pack in alpha stage and monitoring has nothing to do with the hung env. I did the stacktrace and found the problem and reported it the ES people. The problem only exist in env with systemd. I am testing their workaround at the moment.

We had a talk in the team regarding if we want to rely on x-pack for monitoring and if there was an alternative the answer is “definitely NO”.

Anyway, thnks again

PS: ROR 1.16.5-pre1 has this error:

[CLUSTERWIDE SETTINGS] index settings not found, have you installed ReadonlyREST Kibana plugin? Will keep on using elasticearch.yml. Learn more at https://readonlyrest.com

I got back to ROR 1.16.4 with KBN 0.1.5 and it is working perfectly with the x-pack

(Simone Scarduzio) #8

Thanks Anna, great insight!