[
https://issues.apache.org/jira/browse/PHOENIX-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16423427#comment-16423427
]
Ankit Singhal commented on PHOENIX-2715:
----------------------------------------
bq. my query is being ignored,
[~apurtell], I have already answered your query in the previous
[comment|https://issues.apache.org/jira/browse/PHOENIX-2715?focusedCommentId=16422079&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16422079].
I recommended marking binding parameters logging with TRACE so it will be
logged only when TRACE is enabled. Let me know if it addresses your issue.
{code}
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.
{code}
But still, an admin has to take care the permission on SYSTEM.LOG considering
the type of information is getting logged in the table(like giving WRITE
permission to all but keep READ permission to himself) as PII information might
also be available in other parameters like a scan and explain output of the
query which might be defined at a different logging level.
These logging levels are client-side configuration and if a user has a WRITE
permission on LOG table, they will be able to log anything they want, are you
looking for server-side configuration to control this?
> 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)
