netflix / servo

Netflix Application Monitoring Library

DEPRECATED

This project receives minimal maintenance to keep software that relies on it working. There is no active development or planned feature improvement. For any new projects it is recommended to use the Spectator library instead.

For more details see the Servo comparison page in the Spectator docs.

No-Op Registry

As of version 0.13.0, the default monitor registry is a no-op implementation to minimize the overhead for legacy apps that still happen to have some usage of Servo. If the previous behavior is needed, then set the following system property:

com.netflix.servo.DefaultMonitorRegistry.registryClass=com.netflix.servo.jmx.JmxMonitorRegistry

Servo: Application Metrics in Java

servo v. : WATCH OVER, OBSERVE

Latin.

Servo provides a simple interface for exposing and publishing application metrics in Java. The primary goals are:

• Leverage JMX: JMX is the standard monitoring interface for Java and can be queried by many existing tools.
• Keep It Simple: It should be trivial to expose metrics and publish metrics without having to write lots of code such as MBean interfaces.
• Flexible Publishing: Once metrics are exposed, it should be easy to regularly poll the metrics and make them available for internal reporting systems, logs, and services like Amazon CloudWatch.

This has already been implemented inside of Netflix and most of our applications currently use it.

Project Details

Build Status

Versioning

Servo is released with a 0.X.Y version because it has not yet reached full API stability.

Given a version number MAJOR.MINOR.PATCH, increment the:

• MINOR version when there are binary incompatible changes, and
• PATCH version when new functionality or bug fixes are backwards compatible.

Documentation

• GitHub Wiki
• Javadoc

Communication

• Google Group: Netflix Atlas
• For bugs, feedback, questions and discussion please use GitHub Issues.
• If you want to help contribute to the project, see CONTRIBUTING.md for details.

Project Usage

Build

To build the Servo project:

$ git clone https://github.com/Netflix/servo.git
$ cd servo
$ ./gradlew build

More details can be found on the Getting Started page of the wiki.

Binaries

Binaries and dependency information can be found at Maven Central.

Maven Example:

<dependency>
    <groupId>com.netflix.servo</groupId>
    <artifactId>servo-core</artifactId>
    <version>0.12.7</version>
</dependency>

Ivy Example:

<dependency org="com.netflix.servo" name="servo-core" rev="0.12.7" />

License

Copyright 2012-2016 Netflix, Inc.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at:

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

servo's Issues

timers should protect against negative values that are recorded

BasicTimer (and probably others like StatsTimer) do not current prevent negative values from getting recorded. This can happen if say the clock source is not monotonic and there is an ntp adjustment. This will cause an incorrect total time to show up.

Negative values should be ignored, maybe logged so the user will know, though I worry about having logging in the record call if it is used as part of a really tight loop.

Ensure that TagList is sorted

List should be sorted by a tag's key and then value.

Graphite metric names are ignoring the type and instance tags

i noticed this while trying to tune some Hystrix commands. the historical Hystrix metrics sent to Graphite appeared to be aggregated across all commands.

while debugging, i noticed that the type and instance tags were being ignored in the BasicGraphiteNamingConvention class.

i've fixed and verified the patch using FluxCapacitor as a live, running example as well as through a new unit test added to BasicGraphiteNamingConventionTest.

about to submit the patch assuming the Git Gods are with me tonight.

Unable to use JmxMonitorRegistry for registering metrics

To Use JmxMonitorRegistry/ DefaultMonitorRegistry, I have to pass them a Monitor<?> types argument. But I just have a POJO class in which some properties have been annotated with @monitor annotation. Now I want to publish these properties to JMX server for monitoring purpose. But, when I follow your example,

Server s1 = new Server("s1");
DefaultMonitorRegistry.getInstance().registerObject(s1);

This is not working for me as DefaultMonitorRegistry's registerObject method requires a Monitor<?> object and not a simple Java Object.

Can you please explain how can I use DefaultMonitorRegistry/JmxMonitorRegistry to register properties of my simple java class ?

Thanks,
Ajay Arora

create proxy monitor for easily tracking all calls to an interface

I was adding some metrics so I can track all of our usage for AWS calls and started thinking about something that would make this a lot easier, in particular:

http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Proxy.html

The proxy class allows us to create a dynamic implementation of an interface with a handler method that will get invoked. In the handler we could register a timer so we can easily track all calls to a given method and then just forward the call to a wrapped instance that actually implements the logic. For interfaces with a lot of methods, for example:

