* prom-client JSON to InfluxDB line protocol converter
* Converts a metric with separate names
* prom-client JSON to InfluxDB line protocol (version 2) converter
* Server has instance id
* Read the instance id from an environment variable
* More unit tests for instance-metadata
* Log instance id
* Push influx metrics
* INSTANCE_ID with dyno metadata
* Prepare influx metrics in one place
* Influx metrics endpoint should return metrics
* More readable tests
* Env added to instance metadata
* hostname as an instance label value
* HEROKU_DYNO_ID as an instance id for heroku
* Instance env can be set by env variable
* HEROKU_APP_NAME as an instance env
* Log instance metadata as a JSON
* Typo fix
* Code refactoring in tests
* wait-for-expect dev dependency added
* Test for pushing metrics
* Test for pushing metrics
* Use basic authentication for pushing metrics
* intervalSeconds=2 for development env
* Using existing methods
* TODOs removed
* Schema for influx credentials
* Influx config removed from config files
* Require username and password when influx metrics are enabled
* Unused args removed
* pushing component should log errors
* Speed up tests
* should log error responses
* InstanceMetadata class replaces by simple object
* Influx metrics can be configuredd by env variables
* Use application label name instead of service
* Unused code removed
* Integration test for prom-client and converter
* metrics.influx.enabled configuration option added
* Improved influx configuration schema
* instanceMetadata validation
* Typo fix
* Default value for env
* metrics.infux.hostnameAsAInstanceId added
* should add hostname as an instance label when hostnameAsAInstanceId is enabled
* Default values for influx configuration
* flatMap is not available in Node.js 9.4
* Env vars removed from Procfile
* Better instance metadata values in tests
* Typo fix
* lodash.groupby added to prod dependencies
* Allow other keys in private config
* Missing test - should allow other private keys when influx metrics are enabled
* Missing test - should require private metrics config when influx configuration is enabled
* log.error instead of console.log
* metrics.influx.uri -> metrics.influx.url
* Unused arguments removed
* async removed
* promisify sendMetrics
* Allow to disable prometheus metrics
* Create test server with custom config
* 'metrics-influx' resource removed
* 'metrics-influx' resource removed
* Private config schema flattened out
* Extra code removed in Prometheus tests
* promisify moved outside of the class
* Do not throw errors from got in a specific test
* hostnameAliases added
* instanceIdFrom added
* instanceIdEnvVarName added
* envLabel added to schema
* instanceMetadata is not used by InfluxMetrics
* Instance metadata removed
* hostnameAsAnInstanceId removed
* A comment added
* waitForExpect removed
* Unused code removed
* Response size metric for all services
* Unused code removed
* Test for service response size metric
* All buckes of the service_response_bytes in a comment
* Register parameter in PrometheusMetrics is optional
* service response size metric enabled for dynamic badges
* Better test name
* JSDoc removed
* One import from one file
* Gather metrics in the background
* Revert saving response time metrics in the background
* Refactor existing metrics support into MetricHelper
This completes the refactor done at https://github.com/badges/shields/pull/3662#issuecomment-509011229 in anticipation of adding more metrics support, such as response size of an upstream service, or response time.
* Clean up
* Renames
* Add response time metrics
This adds around 30 new metrics to cover response times at a fairly granular level. We may be able to shrink the number of buckets with time, though I think using 30 metrics is probably okay given that I think may become our most important metric.
* Fix
This picks up #2068 by adding per-badge stats as discussed in #966.
It ensures every service has a unique `name` property. By default this comes from the class name, and is overridden in all the various places where the class names are duplicated. (Some of those don't seem that useful, like the various download interval services, though those need to be refactored down into a single service anyway.) Tests enforce the names are unique. These are the names used by the service-test runner, so it's a good idea to make them unique anyway. (It was sort of strange before that you had to specify `nuget` instead of e.g. `resharper`.)
I've added validation to `deprecatedService` and `redirector`, and required that every `route` has a `base`, even if it's an empty string.
The name is used to generate unique metric labels, generating metrics like these:
```
service_requests_total{category="activity",family="eclipse-marketplace",service="eclipse_marketplace_update"} 2
service_requests_total{category="activity",family="npm",service="npm_collaborators"} 3
service_requests_total{category="activity",family="steam",service="steam_file_release_date"} 2
service_requests_total{category="analysis",family="ansible",service="ansible_galaxy_content_quality_score"} 2
service_requests_total{category="analysis",family="cii-best-practices",service="cii_best_practices_service"} 4
service_requests_total{category="analysis",family="cocoapods",service="cocoapods_docs"} 2
service_requests_total{category="analysis",family="codacy",service="codacy_grade"} 3
service_requests_total{category="analysis",family="coverity",service="coverity_scan"} 2
service_requests_total{category="analysis",family="coverity",service="deprecated_coverity_ondemand"} 2
service_requests_total{category="analysis",family="dependabot",service="dependabot_semver_compatibility"} 3
service_requests_total{category="analysis",family="lgtm",service="lgtm_alerts"} 2
service_requests_total{category="analysis",family="lgtm",service="lgtm_grade"} 3
service_requests_total{category="analysis",family="snyk",service="snyk_vulnerability_git_hub"} 4
service_requests_total{category="analysis",family="snyk",service="snyk_vulnerability_npm"} 5
service_requests_total{category="analysis",family="symfony",service="sensiolabs_i_redirector"} 1
service_requests_total{category="analysis",family="symfony",service="symfony_insight_grade"} 1
service_requests_total{category="build",family="appveyor",service="app_veyor_ci"} 3
service_requests_total{category="build",family="appveyor",service="app_veyor_tests"} 6
service_requests_total{category="build",family="azure-devops",service="azure_dev_ops_build"} 6
service_requests_total{category="build",family="azure-devops",service="azure_dev_ops_release"} 5
service_requests_total{category="build",family="azure-devops",service="azure_dev_ops_tests"} 6
service_requests_total{category="build",family="azure-devops",service="vso_build_redirector"} 2
service_requests_total{category="build",family="azure-devops",service="vso_release_redirector"} 1
service_requests_total{category="build",family="bitbucket",service="bitbucket_pipelines"} 5
service_requests_total{category="build",family="circleci",service="circle_ci"} 5
```
This is predicated on being able to use Prometheus's [`rate()`](https://prometheus.io/docs/prometheus/latest/querying/functions/#rate) function to visualize a counter's rate of change, as mentioned at https://github.com/badges/shields/issues/2068#issuecomment-466696561. Otherwise the stats will be disrupted every time a server restarts.
The metrics only appear on new-style services.
