Hi Alessandro, Taylor, Any more updates on this one? This seems like a very good feature to have.
Thanks TI On Tue, Dec 6, 2016 at 10:37 AM, Alessandro Bellina < abell...@yahoo-inc.com.invalid> wrote: > Hi S G, > Not something I am working on now. What I pushed was just reporter config > for Taylor since he needed it. I do think that if default reporting works > we could just go to the rocksdb store and ask it for the metrics there? > There are other parts of this I haven't published yet but looking to do so > either this or next week. > Thanks, > Alessandro > > > > On Tuesday, December 6, 2016, 11:10:57 AM CST, S G < > sg.online.em...@gmail.com> wrote:Hey Alessandro, > > Thanks for sharing. > Please share if we have plans to use the metrics-servlets from dropwizard? > (http://metrics.dropwizard.io/3.1.0/manual/servlets/#adminservlet) > > I think it will be very convenient to have the metrics reported through a > REST API from every process (worker, supervisor, nimbus etc.) and in line > with most other software like Solr, ES etc. This can be achieved very > easily if we use the above metric servlets and they also provide ping, > health-check, thread dump etc which are useful too. > > Please ignore if its already there in the code shared above and I could not > find it. > > Thanks, > SG > > > > On Mon, Dec 5, 2016 at 9:49 PM, Alessandro Bellina <abell...@yahoo-inc.com > > > wrote: > > > Hi Taylor > > > > Please see latest commit in: https://github.com/abellina/ > > storm/tree/reporters > > > > Specifically inside: storm-core/src/jvm/org/apache/storm/metrics2 > > > > I have a default config that sets up a couple of reporters in > > default.yaml. The format is inline with what we discussed, but updated > with > > what I suggested over the weekend. > > > > This is definitely a work in progress, but you should be able to > > instantiate reporters for your purposes. > > > > Thanks, > > > > Alessandro > > > > > > > > On Monday, December 5, 2016, 1:26:41 PM CST, Alessandro Bellina < > > abell...@yahoo-inc.com.INVALID> wrote: > > Yes. Will PR this tonight Taylor. Thanks! > > On Monday, December 5, 2016, 12:37:18 PM CST, P. Taylor Goetz < > > ptgo...@gmail.com> wrote:Alessandro, > > > > Are you in a position to open a pull request against the metrics_v2 > > branch? I’d like to start integrating the work I’ve been doing with the > > reporter configuration stuff you have. If what you have is > incomplete/WIP, > > that’s not a big deal as the metrics_v2 branch is a feature branch and > > we’ll have plenty of opportunities to clean things up. > > > > -Taylor > > > > > On Nov 29, 2016, at 3:27 PM, Alessandro Bellina < > abell...@yahoo-inc.com> > > wrote: > > > > > > Taylor, > > > > > > Ok maybe there is some effort duplication. For the config, I have the > > bare minimum to get the default reporter up. I'll focus on that since you > > could use it. Will update JIRA with more. > > > > > > Alessandro > > > > > > > > > ----- Forwarded Message ----- > > > From: P. Taylor Goetz <ptgo...@gmail.com> > > > To: "dev@storm.apache.org" <dev@storm.apache.org> > > > Cc: S G <sg.online.em...@gmail.com>; na...@narendasan.com < > > na...@narendasan.com>; Austin Chung <achun...@illinois.edu> > > > Sent: Tuesday, November 29, 2016, 1:27:58 PM CST > > > Subject: Re: Are storm metrics reported through JMX too? > > > > > > Alessandro, > > > > > > Where do you stand with the reporter configuration via the storm.yaml > > config file? > > > > > > I have metrics collection for workers and disruptor queues almost > ready, > > but now I’m looking for flexible configuration (right now I have > reporters > > hard coded). > > > > > > -Taylor > > > > > > > On Nov 29, 2016, at 1:57 PM, Alessandro Bellina < > > abell...@yahoo-inc.com.INVALID <mailto:abell...@yahoo-inc.com.INVALID>> > > wrote: > > > > > > > > S G, > > > > I am slowly making progress and plan to share something this week, > > specifically for hooking up a default codahale reporter to the workers. > > Also the U of I students for the open source class have made progress on > > their rocksdb implementation for the default store (the stuff I am doing > > should feed into their store). I don't think any of this is going to be > in > > 1.1.0 given that it hasn't really been looked at by others, let alone > > reviewed. > > > > Thanks > > > > Alessandro > > > > On Monday, November 28, 2016, 4:51:34 PM CST, S G < > > sg.online.em...@gmail.com <mailto:sg.online.em...@gmail.com>> wrote:Hi, > > > > > > > > I see https://issues.apache.org/jira/browse/STORM-2153 < > > https://issues.apache.org/jira/browse/STORM-2153>being open for this > > > > and a lot of good discussion happening too. > > > > There is also a talk for releasing 1.1.0 version soon. > > > > > > > > So I just wanted to check if any metric related improvements will be > > > > available in 1.1.0. > > > > It would be great to try out these new improvements. > > > > > > > > Thanks > > > > SG > > > > > > > > On Tue, Oct 18, 2016 at 8:57 PM, Abhishek Nigam <adn5...@gmail.com > > <mailto:adn5...@gmail.com>> wrote: > > > > > > > >> Hi all, > > > >> > > > >> I'm Abhishek Nigam, one of the students from the group at the > > University of > > > >> Illinois; I'm really looking forward to working on this issue! We'll > > be > > > >> sure to keep you all updated as to how we progress. > > > >> > > > >> Cheers, > > > >> -- > > > >> Abhishek > > > >> > > > >> On Tue, Oct 18, 2016 at 1:23 PM Alessandro Bellina < > > abell...@yahoo-inc.com <mailto:abell...@yahoo-inc.com> > > > >>> > > > >> wrote: > > > >> > > > >>> + Naren, Austin, and Abhishek, the students from the University of > > > >>> Illinois Open Source class. > > > >>> > > > >>> > > > >>> On Tuesday, October 11, 2016 11:48 PM, S G < > > sg.online.em...@gmail.com <mailto:sg.online.em...@gmail.com>> > > > >>> wrote: > > > >>> > > > >>> > > > >>> Response on this important issue is pretty good. I am happily > > surprised > > > >> :) > > > >>> > > > >>> I want to mention our strategy for extracting metrics from other > > > >> products. > > > >>> We use jolokia_proxy (https://jolokia.org/features/proxy.html < > > https://jolokia.org/features/proxy.html>) to get > > > >> JMX > > > >>> beans from several softwares and feed them to telegraf. That way, > we > > > >> avoid > > > >>> writing custom processors for all these different products. > > > >>> > > > >>> Telegraf is quickly becoming a standard for metrics data. (Just see > > the > > > >>> list of input plugins here: > > > >>> https://github.com/influxdata/telegraf/tree/master/plugins/inputs > < > > https://github.com/influxdata/telegraf/tree/master/plugins/inputs>). And > > > >> it > > > >>> integrates well with several outputs too ( > > > >>> https://github.com/influxdata/telegraf/tree/master/plugins/outputs > < > > https://github.com/influxdata/telegraf/tree/master/plugins/outputs>). > > > >>> > > > >>> Also since the metrics in JMX, they can be queried by jolokia-agent > > > >>> installed per node. This avoids the extra metrics-consumer bolt > > which can > > > >>> hit the topology throughtput too. > > > >>> > > > >>> So I cast my vote in favor of JMX-implementation of metrics. > > > >>> Other approaches are welcome to be discussed. > > > >>> > > > >>> On Tue, Oct 11, 2016 at 7:30 PM, Alessandro Bellina < > > > >>> abell...@yahoo-inc.com.invalid <mailto:abellina@yahoo-inc. > > com.invalid>> wrote: > > > >>> > > > >>>> blockquote, div.yahoo_quoted { margin-left: 0 !important; > > > >>> border-left:1px > > > >>>> #715FFA solid !important; padding-left:1ex !important; > > > >>>> background-color:white !important; } Yeap that's a requirement > from > > our > > > >>>> perspective (working through this list). > > > >>>> Sure I think as usual we can start with master with an eye for > what > > > >> would > > > >>>> need to be back ported. > > > >>>> Sent from Yahoo Mail for iPhone > > > >>>> > > > >>>> > > > >>>> On Tuesday, October 11, 2016, 8:50 PM, P. Taylor Goetz < > > > >>> ptgo...@gmail.com <mailto:ptgo...@gmail.com>> > > > >>>> wrote: > > > >>>> > > > >>>> I hope I didn't come across as overly critical. You did the best > > with > > > >>> what > > > >>>> you had to work with. Which isn't pretty. > > > >>>> > > > >>>> We could potentially do a parallel metrics API in 1.1, 1.2, or > > master > > > >> and > > > >>>> still stay close to semantic versioning...? > > > >>>> > > > >>>> -Taylor > > > >>>> > > > >>>>> On Oct 11, 2016, at 9:28 PM, Jungtaek Lim <kabh...@gmail.com > > <mailto:kabh...@gmail.com>> wrote: > > > >>>>> > > > >>>>> Yeah I admit that configuration flag was bad for me also, but I > > have > > > >> no > > > >>>>> alternatives. Only way to avoid struggling with design limitation > > is > > > >>>> revamp > > > >>>>> / redesign. > > > >>>>> Thanks S G for exposing willingness of volunteer and great news > > > >>>> Alessandro > > > >>>>> for that project. > > > >>>>> Alessandro, could you forward the upcoming news for the project > to > > > >> dev@ > > > >>>>> list? > > > >>>>> > > > >>>>> - Jungtaek Lim (HeartSaVioR) > > > >>>>> > > > >>>>> 2016년 10월 12일 (수) 오전 10:22, P. Taylor Goetz <ptgo...@gmail.com > > <mailto:ptgo...@gmail.com>>님이 > > > >> 작성: > > > >>>>> > > > >>>>>> I was thinking on a smaller scale in terms of effort, but the > > more I > > > >>>> think > > > >>>>>> about it, the more supportive I would be of a full revamp (new > > API) > > > >>> for > > > >>>>>> metrics based on Coda Hale's metrics library. It's proven and > > > >> stable. > > > >>>> I've > > > >>>>>> used it many times. I think either approach would be roughly the > > > >> same > > > >>>>>> amount of work. > > > >>>>>> > > > >>>>>> Some of the metrics API improvements in the 1.1.x branch are > nice, > > > >> but > > > >>>>>> IMHO are lipstick on a pig. > > > >>>>>> > > > >>>>>> With apologies to Jungtaek, who has done amazing work all across > > the > > > >>>>>> codebase, I'm a little squeamish about the proposed change to > > > >> metrics > > > >>>> that > > > >>>>>> changes the consumer API based on a configuration flag (don't > know > > > >> the > > > >>>> PR > > > >>>>>> number offhand). > > > >>>>>> > > > >>>>>> I'm +1 for moving in this direction (revamped metrics). Let's > end > > > >> the > > > >>>>>> metrics pain. > > > >>>>>> > > > >>>>>> -Taylor > > > >>>>>> > > > >>>>>>> On Oct 11, 2016, at 10:15 AM, Bobby Evans < > > > >>> ev...@yahoo-inc.com.INVALID <mailto:ev...@yahoo-inc.com.INVALID> > > > >>>>> > > > >>>>>> wrote: > > > >>>>>>> > > > >>>>>>> I agree that IMetricsConsumer is not good, but the reality is > > that > > > >>> all > > > >>>>>> of the metrics system needs to be redone. The problem is that > we > > > >> ship > > > >>>> an > > > >>>>>> object as a metric. If I get an object I have no idea what it > is > > > >> hand > > > >>>>>> hence no idea how to report it or what to do with it. What is > > more > > > >>> the > > > >>>>>> common types we use in the metrics we provide are really not > > enough. > > > >>>> For > > > >>>>>> example CountMetric sends a Long. Well when I get it in the > > metrics > > > >>>>>> consumer I have no idea if I should report it like a counter or > > if I > > > >>>> should > > > >>>>>> report it like a gauge (something that every metrics system I > have > > > >>> used > > > >>>>>> wants to know). But then we support pre-aggregation of the > > metrics > > > >>> with > > > >>>>>> IReducer so the number I get might be an average instead of > > either a > > > >>>> gauge > > > >>>>>> or a counter, which no good metrics system will want to collect > > > >>> because > > > >>>> I > > > >>>>>> cannot aggregate it with anything else, the math just does not > > work. > > > >>>>>>> The proposal I have said before and I still believe is that we > > need > > > >>> to > > > >>>>>> put in place a parallel metrics API/system. We will deprecate > all > > > >> of > > > >>>>>> https://git.corp.yahoo.com/storm/storm/tree/master- < > > https://git.corp.yahoo.com/storm/storm/tree/master-> > > > >>>> security/storm-core/src/jvm/backtype/storm/metric/api > > > >>>>>> and create a new parallel one that provides an API similar to > > > >>>>>> http://metrics.dropwizard.io/3.1.0/. > > > >>> <http://metrics.dropwizard.io/3.1.0/ < > http://metrics.dropwizard.io/ > > 3.1.0/>> I would even be fine in just > > > >>>> using > > > >>>>>> their API and exposing that to end users. Dropwizard has solved > > all > > > >>> of > > > >>>>>> these problems already and I don't see a reason to reinvent the > > > >> wheel. > > > >>>> I > > > >>>>>> don't personally see a lot of value in trying to send all of the > > > >>> metrics > > > >>>>>> through storm itslef. I am fine if we are able to support that, > > but > > > >>> it > > > >>>> is > > > >>>>>> far from a requirement. - Bobby > > > >>>>>>> > > > >>>>>>> On Monday, October 10, 2016 10:47 PM, S G < > > > >>> sg.online.em...@gmail.com <mailto:sg.online.em...@gmail.com>> > > > >>>>>> wrote: > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> +1 > > > >>>>>>> We can probably start by opening a JIRA for this and adding a > > > >> design > > > >>>>>>> approach for the same? > > > >>>>>>> I would like to help in the coding-effort for this. > > > >>>>>>> > > > >>>>>>> -SG > > > >>>>>>> > > > >>>>>>>> On Mon, Oct 10, 2016 at 1:51 PM, P. Taylor Goetz < > > > >> ptgo...@gmail.com <mailto:ptgo...@gmail.com> > > > >>>> > > > >>>>>> wrote: > > > >>>>>>>> > > > >>>>>>>> I’ve been thinking about metrics lately, specifically the fact > > > >> that > > > >>>>>> people > > > >>>>>>>> tend to struggle with implementing a metrics consumer. (Like > > this > > > >>> one > > > >>>>>> [1]). > > > >>>>>>>> > > > >>>>>>>> The IMetricsConsumer interface is pretty low level, and common > > > >>>>>>>> aggregations, calculations, etc. are left up to each > individual > > > >>>>>>>> implementation. That seems like an area where further > > abstraction > > > >>>> would > > > >>>>>>>> make it easier to support different back ends (Graphite, JMX, > > > >>> Splunk, > > > >>>>>> etc.). > > > >>>>>>>> > > > >>>>>>>> My thought is to create an abstract IMetricsConsumer > > > >> implementation > > > >>>> that > > > >>>>>>>> does common aggregations and calculations, and then delegates > > to a > > > >>>>>> plugable > > > >>>>>>>> “metrics sink” implementation (e.g. “IMetricsSink”, etc.). > That > > > >>> would > > > >>>>>>>> greatly simplify the effort required to integrate with various > > > >>>> external > > > >>>>>>>> metrics systems. I know of at least a few users that would be > > > >>>>>> interested, > > > >>>>>>>> one is currently scraping the logs from LoggingMetricsConsumer > > and > > > >>>>>> polling > > > >>>>>>>> the Storm REST API for their metrics. > > > >>>>>>>> > > > >>>>>>>> -Taylor > > > >>>>>>>> > > > >>>>>>>> [1] http://twocentsonsoftware.blogspot.co.il/2014/12/ < > > http://twocentsonsoftware.blogspot.co.il/2014/12/> > > > >>>>>>>> sending-out-storm-metrics.html > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>>> On Oct 10, 2016, at 12:14 PM, Bobby Evans > > > >>>> <ev...@yahoo-inc.com.INVALID <mailto:ev...@yahoo-inc.com.INVALID> > > > >>>>>>> > > > >>>>>>>> wrote: > > > >>>>>>>>> > > > >>>>>>>>> First of all the server exposes essentially the same > interface > > > >> that > > > >>>> the > > > >>>>>>>> IMetricsConsumer exposes. It mostly just adds a bunch of > > overhead > > > >>> in > > > >>>>>> the > > > >>>>>>>> middle to serialize out the objects send them over http to > > another > > > >>>>>> process > > > >>>>>>>> which then has to deserialize them and process them. If you > > > >> really > > > >>>>>> don't > > > >>>>>>>> need the metrics to show up on a special known box you can > have > > > >> that > > > >>>>>> exact > > > >>>>>>>> same code running inside the metrics consumer without all of > the > > > >>>>>> overhead. > > > >>>>>>>>> The server/client are insecure, have to deal with thread > issues > > > >>> that > > > >>>> a > > > >>>>>>>> normal IMetricsConsumer does not, and are not written to be > > robust > > > >>> (If > > > >>>>>> the > > > >>>>>>>> HTTP server is down the consumer crashes and continues to > crash > > > >>> until > > > >>>>>> the > > > >>>>>>>> server is brought back up). It was written very quickly for a > > > >> test > > > >>>>>>>> situation and it honestly never crossed my mind that anyone > > would > > > >>> want > > > >>>>>> to > > > >>>>>>>> use it in production. > > > >>>>>>>>> > > > >>>>>>>>> - Bobby > > > >>>>>>>>> > > > >>>>>>>>> On Monday, October 10, 2016 10:59 AM, S G < > > > >>>>>> sg.online.em...@gmail.com <mailto:sg.online.em...@gmail.com>> > > > >>>>>>>> wrote: > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> Thanks Bobby. > > > >>>>>>>>> > > > >>>>>>>>> If we write our own metrics consumer, how do we ensure that > it > > is > > > >>>>>> better > > > >>>>>>>>> than HttpForwardingMetricsServer? In other words, what > aspects > > of > > > >>> the > > > >>>>>>>>> HttpForwardingMetricsServer > > > >>>>>>>>> should we avoid to make our own metrics consumer better and > > ready > > > >>> for > > > >>>>>>>>> production? > > > >>>>>>>>> > > > >>>>>>>>> Is versign/storm-graphite <https://github.com/verisign/ < > > https://github.com/verisign/> > > > >>>> storm-graphite> > > > >>>>>>>>> production > > > >>>>>>>>> ready? > > > >>>>>>>>> > > > >>>>>>>>> Also, we should add a line about production-readiness of > > > >>>>>>>>> HttpForwardingMetricsServer > > > >>>>>>>>> in the documentation at http://storm.apache.org/ < > > http://storm.apache.org/> > > > >>>>>>>> releases/1.0.2/Metrics.html > > > >>>>>>>>> (We were just about to think seriously on using this for > > > >> production > > > >>>> as > > > >>>>>> we > > > >>>>>>>>> thought this to be the standard solution for metrics' > > consumption > > > >>> in > > > >>>>>> 1.0+ > > > >>>>>>>>> version). > > > >>>>>>>>> > > > >>>>>>>>> -SG > > > >>>>>>>>> > > > >>>>>>>>> On Mon, Oct 10, 2016 at 6:37 AM, Bobby Evans < > > > >> ev...@yahoo-inc.com <mailto:ev...@yahoo-inc.com>> > > > >>>>>>>> wrote: > > > >>>>>>>>> > > > >>>>>>>>>> First of all there really are two different sets of metrics. > > > >> One > > > >>>> set > > > >>>>>> is > > > >>>>>>>>>> the topology metrics and the other set is the daemon metrics > > > >>>> (metrics > > > >>>>>>>> for > > > >>>>>>>>>> things like the ui and nimbus). The JmxPreparableReporter > > > >> plugin > > > >>>> only > > > >>>>>>>>>> exposes daemon metrics not the topology metrics through JMX. > > > >>>> Exposing > > > >>>>>>>>>> topology metrics through JMX is a non trivial task. The > > current > > > >>>>>> metrics > > > >>>>>>>>>> feature was not designed for this. We are in the process of > > > >>> trying > > > >>>> to > > > >>>>>>>>>> redesign the metrics system to allow for features like this, > > but > > > >>> it > > > >>>> is > > > >>>>>>>>>> still a ways off. > > > >>>>>>>>>> > > > >>>>>>>>>> - Bobby > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> On Saturday, October 8, 2016 11:39 AM, S G < > > > >>>> sg.online.em...@gmail.com <mailto:sg.online.em...@gmail.com> > > > >>>>>>> > > > >>>>>>>>>> wrote: > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> Thanks Bobby, > > > >>>>>>>>>> > > > >>>>>>>>>> We will need some kind of IMetricsConsumer to talk to > > telegraf. > > > >>>>>>>>>> Many other softwares like Solr, Elastic-Search, Cassandra > etc. > > > >>>> provide > > > >>>>>>>>>> metrics through a URL making it very easy to consume by > tools > > > >> like > > > >>>>>>>> telegraf. > > > >>>>>>>>>> How about a IMetricsConsumer that will run on storm-ui and > > > >> provide > > > >>>> the > > > >>>>>>>>>> metrics through a URL such as <storm-ui-host>/metrics ? > > > >>>>>>>>>> > > > >>>>>>>>>> Also, I see the following option in defaults.yaml: > > > >>>>>>>>>> #default storm daemon metrics reporter plugins > > > >>>>>>>>>> storm.daemon.metrics.reporter.plugins: > > > >>>>>>>>>> - "org.apache.storm.daemon.metrics.reporters. > > > >>>>>>>> JmxPreparableReporter" > > > >>>>>>>>>> > > > >>>>>>>>>> Is this a good option to use for converting metrics into > JMX ? > > > >>>>>>>>>> > > > >>>>>>>>>> Thanks > > > >>>>>>>>>> SG > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> On Fri, Oct 7, 2016 at 8:11 AM, Bobby Evans > > > >>>>>> <ev...@yahoo-inc.com.invalid <mailto:ev...@yahoo-inc.com. > invalid> > > > >>>>>>>>> > > > >>>>>>>>>> wrote: > > > >>>>>>>>>> > > > >>>>>>>>>> HttpForwardingMetricsServer is a real hack intended really > for > > > >>>>>> tests. I > > > >>>>>>>>>> know I wrote it :). Please don't use it in production. You > > can > > > >>>> write > > > >>>>>>>> your > > > >>>>>>>>>> own IMetricesConsumer to do whatever you want to with the > > > >> metrics. > > > >>>>>>>>>> https://github.com/apache/ <https://github.com/apache/> > > storm/blob/master/storm-core/ > > > >>>>>>>>>> src/jvm/org/apache/storm/ metric/api/IMetricsConsumer. java > > > >>>>>>>>>> <https://github.com/apache/storm/blob/master/storm-core/ < > > https://github.com/apache/storm/blob/master/storm-core/> > > > >>>>>>>> src/jvm/org/apache/storm/metric/api/IMetricsConsumer.java> > > > >>>>>>>>>> > > > >>>>>>>>>> That is the correct way to get the data out. If you want to > > > >>> write a > > > >>>>>>>>>> bridge to JMX for this that might work, but going directly > to > > > >>>>>> telegraph > > > >>>>>>>>>> would probably be better. - Bobby > > > >>>>>>>>>> > > > >>>>>>>>>> On Thursday, October 6, 2016 1:43 PM, S G < > > > >>>>>>>> sg.online.em...@gmail.com <mailto:sg.online.em...@gmail.com>> > > > >>>>>>>>>> wrote: > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> Hi, > > > >>>>>>>>>> > > > >>>>>>>>>> We want to use Telegraf ( > > > >>>>>>>>>> https://github.com/influxdata/ <https://github.com/ > > influxdata/>telegraf/tree/master/plugins > > > >>>>>>>>>> <https://github.com/influxdata/telegraf/tree/master/plugins > < > > https://github.com/influxdata/telegraf/tree/master/plugins>>) > > > >> for > > > >>>>>>>> getting > > > >>>>>>>>>> storm's metrics. > > > >>>>>>>>>> > > > >>>>>>>>>> But we do not want to add a HttpForwardingMetricsServer just > > to > > > >>> get > > > >>>>>> the > > > >>>>>>>>>> metrics and send them to telegraf. > > > >>>>>>>>>> > > > >>>>>>>>>> Other option is to use Jolokia (https://jolokia.org/ < > > https://jolokia.org/>) that can > > > >>> read > > > >>>>>> JMX > > > >>>>>>>>>> and > > > >>>>>>>>>> write into telegraf. > > > >>>>>>>>>> > > > >>>>>>>>>> Does storm report all its metrics (including those of custom > > > >>>>>>>> spouts/bolts) > > > >>>>>>>>>> into JMX? > > > >>>>>>>>>> Or spawning a HttpForwardingMetricsServer is the only > option? > > > >>>>>>>>>> > > > >>>>>>>>>> Thanks > > > >>>>>>>>>> SG > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>> > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >>> > > >