Skip to content

[FrameworkBundle] Add configuration for profiler log channels #23247

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

maff
Copy link
Contributor

@maff maff commented Jun 21, 2017

Q A
Branch? 3.4 or master
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets
License MIT
Doc PR

In larger projects, the amount of logs stored in the profiler can grow quickly and the web profiler takes quite some time to render the logs screen when having hundreds of event and db log entries. This PR adds a configuration entry to exclude/include certain log channels from the profiler. The format follows the channels configuration entry from the monolog bundle:

framework:
    profiler:
        log_channels: ["!event", "!doctrine"]

# more verbose
framework:
    profiler:
        log_channels:
            channels: ["!event", "!doctrine"]

# or profile only certain channels
framework:
    profiler:
        log_channels:
            channels: ["event", "doctrine"]

I'll be happy to add a doc PR if this is accepted.

@maff maff force-pushed the profiler-log-channels branch from 4a10c2c to fc4e108 Compare June 21, 2017 11:01
@xabbuh xabbuh added this to the 3.4 milestone Jun 21, 2017
@nicolas-grekas
Copy link
Member

Adding configuration is always adding complexity for the end user. If we can do otherwise (including doing nothing), i think that might be better. I all depends on the current "brokenness" status.

@@ -40,6 +56,17 @@ public function __invoke(array $record)
return $record;
}

private function isFiltered(array $record)
{
if ($this->channelsExclusive && !in_array($record['channel'], $this->channels)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

         if ($this->channelsExclusive && !in_array($record['channel'], $this->channels, true)) {
             return false;
         }
 
         return in_array($record['channel'], $this->channels, true);
     }

}
}

if (!count($channels)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (!$channels) {
}

@fabpot
Copy link
Member

fabpot commented Aug 23, 2017

I agree with @nicolas-grekas. What about truncating the logs when there are too important instead?

fabpot added a commit that referenced this pull request Sep 27, 2017
This PR was squashed before being merged into the 3.3 branch (closes #24244).

Discussion
----------

TwigBundle exception/deprecation tweaks

| Q             | A
| ------------- | ---
| Branch?       | 3.3
| Bug fix?      | yes
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes/no
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!--highly recommended for new features-->

- 1st commit) if you view a exception in the profiler, there is no logger available. Making the tab useless, disabled state is now triggered at zero log messages. There's a specialized panel here.
- 2nd commit) when an exception occurs this highlights deprecations in the log table outside the profiler with a warning status. This follows the same signal colors in the profiler.
- 3rd commit) hide the default inactive tabs from CSS to avoid scrollbar flickering.
- 4th commit) favors document.DOMContentLoaded over window.load, we dont want to wait for images to be loaded

Further out-of-scope improvements could be;

- From #24191; i think the logs table should show a direct `View file` link for every error/deprecation/red or yellow line in here. Traversing with `Show context` is tedious.
  - links to file.php for your trigger_error() calls
  - links to config.yml for trigger_error() calls by SF
- From #24151; having the same tooling on both sides is nice
- Events/Translations logs is noise, we have specialized panels for those. To further reduce the overall page size container logs can be moved away too, linked from Configuration and/or Logs. Also see #23247

Commits
-------

1c595fc [TwigBundle][WebProfilerBundle] Switch to DOMContentLoaded event
ea4b096 [WebProfilerBundle] Hide inactive tabs from CSS
0c10f97 [TwigBundle] Make deprecations scream in logs
03cd9e5 [TwigBundle] Hide logs if unavailable, i.e. webprofiler
@nicolas-grekas
Copy link
Member

Moving to 4.1. Rebase on master might be needed, where PHP 7.1 features can be used btw.

@nicolas-grekas nicolas-grekas modified the milestones: 3.4, 4.1 Oct 8, 2017
@maff
Copy link
Contributor Author

maff commented Oct 9, 2017

Sorry, I missed this conversation somehow. Regarding "brokenness": it really depends on the project, but we've seen issues with large profiler data and profiler not being able to load when lots of events and/or doctrine queries are logged during a request. At that time the profiler still popped up the alert window which really made it a problem, now with the toolbar just showing an error it's way better.
For me it's also fine to not include this change as long as I can override this on a project level when really needed (e.g. by decorating the DebugProcessor).

Regarding truncating: could work as well, but I don't really have an idea how to decide what and when to truncate.

