Re: [heka] New Heka release?

[Waqar Khan]

Hi Eric,

Heka is now deprecated, I do not think they will make any future releases.
See the mail archive for more details.

Regards

On 2 September 2016 at 15:57, Eric LEMOINE  wrote:

> Hi
>
> Heka 0.10.0 was released in December 2015. Since then a number of
> features and fixes have been added to the "dev" branch. For that
> reason we currently use the "dev" branch, which we build ourselves.
> Would releasing 0.11 make sense? I think that would make a lot people
> happy :)
>
> Thanks!
> ___
> Heka mailing list
> Heka@mozilla.org
> https://mail.mozilla.org/listinfo/heka
>
___
Heka mailing list
Heka@mozilla.org
https://mail.mozilla.org/listinfo/heka

Re: [heka] State and future of Heka

[Waqar Khan]

I think it would be a good if you could add a message or something at the
front page of the github repo to state that this project will soon be
discontinued. Because if I were someone looking for a new tool to use, I
would most definitely be impressed and go ahead and start using it - only
to find that its going to be discontinued!

Regards

On 3 June 2016 at 19:03, Rob Miller  wrote:

> As I mentioned in the first message, Hindsight carries forward a lot of
> the ideas that made Heka so useful, and pretty much any Lua code that was
> written for Heka will work in Hindsight with little or no change.
>
> Another idea that I might explore is generating a stripped down subset of
> Heka that only includes inputs, along with a Hindsight input that works
> with this stripped down subset. It's not ideal in that it would be two
> processes instead of one, but it could provide a bridge so that any input
> code that hasn't yet been ported to Hindsight could still be used to feed
> into a Hindsight centered pipeline.
>
> -r
>
>
> On 06/03/2016 04:19 AM, Mac Stork wrote:
>
>> Hi all,
>>
>> Ali, I share your opinion concerning Heka's strengths. I also think that
>> Heka stands out because of the flexibility of its filters. There are few
>> to none lightweight data collectors/shippers that allow to process
>> events with that many decoders/filters/encoders, with the possibility of
>> chaining them. The numerous filtering possibilities was what made us use
>> Heka.
>>
>> Concerning the alternative to Heka, i.e elastic's Beats: there is
>> obviously a lack of outputs. However things might take a turn and you
>> should look (might even participate) at this recent ticket about having
>> community-maintained outputs:
>> https://github.com/elastic/beats/pull/1681
>>
>> Vincent
>>
>> On 2 June 2016 at 22:22, Ali > > wrote:
>>
>> Thanks, Rob!
>>
>> I have to say, I'm EXTREMELY DISAPPOINTED to hear this.
>>
>> I have been away from Heka for a while (working on other projects at
>> work) and am now able to refocus on designing our new data
>> collection/analysis/reporting system.  Once I read this e-mail, I
>> started looking around to see what else was out there and what has
>> changed over the last several months.  Elastic's Beats
>>  project, particularly
>> Filebeat
>> <
>> https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-overview.html
>> >,
>> seemed like a really interesting and welcome development.  However,
>> compared to the flexibility of Heka's ins and outs, Filebeats seems
>> to be wanting badly.
>>
>> Suffice it to say, Heka still seems to stand alone in this space.
>> Its flexibility is amazing.  (Again, mostly talking about inputs and
>> outputs here.)  The closest I can come to it is nxlog
>> , and I just really dislike
>> that it's not more transparent and open-source.
>>
>> Anyway, I understand the rationale behind this decision and am
>> hopeful that another org will continue work on this project.  Thanks
>> for all of your efforts, Rob et al!
>>
>> -Ali
>>
>> P.S.  If anyone's interested, here's my situation right now:
>>
>> https://www.reddit.com/r/bigdata/comments/4m81vo/which_log_collectors_to_use_for_robust_handling/
>> and
>>
>> https://discuss.elastic.co/t/how-can-i-get-data-from-filebeat-to-flume/51734
>>
>>
>> On Fri, May 6, 2016 at 12:51 PM Rob Miller > > wrote:
>>
>> Hi everyone,
>>
>> I'm lng overdue in sending out an update about the current
>> state of
>> and plans for Heka. Unfortunately, what I have to share here will
>> probably be disappointing for many of you, and it might impact
>> whether
>> or not you want to continue using it, as all signs point to Heka
>> getting
>> less support and fewer updates moving forward.
>>
>> The short version is that Heka has some design flaws that make
>> it hard
>> to incrementally improve it enough to meet the high throughput and
>> reliability goals that we were hoping to achieve. While it would
>> be
>> possible to do a major overhaul of the code to resolve most of
>> these
>> issues, I don't have the personal bandwidth to do that work,
>> since most
>> of my time is consumed working on Mozilla's immediate data
>> processing
>> needs rather than general purpose tools these days. Hindsight
>> (https://github.com/trink/hindsight), built around the same Lua
>> sandbox
>> technology as Heka, doesn't have these issues, and internally
>> we're
>> using it more and more instead of Heka, so there's no
>> organizational
>> imperative for me (or anyone else) to