http://docs.amazonwebservices.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/ec2/AmazonEC2.html

This would be a real time saver and would also make it easier to migrate to new versions if methods were added.

NoSuchMethodError

Hi, i'm running into this error trying to use servo. Does anyone have any ideas?

java.lang.NoSuchMethodError: com.netflix.servo.Metric.getConfig()Lcom/netflix/servo/MetricConfig;

code snippet:
DefaultMonitorRegistry.getInstance().register(Monitors.newObjectMonitor(observable));

    final CloudWatchMetricObserver observer = new CloudWatchMetricObserver("BlobObserver", "BlobDomain",
            new ClasspathPropertiesFileCredentialsProvider().getCredentials());

    final PollCallable poller = new PollCallable(new MonitorRegistryMetricPoller(), BasicMetricFilter.MATCH_ALL);

    new Timer().schedule(new TimerTask() {
        @Override
        public void run() {
            try {
                observer.update(poller.call());
            } catch (Throwable e) {
                log.error(LogFactory.getJsonLogger(String.format("Exception observing metric: %s: %s", e.getClass().getName(), e.getMessage())));
            }
        }}, 0, PING_INTERVAL * 1000);

my pom file includes:

        <dependency>
            <groupId>com.netflix.servo</groupId>
            <artifactId>servo-core</artifactId>
            <version>0.4.32</version>
        </dependency>
        <dependency>
            <groupId>com.netflix.servo</groupId>
            <artifactId>servo-cloudwatch</artifactId>
            <version>0.1.0</version>
        </dependency>
        <dependency>
            <groupId>com.netflix.servo</groupId>
            <artifactId>servo-aws</artifactId>
            <version>0.4.32</version>
        </dependency>
        <dependency>
            <groupId>com.amazonaws</groupId>
            <artifactId>aws-java-sdk</artifactId>
            <version>1.3.26</version>
        </dependency>

thanks, Mitchell

No "com.netflix.servo" prefix for tag?

Hello, I know this library has invented to be used in Netflix, so it's somewhat makes sense that every JMX monitoring types have "com.netflix.servo" prefix, but maybe it's also make sense to remove those prefix for general use of this library.

Also, some folks may want to show every COUNTER, METER, TIMER types to be located under same position, others may not want those. This is just one line change during instance creation by not adding additional tag.

Remove Tags from @Monitor

AwsInjectableTag appends new line character causing Exception

The new line character for tags like INSTANCEID can result in error during cloudwatch data submission because new line is a non-ASCII character and for a value like i-32aserv (instance-id).

parameter MetricData.member.5.Dimensions.member.1.Value contains non-ASCII characters.

It should be possible that for one line response no new line character is added.

TimedInterfaceTest is flaky on cloudbees jenkins server

https://netflixoss.ci.cloudbees.com/job/servo-master/5/console

Fix Checkstyle issues

Wrap annotated objects in their concrete types

Things annotated as Gauge should create a Gauge object that gets registered.

simplify process of setting up background publishing

Based on a number of the recent issues:

#141
#130

It can be quite confusing to get the background poll and publish tasks setup and running in a way that is intuitive. I think we can find a way that would work for most users without them having to worry about all the details for how and why some of this stuff works. For example, right now are default examples don't mention anything about the poller reset which can lead to getting an accumulated value for the life of the application.

DynamicCounter should not throw RuntimeException on increment if tag is empty string

DynamicCounter.increment() does not document that it will throw IllegalArgumentException if tag string is empty. Since tag is usually calculated dynamically at runtime, it is hard to guarantee what the value will be. What happens is that when the application is deployed, it encounters an empty tag at runtime which cause the failure of the operation simply because the counter throws an unexpected RuntimeException. This might be discovered too late.

Instead, can we log an error and treat empty string as non existent tag?

instructions for integration with graphite

are there instructions/examples on how to integrate servo with graphite?

i've got graphite setup per http://graphite.wikidot.com/installation, servo-graphite setup in my pom.xml file, my code instrumented with counters and such, and now i need to glue everything together.

i looked at the CloudWatchExample and i see the use of CloudWatchMetricObserver and PollCallable in a while(true) loop. i found the equivalent GraphiteMetricObserver, but still not clear on how to use it properly.

the following is the specific code that i'm trying to integrate:

