cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Shook (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-9168) Allow single-shot tracing on an active node
Date Fri, 10 Apr 2015 17:57:13 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-9168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jonathan Shook updated CASSANDRA-9168:
--------------------------------------
    Description: 
It would be useful to be able to ask a node for a single trace, or possibly even a few, without
having to use traceprobability.  This might allow more users to benefit from the clarity that
tracing can provide without having to worry about accidentally setting the probability too
high or leaving it on too long.

This would be a simple JMX operation representing a single request for a trace, with everything
else working as settraceprobability does presently.
Optionally, an argument could be provided which represents a request for N traces, with a
default minimum interval between them of 5.0 seconds. If a second parameter were provided,
it would work as an override to the minimum interval in fractional seconds.

Another form of the command would allow a user to specify a specific keyspace and table to
trace. While this might add overhead, it could be implemented in such a way that the overhead
is almost non-existent except when there are traces queued, and minimal even then.

Ideally a user would be able to collect information on traces collected in this way. This
could be implemented in the trace logic as a simple list of sessions which were flagged for
tracing by the triggering logic. If this data were available via JMX, then nodetool as well
as other operational tools would be able to provide an interactive mode of studying traces,
even on an active system.

While it may still be possible to submit an unreasonable trace request to a system under load,
this form would be much less ominous for casual use on active systems.


  was:
It would be useful to be able to ask a node for a single trace, or possibly even a few, without
having to use traceprobability.  This might allow more users to benefit from the clarity that
tracing can provide without having to worry about accidentally setting the probability too
high or leaving it on too long.

This would be a simple JMX operation representing a single request for a trace, with everything
else working as settraceprobability does presently.
Optionally, an argument could be provided which represents a request for N traces, with a
default minimum interval between them of 5.0 seconds. If a second parameter were provided,
it would work as an override to the minimum interval in floating point seconds.

Another form of the command would allow a user to specify a specific keyspace and table to
trace. While this might add overhead, it could be implemented in such a way that the overhead
is almost non-existent except when there are traces queued, and minimal even then.

Ideally a user would be able to collect information on traces collected in this way. This
could be implemented in the trace logic as a simple list of sessions which were flagged for
tracing by the triggering logic. If this data were available via JMX, then nodetool as well
as other operational tools would be able to provide an interactive mode of studying traces,
even on an active system.

While it may still be possible to submit an unreasonable trace request to a system under load,
this form would be much less ominous for casual use on active systems.



> Allow single-shot tracing on an active node
> -------------------------------------------
>
>                 Key: CASSANDRA-9168
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9168
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Shook
>            Priority: Minor
>
> It would be useful to be able to ask a node for a single trace, or possibly even a few,
without having to use traceprobability.  This might allow more users to benefit from the clarity
that tracing can provide without having to worry about accidentally setting the probability
too high or leaving it on too long.
> This would be a simple JMX operation representing a single request for a trace, with
everything else working as settraceprobability does presently.
> Optionally, an argument could be provided which represents a request for N traces, with
a default minimum interval between them of 5.0 seconds. If a second parameter were provided,
it would work as an override to the minimum interval in fractional seconds.
> Another form of the command would allow a user to specify a specific keyspace and table
to trace. While this might add overhead, it could be implemented in such a way that the overhead
is almost non-existent except when there are traces queued, and minimal even then.
> Ideally a user would be able to collect information on traces collected in this way.
This could be implemented in the trace logic as a simple list of sessions which were flagged
for tracing by the triggering logic. If this data were available via JMX, then nodetool as
well as other operational tools would be able to provide an interactive mode of studying traces,
even on an active system.
> While it may still be possible to submit an unreasonable trace request to a system under
load, this form would be much less ominous for casual use on active systems.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message