-
Notifications
You must be signed in to change notification settings - Fork 287
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
Support Elasticsearch 8 #92
Comments
ES8 support may need to be considered in addition to doc_type. In ES7.X this include_type_name default has been changed to false, but elastalert explicitly specifies Also, the specification of elasticsearch>=7.0.0,<8.0.0
The following are expected changes that need to be addressed.
add
elastalert/create_index.py before
after
elastalert/loaders.py It is necessary to prevent the following checks from being performed on elasticsearch 8 or later versions
elastalert/elastalert.py before
after
before
after
before
after
elastalert/test_rule.py before
after
elastalert/tests/conftest.py mock_es_client add
mock_es_sixsix_client add
elastalert/es_mappings/8/elastalert.json add file dateOptionalTime→date_optional_time
add Directory elastalert/es_mappings/8 elastalert/es_mappings/8/elastalert_error.json ・・・add file dateOptionalTime→date_optional_time
elastalert/es_mappings/8/elastalert_status.json・・・add file dateOptionalTime→date_optional_time
elastalert/es_mappings/8/past_elastalert.json・・・add file dateOptionalTime→date_optional_time
elastalert/es_mappings/8/silence.json・・・add file dateOptionalTime→date_optional_time
elastalert/create_index.py before
after
tests/create_index_test.py add test_read_es_8_index_mappings
|
If elasticsearch 8 is released and supported, the docker image will likely need to provide both |
This is the exact code block that needs to be changed:
|
I noticed the alpha ES 8 image is now available from in the Elasticsearch Docker registry. I'll start working on ES 8 compatibility this weekend, assuming no one else is already looking at this. |
Thanks @ferozsalam. |
Since elasticsearch-py 8.0.0 of elasticsearch's pytnon client has not been released yet, is it correct to change the code once in the state of elasticsearch-py 7.0.0 and check the operation? |
That's a good point. I think my plan will be to see if I can get things working with the ES8 alpha and elasticsearch-py 7.0.0 over the weekend. Elastic has already started work on elasticsearch-py 8.0.0, so if 7.0.0 doesn't work I might try using the latest version of the library direct from the repository. If it all doesn't work and we need to wait for elasticsearch-py 8.0.0, I'll post here and pause for a while. |
Since the latest elasticsearch-py currently has an implementation that does not connect to Amazon Elasticsearch Service, it is necessary to support opensearch-py at the same time as supporting elasticsearch-py 8. opensearch-py seems to be able to connect to both elasticsearch and Amazon Elasticsearch Service, but the client version before the connection restrictions were built in was elasticsearch-py 7.13.4. Please note that elastalert2 uses elasticsearch-py7.0.0, so if you change all connections to opensearch-py, some rules will not work. https://opensearch.org/docs/clients/index/
|
The index |
Share information about es 8. Deprecation warnings in 7.15.0 pre-releases
I didn't expect the API body parameter to be deprecated. I think it has a big impact. |
I've spent some time this weekend (much delayed!) getting a development environment setup, and have managed to get ElastAlert running and communicating to Elasticsearch 8.0.0-alpha2 using elasticsearch-py 7.0.0 with a single debug rule running. The good news is that it looks like ES 8-alpha2 still works (at least for ElastAlert) with elasticsearch-py 7.0.0. There are several places where I need to make further tweaks to handle the removal of doc types, but I don't foresee that proving a major hurdle. My goal for this week is to get the unit test suite working to see what else needs fixing/changing. I will probably start doing the development work on a separate branch. Thanks very much for your code samples above @nsano-rururu - they saved me a lot of time. A question - does anyone know why we have pinned the current |
Yelp/elastalert#2593 (comment)
Fix issue caused by 7.x breaking change (_source_include/_source_exclude)
ES Version revert to 7.0.0 |
The advantage of fixing with elasticsearch-py 7.0.0 is that ES 6/7/8 and OpenSearch only need to provide one docker image. elasticsearch-py [7.x] » Release notes https://www.elastic.co/guide/en/elasticsearch/client/python-api/current/release-notes.html |
After that, if there is a new query writing method supported in the version after elasticsearch-py 7.0.0 release, it will not be usable. And since using elasticsearch-py 7.x with elasticsearch 8 is an unofficial method, the chances of something going wrong are not zero. Since it is officially announced that it will be used as follows |
Continuing to use middleware with older versions has a non-zero potential for security issues. If you understand that and still use the older version, I won't say anything anymore. |
Yes, completely understand and agree that the aim should be to move over to the latest library version as quick as is possible. However if migrating to ES 8 does not have a hard dependency on elasticsearch-py 8.0.0, then I think it might make more sense to work on the two tasks separately, especially if there are significant other changes required to support elasticsearch-py 8.0.0. @jertel do you have an opinion here? Thanks for the explanation on the Docker image - it might be an idea to offer multiple Docker images so that we can move forward with elasticsearch-py version, perhaps based on different branches of the repo? Again something that I think @jertel would have to set up, so would be interested in knowing his thoughts. |
Ideally we would continue with:
My preference is to have a single branch to avoid maintaining multiple copies of the source code. I think having a temporary branch to work through the ES 8 compatibility is fine though, provided the development and testing doesn't take months to complete before we can merge it back to master. Below is my understanding of the library compatibility matrix (If there are corrections please tell me so I can update this): elasticsearch-py8
elasticsearch-py7 (specifically 7.0.0)
opensearch-py
Abstracting the calls to the Elastic API away from the general ElastAlert 2 source code and into a new search.py class would give us the ability to put all the logic in that new class for choosing whether to use the opensearch-py library or the elasticsearch-py library. This might be easier said than done, but it would help isolate all of this complexity into one place. If @ferozsalam can prove that ES8 compatibility can be had with the removal of doc_type and without switching to the new library then let's proceed with getting ES8 support into master without changing the Python library and without breaking ES7 or OpenSearch compatibility. Then, separately, we can discuss deprecating support for old versions of Elasticsearch, based on Elastic's End-of-Life (EOL) dates. This will allow us to begin upgrading the elasticsearch-py library to newer versions. |
Elastic Cloud, but according to the following material, it seems that you need to add the parameter
elasticsearch-py [7.x] » Release notes
|
It's opensearch-py, but it seems that I'm trying to remove the code related to Elastic Cloud connection. I have a pull request. |
Thanks, I've updated the post above to mention that ES Cloud is "NOT supported" by opensearch-py. |
Since opensearch-py should fork elasticsearch-py 7.13.4 as a new project, I think ES7 and ES8 will be as follows. ES 7: Unknown → Supported |
Ok, then it probably also means opensearch-py does not support ES6 or lower, based on #90. I'll update that now. |
Hello folks 👋 Saw this thread and was wondering if there's anything I can do to help or clarify. One thing I saw that I wasn't sure of was:
Elastic Cloud is definitely supported by all 7.x versions of the client, the |
Thanks for chiming in @sethmlarson. I've updated the post above to reflect that clarification. While you're here, could you comment on the following:
|
Thank you!
Our compatibility policy is forwards compatibility, so there's no guarantee that v8.0 clients will work with v7.x servers. However if you're not relying on removed features (mapping types, filters) then it'd maybe work? Wanted to highlight the difference between "supported" and "happens to work".
Mapping types and anything removed in 8.0 are still removed even when using "compatibility mode". However in client versions pre-7.16 will likely need to be more hands-on with the compatibility mode by settings HTTP headers yourself. In 7.16 I'm working towards getting the mode to be much easier to use. |
One point supplement. The HTTP header cannot be set without modifying the current elastalert2 program. allow custom http_headers in config.yaml |
Thanks all for your feedback and suggestions here, there’s a lot to think about. I think we have two options. Option 1We’re currently unable to upgrade our If we were to formally drop support for ES 6 and below, we could then move to elasticsearch-py 7.15.0 (and eventually 7.16.0), which will give us some nice fixes while also making compatibility with ES 8 neater, judging by @sethmlarson's comment above. With support for ES 8 done, we could then work on the changes necessary to support elasticsearch-py 8.0.0 without any (significant) time pressure. Option 2Otherwise we hardcode the compatibility header into our HTTP requests and continue with ES 7.0.0 until a point where we are happier to drop support for ES 6. My preference is for Option 1, as:
What does everyone else think? |
I think option1 is fine. Since elasticsearch-py 8.0.0 will end support for Python 3.5 and earlier, is it possible to check the python version with setup.py? I think you should add settings if you can easily do it. |
I agree with Option 1. |
Regarding the abolition of the body parameter, it seems that it has changed to elasticsearch-py 9.0.0. elasticsearch-py 8.0.0 seems to support both old and new writing |
Looks like Elasticsearch 8.0 is already out, and somewhat predictably, I haven't found the time to enable support! 😄 I'll take a look later this weekend, although with the compatibility mode I suspect the changes will be minimal. |
While trying to update our Elastic Cloud 7.17.0 to 8.0 the cluster upgrade failed.
|
It's a natural result because it doesn't support elasticsearch 8 yet. |
Does this Elasticsearch 8 support mean the following support and operation check? Create Index elastalert-test-rule Do you support not to specify doc_type in elasticsearch 8? Rule Type
Don't check
Operation check when Loading Filters Directly From Kibana 3 Currently not moving normally, so it does not correspond. others
elastalert.py・・・elastalert.py may have other modifications get_hits The following seems to need to be prevented from running on es8
|
Please let us know if you need an investigation. |
Referring to this issue, is there any (relatively simple) automated workaround to this? Or should we be creating an instruction page for people looking to migrate from ES 7 -> ES 8 with instructions on the manual steps they need to take? |
Do you mean to add to the FAQ how to check the index of elastalert, how to delete it, and have it run createindex again? |
Yes, exactly. I am not sure if the process is easily automatable, but given that people only have to do it once per cluster, perhaps manual instructions will be enough? |
I agree to add it to the FAQ. |
It would make life easier for users if it was automated. If it's automated then the existing indices should be renamed with a Either way, the manual upgrade steps should be documented. Perhaps something like the following:
|
Hi
Any help? |
Hey @konstantin-921 I suspect that part of the reason is because a release with alpha ES 8 support hasn't been cut yet - if you're using 2.3.0, you won't have the latest changes. Please note that ElastAlert isn't guaranteed to work with ES 8, even with the latest (unreleased) changes. This is still a work in progress. |
Thank you for your response @ferozsalam . Then I will wait for new releases. |
In elasticsearch 8, elastalert/test_rule.py doc_type = res['hits']['hits'][0]['_type'] elastalert/elastalert.py if 'doc_type' not in rule and len(hits):
rule['doc_type'] = hits[0]['_type'] |
Elasticsearch v8 no longer supports doc_type. There is likely going to be some effort need to update this project to deal with this.
The text was updated successfully, but these errors were encountered: