Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-2593

Audit logs - Phase1: Forward existing audit logs to the standard container/pod logs

    Details

    • Type: Feature Request
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: System
    • Labels:
    • Story Points:
      2
    • Target Release:
    • Sprint:
      3scale 2019-06-03
    • 3scale PT Product Specs:
      Not Started
    • 3scale PT Docs:
      Not Started
    • 3scale PT Verified Product:
      Not Started
    • 3scale PT Product Update Ready:
      Not Started
    • 3scale PT Released In Saas:
      Not Started
    • 3Scale PT Tested upstream:
      Not Started

      Description

      For benefit of On Prem customers (and for Support to minimize use of Rails console for SaaS customers?): forward all existing application logs to the standard container/pod logs, so they can be queried with EFK, plus docs on how to do this. Users want the logs all in one place

      @hery says something like

      Openshift pod is multiple containers but when we deploy some of the logs are not forwarded to standard output. Some of our pods may not forward the outputs to the logs and they want to do it for all the logs. We need to verify that.
      Sidekiq, unicorn, tagging the logs, database, request queryID,....what else?
      Also what should we be logging?

      Dev notes

      Simple proposition

      For many models we store in the database some audits with the audited gem

      What we could do is to redirect a simple version of this information into the logs.
      We will output the minimal required information:

      • Type of the action (Create/Delete/Update)
      • Object type
      • ID of the object
      • Name of the fields changed and its value.
      • Date of action
      • Type of action (Creation, Update, Deletion)
      • ID of the user triggering the action if available (no user when triggered by a background job)
      • Role of the user triggering the action if available

      That will not solve the case when the event was unsuccessful. E.g. A user tried to create a service but an error occurred.
      Given that information, in the phase 2, the customer can use the API to have more details on the changed fields.

      Implementation idea


      We will iterate over this base, including later more events and stream information to the logs.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  amasferr amasferr
                  Developer:
                  Marcos Guiherme Cassolato de Oliveira
                  Tester:
                  Jakub Smolár
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  8 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: