중요
Enable the AWS CloudWatch Metric Streams integration to monitor all CloudWatch metrics from your AWS services, including custom namespaces. Individual integrations are no longer our recommended option.
New Relic infrastructure integrations include an Amazon Elastic Classic Load Balancing (ELB) integration for reporting Classic ELB data to New Relic. This document explains the integration's features, how to activate it, and what data can be reported.
Features
New Relic's integration for Amazon Elastic Classic Load Balancing (ELB) reports ELB data, including HTTP code message counts, healthy and unhealthy host counts, latency times, and ELB configuration states. AWS integration data is also available for querying and chart creation.
Amazon offers three types of load balancers: Classic Load Balancer, Application Load Balancer (ALB), and Network Load Balancer (NLB). New Relic also offers an ALB/NLB integration to monitor the last two types of load balancers.
Activate integration
To enable this integration, follow standard procedures to connect AWS services to New Relic.
Configuration and polling
You can change the polling frequency and filter data using configuration options.
Default polling information for the AWS ELB integration:
- New Relic polling interval: 5 minutes
- Amazon CloudWatch data interval: 1 minute
View and use data
To view and use this integration's data, go to one.newrelic.com > All capabilities > Infrastructure > AWS and select one of the ELB integration links.
You can query and explore your data using the LoadBalancerSample
event type, with a provider
value of Elb
.
Metric data
The integration collects the following metrics. For additional details about these metrics, see Amazon's ELB Classic Load Balancer metrics documentation.
Name | Description |
---|---|
| Rate of the number of connections per second that were not successfully established between the load balancer and the registered instances. The load balancer retries the connection when there are errors, so this count may exceed the request rate. This count also includes any connection errors related to health checks. |
| The number of healthy or unhealthy instances registered with your load balancer. A newly registered instance is considered healthy after it passes the first health check. If cross-zone load balancing is enabled, the number of healthy instances for the |
| [HTTP listener] The number of HTTP response codes generated per second by registered instances. This count does not include any response codes generated by the load balancer. |
| [HTTP listener] The number of HTTP |
| [HTTP listener] The number of HTTP |
| [HTTP listener] The total time elapsed, in seconds, from the time the load balancer sent the request to a registered instance until the instance started to send the response headers. [TCP listener] The total time elapsed, in seconds, for the load balancer to successfully establish a connection to a registered instance. Available statistics:
|
| The number of requests completed or connections made per second during the specified interval (1 or 5 minutes). |
| The total number of requests that were rejected per second, due to the surge queue being full. |
| The total number of requests that are pending routing. The load balancer queues a request if it is unable to establish a connection with a healthy instance in order to route the request. The maximum size of the queue is 1,024. Additional requests are rejected when the queue is full. For more information, see |
| The estimated number of concurrent TCP connections active from clients to the load balancer and from the load balancer to targets. |
| The estimated number of load balancer capacity units (LCU) used by an application load balancer. |
| The estimated number of new TCP connections established from clients to the load balancer and from the load balancer to targets. |
| The estimated number of bytes processed by an application load balancer. |