The V2 release includes several additional features and does include a few breaking changes. Deployment configurations, alerts, and dashboards may require updates.
The nozzle now connects to the Loggregator using the Reverse Log Proxy (RLP) Gateway and consumes V2 envelopes. This ensures compatability with PCF 2.9+.
Events are no longer all sent to the PcfFirehoseEvent event type. They are now broken out by envelope type. You will now see events in PCFLogMessage, PCFContainerMetric, PCFValueMetric, etc. This will require alert and dashboard adjustments.
Event attribute names have changed from using camel case to a dimensional metric type format. Examples include app.name, metric.max, etc. This will require alert and dashboard adjustments.
Metric based data points now aggregate samples to reduce the number of events being sent to Insights. Instead of seeing an event for each sample, you will receive an event each minute that contains metric.max, metric.min, metric.sample.last.value, metric.samples.count, and metric.sum. The previous nozzle configuration could have sent 2-100+ events for each of these data points per minute. Aggregation occurs for all event types except HttpStartStop and LogMessage. The average can be calculated by dividing metric.sum by metric.samples.count.
Version 1.12.19 and above of the [New Relic Service Broker for Pivotal Platform] (https://network.pivotal.io/products/p-new-relic) enable rpmAccountId and insightsInsertKey to be defined at the plan level for each application. If these values are set, application specific LogMessage and ContainerMetric events can be sent to different New Relic accounts. The insert key and account ID settings in your manifest or tile configuration define the default account that will receive all events that either are not application specific (not LogMessage or ContainerMetric events) and all events that are application specific but rpmAccountId and insightsInsertKey have not been defined in the application's Service Broker plan.
Multiple improvements have been made to reduce the number of CF application API calls made by the nozzle.
- CF application details are now cached for up to 30 minutes
- Application instance details are retrieved every 30 seconds
- API calls are rate limited to a maximum of 5 concurrent calls per nozzle instance.
Configuration variable names have changed and different fields are included in the tile based deployment process. See the Push as an Application and Import as a Tile in Ops Manager sections for more details.
Include and exclude filters for LogMessage events are available. Multiple | or , separated filters can be included in each of these environment variables. Include filters are processed before exclude filters and you can combine these to limit LogMessage events to only useful events. For example, you could include all events with the source of RTR but exclude events that contain GET in the message.
NRF_LOGMESSAGE_SOURCE_INCLUDE
Ignore events unless the source matches a source in this list. For example, RTR or APP/PROC/WEB
NRF_LOGMESSAGE_SOURCE_EXCLUDE
Ignore events if their source matches a source in this list. For example, RTR or APP/PROC/WEB
NRF_LOGMESSAGE_MESSAGE_INCLUDE
Only include events that contain these strings in the log message. If you set this to ERROR|crash you should only receive error and crash related log events.
NRF_LOGMESSAGE_MESSAGE_EXCLUDE
Exclude events that contain these strings in the log message.
Metric related inclusion/exclusion filters (deployment, job, and origin) have been removed. Event reduction provided by metric aggregation should reduce the impact of this change.
The nozzle captures the SIGTERM signal created by cf stop or scale down commands and gracefully shuts down.