datadog.conf
log_level: warn
log_file: /var/log/datadog/agent.log
log_to_syslog: no
dd_url: https://app.datadoghq.com
api_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
process_config:
enabled: "true"
logs_enabled: true
tags:
- env:stage
- nginx
- webserver
- frontend
- php-fpm
- php
use_dogstatsd: true
dogstatsd_port: 8125
I needed to enable flag logs_enabled: true in order to collect PHP logs but with this, I also collect Nginx logs (access and error logs)
If logs_enabled is set to false then I do not collect even PHP logs.
How can I exclude Nginx logs from being collected?
# php.d/conf.yaml
init_config:
instances:
logs:
- type: file
path: "/var/www/{{ env }}/var/log/app-log.json"
service: php
source: php
sourcecategory: sourcecode
The solution was very simple.
Data dog agent configuration is related to enabling/disabling collecting logs from a webserver.
In order to turn off/on specific service logging, it must be done from the DataDog webservice.
Visit the next URL https://app.datadoghq.com/logs/pipelines/indexes
And then add the exclusion rule.
Simple as that :)
Related
I got an error 500 on production env so I spent a lot of time to search where error was displaying. I found that symfony log errors using logger who send output to stderr by default so apache's error log is used in my case. I want to send messages to symfony's env.log (e.g var/log/dev.log and var/log/prod.log)
Documentation says :
The minimum log level, the default output and the log format can also be changed by passing the appropriate arguments to the constructor of Logger. To do so, override the "logger" service definition.
But I can't figure out how I can change logger's output, for testing purpose I changed logger construct in vendor/symfony/http-kernel/Log/Logger.php as following with success:
public function __construct(string $minLevel = null, $output = 'abspath/to/project/var/log/dev.log', callable $formatter = null)
but I can't edit files in vendor dir.
So How I can override the "logger" service definition ?
Do not edit the vendor files. Those are included by composer, and overwriten on each install/update.
If you want to change the log path you can do this with using monolog and config
composer require symfony/monolog-bundle
monolog:
handlers:
# this "file_log" key could be anything
file_log:
type: stream
# log to var/log/(environment).log
path: "%kernel.logs_dir%/%kernel.environment%.log" #change path here
# log *all* messages (debug is lowest level)
level: debug
syslog_handler:
type: syslog
# log error-level messages and higher
level: error
coming from Java development, I learned to appreciate LogLevel, how to set it in Logback or Log4j.
Monolog is used in my symphony 4.2 project.
I would like to see that from a certain controller/namespace the log entries with level info can also be seen in the production log file without all the other log entries with the info level filling the log file.
Unfortunately I didn't find any explanations.
After a little more research, I configured my monolog.yaml for dev and also prod this way
monolog:
channels: ['appinfo']
handlers:
custom:
channels: ['appinfo']
level: info
max_files: 30
path: "%kernel.logs_dir%/appinfo.log"
type: rotating_file
The important thing is the channel, appinfo in my case.
The handler, custom in my case, can be named any way you like.
Then in the services.yaml one has to define the "type" of the injected logger.
App\Controller\DefaultController:
arguments:
$logger: '#monolog.logger.appinfo'
This works with controllers as with services
Could you suggest how to print any debug data into browser console in Symfony 2?
Especially, is it possible to implement with Symfony VarDumper Component?
In Zend Framework you can use tool Zend_Log_Writer_Firebug to do so which is very helpful. Does Symfony has something like this from the box?
Monolog, the logger used by Symfony, has a built-in support for FirePHP and ChromePHP.
In Symfony Standard Edition you can configure monolog handlers in your application configuration.
FirePHP and ChromePHP handlers are even present in config_dev.yml, but are commented out:
monolog:
handlers:
main:
type: stream
path: "%kernel.logs_dir%/%kernel.environment%.log"
level: debug
channels: [!event]
console:
type: console
channels: [!event, !doctrine]
# uncomment to get logging in your browser
# you may have to allow bigger header sizes in your Web server configuration
#firephp:
# type: firephp
# level: info
#chromephp:
# type: chromephp
# level: info
All you need to do to see your logs in the browser is to uncomment the needed handler.
Currently, the VarDumper component doesn't support dumping anything to the browser's console. However, you can see the dumped values in the web debug toolbar (or in html if you don't use the toolbar).
I'm developing a website using Symfony2, and until today - had no problem logging in. But now when logging in I'm not correctly authenticated - Symfony profiler lists me as logged in as: anon instead of the user I logged in as. I'm also redirected back to the login page instead of the target path.
The login process consists of a traditional login form (i.e. username + password) with a submit button. All user credentials are stored in MySQL and I've setup a User entity as a provider.
There are no errors in my php errors log, or listed in the Symfony profiler under Exception or Logs.
One observation I've made is nothing is listed under the Session Attributes heading (within Symfony profiler > Request) - normally there would be some security context information listed after successfully logging in, but now it's always empty. I tried setting a basic session variable on the homepage which was partially successful as it gets set and is shown under Session Attributes, but get's cleared whenever attempting to login!
This is my security.yml file:
# app/config/security.yml
security:
encoders:
Woodcut\UserBundle\Entity\User: sha512
role_hierarchy:
ROLE_ADMIN: ROLE_USER
ROLE_SUPER_ADMIN: [ROLE_USER, ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH]
providers:
main:
entity: { class: Woodcut\UserBundle\Entity\User, property: username }
firewalls:
secured_area:
pattern: ^/
anonymous: ~
form_login:
login_path: login
check_path: login_check
username_parameter: _username
success_handler: custom_authentication_handler
failure_handler: custom_authentication_handler
#always_use_default_target_path: true
#default_target_path: /login_router
logout:
path: /logout
target: /
dev:
pattern: ^/(_(profiler|wdt)|css|images|js)/
security: false
access_control:
- { path: ^/admin, roles: ROLE_ADMIN }
- { path: ^/ratings/update, roles: ROLE_USER }
- { path: ^/ratings/new, roles: ROLE_USER }
- { path: ^/favourite, roles: ROLE_USER }
I'm using a typical LAMP stack to run my site with Symfony 2.3.13 and PHP 5.4.28 on a Ubuntu 12.04 Virtual machine. PHP is running as mod_php.
Output from Symfony Profiler > Debug:
INFO - Populated SecurityContext with an anonymous Token
DEBUG - Notified event "kernel.exception" to listener "Symfony\Component\Security\Http\Firewall \ExceptionListener::onKernelException".
DEBUG - Access is denied (user is not fully authenticated) by "/vagrant_www/vprojects/woodcut/vendor/symfony/symfony/src/Symfony/Component/Security/Http/Firewall/AccessListener.php" at line 70; redirecting to authentication entry point
DEBUG - Calling Authentication entry point
If someone can please help me determine why users are authenticated as anonymous instead of as themselves that would be great. Been pulling my hear out the last two days trying to find the cause.
Thanks in advance for any help provided!
Additional info: I have a VPS running a copy of the site (for client previewing). I dev on my local VM and git push my changes, I then SSH into my VPS and do a git pull to keep my two version in sync.
What's strange is the VPS version does not exhibit this issue (i.e. login works fine) yet both versions use an identical codebase except for some minor differences in their respective parameters.yml and parameters_dev.yml files.
Update: Problem started happening after making a large number of edits to the code base and performing a apt-get update and apt-get upgrade on my VM. So in an effort to isolate the possible cause I rolled back to an earlier commit - to see if the problem was code related. But despite rolling back to before my major coding changes, the problem is still there.
This has me thinking the cause may not be code related and instead could be server related, something in the new version of PHP (5.4.28) that was installed via apt-get upgrade perhaps OR a new php.ini directive maybe?
I've run the Symfony configuration checker tool and everything seems fine!
Weird.
I was struggling with the same problem. I checked almost everything and after that suspecion fell on session handler...
I have
session: ~
changed to:
session:
handler_id: ~
More about session handling:
http://symfony.com/doc/2.2/components/http_foundation/session_configuration.html#native-php-save-handlers
This problem happens when the PHPSESSID cookie is changing with each request.
If that is your case then you should check the PHPSESSID response cookies between these request, I bet you that they are changed. Why is that happening, that is the real question!
Let's assume for a moment that the above assertion is true.
By seeing this cookie changing all the time Symfony/PHP assumes that the session manager have created in fact a new user session, obviously that would require the user to re-authenticate (unless RememberMe=true which wouldn't cause a login page redirection).
For instance, while working in dev environment I had no problem with this session issue. However, as soon I switched to prod environment - and by this I mean (1) I flushed the --env=prod cache then (2) I loaded the production /app.php instead /app_dev.php page - it just started to redirect me to the login page after a successful authentication & request.
Obviously at first I thought that there is a configuration problem, perhaps I'm using a different set of params on these environments. But that wasn't the case. So there must be something else, but what?
I've checked the var/session/prod directory and I saw many sess_xxx files. The same in var/session/dev directory. Obviously that is not OK. So I removed the var/session/{prod,dev} entirely then I reloaded the /app.php page. This created 2-3 sess_xxx files in both environment, in prod but also in dev. That is not good. It is a sign that somehow something sends a request to the app_dev.php which will load the dev enviroment which might log out you automatically (based on your app's security/firewall configuration). I opened the app_dev.php and I added an exit(0) then suddenly everything started to work well. So that was what was happening, somehow these environments were mixed and a call to prod would eventually trigger a call to the dev which would log you out immediately.
For a quick fix some people just change the framework::session::save_path to /tmp, which is going to be shared by both environments and thus you are not going to be logged out although your app will somehow still send a request to both the app.php and app_dev.php but since they used the same session folder they think the session is the same (unchanged). So in general this is a quick fix as long the session path is the same for all environments. However this is not the solution to the problem!
One other fix is to not use the app_dev.php in the same time with app.php (or vice-versa) and by that I mean only one file/env at a time. That's also a quick fix and not the solution.
What I did, but I still don't understand what happened, was to remove entirely the web {assetic,css,js,fonts} (or bin/console assetic:dump --env=prod --no-debug) stuff and recreate them again with --env=prod --no-debug. That did the trick but I still don't understand how that could fix it.
I hope the steps above would help you to trace the cause of your problem better than I did :-)
I had the same issue as you.
While #plewandowski's answer solved my issue, the root cause was that the session.save_path as set in PHP's config was a directory with incorrect permissions.
As a sanity check, run
php -i | grep session. and then see if the permissions for the save_path are correct..
In my case, session.save_path => /var/lib/php/sessions => /var/lib/php/sessions
Checking the permissions
vagrant#vps:/var/www/site$ ls -lah /var/lib/php
total 16K
drwxr-xr-x 4 root root 4.0K Aug 5 18:01 .
drwxr-xr-x 56 root root 4.0K Aug 5 20:29 ..
drwxr-xr-x 6 root root 4.0K Aug 5 18:23 modules
drwx-wx-wt 2 root root 4.0K Jul 26 11:05 sessions
In this case, the user under which PHP runs (www) it could not access the directory and caused the issue.
Fixed with sudo chmod 1777 /var/lib/php/sessions/
In Symfony 4, I had this error.
In my entity I didn't have the username and password, just I have to add them.
/** #see \Serializable::serialize() */
public function serialize()
{
return serialize(array(
$this->userId,
$this->userUsername,
$this->userPassword
// see section on salt below
// $this->salt,
));
}
/** #see \Serializable::unserialize() */
public function unserialize($serialized)
{
list (
$this->userId,
$this->userUsername,
$this->userPassword
// see section on salt below
// $this->salt
) = unserialize($serialized, array('allowed_classes' => false));
}
How to disable profiler in Symfony2 in production?
I do not mean the toolbar - I mean the profiler.
I want to disable it in production, I use it extensively for development so the solution with removing its bundle is a no-go.
I have tried setting framework.profiler.only_exceptions to true. I have tried removing the framework.profiler section altogether. No matter what the profiler.db is growing after every request and every response contains x-debug-token header.
I have double-checked the config files (config.yml and config_prod.yml) and everything seems to be fined.
What's more the command app/console router:dump-apache --no-debug always dumps the _wdt and _profiler routes, but I don't have them in my routing_prod.yml and they don't seem to be present when trying to access them from the browser (404).
I'm running symfony 2.0 and I won't upgrade right now because of some major changes in 2.1 which would require a rewrite of many elements. It wouldn't be wise to start it just before initial deployment.
Symfony >= 2.2
As of Symfony 2.2 the profiler supports an enabled flag in the framework's configuration and is disabled by default in the test environment.
# app/config/config_test.yml
framework:
profiler:
enabled: false
See this Blog entry about Profiling by Fabien Potencier and the FrameworkBundle configuration reference for more details.
Update: This flag is still valid in Symfony 4.0.
Symfony <= 2.1
In Symfony <= 2.1 The profiler is disabled entirely if there's no framework.profilerkey in the configuration.
You can see this in the ProfilerPass of the Symfony2 FrameworkBundle configuration.
This is the case for the default config.yml and config_prod.yml (which includes the former). So if you didn't tinker with the default configurations you're fine.
In config_dev.yml however the default setting is:
framework:
profiler: { only_exceptions: false }
Which enables profiling for the dev environment and all enviroments that import config_dev.yml like config_test.yml.
If you want to unset the profiler value in a subsequent configuration use:
framework:
profiler: false
Values like {} or ~ won't unset the value. You have to use false.
Did you try this (enable only for development)
As the profiler adds some overhead, you might want to enable it only
under certain circumstances in the production environment. The
only-exceptions settings limits profiling to 500 pages, but what if
you want to get information when the client IP comes from a specific
address, or for a limited portion of the website? You can use a
request matcher:
framework:
profiler:
matcher: { ip: 192.168.0.0/24 }
http://symfony.com/doc/current/book/internals.html#profiler
or
the profiler can be disabled on a per-action basis by doing something like:
if(in_array($this->container->get('kernel')->getEnvironment(), array('prod'))) {
$this->container->get('profiler')->disable();
}
I figured it out, but still I'm not sure why the profiler settings didn't work. I did clear the cache with --no-debug after each change of the configuration.
Firstly I examined the Configuration of FrameworkBundle and found out that profiler conf node has canBeDisabled(). Then I checked what does it mean exactly.
It turns out that each canBeDisabled node has an implied child node enabled with default value set to true. You can either override it or set the parent node directly to false or null to disable the section. If you simply omit the profiler section then it is enabled by default.
Maybe I missed it in the docs, but I'm pretty sure it should be mentioned here. Also, in my opinion profiler should be disabled by default in production. I can't imagine a scenario when it would be beneficial to run profiler in production in the long run. I'll be happy if anybody proves me wrong.
BTW I noticed then as the profiler.db grows then each request becomes slower, but that may not be the case in prod.