pom.xml: https://github.com/cfregly/fluxcapacitor/blob/master/flux-core/pom.xml

instrumented code including DefaultMonitorRegistry.register() code:
https://github.com/cfregly/fluxcapacitor/blob/master/flux-edge/src/main/java/com/fluxcapacitor/edge/jersey/resources/EdgeResource.java

any tips would be very helpful.

thanks!

-chris

Remove @MonitorId

Tags should be used instead to accomplish the same thing.

add task to build for easily running examples

The documentation mentions:

$ mvn exec:java -Dexec.mainClass=com.netflix.servo.examples.BasicExample

Not sure how to do the equivalent of that with gradle. The build script does have:

task(pollLoop, dependsOn: 'classes', type: JavaExec) {
    main = 'com.netflix.servo.examples.ManyMetricsExample'
    classpath = sourceSets.main.runtimeClasspath
    args = ['10', '25000']
}

But it would be nice to have a way to run an example without having to explicitly add them to the build file. Not sure how to pass in the main class and args.

CounterToRateMetricTransform fail when DynamictCounter create a ResettableCounter which type is RATE

EchoServerExample.java is wrong, because it use DynamictCounter to create ResettableCounter with type is RATE.

CounterToRateMetricTransform only compute the rate when the tyep is COUNTER

Change DefaultMonitorRegistry to an Enum Singleton

JMX Registration does not include MonitorId in the ObjectName

This causes a problem when trying to register/deregister to objects that are of the same class and type, but have different names. It also fails a unit test.

Incorrect Concurrent MinGauge/MaxGauge

I was looking through the code evaluating and I noticed a small issue with MinGauge.java

Current Code doesn't do the get()/set() atomically.

    private final AtomicLong min = new AtomicLong(Long.MAX_VALUE);
/** Update the min if the provided value is smaller than the current min. */
    public void update(long v) {
        if (v < min.get()) {
            min.set(v);
        }
    }

Another thread between the call to min.get() and min.set() could set it to a lower value and the current thread would then wipe it away.

You probably want to follow the pattern that is done inside AtomicLong to do increments... It should be something like the following, which checks to make sure that the minValue you did the comparison against is the same one you are overwriting in the set.

        long currentMinValue = -1;
        while( value < (currentMinValue = minValue.get()) ) {
            if( minValue.compareAndSet(currentMinValue, value) ) {
                break;
            }
        }

CounterToRateMetricTransform should change metric types to gauges

example codes two different places?

Hello, I'm seeing there are servo-example project as well as "example" package under servo-core project; however, those classes under servo-example looks like just servo-core's example. Any reason those are separated into different places?

ResettableCounter should return a rate per second

The current ResettableCounter implementation returns an accumulated count since the last reset. To better match the behavior of other Counter implementations and to be more usable with multiple pollers running at different frequencies it should return a rate per second since the last reset.

The slight complication here is that it implements Counter which is a Monitor and it really should return a double for the computed rate.

APIs for Timer, Statistics

counts that are available without crossing sampling interval

Some counters may show up on-demand when an error occurs. If the counter only gets reported within a single sampling interval then we cannot compute a rate and nothing will show up on the graph.

Provide atomic Increment & Decrement functionality in various Gauge implementation

Gauge implementations like LongGauge, DoubleGauge holds an atomic number internally to store the current value of the gauge & provides a set value to override the value.
For usecases that actually are maintaining a counter (eg: clients connected to a server), the user would have to manage an additional AtomicLong variable to actual maintain this count. On top of it, setting this value in the gauge can not be atomic unless additional synchronization is added.

It will be useful, if these gauge classes either provide a handle to the underlying Atomic counters (may be a protected access) or provide ways to atomically increment & decrement the counts.

AwsInjectableTag fails to log error

AwsInjectableTag is suffering from the issue reproduced by given below code.

in line

  log.warn("Unable to read value from AWS metadata URL", e);

instead of using

  private static final Logger log = LoggerFactory.getLogger(EnumLoggerTest.class);

It should be using

    private static Logger getLogger()
    {
        return LoggerFactory.getLogger(EnumLoggerTest.class);
    }

This code shows that my actual exception is being eaten due to log being null. Enum initialization is different from Class.

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class EnumLoggerTest
{
     public static void main(String[] args) {
         System.out.print(TestEnum.D);
     }
}

enum TestEnum
{

    D(myStaticMethod("something"));

    private static final Logger log = LoggerFactory.getLogger(TestEnum.class);

    private final String key;

    private TestEnum(String key)
    {
        this.key = key;
    }

    static String myStaticMethod(String path)
    {
        try
        {
            throw new Exception("my exception");
        }
        catch (Exception e)
        {
            // log is null, my exception is lost
            log.warn("Unable to read value from AWS metadata URL", e);
        }
        return path;
    }

    public String getKey()
    {
        return key;
    }
}

Tags need to be included in JMX ObjectName

CounterToRateMetricTransform fail when DynamictCounter create a ResettableCounter

EchoServerExample.java is wrong, because it use DynamictCounter to create ResettableCounter with type is RATE.

CounterToRateMetricTransform only compute the rate when the tyep is COUNTER

Need to add support for registering Monitor objects

Functionality needs to be added to the interface and the implementations need to be updated.

un-final PollScheduler?

For my unit tests, I wanted to mock PollScheduler so that I can intercept and manually run PollRunnable objects that are scheduled. Since the PollScheduler class is final I can't mock it with EasyMock without bringing in a definalizer. I know I can start a PollScheduler with a mocked ScheduledExecutorService, but multiple tests are typically run in parallel so this won't work without a lot more complexity. Is there any chance of the final keyword being removed from the PollScheduler class declaration?

document simple best practice usage of servo

It would be useful to come up with best practices for how to use servo and maybe deprecate some of the options that are mostly historical. In particular we seem to get a lot of questions around:

• Handling of interaction with registry.
• Appropriate use and granularity of monitors vs logs.
• Debugging an explosion of metrics, and possibly supporting some scheme for automated rollup on the observer to prevent overwhelming a backend.

What is the best way to shim Servo-enabled Metrics / Monitoring into Karyon

For example, suppose before HelloWorldResource is encounted at Runtime in Karyon, a filter containing (ie) https://github.com/Netflix/servo/blob/master/servo-core/src/main/java/com/netflix/servo/examples/JvmMetricExample.java is run to keep track of all bytes in/out, etc for all Resources.

Basically we want to say "HelloWorldResource is your stub, and you get metrics and monitoring for free..."

Thanks

add support for timer to track longer duration events

Current timers are useful for tracking frequent calls where the duration is generally expected to be less than the polling interval. However, that aren't that useful for tracking a longer operation that might last for many minutes or hours.

Thread leak when run in Tomcat

When shutting down a Tomcat app that uses Servo, the following is logged:

