The metrics are collected in a new handler (BackendMetricsHandler), which gets outbound FullHttpRequest and inbound FullHttpResponse. All metrics collected here are backend metrics, i. e. metrics about connection between the proxy and GAE. They also corresponds to the metrics that we are correctly collection from the [] proxy, minus a few that are related to quota management, which are yet to be implemented.
This CL also removed some unnecessary steps to write the frontend protocol name and client hash certificate into backend channel attributes. Instead, BackendMetricsHandler will read these information from the frontend channel attributes directly. This is because backend channel is established after frontend channel, and reading frontend channel attributes from backend handlers always works. On the other hand, there is no easy way to guarantee that the backend channel attributes are writable from frontend handlers, because the channel itself may not have been fully established.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174513334
Also making these methods public so that other test methods can use them.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174074038
Currently to assert that a given Metric<Distribution> as a certain distribution for some labels, the caller needs to manually create an ImmutableDistribution and pass it to #hasValueForLabels method. With this change, an ImmutableSet of data points can be passed to #hasDataSetForLabels method.
Also switched to use expectThrow backport from JUnit 4.13.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=173544521
They can be inferred correctly even in Java 7, and display as
compiler warnings in IntelliJ.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=173451087
Unfortunately this tool isn't smart enough to deal with the assertThat
situation (which has two static imports of a function with the same name).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172000753
This was a surprisingly involved change. Some of the difficulties included
java.util.Optional purposely not being Serializable (so I had to move a
few Optionals in mapreduce classes to @Nullable) and having to add the Truth
Java8 extension library for assertion support.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171863777
Also fixes the issue that dry run EPP commands were incorrectly being
reported on.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171062984
The concrete implementation of a Metric is not of importance when asserting on the values it contains. Therefore this CL removes Metric<T> as a type parameter of AbstractMetricSubject. As a result the two implementations of the abstract subject can be used on any Metric<Long> and Metric<Distribution>, respectively.
Also migrate to Subject.Factory from deprecated SubjectFactory.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171012012
Users of the client library should be responsible for providing the bindings required. By removing the injectable constructors and named bindings in their parameters, the client library is no longer forcing its users to provide bindings with specific named annotations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170490834
*** Reason for rollback ***
Rolling back to fix []
*** Original change description ***
Remove @Inject annotation in StackDriverWriter
StackDriverWriter is provided by java.google.registry.monitoring.whitebox.StackdriverModule. The @Inject annotation in its constructor is not used. It also uses outdated named binding like @Named(stackdriverGcpProject) which causes confusion because that name is not provided anywhere in the code.
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169931047
StackDriverWriter is provided by java.google.registry.monitoring.whitebox.StackdriverModule. The @Inject annotation in its constructor is not used. It also uses outdated named binding like @Named(stackdriverGcpProject) which causes confusion because that name is not provided anywhere in the code.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169922096
It turns out that StackdriverWriter uses reflection on the class of
the DistributionFitter instance, so rather than giving it custom
handling for FibonacciFitters, it's easier to turn FibonacciFitter
into a single utility method that takes advantage of existing support
for CustomFitters.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158190147
We want to know how long it's actually taking to process asynchronous
contact/host deletions and DNS refreshes on host renames. This adds
instrumentation. Five metrics are recorded as follows:
* An incrementable metric for each async task processed (split out by
type of task and result).
* Two event metrics for processing time between when a task is enqueued
and when it is processed -- tracked separately for contact/host
deletion and DNS refresh on host rename.
* Two event metrics for batch size every time the two mapreduces are
run (this is usually 0). Tracked separately for contact/host deletion
and DNS refresh on host rename.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157001310
A Fibonacci fitter is useful in situations where you want more precision on the
low end than an ExponentialFitter with exponent base 2 provides without the
hassle of dealing with non-integer boundaries, such as would be created by an
exponential fitter with a base of less than 2. Fibonacci fitters are ideal for
integer metrics that are bounded across a certain range, e.g. integers between 1
and 1,000.
This also cleans up some unit test comments.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156773367
This CL adds Truth framework subjects to some metrics in the Stackdriver metrics library, in a contrib subpackage. It doesn't deal with gauge metrics, and for event metrics, the assertions can only be that a metric has or does not have a distribution for a particular set of label values. Asserting more fine-grained propositions regarding the distribution will require a distribution subject.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=149112692
Downstream users who use gRPC rather than REST don't want to pull down
rest-related dependencies.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145834701
We're now using java_import_external instead of maven_jar. This allows
us to specify the relationships between jars, thereby allowing us to
eliminate scores of vendor BUILD files that did nothing but re-export
@foo//jar targets, thus addressing the concerns of djhworld on Hacker
News: https://news.ycombinator.com/item?id=12738072
We now have redundant failover mirrors, which is a feature I added to
Bazel 0.4.2 in ed7ced0018
A new standard naming convention is now being used for all Maven repos.
Those names are calculated from the group_artifact name using the
following algorithm that eliminates redundancy:
https://gist.github.com/jart/41bfd977b913c2301627162f1c038e55
The JSR330 dep has been removed from java targets if they also depend
on Dagger, since Dagger always exports JSR330.
Annotation processor dependencies should now be leaner and meaner, by
more appropriately managing what needs to be on the classpath at
runtime. This should trim down the production jar by >1MB. As it stands
currently in the open source world:
- backend_jar_deploy.jar: 50MB
- frontend_jar_deploy.jar: 30MB
- tools_jar_deploy.jar: 45MB
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143487929
This allows separate Bazel projects to reference Nomulus as an external
repository. They can then copy the []
directory structure into their own project and customize the Action
and Module lists for the GAE modules in their own deployment.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136863886
The Stackdriver API requires that the end time always be greater than the start
time for cumulative metric points.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134396192
This DistributionFitter is suitable for tracking the latency of network calls.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132400538
This is one of a series of CLs adding a new metric type, EventMetric, which
is used for tracking numerical distributions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132103552
The major changes are using the ExpectedException rule instead of a try/catch
pattern, asserting the message for thrown exceptions, defaulting to JUnit4
unless Mockito is really necessary, and making each test examine one behavior.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131211346
