-
Notifications
You must be signed in to change notification settings - Fork 116
Improve Elasticsearch connection in alarm logging service #3001
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
Improve Elasticsearch connection in alarm logging service #3001
Conversation
This brings two improvements: First, it is now possible to specify a scheme (use HTTPS instead of HTTP). Second, more than one host can be specified, which is useful when using a high-availability cluster.
The authentication can either be performed by specifying a custom “Authorization” header, or by specifying a username and password.
Due to a lack of synchronization, two instances of ElasticClientHelper could be created or an uninitialized instance could be returned.
georgweiss
left a comment
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.
Looks good, but I'd like to keep the default values for es_host and es_port in the properties file as I find it useful when running the service locally with local Elasticsearch.
|
@georgweiss Thank you for your feedback. I set them to the empty string in the properties file, so that it is easier to detect whether both the URL and the hostname / port has been set (and log an appropriate warning). The setting of I could change this and instead detect in the code when more than one of these properties has a non-default value, but I think that this would make the code slightly less readable and it does not really provide any benefits for the user. Would you still prefer that solution? |
I think this would be messy and confusing. A part of me dislikes have multiple properties controlling the same attributes...but backwards compatibility. @georgweiss can we mark the old host and port as deprecated and remove them in a future release? |
|
@georgweiss sorry to keep pinging you... but can we merge this? |
|
Sure, go ahead and merge |
|
This update has certainly improved the connection between the alarm logging service and elasticsearch. Many thanks. |
This PR introduces three changes to the alarm logging service:
es_hostandes_port, it is now possible to specifyes_urls. Ines_urlsa scheme can be specified, so it is possible to use HTTPS instead of HTTP. It is also possible to specify multiple URLs belonging to the same Elasticsearch cluster, thus enabling automatic failover when one of the nodes is not available.es_auth_header,es_auth_username, andes_auth_password.es_auth_usernameandes_auth_passwordcan be used to enable HTTP Basic authentication. As an alternative, thees_auth_headeroption can be used to directly set the contents auf the HTTP Authorization header, thus enabling arbitrary authentication schemes.ElasticClientHelper.getInstance()has been fixed. This race condition could have the effect that contrary to expectation, more than oneElasticClientHelperwas created. It could also result in an uninitialized instance ofElasticClientHelperbeing returned.The first two changes are very similar to a PR that was recently merged into the Channel Finder service.