生産ログには、Symfony\Component\Debug\Exception\FatalErrorExceptionのようないくつかの例外があります。私たちにはエラーがあり、修正するつもりですが、私が気になるのは、それらが「デバッグ」クラスだということです。本番環境でSymfony Component Debug Exception FatalErrorException例外が発生するのは正常ですか？
私たちは "prod"環境で動作していますが、 "debug"の例外はありますか？それとも、何かを間違って構成しましたか？
例外は、デバッグログが有効になっている場合とは異なります。
基本的にサービスはcontainerで利用できます。実行されるコードに関する重要な情報をいつでも追加することができます。環境ごとに異なるロギング構成を持つことが賢明でしょう。たとえば、prod環境では404エラーをログに記録する必要はありませんが、test環境でログに記録する必要がありますか？ config_prod.ymlで除外することができます。参照：http://symfony.com/doc/current/cookbook/logging/monolog_regex_based_excludes.html
実際のログとは別に、特定のしきい値に達すると、monologはメールを送信できます。 prodにはaction_level: criticalと、testにはaction_level: errorでさらに多くのメールを受け取ることができます。 levelを設定すると、電子メールにログメッセージを含める最小レベルを設定できます。ロギングに関するhttp://symfony.com/doc/current/cookbook/logging/monolog_email.html
その他のレシピはで見つけることができます参照してください。debugパラメータとExceptionに戻って取得するにはhttp://symfony.com/doc/current/cookbook/logging/index.html
、symfonyは有効になってデバッグで動作が異なります。ほとんどの標準アプリケーションでは、Webツールバーとプロファイラが有効になり、例外がスローされると、Symfonyは例外ページを表示します。基本的には、より多くのデータがdebugに収集されます。デバッグが無効になっている場合は、loggerはそのまま残ります。例外は、未知のアプリケーションの動作（read：バグ）の結果であるため、常に発生する可能性があります。私はこれらの例外をデバッグするのに十分な情報を含む電子メールを得るためにロガーを賢明に使用することをお勧めします。
'app.php'の行を確認してください。 '$ kernel = new AppKernel（ 'prod'、false）;' 2番目の引数はデバッグステータスです。 – DevDonkey
@DevDonkeyカーネルは本当にdebugが 'false'で作成されています。あなたはこれが「正常」ではないことを確認しますか？ （つまり、例外クラスは使用しないでください） –
私たちの生産ログ（Sym 2.8.3）を見ると、FatalThrowableExceptionの呼び出しもあります。コアコードを見てみると、 'Symfony \ Component \ Debug'名前空間にあるロギングシステムの一部のように見えます。個人的には、あなたは大丈夫だと言いたい。 – DevDonkey