I think on 1.x you can work around it by directly accessing the Storm
metrics registry. That's what TopologyContext would do when you use it
https://github.com/apache/storm/blob/2ade13055315b69980f228ed786c6a76efb695a7/storm-core/src/jvm/org/apache/storm/task/TopologyContext.java#L397
Den tor. 4.
unsubscribe
As far as I can tell, the JMX reporting is only hooked up to the metrics v2
API. You're using metrics v1. Could you try to register your metric with
the new metrics system? You can find documentation at
https://storm.apache.org/releases/2.0.0-SNAPSHOT/metrics_v2.html.
Den ons. 3. apr. 2019 kl.
There might be an issue with the API for StateFactory here. You need a
TopologyContext to use the new metrics API, but makeState doesn't take one.
Others can correct me if this is not an issue, but IMO feel free to
register an issue at https://issues.apache.org/jira.
Den tor. 4. apr. 2019 kl.
Hi,
I'm using log4j to log all my topology logs in apache storm. Using the
following standard format I'm generating appender files:
> fileName="${sys:workers.artifacts}/${sys:storm.id
> }/${sys:worker.port}/${sys:logfile.name}"
> filePattern="${sys:workers.artifacts}/${sys:storm.id
>
Is there any way to use TopologyContext in the Trident StateFactory?
Also, I tried directly using Dropwizard metrics JMX reporter, which worked
on the single node setup but when I deployed on the cluster then those
metrics via my own reporter were not visible.
On Thu, Apr 4, 2019 at 12:39 PM Stig
I believe this is handled by the Logviewer daemon. If you run "storm
logviewer" on your worker machines, the Logviewer daemon will periodically
delete old topology directories.
Take a look at
Hi,
We are using storm 1.2.2 on kubernetes(K8) cluster. We have 1 storm nimbus
and 3 supervisors to submit topology. We are getting logs in worker.log
file against each supervisor.
But we want logs within kubernetes console which can be accessed with
"kubectl logs -f -n namespace".
We changed the
You could probably also just tail the worker log files into the console you
are using to run the supervisor, but it'll most likely get messy to read.
Den tor. 4. apr. 2019 kl. 20.04 skrev Stig Rohde Døssing <
stigdoess...@gmail.com>:
> I don't think you can get the worker logs in the console
I don't think you can get the worker logs in the console directly. The
issue is that your container will be running both the supervisor, and a
number of workers. The workers are started by the supervisor, and aren't
attached to the console you use to start the supervisor. Even if you
configure a
10 matches
Mail list logo
