Blackfire.io add-on fails to pass Varnish reverse proxy?

holtkamp commented 9 years ago

When using the Blackfire.io add-on, the following error-message is displayed by the Blackfire Companion Chrome extension as soon as I try to profile an URL that ends in .html, .js, .css, .txt, etc.

Are you authorized to profile this page? Probe not found, invalid signature or Varnish related issue. Troubleshooting?

Does the current CloudControl Varnish configuration allow the HTTP headers as suggested in the Blackfire documentation?

A simple info.php or other URLs that are skipped by Varnish are profiled without problem.

TooAngel commented 9 years ago

Our varnish configuration tries not to manipulate any headers. Does this happen for cached files or static files? Or does these files just end with .html but served by php? If these are just static files, they are served by apache and I would guess that blackfire only hooks into the php process.

havvg commented 9 years ago

Just a wild thought: maybe it's something with cloudcontrolled.com vs cloudcontrolapp.com?

TooAngel commented 9 years ago

Are there any news here?

If you have the problem with static files, are these delivered by apache, so that blackfire has no chance to set any specific headers?

holtkamp commented 9 years ago

Haven't used Blackfire.io for a while, the context is .php files. Will try to dive into this next week and report back.

holtkamp commented 8 years ago

Still encountering this issue, now also for .php files. It seems the probe is installed properly, but not configured completely.

How to reproduce Got a very basic deployment with blackfire.free add-on installed and the following composer.json:

{
    "require": {
        "php-64bit": "~5.6",
        "ext-blackfire": "*"
    }
}

Push and deploy succeed:

cctrlapp projectName/default push
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 717 bytes | 0 bytes/s, done.
Total 4 (delta 1), reused 0 (delta 0)

-----> Receiving push
-----> Found php version definition ~5.6
-----> Using php version php-5.6.15
Installing blackfire ...
-----> Packaging ext/blackfire 1.6.0 (for Zend module API version 20131226)...
     Done.
-----> Packaging bin/blackfire-agent 1.4.0...
     Done.
-----> Loading extension: blackfire
-----> Installing composer dependencies...
Loading composer repositories with package information
Installing dependencies (including require-dev)
Nothing to install or update
Writing lock file
Generating autoload files
-----> Building image
-----> Uploading image (50.3 MB)

To ssh://projectName@cloudcontrolled.com/repository.git
   ab91199..a176372  master -> master

When using Chrome with the Blackfire Companion addon installed, trying to profile a simple info.php page with only a echo phpinfo(); content results in:

Are you authorized to profile this page? Probe not found, invalid signature or Varnish related issue. Troubleshooting?

When looking at the output of phpinfo(), the Blackfire io section is:

Note that the blackfire.server_id and blackfire.server_token entries are empty. I suspect these settings have to be populated with the ones I see in the popup displayed when clicking the credentials link on the CloudControl dashboard => Blackfire addon.

The addon documentation states

When added, Blackfire automatically creates a user for the application and updates the addon configuration with its credentials.

It seems that last part does not work as expected/described?

pst commented 8 years ago

Does ist work using the .cloudcontrolapp.com subdomain? That one does not use Varnish. Even though I see no reason why Varnish would not preserve the Blackfire headers. If it's a problem with the fact that we do random distribution and do not provide backend stickiness then there is little we can do about this. So the question is, if it works with apps scaled to one container only but not on multiple containers. Or if the subdomain used makes any difference.

holtkamp commented 8 years ago

Just tried it at projectName.cloudcontrolapp.com/info.php, the error message changes, indicating even more that the probe is not configured/started properly.

Are you authorized to profile this page? Probe not found, invalid signature (HTTP 200). Troubleshooting?

So I added a file ```.buildpack/php/conf/blackfireIoExtension.ini with some content:

[BlackfireIo]
blackfire.log-level=4
blackfire.log_file=/srv/www/code/probe.log
blackfire.server_id = SERVER_ID_FROM_CLOUD_CONTROL_ADDON_CREDENTIALS
blackfire.server_token = SERVER_TOKEN_FROM_CLOUD_CONTROL_ADDON_CREDENTIALS

Problem remains and it seems no log file is written at projectName.cloudcontrolapp.com/probe.log

Can it be that the configuration of the blackfire probe broke when fixing the installation in https://github.com/cloudControl/buildpack-php/issues/26?

When I try to have a look using the shell, this is the result:

cctrlapp projectName/default run bash
Connecting...
Blackfire credentials available - extension enabled
Blackfire credentials available - extension enabled
[projectName/default]:~$ [2015-11-20T10:41:49Z] ERROR: Socket '/app/var/blackfire/run/agent.sock' already exists and a process is already listening on it. Aborting.
[2015-11-20T10:41:49Z] ERROR: Socket '/app/var/blackfire/run/agent.sock' already exists and a process is already listening on it. Aborting.

Do you guys have a working deployment using the add-on?

pst commented 8 years ago

I hope @Nicofuma who built the integration can shed some light onto this?

TooAngel commented 8 years ago

I used a test deployment for fixing the php version issue: http://phpblackf.cloudcontrolled.com/ The blackfire server_id & server_token seem fine. I will also have a look at the issue as soon as possible, not sure if I'm able to do that today.

holtkamp commented 8 years ago

@Nicofuma, can you confirm this is on your radar?

holtkamp commented 8 years ago

Ok, gave it another shot after seeing some activity in this repository and made some progress on a test deployment that uses HTTP Basic Authentication. To be able to inspect the probe.log file directly at url.ext/probe.log I used this .buildpack/php/conf/blackfire.ini file:

[Blackfire]
blackfire.log_level=4
blackfire.log_file=/app/code/probe.log

Note that in my previous attempt there was a typo in the log_level entry....

This now results in:

Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 456 bytes | 0 bytes/s, done.
Total 6 (delta 2), reused 0 (delta 0)

-----> Receiving push
-----> Found php version definition ~5.6
-----> Using php version php-5.6.15
Installing blackfire ...
-----> Packaging ext/blackfire 1.7.0 (for Zend module API version 20131226)...
     Done.
-----> Packaging bin/blackfire-agent 1.4.0...
     Done.
-----> Loading extension: blackfire
-----> Installing composer dependencies...
Loading composer repositories with package information
Installing dependencies (including require-dev)
Nothing to install or update
Writing lock file
Generating autoload files
-----> Building image
-----> Uploading image (50.3 MB)

The phpinfo() shows the credentials section properly populated.

Closing issue, still got some problems when using .htaccess based enforcing of https:// instead of http://, but that is out of the scope of this issue. Thanks all!

holtkamp commented 8 years ago

Small note, it seems not possible to influence the log level of the probe, this changes nothing, while the log file entry CAN be influenced:

[Blackfire]
blackfire.log_level=4

When removing the extension and refreshing the phpinfo() output a few times, the log_level IS changed to 4. Adding the extension again and refreshing causes it to be set to 1 again. I guess some settings are overwritten...

cloudControl / buildpack-php

Blackfire.io add-on fails to pass Varnish reverse proxy? #27