The logs are mysteriously truncated. It might be that Kibana is running out of memory, if you're running Kibana in docker you should see the stack trace, but I'm not sure how this works with docker-compose. I'd suggest running Kibana without docker compose to see if you can't see the logs. Without logs anything we do is just guessing.
I missed this previously:
The amount of total data is not more than 250MB
By default Kibana will read 1000 documents during a migration and try to write all 1000 of them using a bulk index. In your case this will create a bulk indexing payload of at least 250MB which will run into Elasticsearch's http.max_content_length limit which defaults to 100MB.
You can try to set migrations.batchSize: 1 to see if migrations would pass.
If each of your 19 saved objects are 250/19=13MB that would be fine, but if one of them are larger than 100MB this would still fail. So you might have to trim back your jupyter notebooks before importing them into Kibana.
Thanks for the explanation. I could guess about the memory size in kibana but i don't know what is in particular the problem. Can I ask you, how can I solve the problem? I think a solution could be remouve only the saved_object. I can guess the name of the visualization but how can I remouve from bash, becuase kibana doesn't work? Or in faster way I can remouve .kibana index such that I can restore the index-patterns and visualization.
The best way to do this is to rollback to a previous version of Kibana. I'm guessing you might not have backup snapshots so then you'll need to follow these instructions: Upgrade migrations | Kibana Guide [7.14] | Elastic
Once you've rolled back you can use saved objects management to delete the visualization.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.