ostrolucky pushed a commit to ostrolucky/symfony that referenced this pull request Mar 25, 2018
This PR was squashed before being merged into the 3.3 branch (closes symfony#24244).

Discussion
----------

TwigBundle exception/deprecation tweaks

| Q             | A
| ------------- | ---
| Branch?       | 3.3
| Bug fix?      | yes
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes/no
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!--highly recommended for new features-->

- 1st commit) if you view a exception in the profiler, there is no logger available. Making the tab useless, disabled state is now triggered at zero log messages. There's a specialized panel here.
- 2nd commit) when an exception occurs this highlights deprecations in the log table outside the profiler with a warning status. This follows the same signal colors in the profiler.
- 3rd commit) hide the default inactive tabs from CSS to avoid scrollbar flickering.
- 4th commit) favors document.DOMContentLoaded over window.load, we dont want to wait for images to be loaded

Further out-of-scope improvements could be;

- From symfony#24191; i think the logs table should show a direct `View file` link for every error/deprecation/red or yellow line in here. Traversing with `Show context` is tedious.
  - links to file.php for your trigger_error() calls
  - links to config.yml for trigger_error() calls by SF
- From symfony#24151; having the same tooling on both sides is nice
- Events/Translations logs is noise, we have specialized panels for those. To further reduce the overall page size container logs can be moved away too, linked from Configuration and/or Logs. Also see symfony#23247

Commits
-------

1c595fc [TwigBundle][WebProfilerBundle] Switch to DOMContentLoaded event
ea4b096 [WebProfilerBundle] Hide inactive tabs from CSS
0c10f97 [TwigBundle] Make deprecations scream in logs
03cd9e5 [TwigBundle] Hide logs if unavailable, i.e. webprofiler
@nicolas-grekas nicolas-grekas modified the milestones: 4.1, next Apr 20, 2018
fabpot added a commit that referenced this pull request Oct 10, 2018
This PR was submitted for the 3.4 branch but it was merged into the 4.2-dev branch instead (closes #24263).

Discussion
----------

Filter logs by level

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!--highly recommended for new features-->

Proposal to filter logs by level. This PR competes with #23247 (but also see #23038) which propose to filter by channel.

<details>
<summary>Before</summary>

![image](https://user-images.githubusercontent.com/1047696/30607022-00536bbe-9d74-11e7-84dd-6427d328f50b.png)

</details>

<details>
<summary>After</summary>

![image](https://user-images.githubusercontent.com/1047696/31036405-6346da12-a56c-11e7-8747-b1ae89c549f2.png)

</details>

From #23247 (comment)

> Adding configuration is always adding complexity for the end user. If we can do otherwise (including doing nothing), i think that might be better. I all depends on the current "brokenness" status.

This avoids that. Also single click; noise gone.

Commits
-------

8f88753 Filter logs by level
@stof
Copy link
Member

stof commented Apr 7, 2019

Decorating the debug.log_processor service is already possible if the project actually needs to filter logs to avoid storing them in the profiler:

class FilteredDebugProcessor implements DebugLoggerInterface
{
    private $innerProcessor;

    public function __construct(DebugLogProcessor $processor)
    {
        $this->innerProcessor = $processor;
    }


    public function __invoke(array $record)
    {
        if (/* condition to exclude*/) {
            return $record;
        }

        return $this->innerProcessor->__invoke($record);
    }

    /**
     * {@inheritdoc}
     */
    public function getLogs(Request $request = null)
    {
        return $this->innerProcessor->getLogs($request);
    }

    /**
     * {@inheritdoc}
     */
    public function countErrors(Request $request = null)
    {
        return $this->innerProcessor->countErrors($request);
    }

    /**
     * {@inheritdoc}
     */
    public function clear()
    {
        $this->innerProcessor->clear();
    }
}
services:
    filtered_debug_processor:
        class: FilteredDebugProcessor
        arguments: filtered_debug_processor.inner
        decorates: debug.log_processor

@stof
Copy link
Member

stof commented Apr 7, 2019

I'm closing this PR, as I don't think that this additional complexity is needed in the core (and @fabpot and @nicolas-grekas already said the same a long time ago).

@stof stof closed this Apr 7, 2019
@nicolas-grekas nicolas-grekas modified the milestones: next, 4.3 Apr 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants