Difficulty with initial configuration

[josephruscio]

Had a report from one of our users that initial configuration is confusing:

QUOTE
I'm using metrics-librato, but don't seem to be getting a response back from you, judging by the following log entry:

[error] c.l.m.LibratoBatch - Unable to post to Librato API
java.util.concurrent.ExecutionException: java.util.concurrent.TimeoutException: No response received after 5

I have verified that my username and api key works by trying a GET from the command line using curl.

It's not clear from the documentation if there's anything else I need to do to make this work.
ENDQUOTE

[opyate]

Hello, I'm the user. I added extra log output to the libraries, and here is the log:

https://gist.github.com/3277519

BTW, I may be mistaken, but shouldn't the request's inAuth parameter be true?

Other information:

• I'm running my app locally (for testing purposes)
• not behind any proxies or firewalls
• I'm definitely capturing metrics. See the very last line: [debug] c.l.m.LibratoBatch - Posted 310 measurements

I'm not sure if these 310 measurements is too much for the trial account.
Also, I'm not sure if I need to set up anything in the Librato console that matches the data it's expecting from my app.

[mihasya]

The logs seem to indicate that auth headers arent being set. Are you instantiating the LibratoReporter using the enable method per the readme? Could you gist the code please? Blank out the token of course. I would expect a 401 rather than a timeout in that case, also..

[opyate]

Sure, updated here: https://gist.github.com/3277519#file_global.scala

[mihasya]

Not familiar with scala, unfortunately. What does flatMap return? What does the getOrElse method return? Can you log out the values of libratoUsername and libratoAPIKey and verify they are the correct values? Will scala error on a type mismatch?

[opyate]

Those are fine. I use similar code for my other properties too. Just to be sure, I swapped out the actual text values.

I also emailed Librato issues account a Wireshark dump.

[opyate]

Example app added here: https://github.com/opyate/librato-play-example

[mihasya]

Please try version 2.1.2.4-SNAPSHOT from maven and report what happens. The auth header is now set explicitly, and there's a bit of error checking for the auth values. Thanks!

[opyate]

Thanks, I now see a load of metric entries on the METRICS tab. I suppose my next step is to configure a custom dashboard with a selection of these metrics which mean most to me.

Another word of warning: this happens with every upload:

    2012-09-10 14:01:28,404 - [ERROR] - from com.librato.metrics.LibratoBatch in metrics-librato-reporter-thread-1 
    Unable to post to Librato API
    java.util.concurrent.ExecutionException: java.util.concurrent.TimeoutException: No response received after 5
        at com.ning.http.client.providers.netty.NettyResponseFuture.get(NettyResponseFuture.java:223) ~[async-http-client-1.7.0.jar:na]
        at com.librato.metrics.LibratoBatch.postPortion(LibratoBatch.java:131) [librato-java-0.0.6-SNAPSHOT.jar:na]
        at com.librato.metrics.LibratoBatch.post(LibratoBatch.java:115) [librato-java-0.0.6-SNAPSHOT.jar:na]
        at com.librato.metrics.LibratoReporter.run(LibratoReporter.java:75) [metrics-librato-2.1.2.4-SNAPSHOT.jar:na]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [na:1.6.0_33]
        at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [na:1.6.0_33]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [na:1.6.0_33]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [na:1.6.0_33]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) [na:1.6.0_33]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) [na:1.6.0_33]
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [na:1.6.0_33]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [na:1.6.0_33]
        at java.lang.Thread.run(Thread.java:680) [na:1.6.0_33]
    Caused by: java.util.concurrent.TimeoutException: No response received after 5
        at com.ning.http.client.providers.netty.NettyResponseFuture.get(NettyResponseFuture.java:215) ~[async-http-client-1.7.0.jar:na]
        ... 12 common frames omitted

The problem seem to be solved, though.

BTW, I also had to apply the librato-java-0.0.6-SNAPSHOT solution as in issue 7 before I could get this to work.

[SeanTAllen]

This plus using librato-java-0.0.6-SNAPSHOT solved the issues I was having that we discussed in the campfire chat room last Friday.

Are you planning on versioning those soon?

[mihasya]

Absolutely. Need to look into why librato-java 0.0.6-SNAPSHOT would be required, and another report of tests failing in that version. Will try to do that and cut both libraries tonight.

[SeanTAllen]

FYI, we've been running the snapshotted versions in production since this morning with no issues, so I'm feeling pretty good about them.

[mihasya]

I just released metrics-librato-2.1.2.4 which depends on the simultaneously released librato-java-0.0.6, fixing this issue, as well as a few others. Should be in maven central in a few hours.

@opyate the timeout error is likely the result of large batches taking a while to post to Librato. The timeout is configurable, see

metrics-librato/src/main/java/com/librato/metrics/LibratoReporter.java

Line 184 in f50d180

/**

It is safe to set that to a value just lower than what your posting interval is.