Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Riemann reporter doesn't appear to work #106

Open
yogsototh opened this issue Jun 21, 2016 · 4 comments
Open

Riemann reporter doesn't appear to work #106

yogsototh opened this issue Jun 21, 2016 · 4 comments

Comments

@yogsototh
Copy link

yogsototh commented Jun 21, 2016

I use 2.7.0 version, the lein install doesn't appear to do anything or takes ages when I cloned this repository.

Mainly I see this in the logs:

2016-06-21 12:06:58,449 DEBUG (metrics-riemann-reporter-thread-1) [com.codahale.metrics.riemann.RiemannReporter] - Reporting metrics: for 1466503618 at 1466503618449

only once, and I can't see the data in Riemann.

Riemann appear to works as I tried to add metrics manually. I don't have any hint on how to make it works.

I use call this function at start time:

(defn init! []
 (let [host "127.0.0.1"
          port 5555
          riemann-client (riemann/make-riemann host port)
          riemann-reporter (riemann/reporter riemann-client
                                             {:rate-unit TimeUnit/SECONDS
                                              :duration-unit TimeUnit/MILLISECONDS
                                              :filter MetricFilter/ALL})]
      (log/debug (str "connecting to Riemann: " host ":" port))
      (riemann/start riemann-reporter 1)))
@michaelklishin
Copy link
Collaborator

Please inspect the JVM with VisualVM or similar. Only a thread dump can tell if the reporter is still running or had to abort e.g. due to an unhandled exception

@yogsototh
Copy link
Author

Using VisualVM the metrics-riemann-reporter-thread-1 seems to be always parked.

Here is the riemann specific thread dump

"metrics-riemann-reporter-thread-1" #31 daemon prio=5 os_prio=31 tid=0x00007fad6b2b6800 nid=0x7203 waiting on condition [0x000070000227c000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x0000000772337e90> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - None

I've provided the complete thread dump here but I'm not sure it will be useful:

https://www.wetransfer.com/downloads/2dc8849a6d70945154ffb3ef0e6bba1320160621112540/626feecd2fcf77e042b8a6da141b9b4220160621112540/f20e2e

@michaelklishin
Copy link
Collaborator

Parked by ScheduledThreadPoolExecutor specifically. This makes me believe something operates on a schedule that you don't expect, e.g. reporting interval is widely off.

@timgilbert
Copy link

timgilbert commented Jan 4, 2018

Any update on this? I'm seeing the same behavior, can't get metrics to send anything to reimann at all.

EDIT: looks like I had a PEBKAC problem - I hadn't passed the correct registry value into (metrics.reporters.riemann/reporter). I corrected this and everything seems to be working fine; I've got metrics flowing into riemann correctly now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants