# Output beat events as plain HTTP POST **URL:** \ **Category:** Beats\ **Tags:** beats-development\ **Created:** [August 12, 2016, 12:50pm UTC](https://discuss.elastic.co/t/output-beat-events-as-plain-http-post/57923 "2016-08-12T12:50:47Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![raboof](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raboof/32/9851_2.png) [@raboof](https://discuss.elastic.co/u/raboof)\ **Post date:** [August 12, 2016, 12:50pm UTC](https://discuss.elastic.co/t/output-beat-events-as-plain-http-post/57923/1 "2016-08-12T12:50:47Z")
The current suite of output modules doesn't include a publisher that simply POST's the events to some generic HTTP endpoint, without having to go through e.g. logstash. I've made a PoC of this idea at [https://github.com/elastic/beats/compare/master...raboof:httpOutput](https://github.com/elastic/beats/compare/master...raboof:httpOutput) Would such a thing be useful to include upstream? ---
**Author:** ![tudor](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tudor/32/3753_2.png) [@tudor](https://discuss.elastic.co/u/tudor)\ **Post date:** [August 16, 2016, 12:45pm UTC](https://discuss.elastic.co/t/output-beat-events-as-plain-http-post/57923/2 "2016-08-16T12:45:14Z")
Thank you for opening this discussion, we do hear the request for a generic HTTP output from time to time. In general, however, we're very conservative when it comes to adding new outputs. They tend to start simple, but require a lot of maintenance work over time, plus Logstash has a lot of outputs already, which can be used at the cost of adding another project. We've added Kafka & Redis to libbeat because these two are really popular as deployment options among our users, but at the same time planned to stop there :-). In the particular case of HTTP, while it's great that the code change serves your needs, we can expect people to request bulking, custom parameters and headers, authentication mechanisms, different http versions, a.s.o as basic functionality. That's why we're quite reticent in accepting this patch. Because we didn't have one before, I started an [enhancement ticket](https://github.com/elastic/beats/issues/2275) to measure the interest in this, and we can reconsider if we see this being a must for many of our users. ---
**Author:** ![raboof](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raboof/32/9851_2.png) [@raboof](https://discuss.elastic.co/u/raboof)\ **Post date:** [August 18, 2016, 8:18am UTC](https://discuss.elastic.co/t/output-beat-events-as-plain-http-post/57923/3 "2016-08-18T08:18:03Z")
> [@tudor](#): > > (outputs) require a lot of maintenance work over time, plus Logstash has a lot of outputs already, which can be used at the cost of adding another project > [@tudor](#): > > we can expect people to request bulking, custom parameters and headers, authentication mechanisms, different http versions, a.s.o as basic functionality Agreed, I can see how this could be a slippery slope, and certainly slowly re-implementing most of Logstash as libbeat outputs is not really an appealing idea ;). On the other hand requiring Logstash is a hurdle operationally: asking users to run the beat is one thing, but asking them to also configure and run a Logstash instance goes a bit further. > [@tudor](#): > > We've added Kafka & Redis to libbeat because these two are really popular as deployment options among our users, but at the same time planned to stop there :-). Makes sense. I wonder if we could allow additional outputs as 'third-party' extensions: outputs already register themselves on initialization, so that looks good, but I'm not sure I could register my own output in my beat without adding it to the list at `libbeat/publisher/publish.go`. That might be a way to introduce a bit more flexibility, without taking on too much of a maintenance burden. > [@tudor](#): > > I started an enhancement ticket to measure the interest in this Thanks! You mention using the existing elasticsearch endpoint for this purpose. That might be an interesting avenue to explore, though I seem to remember considering it and deciding there was a bit too much ES-specific logic in there. Perhaps I should take another look ;). ---
**Author:** ![steffens](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/steffens/32/79630_2.png) [@steffens](https://discuss.elastic.co/u/steffens)\ **Post date:** [August 18, 2016, 10:38am UTC](https://discuss.elastic.co/t/output-beat-events-as-plain-http-post/57923/4 "2016-08-18T10:38:52Z")
> Makes sense. I wonder if we could allow additional outputs as 'third-party' extensions: outputs already register themselves on initialization, so that looks good, but I'm not sure I could register my own output in my beat without adding it to the list at libbeat/publisher/publish.go. That might be a way to introduce a bit more flexibility, without taking on too much of a maintenance burden. Outputs already act kinda like plugins (just golang having no proper plugin support yet). That is, it's already supported by beats. See this post in reply to very custom syslog output proposal: [New syslog output by avleen · Pull Request #1525 · elastic/beats · GitHub](https://github.com/elastic/beats/pull/1525#issuecomment-217651768) The init function will be executed for any package being directly or indirectly imported by the main package. ---
**Author:** ![raboof](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raboof/32/9851_2.png) [@raboof](https://discuss.elastic.co/u/raboof)\ **Post date:** [August 18, 2016, 11:05am UTC](https://discuss.elastic.co/t/output-beat-events-as-plain-http-post/57923/5 "2016-08-18T11:05:16Z")
> [@steffens](#): > > The init function will be executed for any package being directly or indirectly imported by the main package Interesting, I'll definitely check that out! Thanks for the pointer. ---
**Author:** ![raboof](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raboof/32/9851_2.png) [@raboof](https://discuss.elastic.co/u/raboof)\ **Post date:** [August 19, 2016, 9:19am UTC](https://discuss.elastic.co/t/output-beat-events-as-plain-http-post/57923/6 "2016-08-19T09:19:08Z")
> [@steffens](#): > > Outputs already act kinda like plugins (just golang having no proper plugin support yet). > > That is, it's already supported by beats. See this post in reply to very custom syslog output proposal: [New syslog output by avleen · Pull Request #1525 · elastic/beats · GitHub](https://github.com/elastic/beats/pull/1525#issuecomment-217651768) Jup this seems to work out great! [GitHub - raboof/beats-output-http: HTTP output producer for the Elastic Beats framework](https://github.com/raboof/beats-output-http) - thanks for the nudge 🙂 ---
**Author:** ![steffens](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/steffens/32/79630_2.png) [@steffens](https://discuss.elastic.co/u/steffens)\ **Post date:** [August 19, 2016, 2:46pm UTC](https://discuss.elastic.co/t/output-beat-events-as-plain-http-post/57923/7 "2016-08-19T14:46:28Z")
Great it works. We hope this will keep maintenance somewhat managable (maintaining forks is always painful) until golang one day provides proper plugin support. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [September 2, 2016, 12:50pm UTC](https://discuss.elastic.co/t/output-beat-events-as-plain-http-post/57923/8 "2016-09-02T12:50:48Z")
This topic was automatically closed after 21 days. New replies are no longer allowed.