Consider logstash configuration useability#109
Conversation
|
We've discussed this here before. I agree with your suggested approach. Users want to interact with mesos-logstash in a similar way to Logstash. However we wouldn't be able to just pass through a Logstash config file without alteration. Some current features are more dynamic, e.g. adding the Mesos slave ID to each log event. |
|
What about having the config file generated by the scheduler and available on an endpoint? On task launch it can be downloaded by the Mesos fetcher just like the executor Jar and the logstash distribution. |
|
Another thing… So I was thinking about using a template engine like Freemarker to generate Logstash configuration. Which is fairly easy. But then comes the resources, mainly ports. I see two solutions to giving users total freedom with a template logstash configuration:
I vote for 2nd. |
|
Quite a few things happened here.
|
| deployScheduler(null, null, false, logstashConfig, false); | ||
|
|
||
| final int elasticsearchPort = 9300; | ||
| SECONDS.sleep(2); |
There was a problem hiding this comment.
Probably not necessary considering the await next.
There was a problem hiding this comment.
The driver throws a stupid Exception, because nothing was ready.
|
That looks great Martin. Ready. |
|
Make sure you do some manual testing before you release, though. |
Consider logstash configuration useability
I don't know the right answer. But using CLI parameters to alter the logstash config seems clunky. It's not immediately obvious to users who are used/have read that you use a configuration file.
Consider allowing the use of a configuration file (like ES) that is the same as a logstash configuration file. Parse and alter if you must, but it may be more simple (and reduce lines of code) to not parse the file at all. I.e. the user is responsible for passing the correct ES endpoint, etc.