Uploaded image for project: 'IGB'
  1. IGB
  2. IGBF-1072

Implement new remote service for asynchronous error logging

    Details

    • Type: New Feature
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Story Points:
      4
    • Sprint:
      Sprint 32

      Description

      We have a nice opportunity to take advantage of OSGi remote services to remotely log (http://wiki.osgi.org/wiki/Remote_Service_Admin) errors occurring in the wild. The IGB application would be the consumer of our remote logging error service and would append error logs in an asynchronous way to avoid any impact on application performance.

      This new service could potentially radically change our ability to learn about and patch bugs. If integrated into our existing ELK stack infrastructure, we could get "real time" visibility into the errors occurring int he application.

      We could also use these logs to notify APP developers when errors are occurring in their apps.

        Attachments

          Activity

          dcnorris David Norris (Inactive) created issue -
          dcnorris David Norris (Inactive) made changes -
          Field Original Value New Value
          Rank Ranked higher
          dcnorris David Norris (Inactive) made changes -
          Description We have a nice opportunity to take advantage of OSGi remote services to remotely log errors occurring in the wild. The IGB application would be the consumer of our remote logging error service and would append error logs in an asynchronous way to avoid any impact on application performance.

          This new service could potentially radically change our ability to learn about and patch bugs. If integrated into our existing ELK stack infrastructure, we could get "real time" visibility into the errors occurring int he application.
          We have a nice opportunity to take advantage of OSGi remote services to remotely log errors occurring in the wild. The IGB application would be the consumer of our remote logging error service and would append error logs in an asynchronous way to avoid any impact on application performance.

          This new service could potentially radically change our ability to learn about and patch bugs. If integrated into our existing ELK stack infrastructure, we could get "real time" visibility into the errors occurring int he application.

          We could also use these logs to notify APP developers when errors are occurring in their apps.
          dcnorris David Norris (Inactive) made changes -
          Description We have a nice opportunity to take advantage of OSGi remote services to remotely log errors occurring in the wild. The IGB application would be the consumer of our remote logging error service and would append error logs in an asynchronous way to avoid any impact on application performance.

          This new service could potentially radically change our ability to learn about and patch bugs. If integrated into our existing ELK stack infrastructure, we could get "real time" visibility into the errors occurring int he application.

          We could also use these logs to notify APP developers when errors are occurring in their apps.
          We have a nice opportunity to take advantage of OSGi remote services to remotely log (http://wiki.osgi.org/wiki/Remote_Service_Admin) errors occurring in the wild. The IGB application would be the consumer of our remote logging error service and would append error logs in an asynchronous way to avoid any impact on application performance.

          This new service could potentially radically change our ability to learn about and patch bugs. If integrated into our existing ELK stack infrastructure, we could get "real time" visibility into the errors occurring int he application.

          We could also use these logs to notify APP developers when errors are occurring in their apps.
          dcnorris David Norris (Inactive) made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          dcnorris David Norris (Inactive) made changes -
          Status In Progress [ 3 ] Needs Testing [ 10002 ]
          dcnorris David Norris (Inactive) made changes -
          Sprint Sprint 31 [ 39 ]
          dcnorris David Norris (Inactive) made changes -
          Sprint Sprint 32 [ 40 ]
          dcnorris David Norris (Inactive) made changes -
          Rank Ranked higher
          mason Mason Meyer (Inactive) made changes -
          Rank Ranked lower
          mason Mason Meyer (Inactive) made changes -
          Status Needs Testing [ 10002 ] Testing In Progress [ 10003 ]
          mason Mason Meyer (Inactive) made changes -
          Assignee David Norris [ dcnorris ] Mason Meyer [ mason ]
          mason Mason Meyer (Inactive) made changes -
          Resolution Done [ 10000 ]
          Status Testing In Progress [ 10003 ] Closed [ 6 ]
          ann.loraine Ann Loraine made changes -
          Workflow Loraine Lab Workflow [ 16941 ] Fall 2019 Workflow Update [ 19751 ]
          ann.loraine Ann Loraine made changes -
          Workflow Fall 2019 Workflow Update [ 19751 ] Revised Fall 2019 Workflow Update [ 21870 ]

            People

            • Assignee:
              mason Mason Meyer (Inactive)
              Reporter:
              dcnorris David Norris (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: