Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

Feedback Improve support for third party logging frameworks

Discussion in 'Editor & General Support' started by DrummerB, Jun 21, 2019.

  1. DrummerB

    DrummerB

    Joined:
    Dec 19, 2013
    Posts:
    139
    It's possible to integrate third-party logging frameworks into a Unity project. For the most part, this works quite nicely. There are basically two aspects to this:
    1. Set up the logging framework to forward logs to the Unity console, so that if you write CustomLog.Info("Something") it will appear on the Unity console, in addition to whatever other targets you define for the framework.
    2. Hook into existing Debug.Log calls, so that they are forwarded to the new logging framework. Even if you can convert all your own log calls to the new framework, it's probably better not to change third-party code (e.g. SteamVR plugin), since it will be difficult to update in future. You just have to implement the ILogHandler interface and assign an instance to Debug.unityLogger.

    Overall, this works quite nicely. But there are some issues within the Editor, when using your own log framework. Most of these are related to opening the correct line of code when double-clicking the logs in the Editor Console.

    Because the last couple of frames on the stack trace are going to be functions from the custom logging framework, Unity will jump to an irrelevant line within the framework, instead of the correct Log call further down in the stack. This problem can mostly be solved by wrapping the custom logging framework in a managed plugin DLL, because Unity seems to skip source files that are not in the project.

    Even if you wrap the logging into a plugin, the stack trace will still be spammed with irrelevant frames from the logging framework. For comparison, here is a nice and concise stack trace from a normal Debug.Log:



    And here is the same log with a custom logging framework:



    The entire highlighted part is noise. It doesn't matter if the stack trace type is set to Full or ScriptOnly. Unity considers the logging framework a script.

    It is possible to completely disable the built-in stack traces of Unity with Application.SetStackTraceLogType, and printing a custom filtered stack trace instead, e.g. by using StackTraceUtility.ExtractStackTrace. However, this breaks the go-to-line on double-click behavior again. I assume Unity doesn't parse the stack trace when double clicking and instead just remembers the location when generating the stack trace the first time and if the stack traces are disabled, this doesn't work.

    I think the most elegant solution would be to add an option to DLLs and assembly definitions to ignore them in the Console (stack trace + double click feature). This option would filter frames from these assemblies when Unity generates the stack trace for a log (the same it filters internal stuff in ScriptOnly mode). This may also fix the double click issue. All you would need to do to hook up a custom logging framework is to create a separate assembly definition for the glue code and mark it to be ignored in the Console.

    Alternatively, Unity could provide a callback for us to implement to filter the generated stack traces. Any frame that we discard should not be printed and not be used for the double click feature.

    An even more powerful solution would be a callback for the double click event. This would allow us to generate a custom stack trace, implement the default double click behavior or even add context-dependent actions.
     

    Attached Files:

    a436t4ataf likes this.
  2. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,629
  3. DrummerB

    DrummerB

    Joined:
    Dec 19, 2013
    Posts:
    139
    Good idea! If this can be implemented in an efficient way, this is probably the most elegant solution.

    I would probably call it [HideInStackTrace] or [HideInConsole] to be more consistent with [HideInInspector]
     
  4. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,629
    Good idea. Perhaps post the naming idea in the other thread, since Unity staff replied there already and is probably watching the thread too.
     
  5. SugoiDev

    SugoiDev

    Joined:
    Mar 27, 2013
    Posts:
    395
    Was this ever implemented or worked on?
    Did anything change, @benoitd_unity?

    Should we create a new thread in the alpha or beta forums?


    Previously, I was patching the StackTraceUtility.ExtractFormattedStackTrace method to have this functionality ad-hoc, but now the extracting of stacktraces is more involved and I can't patch it as before: StackTraceUtility.ExtractStackTrace will call Debug.ExtractStackTraceNoAlloc when possible instead of going through ExtractFormattedStackTrace only, and the Debug.ExtractStackTraceNoAlloc is extern, so I can't patch it.

    Even with my "lean" logging framework, I still have an extra 7 lines of noise for every Debug.Log call.
     
  6. RobinBGbanga

    RobinBGbanga

    Joined:
    Oct 20, 2014
    Posts:
    16
    Is this still being considered?

    We tried implementing our own
    ILogHandler
    implementation, but the only way to let that implementation then forward the processed logs seems to be forwarding them to Unity's default handler (

    Debug.unityLogger.logHandler
    ), which, in turn, appends our logger to the stacktrace.

    The biggest downside is that crash analytics platforms, such as Firebase Crashlytics, will then group all crashes under one entry of our own ILogHandler, making them impossible to use.
     
    DrummerB likes this.
  7. DrummerB

    DrummerB

    Joined:
    Dec 19, 2013
    Posts:
    139
    RobinBGbanga likes this.
  8. RobinBGbanga

    RobinBGbanga

    Joined:
    Oct 20, 2014
    Posts:
    16
    Thanks for the nudge! I've left an upvote on that roadmap item.
     
  9. claudiaantoun

    claudiaantoun

    Unity Technologies

    Joined:
    May 14, 2021
    Posts:
    22
    Good news! :) We've implemented a feature in the console window to exclude custom methods from the stack trace. There is a public [HideInCallstack] attribute that allows you to hide any method flagged with this attribute from the detail area of the console window. To enable this feature, simply click the Console [kebab] menu button, and select Strip logging callstack from the menu. It's important to note that this feature is available in the latest alpha version of 2022.2.
     
    karl_jones and SugoiDev like this.
  10. SugoiDev

    SugoiDev

    Joined:
    Mar 27, 2013
    Posts:
    395
    It is a nice feature, thanks for getting it out there!


    Sadly, there seems to be a bug around that might make this not work as expected for some users.
    I posted about this earlier but didn't have free time to submit a bug report yet.
     
  11. claudiaantoun

    claudiaantoun

    Unity Technologies

    Joined:
    May 14, 2021
    Posts:
    22
    Thanks @SugoiDev for testing out the feature! I'll definitely look into the bug.
     
    SugoiDev likes this.
  12. RobinBGbanga

    RobinBGbanga

    Joined:
    Oct 20, 2014
    Posts:
    16
    That's great news, thanks!

    A follow-up question: will these methods only be hidden from the visual console window, or also from the actual callstacks?

    Our concrete use-case is that we implemented a custom
    ILogHandler
    that unrolls inner exceptions the same as .Net (outermost first), rather than Unity's way (innermost first), but when the log handler forwards the processed stack to Unity's default log handler, that one always appends our custom log handler's method to the stack. Details in this thread. This has 2 downsides:
    1. noise in the console window (this would be solved by your new feature, awesome!)
    2. analytics services, such as Firebase Crashlytics, bundle all exceptions under the same node of our custom log handler
    It would be great if case 2 could also be covered by this feature.
    We're locked to 2021 LTS for our current project, but I'll give the 2022 alpha a shot separately as soon as I find the time!
     
    Last edited: Jun 3, 2022
  13. claudiaantoun

    claudiaantoun

    Unity Technologies

    Joined:
    May 14, 2021
    Posts:
    22
    Hi @RobinBGbanga, glad you like the new feature!

    The methods will solely be hidden from the visual console window and not the actual callstacks.

    For analytics tools like Firebase, it all depends on where in the Unity code the tool retrieves the callstacks. In any case, this would be a completely different feature than the one in the console window.
     
    RobinBGbanga likes this.
  14. SugoiDev

    SugoiDev

    Joined:
    Mar 27, 2013
    Posts:
    395
    Any chance this will be enhanced to actually filter out the final log file?
    The amount of noise in the log files is immense, even using a very lean logging framework.
    I previously used to patch Unity itself (in-memory) to accomplish this, and it was very nice to have clean, easy to follow logs. I mention this here: https://forum.unity.com/threads/imp...party-logging-frameworks.698942/#post-6518751
     
    RobinBGbanga likes this.
  15. claudiaantoun

    claudiaantoun

    Unity Technologies

    Joined:
    May 14, 2021
    Posts:
    22
    It is not in our plans but your request has been noted! :)
     
  16. SugoiDev

    SugoiDev

    Joined:
    Mar 27, 2013
    Posts:
    395
    If that ever comes, the console part would be "free", since the console itself would never see the actual, unfiltered log.
    The drawback is that there's no way to see this unfiltered log with a toggle. You would need to disable the filtering and trigger the initial log again to see it raw.
    Despite that, it was still worthy it for me and is sorely missed.
     
  17. RobinBGbanga

    RobinBGbanga

    Joined:
    Oct 20, 2014
    Posts:
    16
    I would love to see that, too! This would really help us a great deal.
     
  18. hugeandy

    hugeandy

    Joined:
    Nov 2, 2016
    Posts:
    135
    @claudiaantoun just discovered [HideInCallstack] and was hyped! It is great and tidies up our console, because of custom logging tools which add 5 stack frames.

    But, I was disappointed to see that it only removes the callstack lines from the detailed console view. Double clicking on a log entry still takes you to the line of code which generated the log. Double clicking on log entries is super helpful, but impossible for us because of the custom logging tool.

    Any plans to support double clicking ignoring HideInCallstack methods?

    It'd also be great if this attribute could be added to a class, which would ignore all methods in that class. This would avoid the need to add an attribute on every method in the class, as I want them all ignored :)

    Cheers!
     
  19. hugeandy

    hugeandy

    Joined:
    Nov 2, 2016
    Posts:
    135
    @claudiaantoun
    I have a feeling my mention in the previous post didn't work as expected, so I'm trying again!
     
  20. hugeandy

    hugeandy

    Joined:
    Nov 2, 2016
    Posts:
    135