yogsototh/clj-http-client
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
clj-http-client/test/com/puppetlabs/http/client/impl/metrics_unit_test.clj

260 lines
15 KiB
Clojure
Raw Normal View History

(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(ns com.puppetlabs.http.client.impl.metrics-unit-test
(:require [clojure.test :refer :all]
(TK-316) Add specific schemas for different categories of metrics data Rather than having e.g a nil url and method in the metric data when metric-id is filtered on, or a nil metric id if url and method are filtered on, use specific schemas for metrics data returned for each metric category - metric id, url, and url and method.
2016-05-04 17:07:48 +00:00
[puppetlabs.http.client.metrics :as metrics]
[schema.test :as schema-test])
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(:import (com.codahale.metrics MetricRegistry)
(com.puppetlabs.http.client.impl Metrics Metrics$MetricType)
(org.apache.http.message BasicHttpRequest)))
(TK-316) Add specific schemas for different categories of metrics data Rather than having e.g a nil url and method in the metric data when metric-id is filtered on, or a nil metric id if url and method are filtered on, use specific schemas for metrics data returned for each metric category - metric id, url, and url and method.
2016-05-04 17:07:48 +00:00
(use-fixtures :once schema-test/validate-schemas)
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(def full-response Metrics$MetricType/FULL_RESPONSE)
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(defn add-metric-ns [string]
(str "puppetlabs.http-client.experimental." string))
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(deftest start-full-response-timers-test
(testing "startFullResponseTimers creates the right timers"
(let [url-id (add-metric-ns "with-url.http://localhost/foo.full-response")
url-method-id (add-metric-ns "with-url-and-method.http://localhost/foo.GET.full-response")]
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(testing "metric id timers are not created for a request without a metric id"
(let [metric-registry (MetricRegistry.)]
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(Metrics/startFullResponseTimers metric-registry
(BasicHttpRequest. "GET" "http://localhost/foo")
nil)
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(is (= (set (list url-id url-method-id)) (set (keys (.getTimers metric-registry)))))))
(testing "metric id timers are not created for a request with an empty metric id"
(let [metric-registry (MetricRegistry.)]
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(Metrics/startFullResponseTimers metric-registry
(BasicHttpRequest. "GET" "http://localhost/foo")
(into-array String []))
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(is (= (set (list url-id url-method-id)) (set (keys (.getTimers metric-registry)))))))
(testing "metric id timers are created correctly for a request with a metric id"
(let [metric-registry (MetricRegistry.)]
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(Metrics/startFullResponseTimers metric-registry
(BasicHttpRequest. "GET" "http://localhost/foo")
(into-array ["foo" "bar" "baz"]))
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(is (= (set (list url-id url-method-id
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(add-metric-ns "with-metric-id.foo.full-response")
(add-metric-ns "with-metric-id.foo.bar.full-response")
(add-metric-ns "with-metric-id.foo.bar.baz.full-response")))
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(set (keys (.getTimers metric-registry)))))))
(testing "url timers should strip off username, password, query string, and fragment"
(let [metric-registry (MetricRegistry.)]
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(Metrics/startFullResponseTimers
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
metric-registry
(BasicHttpRequest. "GET" "http://user:pwd@localhost:1234/foo%2cbar/baz?te%2cst=one")
nil)
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(Metrics/startFullResponseTimers
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
metric-registry
(BasicHttpRequest. "GET" "http://user:pwd@localhost:1234/foo%2cbar/baz#x%2cyz")
nil)
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(Metrics/startFullResponseTimers
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
metric-registry
(BasicHttpRequest.
"GET" "http://user:pwd@localhost:1234/foo%2cbar/baz?te%2cst=one#x%2cyz")
nil)
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(Metrics/startFullResponseTimers
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
metric-registry
(BasicHttpRequest.
"GET" "http://user:pwd@localhost:1234/foo%2cbar/baz?#x%2cyz")
nil)
(is (= (set (list
(add-metric-ns
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
"with-url.http://localhost:1234/foo%2cbar/baz.full-response")
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(add-metric-ns
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
"with-url-and-method.http://localhost:1234/foo%2cbar/baz.GET.full-response")))
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(set (keys (.getTimers metric-registry))))))))))
(defn start-and-stop-timers! [registry req id]
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(doseq [timer (Metrics/startFullResponseTimers
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
registry
req
id)]
(.stop timer)))
(deftest get-client-metrics-data-test
(let [registry (MetricRegistry.)
url "http://test.com/one"
url2 "http://test.com/one/two"]
(start-and-stop-timers! registry (BasicHttpRequest. "GET" url) nil)
(start-and-stop-timers! registry (BasicHttpRequest. "POST" url) nil)
(start-and-stop-timers! registry (BasicHttpRequest. "POST" url) (into-array ["foo" "bar"]))
(start-and-stop-timers! registry (BasicHttpRequest. "GET" url2) (into-array ["foo" "abc"]))
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(testing "getClientMetrics without args returns all timers organized by category"
(is (= (set ["url" "url-and-method" "metric-id"])
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(set (keys (Metrics/getClientMetrics registry)))
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(set (keys (Metrics/getClientMetricsData registry)))))
(is (= (set [:url :url-and-method :metric-id])
(set (keys (metrics/get-client-metrics registry)))
(set (keys (metrics/get-client-metrics-data registry)))))
(is (= (set
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
[(add-metric-ns "with-url.http://test.com/one.full-response")
(add-metric-ns "with-url.http://test.com/one/two.full-response")])
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(set (map #(.getMetricName %) (get (Metrics/getClientMetrics registry) "url")))
(set (map #(.getMetricName %) (:url (metrics/get-client-metrics registry))))
(set (map #(.getMetricName %) (get (Metrics/getClientMetricsData registry) "url")))
(set (map :metric-name (:url (metrics/get-client-metrics-data registry))))))
(is (= (set
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
[(add-metric-ns "with-url-and-method.http://test.com/one.GET.full-response")
(add-metric-ns "with-url-and-method.http://test.com/one.POST.full-response")
(add-metric-ns "with-url-and-method.http://test.com/one/two.GET.full-response")])
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(set (map #(.getMetricName %)
(get (Metrics/getClientMetrics registry) "url-and-method")))
(set (map #(.getMetricName %)
(:url-and-method (metrics/get-client-metrics registry))))
(set (map #(.getMetricName %)
(get (Metrics/getClientMetricsData registry) "url-and-method")))
(set (map :metric-name
(:url-and-method (metrics/get-client-metrics-data registry))))))
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(is (= (set ["puppetlabs.http-client.experimental.with-metric-id.foo.full-response"
"puppetlabs.http-client.experimental.with-metric-id.foo.bar.full-response"
"puppetlabs.http-client.experimental.with-metric-id.foo.abc.full-response"])
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(set (map #(.getMetricName %)
(get (Metrics/getClientMetrics registry) "metric-id")))
(set (map #(.getMetricName %)
(:metric-id (metrics/get-client-metrics registry))))
(set (map #(.getMetricName %)
(get (Metrics/getClientMetricsData registry) "metric-id")))
(set (map :metric-name
(:metric-id (metrics/get-client-metrics-data registry)))))))
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(testing "getClientMetricsData with url returns the right thing"
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(let [java-data (Metrics/getClientMetricsDataByUrl registry url full-response)
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
clj-data (metrics/get-client-metrics-data-by-url registry url)]
(is (= 1 (count java-data) (count clj-data)))
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(is (= (add-metric-ns "with-url.http://test.com/one.full-response")
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(.getMetricName (first java-data))
(:metric-name (first clj-data))))
(is (= 3 (.getCount (first java-data))
(:count (first clj-data)))))
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(let [java-data (Metrics/getClientMetricsDataByUrl registry url2 full-response)
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
clj-data (metrics/get-client-metrics-data-by-url registry url2)]
(is (= 1 (count java-data) (count clj-data)))
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(is (= (add-metric-ns "with-url.http://test.com/one/two.full-response")
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(.getMetricName (first java-data))
(:metric-name (first clj-data))))
(is (= 1 (.getCount (first java-data))
(:count (first clj-data)))))
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(testing "getClientMetricsData with url returns nothing if url is not a full match"
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(is (= [] (Metrics/getClientMetricsDataByUrl registry "http://test.com" full-response)
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(metrics/get-client-metrics-data-by-url registry "http://test.com")))))
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(testing "getClientMetricsData with url and method returns the right thing"
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(let [java-data (Metrics/getClientMetricsDataByUrlAndMethod registry url "GET" full-response)
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
clj-data (metrics/get-client-metrics-data-by-url-and-method registry url :get)]
(is (= 1 (count java-data) (count clj-data)))
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(is (= (add-metric-ns "with-url-and-method.http://test.com/one.GET.full-response")
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(.getMetricName (first java-data))
(:metric-name (first clj-data))))
(is (= 1 (.getCount (first java-data))
(:count (first clj-data)))))
(let [java-data (Metrics/getClientMetricsDataByUrlAndMethod
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
registry url "POST" full-response)
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
clj-data (metrics/get-client-metrics-data-by-url-and-method
registry url :post)]
(is (= 1 (count java-data) (count clj-data)))
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(is (= (add-metric-ns "with-url-and-method.http://test.com/one.POST.full-response")
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(.getMetricName (first java-data))
(:metric-name (first clj-data))))
(is (= 2 (.getCount (first java-data))
(:count (first clj-data)))))
(let [java-data (Metrics/getClientMetricsDataByUrlAndMethod
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
registry url2 "GET" full-response)
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
clj-data (metrics/get-client-metrics-data-by-url-and-method registry url2 :get)]
(is (= 1 (count java-data) (count clj-data)))
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(is (= (add-metric-ns "with-url-and-method.http://test.com/one/two.GET.full-response")
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(.getMetricName (first java-data))
(:metric-name (first clj-data))))
(is (= 1 (.getCount (first java-data))
(:count (first clj-data)))))
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(testing "getClientMetricsData with url and method returns nothing if method is not a match"
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(is (= [] (Metrics/getClientMetricsDataByUrlAndMethod
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
registry "http://test.com" "PUT" full-response)
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(metrics/get-client-metrics-data-by-url-and-method registry "http://test.com" :put)))))
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(testing "getClientMetricsData with metric id returns the right thing"
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(let [java-data (Metrics/getClientMetricsDataByMetricId
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
registry (into-array ["foo"]) full-response)
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
clj-data (metrics/get-client-metrics-data-by-metric-id registry ["foo"])]
(is (= 1 (count java-data) (count clj-data)))
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(is (= (add-metric-ns "with-metric-id.foo.full-response")
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(.getMetricName (first java-data))
(:metric-name (first clj-data))))
(is (= 2 (.getCount (first java-data))
(:count (first clj-data)))))
(let [java-data (Metrics/getClientMetricsDataByMetricId
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
registry (into-array ["foo" "bar"]) full-response)
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
clj-data (metrics/get-client-metrics-data-by-metric-id
registry ["foo" "bar"])]
(is (= 1 (count java-data) (count clj-data)))
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(is (= (add-metric-ns "with-metric-id.foo.bar.full-response")
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(.getMetricName (first java-data))
(:metric-name (first clj-data))))
(is (= 1 (.getCount (first java-data))
(:count (first clj-data)))))
(let [java-data (Metrics/getClientMetricsDataByMetricId
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
registry (into-array ["foo" "abc"]) full-response)
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
clj-data (metrics/get-client-metrics-data-by-metric-id
registry ["foo" "abc"])]
(is (= 1 (count java-data) (count clj-data)))
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
(is (= (add-metric-ns "with-metric-id.foo.abc.full-response")
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(.getMetricName (first java-data))
(:metric-name (first clj-data))))
(is (= 1 (.getCount (first java-data))
(:count (first clj-data))))
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(testing "metric id can be specified as keyword or string"
(is (= clj-data
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(metrics/get-client-metrics-data-by-metric-id registry ["foo" :abc])))))
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(testing "getClientMetricsData with metric id returns nothing if id is not a match"
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(is (= [] (Metrics/getClientMetricsDataByMetricId
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
registry (into-array ["foo" "cat"]) full-response)
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(metrics/get-client-metrics-data-by-metric-id registry ["foo" "cat"]))))
(testing "getClientMetrics|Data returns nil if no metric registry passed in"
(is (= nil (Metrics/getClientMetrics nil) (Metrics/getClientMetricsData nil)))
(is (= nil (metrics/get-client-metrics nil) (metrics/get-client-metrics-data nil))))
(testing (str "getClientMetrics|Data returns map with empty arrays as values"
" if no requests have been made yet")
(is (= {"url" [] "url-and-method" [] "metric-id" []}
(into {} (Metrics/getClientMetrics (MetricRegistry.)))
(into {} (Metrics/getClientMetricsData (MetricRegistry.)))))
(is (= {:url [] :url-and-method [] :metric-id []}
(metrics/get-client-metrics (MetricRegistry.))
(metrics/get-client-metrics-data (MetricRegistry.)))))
(testing "getClientMetrics returns correctly without metric-id on request"
(let [registry (MetricRegistry.)
url "http://test.com/one"]
(start-and-stop-timers! registry (BasicHttpRequest. "GET" url) nil)
(let [client-metrics (Metrics/getClientMetrics registry)
client-metrics-data (Metrics/getClientMetricsData registry)]
(is (= (set ["url" "url-and-method" "metric-id"])
(set (keys client-metrics))
(set (keys client-metrics-data))))
(is (= (set [(add-metric-ns
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
"with-url.http://test.com/one.full-response")])
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(set (map #(.getMetricName %) (get client-metrics "url")))
(set (map #(.getMetricName %) (get client-metrics-data "url")))))
(is (= (set [(add-metric-ns
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
"with-url-and-method.http://test.com/one.GET.full-response")])
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(set (map #(.getMetricName %)
(get client-metrics "url-and-method")))
(set (map #(.getMetricName %)
(get client-metrics-data "url-and-method")))))
(is (= []
(get client-metrics "metric-id")
(get client-metrics-data "metric-id")))))))))
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(deftest empty-metric-id-filter-test
(testing "a metric id filter with an empty array returns all metric id timers"
(let [registry (MetricRegistry.)
url "http://test.com/foo/bar"
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
foo-id (add-metric-ns "with-metric-id.foo.full-response")
foo-bar-id (add-metric-ns "with-metric-id.foo.bar.full-response")
foo-bar-baz-id (add-metric-ns "with-metric-id.foo.bar.baz.full-response")]
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(start-and-stop-timers! registry (BasicHttpRequest. "GET" url)
(into-array ["foo" "bar" "baz"]))
(TK-316) Add metrics support This commit adds metrics support to the http client (clojure and java, sync and async). A metric registry can optionally be passed into the client as a client option on creation. If a metric registry is present, timers will be added to time each request. By default, a timer is added for the URL (stripped of username, password, query string, and path fragments) and the URL plus the method used for the request. In addition, a request can include a `metric-id` option, which takes a tuple of metric ids. If this request option is specified, a timer will be created for each element of the metric id tuple - thus if the tuple is [:foo :bar :baz] there will be a foo timer, a foo.bar timer, and a foo.bar.baz timer. In addition, each timer has a "MetricType" - currently there is only one metric type, bytes-read, which is stopped when the full response has been read. In the future, we may add "response-init" timers that get stopped when the first byte of the response has been read. This commit also adds a `get-client-metrics`/`.getClientMetrics` function that takes a client instance and returns the http client-specific metrics from the metric registry and a `get-client-metrics-data`/`.getClientMetricsData` function for clojure and java sync and async clients to get out metrics data from the client. This function takes a client instance and returns a map of metric name to a map of metric data (for clojure) or a ClientMetricData object (for java), both of which include the mean, count, and aggregate for the timer These `get-client-metrics*`/`.getClientMetrics*` functions also have versions that take a url, url and method, or metric id to allow for filtering of the timers/metrics data returned by these functions. The clojure versions of these functions take a metric filter map. There are also metric filter builder functions to build up the type of metric filter desired from a url, a url and method, or a metric id. These will prevent users from having to know the specifics of how to build a metric themselves; instead they can use a convenience function. An empty metric id can be passed in to the filter to return all metric-id timers.
2016-02-26 05:39:21 +00:00
(testing "empty metric filter returns all metric id timers"
(is (= (set (list foo-id foo-bar-id foo-bar-baz-id))
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(set (map #(.getMetricName %)
(Metrics/getClientMetricsDataByMetricId
(TK-316) Rename `bytes-read` to `full-response` Rename the Metric Types from `bytes-read`/`init-repsonse` to `full-response`/`initial-response` (note that the `initial-response` timer has not yet been implemented, but when it is this will be its name).
2016-04-22 21:26:51 +00:00
registry (into-array String []) full-response)))
(TK-316) Improve metrics API This commit does several things to improve the metrics API: * Move get-client-metrics(-data) functions off of client: Previously, the `get-client-metrics(-data)`/`.getClientMetrics(Data)` functions were on the client. This didn't entirely make sense because if two clients were using the same metric registry, these functions would actually return metrics data for *all* clients, rather than just for the client the function was called on. This commit removes these functions and changes the tests to use the metrics namepsace/Metrics class versions instead, which take a metric registry return all http-client related metrics on that metric registry. * Add a `with-url-and-method` namespace: Move the timers that have both the url and the method from the `with-url` namespace to a new `with-url-and-method` namepsace. This better matches the data structure are returned in and the filtering mechanisms for getting them back out (discussed below), and also removes a slight chance of having a conflict with a url timer. * Add a ClientTimer class: Add a ClientTimer class that wraps the Timer class and also holds onto the url, method, or metric id used to create the timer. Use this to add url, method, metricId to ClientMetricData. * Change the `getClientMetrics(Data)` methods to return a map of metric category to an array of timers or timer data: Previously, the methods for getting http client metrics/metric data out of a metric registry returned a map of metric name to timer instance or metric data. However, the metric name was most likely not useful to users, who probably just want to iterate through the timers/data. This commit makes the output of these functions more useful by returning arrays of timers/data sorted into a map indexed by metric category (url, url and method, or metric id). * Add `getClientMetricsBy*` methods: Add `getClientMetrics(Data)ByUrl`, `getClientMetrics(Data)ByUrlAndMethod`, and `getClientMetrics(Data)ByMetricId` methods (and clojure versions) that allow for filtering by a specific metric category and return an array of timers or timer data that match the url, url and method, or metric id specified. * Remove the filter-builder functions: Previously, the `get-client-metrics(-data)` functions did filtering by taking a filter map, and there were filter-builder functions to build these filter maps. Now that there are separate filtering methods, these filter maps are no longer used and the filter-builder functions are removed.
2016-04-07 00:17:53 +00:00
(set (map :metric-name
(metrics/get-client-metrics-data-by-metric-id registry [])))))))))
Reference in a new issue Copy permalink