ekino / ekinonewrelicbundle

Add NewRelic support to Symfony

Ekino NewRelic Bundle

This bundle integrates the NewRelic PHP API into Symfony. For more information about NewRelic, please visit http://newrelic.com. The built-in New Relic agent doesn't add as much Symfony integration as it claims. This bundle adds a lot more essentials. Here's a quick list:

1. Better transaction naming strategy: Your transaction traces can be named accurately by route names, the controller name or you can decide on a custom naming strategy via a seamless interface that uses any naming convention you deem fit. While running console commands, it also sets the transaction name as the command name.

2. Console Commands Enhancements: While running console commands, its sets the options and arguments passed via the CLI as custom parameters to the transaction trace for easier debugging.

3. Exception Listening: It also captures all Symfony exceptions in web requests and console commands and sends them to New Relic (something new relic doesn't do too well itself as symfony aggressively catches all exceptions/errors). It also ensures all HTTP Exceptions (4xx codes) are logged as notices in New Relic and not exceptions to reduce the noise in New Relic.

4. Interactor Service: It provides you the New Relic PHP Agent API via a Service class NewRelicInteractorInterface::class so in my code, I can inject it into any class, controller, service and do stuff like -

   // Bundle
   $this->newRelic->addCustomParameter('name', 'john');
   
   // Extension
   if (extension_loaded('newrelic')) {
       \newrelic_add_custom_parameter('name', 'john');
   }

5. Logging Support: In development, you are unlikely to have New Relic setup. There's a configuration to enable logging which outputs all New Relic actions to your Symfony log, hence emulating what it would actually do in production.

6. Ignored Routes, Paths, Commands: You can configure a list of route name, url paths and console commands to be ignored from New Relic traces.

   

7. Misc: There are other useful configuration like your New Relic API Key, explicitly defining your app name instead of php.ini, notifying New Relic about new deployments via capifony, etc.

Installation

Step 0 : Install NewRelic

review http://newrelic.com ...

Step 1: add dependency

$ composer require ekino/newrelic-bundle

Step 2 : Register the bundle

Then register the bundle with your kernel:

<?php

// in AppKernel::registerBundles()
$bundles = array(
    // ...
    new Ekino\NewRelicBundle\EkinoNewRelicBundle(),
    // ...
);

Step 3 : Configure the bundle

In New Relic's web interface, make sure to get a valid (REST) API Key, not to be confused with your License key : New Relic Dashboard > Account settings > Integration > API Keys

# app/config/config.yml

ekino_new_relic:
    enabled: true                         # Defaults to true
    application_name: Awesome Application # default value in newrelic is "PHP Application", or whatever is set
                                          # as php ini-value
    deployment_names: ~                   # default value is 'application_name', supports string array or semi-colon separated string
    api_key:                              # New Relic API
    api_host: ~                           # New Relic API Host (default value is api.newrelic.com, for EU should be set to api.eu.newrelic.com )
    license_key:                          # New Relic license key (optional, default value is read from php.ini)
    xmit: false                           # if you want to record the metric data up to the point newrelic_set_appname is called, set this to true (default: false)
    logging: false                        # If true, logs all New Relic interactions to the Symfony log (default: false)
    interactor: ~                         # The interactor service that is used. Setting enabled=false will override this value 
    twig: true                            # Allows you to disable twig integration (falls back to class_exists(\Twig_Environment::class))
    exceptions: true                      # If true, sends exceptions to New Relic (default: true)
    deprecations: true                    # If true, reports deprecations to New Relic (default: true)
    instrument: false                     # If true, uses enhanced New Relic RUM instrumentation (see below) (default: false)
    http:
        enabled: true
        using_symfony_cache: false        # Symfony HTTP cache (see below) (default: false)
        transaction_naming: route         # route, controller or service (see below)
        transaction_naming_service: ~     # Transaction naming service (see below)
        ignored_routes: []                # No transaction recorded for this routes
        ignored_paths: []                 # No transaction recorded for this paths
    monolog: 
        enabled: false                    # When enabled, send application's logs to New Relic (default: disabled)
        channels: [app]                   # Channels to listen (default: null). [See Symfony's documentation](http://symfony.com/doc/current/logging/channels_handlers.html#yaml-specification)
        level: error                      # Report only logs higher than this level (see \Psr\Log\LogLevel) (default: error)
        service: app.my_custom_handler    # Define a custom log handler (default: ekino.new_relic.monolog_handler)
    commands: 
        enabled: true                     # If true, logs CLI commands to New Relic as Background jobs (>2.3 only) (default: true)
        ignored_commands: []              # No transaction recorded for this commands (background tasks)

Enhanced RUM instrumentation

The bundle comes with an option for enhanced real user monitoring. Ordinarily the New Relic extension (unless disabled by configuration) automatically adds a tracking code for RUM instrumentation to all HTML responses. Using enhanced RUM instrumentation, the bundle allows you to selectively disable instrumentation on certain requests.

This can be useful if, e.g. you're returning HTML verbatim for an HTML editor.

If enhanced RUM instrumentation is enabled, you can disable instrumentation for a given request by passing along a _instrument request parameter, and setting it to false. This can be done e.g. through the routing configuration.

Transaction naming strategies

The bundle comes with two built-in transaction naming strategies. route and controller, naming the New Relic transaction after the route or controller respectively. However, the bundle supports custom transaction naming strategies through the service configuration option. If you have selected the service configuration option, you must pass the name of your own transaction naming service as the transaction_naming_service configuration option.

The transaction naming service class must implement the Ekino\NewRelicBundle\TransactionNamingStrategy\TransactionNamingStrategyInterface interface. For more information on creating your own services, see the Symfony documentation on Creating/Configuring Services in the Container.

Symfony HTTP Cache

When you are using Symfony's HTTP cache your app/AppCache.php will build up a response with your Edge Side Includes (ESI). This will look like one transaction in New Relic. When you set using_symfony_cache: true will these ESI request be separate transaction which improves the statistics. If you are using some other reverse proxy cache or no cache at all, leave this to false.

If true is required to set the application_name.

Deployment notification

You can use the newrelic:notify-deployment command to send deployment notifications to New Relic. This requires the api_key configuration to be set.

The command has a bunch of options, as displayed in the help data.

$ app/console newrelic:notify-deployment --help
Usage:
 newrelic:notify-deployment [--user[="..."]] [--revision[="..."]] [--changelog[="..."]] [--description[="..."]]

Options:
 --user         The name of the user/process that triggered this deployment
 --revision     A revision number (e.g., git commit SHA)
 --changelog    A list of changes for this deployment
 --description  Text annotation for the deployment — notes for you

The bundle provide a Capifony recipe to automate the deployment notifications (see Resources/recipes/newrelic.rb).

It makes one request per app_name, due roll-up names are not supported by Data REST API.

Interactor services

The config keyekino_new_relic.interactor will accept a service ID to a service implementing NewRelicInteractorInterface. This bundle comes with a few services that may be suitable for you.

Configuration value	Description
Ekino\NewRelicBundle\NewRelic\AdaptiveInteractor	This is the default interactor. It will check once per request if the NewRelic PHP extension is installed or not. It is a decorator for the NewRelicInteractor
Ekino\NewRelicBundle\NewRelic\NewRelicInteractor	This interactor communicates with NewRelic. It is the one decorator that actually does some work.
Ekino\NewRelicBundle\NewRelic\BlackholeInteractor	This interactor does nothing.
auto	This value will check if the NewRelic PHP extension is installed when you build your container.

Note that if you set ekino_new_relic.enabled: false you will always use the BlackholeInteractor no matter what value used for ekino_new_relic.interactor.

Flow of the Request

1. A request comes in and the first thing we do is to setApplicationName so that we use the correct license key and name.
2. The RouterListener might throw a 404 or add routing values to the request.
3. If no 404 was thrown we setIgnoreTransaction which means that we call NewRelicInteractorInterface::ignoreTransaction() if we have configured to ignore the route.
4. The Firewall is the next interesting thing that will happen. It could change the controller or throw a 403.
5. The developer might have configured many more request listeners that will now execute and possibly add stuff to the request.
6. We will execute setTransactionName to use our TransactionNamingStrategyInterface to set a nice name.

All 6 steps will be executed for a normal request. Exceptions to this is 404 and 403 responses that will be created in step 2 and step 4 respectively. If an exception to these step occurs (I'm not talking about \Exception) you will have the transaction logged with the correct license key but you do not have the proper transaction name. The setTransactionName may have dependencies on data set by other listeners that is why it has such low priority.

ekinonewrelicbundle's Issues

Seperate app name for console

I'd like to split the CLI operations into a seperate NR app. I'd need an option to name the app differently if the app is ran as a console command.

Would you merge such PR?

[RFC] Integration with monolog

Monolog provides an handler to report logged errors to NewRelic which is from my experience more usefull than log_exceptions. But is not easily configurable (log level, disable when extension is not loaded, ...)

What's about providing an "shortcut" in this bundle to simplify this configuration?

• provides a new config parameter log_logs (i'm not sure about the name....)
• customize log level and log channel
• check if Monolog is installed
• inject the well configured handler in monolog
• check if the extension is loaded (could also wrap the handler in a class who check it at runtime)

ekino_new_relic:
  log_logs: (treat like canBeEnabled)
    channel: ~ (default null, when null, meaning injected into `monolog.logger`
    level: !php/const \Monolog\Logger::ERROR

If you like the idea, I'm going to implement it.

Some requests are not caught by the bundle

I run my Symfony application behind a reverse proxy server (Varnish). I use both ESI and hinclude. I got two New Relic license keys one for my Wordpress application (AAA) which I defined in php.ini and one for the Symfony applicaiton (BBB) which I defined in the bundle config.

When I look at the AAA account in New Relic I find lots of Symfony requests. Both main requests and ESI requests. Both cachable requests and non-cachable requests.

I can't figure out why the RequestListener::onCoreRequest isn't called or why it is not setting the application and transaction name as it should .

My config looks as follows:

#new relic
ekino_new_relic:
    application_name: %new_relic_name%
    enabled: %new_relic_enabled%
    transaction_naming: service
    instrument: true
    transaction_naming_service: new_relic.transaction_naming_strategy
    api_key: %api_key%
    log_exceptions: true

I'm using version 1.2.2.

Version 1.2

Maybe it's already worth a version 1.2? I prefer release-early even with minor changes 😄 However, last release is 4 months ago.

Handle fatal errors in console

Looks like from code, this bundle doesn't properly handle fatal errors in the console commands... It would be nice add support of it

Ignored routes and urls are not ignored

In RequestListener, both ignoreRoutes and ignoreUrls variables are not used

Getting fatal error if newrelic extension is not loaded

If for some reason the newrelic extension is not loaded, using the bundle causes fatal errors and kills the process running it:

Fatal error: Call to undefined function Ekino\Bundle\NewRelicBundle\NewRelic\newrelic_set_appname() in /someproject/vendor/ekino/newrelic-bundle/Ekino/Bundle/NewRelicBundle/NewRelic/NewRelicInteractor.php on line 21

The solution is to make sure the extension is loaded and also to make sure the function exists before calling it.

Bump new version

Hi, are there any plans to bump a new version, as there are number of changes towards PHP 7.
appreciated

Log an error event?

I am trying to log an error using EkinoNewRelic Bundle. Is this functionality implemented?

newrelic_notice_error ('error message');

If yes, could you point me to the place where it does, and I will update the wiki to give one example

Bundle does not only report exceptions, no error reporting

Hi,

I am using your bundle on Elastic Beanstalk.

It works fine and everything. But it just seems to log exceptions. Is there any possibility to log errors as well? I mean errors like the ones I log with Monlog into the prod.log ?

I am just curious: Is this a problem of elastic beanstalk or is it something I can configure within this bundle?

Split up services.xml

Right now we load everything by default and then remove services in the bundle's extension.

One could use multiple files for service declaration and then load ie twig.xml if the twig config is enabled. Any thoughts?

There is no real pros or cons, but it may make our extension class cleaner.

Unrecognized options "enabled" under "ekino_new_relic"

I think that you have an outdated README.md because as stated in that file there should be an enabled option but this is not defined in your Ekino\Bundle\NewRelicBundle\DependencyInjection\Configuration class. So, if users follow actual documentation they will get:

[Symfony\Component\Config\Definition\Exception\InvalidConfigurationException]
Unrecognized options "enabled" under "ekino_new_relic"

Bye.

SonataBlockBunde and SonataAdminBundle integration

I have very little knowledge of these bundles. Could someone give their opinion if we still need that integration. I see that we support version ^2.2 but 3.0 was released quite some time ago.

Pinging @soullivaneuh and @OskarStark. Does this integration make sense to have here?

Does not listen to Console Commands Exceptions?

When an exception is thrown in a Console Command, it doesn't seem be triggering the ExceptionListener onKernelException?

Does this bundle support logging of exceptions in console commands to new relic? As it doesn't seem to be working for me.

Feature request: Support for app/console

I would like the bundle to track my console commands as well. It seams like it only works for the http requests atm.

OutOfMemoryException Issues

I am occasionally seeing this error from this bundle's ResponseListener:

Uncaught PHP Exception Symfony\Component\Debug\Exception\OutOfMemoryException: "Error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 17538363 bytes)" at /somepath/.../vendor/ekino/newrelic-bundle/Ekino/Bundle/NewRelicBundle/Listener/ResponseListener.php line 86

It would seem that with lengthy HTML pages, preg_replace is not very memory efficient and causes this exception.

I know that I can simply increase the PHP memory limit per request to address this, but this shouldn't be necessary.

Are there any ideas on how we can address this with a more efficient solution than parsing the HTML response each time? Using a Twig extension perhaps as an alternate approach?

Can't turn off new relic without recompiling the container

When you have the bundle active in an application and you turn new relic off, you get exceptions:
Attempted to call function "newrelic_name_transaction" from namespace "Ekino\Bundle\NewRelicBundle\NewRelic".

I believe that all calls to actual new relic functions should be wrapped by a delegator that can check whether or not new relic is active when it's initialized.

Allow modification of the Exception reported to New Relic

Atm we always send the Exception received, except when it's a 404. The issue with this is that, if there is a wrapper exception (for instance, twig) it reduces visibility of the actual issue.

I'd propose that a listener is called before calling the interactor, which would allow us to modify the exception being thrown.

I'm proposing a listener so the user is able to customize it in any way they want.

EkinoNewRelicBundle vs NewRelic php agent

I'm curious, what exactly does this bundle offer over the regular Newrelic php agent? This isn't clear from the documentation.

Order of newrelic api calls

We have just been tracking an issue with newrelic where many of our transactions were being tracked against app.php instead of the route name.

Newrelic's advice was to ensure we always call new relic_set_appname() before any other calls.

I switched the order of the setTransactionName and setApplicationName in Ekino\Bundle\NewRelicBundle\Listener\RequestListener::onCoreRequest() and we now have consistent reporting against route names.

i.e.:
$this->interactor->setTransactionName($route ?: 'symfony unknow route');
$this->interactor->setApplicationName($this->newRelic->getName());

becomes:

$this->interactor->setApplicationName($this->newRelic->getName());
$this->interactor->setTransactionName($route ?: 'symfony unknow route');

Any chance of incorporating this in the next release?

Transaction/Browser metrics stopped reporting after deploying the bundle

Hi,

Transaction/Browser metrics has stopped when I've deployed this bundle.

Here's my configuration :

ekino_new_relic:
    application_name: myappname
    api_key: ...
    license_key: ...
    xmit: false                           
    logging: false                       
    instrument: false                    
    log_exceptions: true                 
    log_commands: true                   
    using_symfony_cache: true           
    transaction_naming: route          

We do use Symfony AppCache for our front end.

The application name is set both in php.ini and in the bundle configuration (so it maybe related to this issue #24).

But if I don't need to set the name of the application in the bundle configuration to prevent data loss, isn't that conflicting with the documentation :
Symfony http cache: If true is required to set the application_name.

ping @magnusnordlander @rande @fabian

Enable StyleCI

That would be great with some forced code style

Using deprecated features - Symfony 2.7.3

DEPRECATED - The Twig_Function_Method class is deprecated since version 1.12 and will be removed in 2.0. Use Twig_SimpleFunction instead.
DEPRECATED - The Twig_Function class is deprecated since version 1.12 and will be removed in 2.0. Use Twig_SimpleFunction instead.
DEPRECATED - Using an instance of "Twig_Function_Method" for function "ekino_newrelic_browser_timing_header" is deprecated. Use Twig_SimpleFunction instead.
DEPRECATED - Using an instance of "Twig_Function_Method" for function "ekino_newrelic_browser_timing_footer" is deprecated. Use Twig_SimpleFunction instead.

documentation missing

what settings should i leave in /etc/php.d/newrelic.ini?
should i set appname, RUM in newrelic.ini, in Symfony config.yml, or in both?

Metrics appears twice

Since some days (I guess) every metric is recorded twice: One as "Custom" and one as "Action". I have no control over the server, so I cannot tell which versions are installed there (if that helps), but I have the feeling, that has something to do with newrelics own Symfony2 support. Any idea?

Update: I think I've found the reason. With xmit enabled it disappears. It seems, that it saves the initial part as Action and after that the "normal" part as Custom metric.

Using newrelic_set_appname discards metrics

Upon reading the New Relic PHP API docs I stumbled upon the following:

The xmit flag is new in version 3.1 of the agent. Usually, when you change an
application name, the agent simply discards the current transaction and does not
send any of the accumulated metrics to the daemon. However, if you want to record
the metric and transaction data up to the point at which you called this function, you
can specify a value of true for this argument to make the agent send the transaction
to the daemon. This has a very slight performance impact as it takes a few
milliseconds for the agent to dump its data. By default this parameter is false.

(source)

If my reading is correct, because newrelic_set_appname is called relatively late we're discarding a bunch of useful metrics regarding framework performance, and bundle initialization performance.

Because we can now disable app naming, this is somewhat mitigated, but I consider this to be somewhat of a problem, and I think we should discuss possible solutions.

The way I see it (and interpret the docs) we have a few options:

1. Remove the ability to set the app name
2. Set the app name earlier (possibly in the bundle boot method?)
3. Use the xmit parameter
4. Document the behavior and do nothing about it

Now, options 1 and 4 comes with the obvious caveats.

Option number 2 is of course problematic because the earliest point we can hook in that I can come up with is Bundle::boot(), but that is sketchy at best because we'd still have to encourage users to keep this bundle very high in the bundle order, and even then we're missing a potentially useful metrics.

If I interpret the docs correctly, option number 3 causes two transactions per request, one with the default app name, containing metrics up to the point where we call newrelic_set_appname, and one containing the data we collect today. Now, one could make the argument that collecting the data (even if the collection is flawed) is better than not collecting the data, but I'm not sure. Splitting transactions would make working with New Relic a worse experience.

What does everyone else think? I'm not at all sure, but I'm leaning towards option 1, because if we can't do it well, we shouldn't do it at all.

App.php in Web transaction metrics

After using this bundle I started getting the route names in new relic instead of app.php, which is very good and what I intended. However, I still see metrics of app.php in new relic and I am not sure how to interpret them or if they are caused by a problem. These metrics are not marginal, they are over 40%.

Detect whether new relic extension is loaded

Hi,

I am thinking in using your bundle in my app. The thing is that I run it in evnironments that have not new relic installed. It would be good if your bundle didn't call the new relic api if the new relic php extension wasn't installed, like

if (extension_loaded('newrelic')) {
  new_relic...
}

I would make a pull request.

Bundle is not compatible with symfony 2.0

NotifyDeploymentCommand has constructor with required parameter:

public function __construct(NewRelic $newrelic)
{
        $this->newrelic = $newrelic;

        parent::__construct();
}

and atleast symfony 2.0 (i only tested with 2.0 and 2.3) is not compatible (fatal error happens) because of how symfony2.0 automatically register commands:

    if ($r->isSubclassOf('Symfony\\Component\\Console\\Command\\Command') && !$r->isAbstract()) {
                $application->add($r->newInstance());
            }

and this is how symfony 2.3 registers commands:

if ($r->isSubclassOf('Symfony\\Component\\Console\\Command\\Command') && !$r->isAbstract() && !$r->getConstructor()->getNumberOfRequiredParameters()) {
$application->add($r->newInstance());
}

You can see that it checks if constructor has required parameters and in case it has - it doesn't register command automatically.

possible solution:
make command extend ContainerAwareCommand class and get NewRelic instance directly from container instead of injecting.

Incorrect Console Event being used to set Input Options/Arguments as Custom Parameters

The code which sets the New Relic Custom parameters when a symfony2 console command is executed is tapping into the onConsoleCommand event to do so.

At this stage --> https://github.com/ekino/EkinoNewRelicBundle/blob/master/Listener/CommandListener.php#L60 Symfony2 has not yet converted the console input into Options / Arguments, so in all circumstances, $input->getOptions() and $input->getArguments() will return an empty result and will never loop.

The correct event to tap into would be the Console Terminate event which takes places after the Command has been executed. Perhaps we can move this code logic into this separate event?

The bug was introduced in this commit 403816a

@gido Did you happen to face this issue or fix it in your local copy?

Notify deployment nodes

Is it really required to notify NewRelic on each node in a cluster?

I have around 20 nodes and see same number of events at NewRelic screen, what is a little bit annoyed and makes all charts pretty ugly.

It would be better to execute task once, on primary node, eg. :roles => :app, :only => { :primary => true }

v1.1.* + Use BlackholeInteractor with LoggingInteractorDecorator without using newrelic extensions => don't log!

Hello,

In development environment, I didn't install newrelic extension and my project is based on Symfony 2.1, so I'm using v1.1.0 version of EkinoNewRelicBundle.

I'm using LoggingInteractorDecorator to check the good implementation of Newrelic on my environment and I'm using BlackholeInteractor (so it won't fail when calling newrelic methods).

But it doesn't work because EkinoNewRelicBundle disable its own listener here: https://github.com/ekino/EkinoNewRelicBundle/blob/1.1.0/DependencyInjection/Compiler/NewRelicCompilerPass.php#L33.

I would like to propose a fix on 1.1.0 branch, but you don't have a such branch 1.1. Could you create it or help me to find a solution to by-pass it?

Thanks for your help,

Olivier V.

Use Application Name from php.ini if not set in config file

In my opinion, it could be cleaner to maintain the license key, application name, etc in the PHP ini file instead of the symfony config file. (especially when having multiple nodes).

But I've noticed some parts of the Bundle will fail to function appropriately unless the 'name' property in the NewRelic class is set to something other than null. (for example the application name used during deployment).

Perhaps we should set the name of the application in the NewRelic class to the value from PHP ini if its not set in the symfony config file? We should still skip the setApplicationName(..) calls on the interactor, but not leave the application name empty in NewRelic.

Alternatively, we could just put a logic in the Deployment command where if the New Relic application name is not set, it should read it from the PHP ini file and use that instead?

What are your thoughts?

[feature] Monolog bridge for easy error reporting

I've just come across this article: Using Monolog for PHP error reporting on New Relic and in my opinion providing a bridge between Monolog and New Relic could be useful.

Just to summarize, the service mentioned in the post:

• declares and uses a new Monolog handler (with fallback)
• uses internally the function newrelic_notice_error() for error reporting

NB: I should need to investigate more the "New Relics logs", but so far I understood that there's only the possibility to write some error messages, through the function newrelic_notice_error()

So, for example some features could be:

1. report an error directly in New Relic using nothing more than Monolog using a dedicated handler
2. provide a request listener for reporting an error to New Relic catching on every Symfony Exception
3. set an alert in New Relic (possible?) to catch this error

Make a new tag

Great work you guys who have contributed to this bundle the last couple of weeks!
I would like to request for a new tag. I would like to have stable dependencies in my composer.json.

Tag version

You havent comitted for a while now, so maybe it is worth a tag to allow installations, that don't want to rely on dev-master-depdencies.

PHP agent (4.2.5.26) Now Supports Symfony

Their official support looks less robust than what you fine people have built in this module. Any thoughts on using the updated agent with this bundle?

Moving forward

Symfony 4 is out and we do not support it yet. @ChristianVermeulen opened PR #129 which removes Silex support and breaks BC. I added support for multiple interactors in #134 where I found out that this bundle is real old. =)

Last release was almost 6 months ago.
Question: Should we drop support for SF<3.4 and PHP <7.1?

It would not give us much more new features but this is a good place to remove all our legacy code.

Fix errorq

I fix documentation and response to execute.

/Unknown Symfony route when using render_hinclude

Hi there,

When using {{ render_hinclude( controller('Bundle:Stuff:Action') ) }} the bundle stores the request route as from "/Unknown Symfony route", it would be great if we could do something about it :)

Thanks !

Fix errors

I fix composer suggest, the documenation, new relic extension and iframe attributes

422 in newrelic:notify-deployment

I can't seem to get around an HTTP 422 (Unprocessable Entity) when running the notify-deployment command.

• config

ekino_new_relic:
    enabled: "%newrelic_reporting_enabled%"
    application_name: "%newrelic_application_name%"
    api_key: "%newrelic_api_key%"
    license_key: "%newrelic_license_key%"
    xmit: false
    logging: false
    instrument: false
    log_exceptions: true
    log_commands: true
    using_symfony_cache: true
    transaction_naming: route
    transaction_naming_service: ~
    ignored_routes: []
    ignored_paths: []
    ignored_commands: []

All of the parameters are defined in parameters.yml correctly.

• bin/console about

-------------------- ---------------------------------------------- 
  Symfony                                                            
 -------------------- ---------------------------------------------- 
  Version              3.3.5                                         
  End of maintenance   01/2018                                       
  End of life          07/2018                                       
 -------------------- ---------------------------------------------- 
  Kernel                                                             
 -------------------- ---------------------------------------------- 
  Type                 AppKernel                                     
  Name                 app                                           
  Environment          dev                                           
  Debug                true                                          
  Charset              UTF-8                                         
  Root directory       ./app                                         
  Cache directory      ./var/cache/dev (970 KiB)                     
  Log directory        ./var/logs (28.0 MiB)                         
 -------------------- ---------------------------------------------- 
  PHP                                                                
 -------------------- ---------------------------------------------- 
  Version              7.1.8-2+ubuntu16.04.1+deb.sury.org+4          
  Architecture         64 bits                                       
  Intl locale          en_US                                         
  Timezone             America/New_York (2017-08-22T13:16:19-04:00)  
  OPcache              true                                          
  APCu                 false                                         
  Xdebug               true                                          
 -------------------- ----------------------------------------------

• terminal output

$ php bin/console newrelic:notify-deployment
Deployment not recorded to 'dev_myapp': Received HTTP status 422
13:37:24 ERROR     [console] Command "newrelic:notify-deployment" exited with code "3" ["command" => "newrelic:notify-deployment","code" => 3] []

Any suggestions on how to further troubleshoot or resolve this?

Enabling use_symfony_cache causes misreporting of http response codes

I've spent a considerable period of time tracking this down, and at this stage I'm not sure if its a problem with this bundle, or the new relic agent itself.

However, when I enable use_symfony_cache in the configuration (we do use it), the httpResponseCode we see in New Relic is always set to 200, even though we see 400s being served.

It seems to be related to calling newrelic_end_transaction() - if I stop this from being called then it reports correctly.

This may be related to #57.

Add integration with newrelic_ignore_apdex

As it says on the tin. We'd like to use this bundle but our primary requirement is to tell NR not to include certain transactions in the apdex score.

NewRelic JS appended in header leads IE9 to ignore X-UA-Compatible meta tag

In our Symfony2 application we're encountering problems with the automated appending of newrelic_get_browser_timing_header() right after the opening <head> in IE9. We're using <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> and since any JS or CSS before this meta tag declares the document as "finalized", this tag gets ignored by IE because of said automated appending, which causes the browser to render the page faulty.

As far as I can see in the code, the JS is appended to the already rendered response with some Regex in an EventListener. A possible workaround would be to turn off the automated appending and manually add the stuff in the Twig template. This works for now, but imho a cleaner solution inside this bundle would be more preferable.

I see two different approaches:

1. Write a Twig extension in this bundle to append the JS where the developer wants it to be appended
2. Tweak the regex so it takes this meta tag into account

If there isn't already a solution for this problem, that is not this hacky workaround, I'd be happy to contribute a PR as soon as we found a good solution that fits.

Performance issue

Hello,

we update our new relic bundle to last release(1.3.2) from 1.2.3, right after that our application avg page load increased about 75 percent, after downgrade it went immediately down(original values).
Anyone has a experience with issue like that?

Make event listeners priority configurable

It would be nice to be able configure what priority the event listeners have. Ie, I have a use case when I want have very high priority on the exception listener.

The FOSRestBundle catches all exceptions and does not let our event listener to execute.

Transaction naming does not work?

We are running lots op Symfony 2 websites, all transmitting data via the PHP agent. The server is running the latest version of the New Relic agent.

Now, since the agent was upgraded we get the route name as the transaction name. But we use a controller with a single route that matches slugs in the database (CMS system) so all "pages" are logged as _slug. This negates a lot of the handy performance information for us.

So I use this bundle to set the transaction name to the URL of the page with a custom naming strategy

class UrlTransactionNamingStrategy implements TransactionNamingStrategyInterface {

    public function getTransactionName(Request $request)
    {
        return $request->getPathInfo();
    }
}

The logs mentions "Setting New Relic Transaction name to /en/media-and-news/press-releases" so i can only assume it runs newrelic_name_transaction. These uri do not appear in NewRelic, i keep getting _slug

Does anyone else have this issue? Is the Agent overriding them somehow?

Version bump

I'd like to know what is the criteria to decide to do release a new version, and when is the next one estimated to be released :)

Confusion over usage of bundle over official PHP agent

This is more of a question than an issue -

New Relic had announced official support for sf2 - http://blog.newrelic.com/2013/11/18/new-relic-php-agent-now-supports-symfony-2/

Is this bundle something to be used now in addition to the above? Is there any possibility of conflict between the two?

What is the separation of concerns between the two?