I’ll confirm that @reimlima is correct. Between the OS dependencies and the fact that you’re jumping two major versions, it’s easier to stand up a new Graylog stack and import the logs than it would be to try and get your stack upgraded piece by piece. I’ll note that given you’re upgrading major versions, each major version would include some sort of breaking change, as is the case with most projects that use semantic versioning.
Consider this: in order to go from 2.4 to 4.0, you’d have to
Upgrade Graylog to ~3.0 first, then upgrade to 3.3, then upgrade to 4.X
As a note, each time you upgrade, there’s going to be a database migration that happens in MongoDB
Upgrade Elasticsearch to 6.X and ensure you reindex, as if you plan to do any upgrades to Elasticsearch in the future, any indices that you have that were created on 5.X won’t work
Upgrade Mongodb–I’ve posted on the forums before that an upgrade path for Mongo isn’t as simple as upgrading to the latest version. You’d have to go from 3.2–>3.6–>4.0–4.2 if you were to run 4.2 in your new stack.
So given the amount of leapfrogging that has to happen, you’d be better off spinning up Graylog with Mongodb 4.0 or 4.2 and Elasticsearch 6.X , and then reindexing from remote so that the new Elasticsearch instance can slurp up the old indices.
Your logs are pretty much Elasticsearch indexes. Once you have successful in migrate your ES to a new version you just need to point your Graylog to the new ES server.