2014-01-10 14:08:28.238 ERROR <> [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoader - The web application [] appears to have started a thread named [com.google.common.base.internal.Finalizer] but has failed to stop it. This is very likely to create a memory leak.

Google recommends as a solution calling FinalizableReferenceQueue.close(), but the instance needed is buried somewhere within Servo. Is there some utility method I can call on Servo itself to do this?

dynamic timer should not use monotonic counters

Dynamic monitors should not use monotonic counters as they require two samples to report and thus lose the first sample. DynamicTimer is currently using BasicTimer which uses BasicCounter.

add support for a PeakRateCounter

Currently we have two counter types:

• BasicCounter: monotonically increasing and converted to rate via a transform on the observer.
• ResettableCounter: reports rate (or should #144) for the interval until being reset by the primary observer.

Both of these are reporting an average rate across the reporting interval. I would like a type of resettable counter that allows me to see the peak rate during the interval. The use-case for this is things like querying cloudwatch or other services that have rate limits applied based on a peak rate per second during the interval.

Question : expose mbean opveration to reset Monitor's status? ( especially for BasicCounter? )

Hello,

I've been using Servo-core for the project, and there is some need to reset some of BasicCounter when it's required, and this need to be done outside of program itself, which means through mbean operation or something.

Let's say there is external monitoring system and it pulls JMX variable and use it for system alerting, but monitoring system want to reset those BasicCounter to zero if alerts are gone or for other reasons.

Is it possible in current version of servo-core library?

Support of cloudwatch StatisticSet

Hello,

I am currently looking at servo to monitor response time of a REST service that is potentially called many times a second. I'd like to send data to Cloudwatch, obviously it needs some aggregation somewhere.

In Cloudwatch documentation (see Aggregation), they take almost the same use case and say that good practice is to use a StatisticSet.

It makes sense because it allows to both aggregate data early in the process, and still not loose valuable information such as Min, Max, Average, total number of measure points.

I believe this is an extremely common use case, therefore can I ask you guys how you handle this at Neflix? Do you create separate metrics for each of min/max/etc.?

Cheers

Pierre

Inteface Changes/Updates

// Restrict set of metrics that get polled
public interface IMetricFilter {
boolean matches(String name, Map<String,String> tags);
}

// Poll a set of metrics from some source, replaces current callback mechanism
// can have implementations for MonitoredResource, Tomcat, Apache, Jvm, ...
public interface IMetricPoller {
void poll(IMetricFilter filter, IMetricWriter writer);
}

// Output source to write metrics
// implementations for epic, cloudwatch, ...
public interface IMetricWriter {
void write(Metric metric);
void close();
}

// Register objects with monitor annotations to some storage, main implementation for jmx
public interface IMonitorRegistry {
void registerObject(Object obj);
void unRegisterObject(Object obj);
}

I'm going to create a few filter and poller implementations to make sure those interfaces will work for what I need, so I may still change them a bit. Annotations:

For the data source type I removed some of the types such as DERIVE, ABSOLUTE, and BOOLEAN. DERIVE and ABSOLUTE come from RRD and are special counter types. COUNTER automatically gets converted to DERIVE right now internally and is the right behavior most of the time. I chose to keep the COUNTER name in the ds type enum because I think it is more intuitive for the user. ABSOLUTE doesn't seem to be used by anybody right now and BOOLEAN doesn't offer any benefit over INFORMATIONAL.

public enum DataSourceType {
GAUGE,
COUNTER,
INFORMATIONAL
}

Monitor and MonitorId are pretty much the same except I added tags to the Monitor annotation. Format is array of strings with "=" as we discussed before.

@retention(RetentionPolicy.RUNTIME)
@target({ElementType.FIELD, ElementType.METHOD})
public @interface Monitor {
public String name();
public DataSourceType type() default DataSourceType.INFORMATIONAL;
public String[] tags() default {};
public String description() default "";
}

@retention(RetentionPolicy.RUNTIME)
@target({ElementType.FIELD, ElementType.METHOD})
public @interface MonitorId {
}

I added a MonitorTags annotation that should go on a method or field that returns a Map<String,String>. Like the current MonitorId it will only be queried once during registration to get the tags that should be applied to all metrics for the instance. If the same tag key is provided on the Monitor annotation it will override the value from this annotation on that attribute.

@target({ElementType.FIELD, ElementType.METHOD})
public @interface MonitorTags {
}

I also changed the JMX representation to allow for filtering based on the metadata before the annotated method is ever called. The JMX domain is "com.netflix.monitoring.MonitoredResource" and the attributes for the object name are class=;[instance=;]field=. The class is set to the canonical class name to make it easy to do filtering of resources based on a package. Instance is optional and is set to the value annotated with MonitorId if present to allow multiple instances of a class to be registered with different ids. Field is one of metadata or value. Metadata is a CompositeDataSupport object that has the metadata from the Monitor annotation and can be retrieved without invoking the annotated method. Value is a simple type and is the actual value of the field or return value of a method.

support timer type annotation

It would be convenient if we could support an annotation for timers around a method call.

@Time
int someExpensiveMethod() {
  // do something
  return 42;
}

The name for the monitor should default to the method name, but it should support a name attribute to override it. The default TimeUnit should be milliseconds, but it should support other TimeUnits.

We'll have to intercept the method call using something similar to https://code.google.com/p/google-guice/wiki/AOP

javadoc link is a 404

http://netflix.github.io/servo/javadoc/

Fresh repository build failed

I am trying to build fresh repository:

gradle build --stacktrace

FAILURE: Build failed with an exception.

• What went wrong:
  A problem occurred configuring root project 'servo'.

  Could not resolve all dependencies for configuration ':classpath'.
  Artifact 'com.google.guava:guava:11.0.2@jar' not found.

• Try:
  Run with --info or --debug option to get more log output.

• Exception is:
  org.gradle.api.ProjectConfigurationException: A problem occurred configuring root project 'servo'.
  at org.gradle.configuration.LifecycleProjectEvaluator.addConfigurationFailure(LifecycleProjectEvaluator.java:79)
  at org.gradle.configuration.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:57)
  at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:465)
  at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:76)
  at org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:31)
  at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:142)
  at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:113)
  at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:81)
  at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:64)
  at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:33)
  at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:24)
  at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:35)
  at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
  at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:50)
  at org.gradle.api.internal.Actions$RunnableActionAdapter.execute(Actions.java:171)
  at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:201)
  at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:174)
  at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:170)
  at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:139)
  at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
  at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
  at org.gradle.launcher.Main.doAction(Main.java:48)
  at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
  at org.gradle.launcher.Main.main(Main.java:39)
  at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:50)
  at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:32)
  at org.gradle.launcher.GradleMain.main(GradleMain.java:26)
  Caused by: org.gradle.api.artifacts.ResolveException: Could not resolve all dependencies for configuration ':classpath'.
  at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingArtifactDependencyResolver.wrapException(ErrorHandlingArtifactDependencyResolver.java:51)
  at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingArtifactDependencyResolver.access$000(ErrorHandlingArtifactDependencyResolver.java:29)
  at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingArtifactDependencyResolver$ErrorHandlingResolvedConfiguration.getFiles(ErrorHandlingArtifactDependencyResolver.java:84)
  at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.getFiles(DefaultConfiguration.java:463)
  at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getFiles(DefaultConfiguration.java:202)
  at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated.getFiles(Unknown Source)
  at org.gradle.api.internal.initialization.DefaultScriptHandler.updateClassPath(DefaultScriptHandler.java:36)
  at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:118)
  at org.gradle.configuration.BuildScriptProcessor.execute(BuildScriptProcessor.java:36)
  at org.gradle.configuration.BuildScriptProcessor.execute(BuildScriptProcessor.java:23)
  at org.gradle.configuration.ConfigureActionsProjectEvaluator.evaluate(ConfigureActionsProjectEvaluator.java:34)
  at org.gradle.configuration.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:55)
  ... 25 more
  Caused by: org.gradle.api.internal.artifacts.ivyservice.ivyresolve.ArtifactNotFoundException: Artifact 'com.google.guava:guava:11.0.2@jar' not found.
  at org.gradle.api.internal.artifacts.ivyservice.DefaultBuildableArtifactResolveResult.notFound(DefaultBuildableArtifactResolveResult.java:38)
  at org.gradle.api.internal.artifacts.repositories.resolver.ExternalResourceResolver.resolve(ExternalResourceResolver.java:495)
  at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.ExternalResourceResolverAdapter.resolve(ExternalResourceResolverAdapter.java:67)
  at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.LocalModuleVersionRepository.resolve(LocalModuleVersionRepository.java:30)
  at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.IvyContextualiser$1.invoke(IvyContextualiser.java:44)
  at com.sun.proxy.$Proxy23.resolve(Unknown Source)
  at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.UserResolverChain$ModuleVersionRepositoryArtifactResolverAdapter.resolve(UserResolverChain.java:159)
  at org.gradle.api.internal.artifacts.ivyservice.ivyresolve.LazyDependencyToModuleResolver$ErrorHandlingArtifactResolver.resolve(LazyDependencyToModuleResolver.java:60)
  at org.gradle.api.internal.artifacts.ivyservice.ResolvedArtifactFactory$1$1.create(ResolvedArtifactFactory.java:39)
  at org.gradle.api.internal.artifacts.ivyservice.ResolvedArtifactFactory$1$1.create(ResolvedArtifactFactory.java:36)
  at org.gradle.cache.internal.DefaultCacheAccess.useCache(DefaultCacheAccess.java:124)
  at org.gradle.cache.internal.DefaultPersistentDirectoryStore.useCache(DefaultPersistentDirectoryStore.java:130)
  at org.gradle.api.internal.artifacts.ivyservice.DefaultCacheLockingManager.useCache(DefaultCacheLockingManager.java:54)
  at org.gradle.api.internal.artifacts.ivyservice.ResolvedArtifactFactory$1.create(ResolvedArtifactFactory.java:36)
  at org.gradle.api.internal.artifacts.ivyservice.ResolvedArtifactFactory$1.create(ResolvedArtifactFactory.java:34)
  at org.gradle.api.internal.artifacts.DefaultResolvedArtifact.getFile(DefaultResolvedArtifact.java:120)
  at org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration$2.run(DefaultLenientConfiguration.java:135)
  at org.gradle.internal.Factories$1.create(Factories.java:22)
  at org.gradle.cache.internal.DefaultCacheAccess.useCache(DefaultCacheAccess.java:124)
  at org.gradle.cache.internal.DefaultCacheAccess.useCache(DefaultCacheAccess.java:112)
  at org.gradle.cache.internal.DefaultPersistentDirectoryStore.useCache(DefaultPersistentDirectoryStore.java:134)
  at org.gradle.api.internal.artifacts.ivyservice.DefaultCacheLockingManager.useCache(DefaultCacheLockingManager.java:58)
  at org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration.getFiles(DefaultLenientConfiguration.java:132)
  at org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration.getFilesStrict(DefaultLenientConfiguration.java:104)
  at org.gradle.api.internal.artifacts.ivyservice.DefaultResolvedConfiguration.getFiles(DefaultResolvedConfiguration.java:45)
  at org.gradle.api.internal.artifacts.ivyservice.SelfResolvingDependencyResolver$FilesAggregatingResolvedConfiguration.getFiles(SelfResolvingDependencyResolver.java:81)
  at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingArtifactDependencyResolver$ErrorHandlingResolvedConfiguration.getFiles(ErrorHandlingArtifactDependencyResolver.java:82)
  ... 34 more

