Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-39126

Collect browser logs and publish via support-core

XMLWordPrintable

      To enable better tracing of errors in blueocean, client side web console errors need to be collected and reported, via the server, to the support core plugin.

      In scope:

      • Trap all js errors on the client side
      • Publish errors to server side endpoint (jenkins under /blue/rest)
      • Server endpoint /errors to collect all error messages
      • A support core "Component" to publish client side logs/data to their own file as needed (similar to browser.md now)
      • Capture additional information (like headers/response payloads) for failures and publish them to server side endpoint

      Nice to have scope:

      • Client side component may not need be blueocean generic - if possible make it work with classic
      • Server side collection point may best live outside of blueocean if possible
      • support-core component may actually be able to be contributed to the support core plugin itself, meaning that there is no blueocean specific code in all this

      The support core plugin to report on things: https://wiki.jenkins-ci.org/display/JENKINS/Support+Core+Plugin

      Background and research so far
      Some interesting reading: http://openmymind.net/2012/4/4/You-Really-Should-Log-Client-Side-Error/
      On reading what is out there for this, it really is quite simple. window.onerror now contains santised stacktraces as well as the error (if they help) so there is no real need for libraries. Many pay for services out there (rollbar is used for the dogfood instance, as an example) but this is probably best done without libs.

      onerror now has stacktraces:
      http://stackoverflow.com/questions/17687410/when-will-proper-stack-traces-be-provided-on-window-onerror-function

          [JENKINS-39126] Collect browser logs and publish via support-core

          Michael Neale added a comment - - edited

          NOTE: split this into server/client components if it makes sense for implementation

          There may be different errors we want to trap depending on the context: eg general unhandled errors, but also error reponses returned to fetch could be treated differently

          Michael Neale added a comment - - edited NOTE: split this into server/client components if it makes sense for implementation There may be different errors we want to trap depending on the context: eg general unhandled errors, but also error reponses returned to fetch could be treated differently

          Keith Zantow added a comment -

          A few notes Ivan, Cliff, and I had about this, from the UI perspective:

          • Collect logs in memory, potentially using some amount of local storage
          • Flush periodically in a background thread
          • We need an easy JS utility API to offer channels and levels of logging
          • If an error happens we might report more logs back to provide more context
          • Things like SSE/connectivity errors, check the logs if there is a pending SSE error already and don't re-report the error

          Keith Zantow added a comment - A few notes Ivan, Cliff, and I had about this, from the UI perspective: Collect logs in memory, potentially using some amount of local storage Flush periodically in a background thread We need an easy JS utility API to offer channels and levels of logging If an error happens we might report more logs back to provide more context Things like SSE/connectivity errors, check the logs if there is a pending SSE error already and don't re-report the error

          Michael Neale added a comment -

          har files have served well as a standard way to collect this and more information that helps diagnosis, along with support core. 

           

           

          Michael Neale added a comment - har files have served well as a standard way to collect this and more information that helps diagnosis, along with support core.     

            Unassigned Unassigned
            michaelneale Michael Neale
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: