[
https://issues.apache.org/jira/browse/CALCITE-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15381413#comment-15381413
]
Josh Elser commented on CALCITE-1311:
-------------------------------------
bq. I'd like to see an argument made that this is the best/only place in the
architecture where this can be done.
Making such an argument is definitely difficult to do because actual
architectures can vary so wildly from group to group. Some hypothetical's to
outline this:
* Avatica is being used just as a front-end to a traditional database to limit
physical access to the database. In this case, the traditional database would
likely do a much better job at recording an audit log. Avatica providing this
functionality would be unnecessary and the databases' functionality should be
used instead.
* Consider the case where Calcite's JDBC driver is used inside of Avatica to
provide access to ElasticSearch, Druid, and a traditional database. Each of
these three backend systems *may* have their own audit logging functionality
built in (I actually don't know if ES and Druid have this -- let's assume they
do). The administrator could see the query that was run on each of these
systems by Calcite, but the original query that a user submitted to Avatica
would be lost. For example, if some query was extracting data from multiple
systems, it would be desirable to know what the user entered in addition to the
final query which was run on the backend.
Taking the 2nd example even further, what if Calcite applied some rules to the
user query which resulted in an incorrect query on the backend. It would be
desirable to know what the user-entered query was to be able to
investigate/reproduce the situation -- knowing only the final query that was
run on the "real database" system would insufficient.
* Building in this functionality to Avatica could also be used as a single
place to implement sending of these audit logs to external systems. It is
likely that not all databases have the ability to report audit logs to external
systems. Avatica could serve as a central place for implementations to these
various systems instead of having to implement them for any/every database.
In short, I'd agree with you that I don't think this feature would be
applicable or beneficial for all use cases, but I feel like there are scenarios
where it would provide some worth. Similar to the recent authentication work,
we should not only inform users about the feature, but when it's appropriate to
use the feature too. WDYT?
> Add high-level record of interactions with the avatica server
> -------------------------------------------------------------
>
> Key: CALCITE-1311
> URL: https://issues.apache.org/jira/browse/CALCITE-1311
> Project: Calcite
> Issue Type: New Feature
> Components: avatica
> Reporter: Josh Elser
>
> It would be nice to have the ability to configure the Avatica server to
> create what is equivalent to an "audit log".
> This functionality would provide administrators the ability to inspect what
> queries were run and the user (client address and optionally the Kerberos
> identity).
> It would be nice to implement this as a framework and provide an initial
> "sink" binding which just writes to a file. This would let us push these logs
> to other systems automatically which would be nice.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