BUILD FAILED

Environment: openSuse, gradle 1.6

Closeables.closeQuietly is deprecated in guava 14

As we look at updating to a more recent version of guava, I tried building with 14.0 and we get deprecation warnings for that method:

http://code.google.com/p/guava-libraries/source/diff?path=/guava/src/com/google/common/io/Closeables.java&format=side&r=b1b0baa96f590f462acdeb19d436045c2c285512&old_path=/guava/src/com/google/common/io/Closeables.java&old=a526a03775b030d15ad29e0629871bf1bbd306ca

Fix PMD Issues

Use of com.google.common.cache libs in DynamicCounter is inefficient for high velocity counting

Getting the Counter from a Google LocalCache is expensive on high velocity counters.
Here is an example of stack traces we see in thread dumps as a bottleneck. Is there a more efficient data structure that can be used for this rather than the google LocalCache?

../cores/threaddump.20131107.074201.3281.txt- at com.google.common.cache.LocalCache$Segment.drainRecencyQueue(LocalCache.java:2658)
../cores/threaddump.20131107.074201.3281.txt- at com.google.common.cache.LocalCache$Segment.expireEntries(LocalCache.java:2682)
../cores/threaddump.20131107.074201.3281.txt- at com.google.common.cache.LocalCache$Segment.runLockedCleanup(LocalCache.java:3510)
../cores/threaddump.20131107.074201.3281.txt- at com.google.common.cache.LocalCache$Segment.cleanUp(LocalCache.java:3502)
../cores/threaddump.20131107.074201.3281.txt- at com.google.common.cache.LocalCache$Segment.postReadCleanup(LocalCache.java:3478)
../cores/threaddump.20131107.074201.3281.txt- at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2267)
../cores/threaddump.20131107.074201.3281.txt- at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
../cores/threaddump.20131107.074201.3281.txt- at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
../cores/threaddump.20131107.074201.3281.txt- at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
../cores/threaddump.20131107.074201.3281.txt: at com.netflix.servo.monitor.DynamicCounter.get(DynamicCounter.java:84)
../cores/threaddump.20131107.074201.3281.txt: at com.netflix.servo.monitor.DynamicCounter.increment(DynamicCounter.java:95)
../cores/threaddump.20131107.074201.3281.txt: at com.netflix.servo.monitor.DynamicCounter.increment(DynamicCounter.java:108)

Add a Meter metric type?

Would be cool to have a Meter type that just returned the rate of some counter.

Maybe something like:

@Monitor(name="hits", type=DataSourceType.METER, unit=TimeUnit.SECOND)

that would give you the rate of change of "hits" per second. Not sure what would be involved in doing this since I'm just getting started with Servo. But so far, I like it!

Unit test additions and clean up

Due to refactoring and additions there is a lot of new code that isn't doesn't have tests of the test don't cover well. This needs to be cleaned up.

Servo support for JMX write operations

Servo is meant to be a monitor, and provides a very easy facility for developers to add the ability for a member field to be monitored. But what about the other half of JMX? IE a write operation like "flushCache()" or "setValue()" ... does Servo have a story around this? Does NetFlix have a story around this?

Thanks.