I think this is an observability related idea which is still rather new to
many companies who are just finally embracing DevOps in the first place. I
love the idea though!
On Mon, Jun 11, 2018 at 10:32, Ralph Goers <ralph.go...@dslextreme.com>
wrote:
> Really? I would think almost everything would want to track who made what
> change to the system.
>
> Ralph
>
> > On Jun 11, 2018, at 5:20 AM, Matt Sicker <boa...@gmail.com> wrote:
> >
> > Ok, thanks for the clarification. It sounded far more advanced, and I’m
> > getting a better picture here. I’ve never worked in a domain that
> requires
> > auditing before.
> >
> > On Mon, Jun 11, 2018 at 08:03, Apache <ralph.go...@dslextreme.com>
> wrote:
> >
> >> No. It implements that feature through the request context but I
> wouldn’t
> >> use a catalog for simple trace logging.
> >>
> >> Ralph
> >>
> >>> On Jun 11, 2018, at 4:29 AM, Matt Sicker <boa...@gmail.com> wrote:
> >>>
> >>> One thing I didn’t notice until now is that this is a superset of
> >>> distributed trace logging. Would you say that’s accurate?
> >>>
> >>>> On Mon, Jun 11, 2018 at 00:54, Apache <ralph.go...@dslextreme.com>
> >> wrote:
> >>>>
> >>>> One thing I forgot to mention. Although Log4J audit doesn’t make use
> of
> >>>> the product or category the catalog’s usefulness really comes into
> play
> >>>> when you want to create a UI to query and display the audit events. In
> >> that
> >>>> case associating events with products and/or categories can be quite
> >>>> helpful.
> >>>>
> >>>> Ralph
> >>>>
> >>>>> On Jun 10, 2018, at 1:36 AM, Apache <ralph.go...@dslextreme.com>
> >> wrote:
> >>>>>
> >>>>> Oh. You don’t have the maven plugin. Since it hasn’t been released
> yet
> >>>> you will have to build the Log4J audit project.
> >>>>>
> >>>>> Sent from my iPad
> >>>>>
> >>>>>> On Jun 10, 2018, at 12:23 AM, Remko Popma <remko.po...@gmail.com>
> >>>> wrote:
> >>>>>>
> >>>>>> That is with
> >>>>>> C:\Users\remko\IdeaProjects\logging-log4j-audit-sample>mvn --version
> >>>>>> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> >>>>>> 2017-10-18T16:58:13+09:00)
> >>>>>> Maven home: C:\apps\apache-maven-3.5.2\bin\..
> >>>>>> Java version: 1.8.0_161, vendor: Oracle Corporation
> >>>>>> Java home: C:\apps\jdk1.8.0_161\jre
> >>>>>> Default locale: en_GB, platform encoding: MS932
> >>>>>> OS name: "windows 10", version: "10.0", arch: "amd64", family:
> >> "windows"
> >>>>>>
> >>>>>>
> >>>>>>> On Sun, Jun 10, 2018 at 4:21 PM, Remko Popma <
> remko.po...@gmail.com>
> >>>> wrote:
> >>>>>>>
> >>>>>>> getting this now
> >>>>>>>
> >>>>>>> [INFO] Reactor Summary:
> >>>>>>> [INFO]
> >>>>>>> [INFO] Audit Sample Parent ................................
> SUCCESS [
> >>>>>>> 0.839 s]
> >>>>>>> [INFO] audit-service-api ..................................
> FAILURE [
> >>>>>>> 0.006 s]
> >>>>>>> [INFO] audit-service-war .................................. SKIPPED
> >>>>>>> [INFO] audit-service ...................................... SKIPPED
> >>>>>>> [INFO] sample-app ......................................... SKIPPED
> >>>>>>> [INFO] ------------------------------------------------------------
> >>>>>>> ------------
> >>>>>>> [INFO] BUILD FAILURE
> >>>>>>> [INFO] ------------------------------------------------------------
> >>>>>>> ------------
> >>>>>>> [INFO] Total time: 1.116 s
> >>>>>>> [INFO] Finished at: 2018-06-10T16:11:08+09:00
> >>>>>>> [INFO] Final Memory: 12M/245M
> >>>>>>> [INFO] ------------------------------------------------------------
> >>>>>>> ------------
> >>>>>>> [ERROR] Plugin
> >>>> org.apache.logging.log4j:log4j-audit-maven-plugin:1.0.0-SNAPSHOT
> >>>>>>> or one of its dependencies could not be resolved: Could not find
> >>>> artifact
> >>>>>>>
> org.apache.logging.log4j:log4j-audit-maven-plugin:jar:1.0.0-SNAPSHOT
> >> ->
> >>>>>>> [Help 1]
> >>>>>>> [ERROR]
> >>>>>>>
> >>>>>>>
> >>>>>>> On Sun, Jun 10, 2018 at 2:53 PM, Ralph Goers <
> >>>> ralph.go...@dslextreme.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> I finally have had time to take a breath and do something with
> >> this. I
> >>>>>>>> have tried to incorporate many of your comments in the
> >> documentation.
> >>>> I
> >>>>>>>> have updated my web site accordingly. Some comments are below.
> >>>>>>>>
> >>>>>>>> I really would like feedback on more than just the site as I need
> to
> >>>>>>>> release this.
> >>>>>>>>
> >>>>>>>>> On May 7, 2018, at 5:42 PM, Remko Popma <remko.po...@gmail.com>
> >>>> wrote:
> >>>>>>>>>
> >>>>>>>>> I had time to look at this during the flight, here it is:
> >>>>>>>>>
> >>>>>>>>> ----
> >>>>>>>>> index.html
> >>>>>>>>>
> >>>>>>>>> typo: Diagnostic logs are critical in aiding in maintaining the
> >>>>>>>>> servicability -> critical in maintaining?
> >>>>>>>>>
> >>>>>>>>> Overall, the first three sections, "What is Audit Logging", What
> is
> >>>> the
> >>>>>>>>> difference between audit logging and normal logging?" and "What
> is
> >>>> Log4j
> >>>>>>>>> Audit?" are very good: give good overview of the purpose and
> don't
> >>>>>>>> assume
> >>>>>>>>> prior knowledge.
> >>>>>>>>>
> >>>>>>>>> From the "Features" section, the narrative changes perspective
> from
> >>>> what
> >>>>>>>>> users would want to what Log4j Audit provides.
> >>>>>>>>> I would add a few sentences to that transition, something like:
> >>>>>>>>>
> >>>>>>>>> {quote}
> >>>>>>>>> (after Features)
> >>>>>>>>> Each application has its own audit events. Before using Log4j
> >> Audit,
> >>>>>>>>> applications need to define AuditMessages that capture the exact
> >>>>>>>> attributes
> >>>>>>>>> of its audit events. The [Getting Started](link) page provides a
> >>>>>>>> tutorial
> >>>>>>>>> that explains how to define audit events for an application.
> >>>>>>>>>
> >>>>>>>>> (after Audit Event Catalog header)
> >>>>>>>>> Once audit events are defined, they need to be maintained: as the
> >>>>>>>>> application evolves, developers will inevitably discover they
> need
> >> to
> >>>>>>>> add,
> >>>>>>>>> remove or change attributes of the audit events. Log4j Audit can
> >>>> persist
> >>>>>>>>> the audit event definitions in a JSON file. This file becomes the
> >>>> Audit
> >>>>>>>>> Event Catalog for the application. Log4j Audit is designed to
> store
> >>>> the
> >>>>>>>>> event definition file in a Git repository so that the evolution
> of
> >>>> the
> >>>>>>>>> audit events themselves have an audit trail in the Git history of
> >> the
> >>>>>>>> file.
> >>>>>>>>> Log4j Audit provides a web interface for editing the events.
> >>>>>>>>>
> >>>>>>>>> Log4j Audit uses the catalog of events to determine ... (continue
> >>>> with
> >>>>>>>>> current text of Audit Event Catalog)
> >>>>>>>>> {quote}
> >>>>>>>>>
> >>>>>>>>> Question about the Requirements section: it isn't clear to me
> (and
> >>>>>>>> likely
> >>>>>>>>> to other readers) why Dynamic Event Catalogs would require a
> >> database
> >>>>>>>>> instead of one or more JSON files. Is that explained somewhere?
> >>>> Perhaps
> >>>>>>>>> Dynamic Audit Events need a separate page or dedicated section
> >>>>>>>> somewhere.
> >>>>>>>>> The Getting Started page mentions "manage dynamic catalogs" in
> the
> >>>>>>>>> paragraph under "What you will build" but I couldn't find
> anything
> >> on
> >>>>>>>> the
> >>>>>>>>> topic of dynamic catalogs.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ----
> >>>>>>>>> catalog.html
> >>>>>>>>>
> >>>>>>>>> From the first paragraph, I would remove "The events may be
> grouped
> >>>> by
> >>>>>>>>> Products and/or Categories, but at this time nothing in Log4j
> Audit
> >>>>>>>> makes
> >>>>>>>>> use of the product or catalog definitions". The same sentences is
> >>>>>>>> repeated
> >>>>>>>>> at the bottom of the page and since this feature is not used it
> is
> >>>>>>>>> confusing to me that the feature is so prominently mentioned in
> the
> >>>>>>>> first
> >>>>>>>>> paragraph of the page. I would consider removing this feature
> >>>>>>>> altogether.
> >>>>>>>>>
> >>>>>>>>> Overall this is a very good page. Succinct but complete. Consider
> >>>>>>>> moving it
> >>>>>>>>> above RequestContext in the left-hand navigation menu.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ----
> >>>>>>>>> gettingStarted.html
> >>>>>>>>>
> >>>>>>>>> Overall, this page is only effective for people who actually
> >> perform
> >>>> the
> >>>>>>>>> steps and execute the commands mentioned in the page.
> >>>>>>>>>
> >>>>>>>>> It would be good if the page would also be useful for people who
> >> only
> >>>>>>>> read
> >>>>>>>>> the page but don't actually perform the steps:
> >>>>>>>>>
> >>>>>>>>> * Can the page also show an example of an audit event in JSON
> >> format.
> >>>>>>>> This
> >>>>>>>>> could be a simple event with few attributes (maybe a login
> event?)
> >> or
> >>>>>>>> the
> >>>>>>>>> transfer event that is used later in the page.
> >>>>>>>>> * I would also like to see the Java interface that is generated
> >> from
> >>>>>>>> this
> >>>>>>>>> JSON audit event.
> >>>>>>>>> * Finally, I would like to see how my application would use this
> >>>>>>>> generated
> >>>>>>>>> Java interface. How do I get an instance, how do I populate the
> >>>>>>>> attributes,
> >>>>>>>>> and what do I do with the instance after I populated it?
> >>>>>>>>>
> >>>>>>>>> I'm sure the above is available in the source code of the sample
> >>>>>>>>> application, but this page is a good place to show some of the
> >>>>>>>> highlights
> >>>>>>>>> of that source code with some explanatory text.
> >>>>>>>>>
> >>>>>>>>> Secondly, the page mentions remote audit logging and how the war
> >> file
> >>>>>>>>> provides endpoints for remove audit logging. Is it worth
> >> dedicating a
> >>>>>>>>> separate page to show how to configure end points for remote
> audit
> >>>>>>>> logging?
> >>>>>>>>>
> >>>>>>>>> Finally, about the catalog screenshots: I understand that
> >> attributes
> >>>> are
> >>>>>>>>> managed separately so they can be reused. The second screenshot
> >> shows
> >>>>>>>> the
> >>>>>>>>> billPay and deposit events. Are these events related to the
> >> transfer
> >>>>>>>> event
> >>>>>>>>> that is mentioned in the curl example in this page?
> >>>>>>>>
> >>>>>>>> These are events that take place in banking. billPay is paying a
> >> bill,
> >>>>>>>> deposit is depositing money into an account, transfer moves money
> >>>> from one
> >>>>>>>> account to another. I used these because many people understand
> >> these
> >>>>>>>> concepts.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> I was trying to see how
> >>>>>>>>> they could be related but couldn't figure it out.
> >>>>>>>>> Also, what are the attributes for the billPay and deposit events?
> >>>>>>>>
> >>>>>>>> The attributes for these events are those shown in the “Assigned
> >>>>>>>> Attributes” column. The request context attributes are available
> for
> >>>> all
> >>>>>>>> events.
> >>>>>>>>
> >>>>>>>>> If the
> >>>>>>>>> Catalog Editor has a screen to show the attributes that are part
> of
> >>>> an
> >>>>>>>>> event then it may be good to add a screenshot for this (I guess
> >> this
> >>>>>>>> would
> >>>>>>>>> be the Edit Event screen) as well. That would tie all these
> >> concepts
> >>>>>>>>> together.
> >>>>>>>>
> >>>>>>>> As I said, the attributes are on the screen that is shown. I would
> >>>>>>>> suggest you perform the steps in the getting started so you can
> see
> >>>> for
> >>>>>>>> yourself.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ----
> >>>>>>>>> requestContext.html
> >>>>>>>>>
> >>>>>>>>> typo: typcial -> typical
> >>>>>>>>> typo: acrossall -> across all
> >>>>>>>>> typo: datbase -> database
> >>>>>>>>>
> >>>>>>>>> About Mapping Annotations:
> >>>>>>>>> This is still a bit abstract to me. Would it be possible to
> provide
> >>>> some
> >>>>>>>>> more explanation on when applications should use ClientServer,
> when
> >>>>>>>> Local,
> >>>>>>>>> and when Chained annotations? Perhaps some example use cases? Or,
> >> if
> >>>>>>>>> possible, tie this to the use case presented in the sample
> >>>> application
> >>>>>>>> (if
> >>>>>>>>> that makes sense)?
> >>>>>>>>
> >>>>>>>> I am not sure what more there is to say. Local means a value in
> the
> >>>>>>>> request context is local to that server and should not be passed
> to
> >>>> called
> >>>>>>>> services. ClientServer means that a value is passed from the
> current
> >>>>>>>> application to services it calls. Chained means the value is
> >>>> associated
> >>>>>>>> with one request context field on the current server but will be
> in
> >> a
> >>>>>>>> different field in the called service. The example for chained is
> >> the
> >>>>>>>> current hostname. The hostname request context field always
> contains
> >>>> the
> >>>>>>>> host name of the current server. When calling a service the
> current
> >>>> host
> >>>>>>>> name moves to the callingHost field so that the called service
> knows
> >>>> what
> >>>>>>>> server called it.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> About Transporting the RequestContext:
> >>>>>>>>> Until now, the information was generically useful for all
> >>>> applications,
> >>>>>>>> but
> >>>>>>>>> this section is specifically useful for web applications.
> >>>>>>>>> For people who don't work on web applications this transition may
> >> be
> >>>> a
> >>>>>>>> bit
> >>>>>>>>> jarring.
> >>>>>>>>> Would it make sense for this section and the following two
> sections
> >>>> to
> >>>>>>>> be
> >>>>>>>>> moved to a separate page? Something like "Web Applications" or
> >>>> "Remote
> >>>>>>>>> Audit Logging”?
> >>>>>>>>
> >>>>>>>> This concept applies to any kind of distributed application. For
> >>>> example,
> >>>>>>>> with AMQP we do the exact same thing by copying the RequestContext
> >>>> fields
> >>>>>>>> into AMQP headers and then repopulating the RequestContext when
> the
> >>>> message
> >>>>>>>> is processed in the consumer. I have added text to describe this.
> I
> >>>> have
> >>>>>>>> components that do this for my day job but I have not added them
> to
> >>>>>>>> log4j-audi.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ----
> >>>>>>>>> Remko
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>> Matt Sicker <boa...@gmail.com>
> >>
> >>
> >> --
> > Matt Sicker <boa...@gmail.com>
>
>
> --
Matt Sicker <boa...@gmail.com>
