[
https://issues.apache.org/jira/browse/PHOENIX-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16422079#comment-16422079
]
Ankit Singhal commented on PHOENIX-2715:
----------------------------------------
bq. Wondering if we want this to be INFO, or even OFF, by default. Not sure..
I think we can keep it OFF as sometimes a client will not have access to
SYSTEM.LOG and they don't want to see there logs getting flood with such
exceptions. User can enable it when they really need to debug their own queries
and Admin can make it ON on PQS server(for audit or any other need) where it
makes more sense as all client queries will be logged.
bq. Wondering if this should be DEBUG. I would guess that, in most cases, we
can understand the intent of a query without the parameters being explicitly
present?
bq. Is it possible to set a flag or a configuration variable so bind parameter
logging can be left out?
We can mark it with LogLevel.TRACE so that it will be logged if TRACE is
enabled.
> Query Log
> ---------
>
> Key: PHOENIX-2715
> URL: https://issues.apache.org/jira/browse/PHOENIX-2715
> Project: Phoenix
> Issue Type: New Feature
> Reporter: Nick Dimiduk
> Assignee: Ankit Singhal
> Priority: Major
> Attachments: PHOENIX-2715.patch, PHOENIX-2715_master.patch
>
>
> One useful feature of other database systems is the query log. It allows the
> DBA to review the queries run, who's run them, time taken, &c. This serves
> both as an audit and also as a source of "ground truth" for performance
> optimization. For instance, which columns should be indexed. It may also
> serve as the foundation for automated performance recommendations/actions.
> What queries are being run is the first piece. Have this data tied into
> tracing results and perhaps client-side metrics (PHOENIX-1819) becomes very
> useful.
> This might take the form of clients writing data to a new system table, but
> other implementation suggestions are welcome.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
