If you are asking for an exploit, nobody here will give you one.
But in short, no, it is not. The CVE says
One vector that allowed exposure to this vulnerability was Log4j’s allowance of Lookups to appear in log messages. This meant that when user input is logged, and that user input contained a JNDI Lookup pointing to a malicious server, then Log4j would resolve that JNDI Lookup, connect to that server, and potentially download serialized Java code from that remote server. This in turn could execute any code during deserialization.
Note first that this says "one vector". If there are other known vectors the following statements may not apply.
"when user input is logged". I cannot think of anything in logstash that logs user input (i.e. event data) unless log.level debug is enabled, and for some inputs it requires trace. If the data never goes to log4j2 then I cannot see that log4j2 is directly exploitable.
"This in turn could execute any code during deserialization". I am familiar with deserialization attacks (I studied the 2015 Lawrence/Frohoff "Pickles" attack) and this feels like an understatement. The attack surface is not "any code that the app calls". It is "any code in the class path".
When an application is built upon a framework built upon frameworks built upon frameworks "any code in the class path" is a ridiculously large attack surface, much of which is unused and some of which has not been maintained for years.
Do not try to develop your own mitigations unless you are a very experienced Java security engineer.