Evaluate how we are exposing the api endpoints

[ph]

The API will need to expose his endpoints with a webserver and we also have a http input providing his own HTTP server. It's probably a good time to see if we offer the HTTP server as a first class service that plugins authors can hook into and add their own endpoints.

PRO:

• Reduce the code
• Offer a centralized configuration for the certificate/port/ip (probably via a logstash.yml)
• Mimic what elasticsearch is doing with their plugin architecture

CON:

• Shared the certificate
• Use same port
• Performance or blocking in the input side could possibly impact the debugging api?

Ref: #2611

[purbon]

I like this idea, I think some of your concern can be simplified by providing proper service interaction, for example I don't see special issues with:

• Providing different ports per service invocation.
• Also providing different certificates.

Only important things for me to consider for now are performance implications, but at the end of the day we've similar ones, just the code is distributed and not provided only by logstash-core.

Worth exploring the idea of having this services, even if for now is just to expose #2611, but with a more general service design. What do you think?

[ph]

Yeah, you are correct if we expose different ports which would be in fact a different puma thread pool the problem would be solve if one of the service make a hang.

But I think the added complexity to do that doesn't give a lot of values unless we have multiples different inputs requiring a webserver, which isn't the case right now we can always reevaluate that at a later time.

[purbon]

Agree a lot with you.

/purbon

On Wed, 9 Dec 2015 15:27 Pier-Hugues Pellerin notifications@github.com
wrote:

Yeah, you are correct if we expose different ports which would be in fact
a different puma thread pool the problem would be solve if one of the
service make a hang.

But I think the added complexity to do that doesn't give a lot of values
unless we have multiples different inputs requiring a webserver, which
isn't the case right now we can always reevaluate that at a later time.

—
Reply to this email directly or view it on GitHub
#3801 (comment).

[ph]

We have decided and implement a different service decoupled from the http input server.
see https://github.com/elastic/logstash/tree/feature/metrics