Re: Expensive to run nodetool status often?

2017-01-26 Thread Xiaolei Li
Nice! Will take a look.

Best,
x.

On Thu, Jan 26, 2017 at 10:30 AM, Jonathan Haddad  wrote:

> Very cool!
>
> On Thu, Jan 26, 2017 at 8:53 AM Eric Evans 
> wrote:
>
>> On Wed, Jan 25, 2017 at 11:20 AM, Xiaolei Li 
>> wrote:
>> > Thanks for the advice!
>> >
>> > I do export a lot via JMX already. But I couldn't find the equivalent
>> of the
>> > Status column (Up/Down + Normal/Leaving/Joining/Moving) from the status
>> > output. Does anyone know if those are available via JMX?
>>
>> I've been working on this off and on for a while (adding things as I
>> have a need for them):
>>
>> https://github.com/eevans/creole
>>
>> The idea was to create a high-level, Cassandra-specific abstraction
>> for JMX.  Mostly it builds representations that are similar to what
>> nodetool provides, but outputs JSON, either on the command line where
>> it could be wrapped by a script, or via a REST interface.  There is no
>> exact equivalent to status just yet, but it would be pretty trivial to
>> add.  I'm happy to do that (give me a few days), or I'd gladly accept
>> a pull request.
>>
>> --
>> Eric Evans
>> john.eric.ev...@gmail.com
>>
>


Re: Expensive to run nodetool status often?

2017-01-26 Thread Jonathan Haddad
Very cool!

On Thu, Jan 26, 2017 at 8:53 AM Eric Evans 
wrote:

> On Wed, Jan 25, 2017 at 11:20 AM, Xiaolei Li 
> wrote:
> > Thanks for the advice!
> >
> > I do export a lot via JMX already. But I couldn't find the equivalent of
> the
> > Status column (Up/Down + Normal/Leaving/Joining/Moving) from the status
> > output. Does anyone know if those are available via JMX?
>
> I've been working on this off and on for a while (adding things as I
> have a need for them):
>
> https://github.com/eevans/creole
>
> The idea was to create a high-level, Cassandra-specific abstraction
> for JMX.  Mostly it builds representations that are similar to what
> nodetool provides, but outputs JSON, either on the command line where
> it could be wrapped by a script, or via a REST interface.  There is no
> exact equivalent to status just yet, but it would be pretty trivial to
> add.  I'm happy to do that (give me a few days), or I'd gladly accept
> a pull request.
>
> --
> Eric Evans
> john.eric.ev...@gmail.com
>


Re: Expensive to run nodetool status often?

2017-01-26 Thread Eric Evans
On Wed, Jan 25, 2017 at 11:20 AM, Xiaolei Li  wrote:
> Thanks for the advice!
>
> I do export a lot via JMX already. But I couldn't find the equivalent of the
> Status column (Up/Down + Normal/Leaving/Joining/Moving) from the status
> output. Does anyone know if those are available via JMX?

I've been working on this off and on for a while (adding things as I
have a need for them):

https://github.com/eevans/creole

The idea was to create a high-level, Cassandra-specific abstraction
for JMX.  Mostly it builds representations that are similar to what
nodetool provides, but outputs JSON, either on the command line where
it could be wrapped by a script, or via a REST interface.  There is no
exact equivalent to status just yet, but it would be pretty trivial to
add.  I'm happy to do that (give me a few days), or I'd gladly accept
a pull request.

-- 
Eric Evans
john.eric.ev...@gmail.com


Re: Expensive to run nodetool status often?

2017-01-25 Thread Brooke Jensen
Have a look in org.apache.cassandra.net:type=FailureDetector


*Brooke Jensen*
VP Technical Operations & Customer Services
www.instaclustr.com | support.instaclustr.com


This email has been sent on behalf of Instaclustr Limited (Australia) and
Instaclustr Inc (USA). This email and any attachments may contain
confidential and legally privileged information.  If you are not the
intended recipient, do not copy or disclose its content, but please reply
to this email immediately and highlight the error to the sender and then
immediately delete the message.

On 26 January 2017 at 04:20, Xiaolei Li  wrote:

> Thanks for the advice!
>
> I do export a lot via JMX already. But I couldn't find the equivalent of
> the Status column (Up/Down + Normal/Leaving/Joining/Moving) from the
> status output. Does anyone know if those are available via JMX?
>
> Thank you.
>
> Best,
> x.
>
> On Wed, Jan 25, 2017 at 8:15 AM, Jonathan Haddad 
> wrote:
>
>> You're about to walk down an unfortunate path.  I strongly recommend
>> getting the information you need for monitoring using JMX.  That's actually
>> how nodetool gets all it's information.  Instead of parsing output, if you
>>  use JMX, you'll have access to a *ton* of useful (and some not so useful)
>> information.
>>
>> If you aren't familiar, run Cassandra locally and type "jconsole" in your
>> terminal.  That'll bring up a decent GUI that you can use to browse all the
>> available metrics.
>>
>> You can export metrics a bunch of ways.  Jolokia, mx4j, jmx_exporter (for
>> prometheus), and I know there's a collectd plugin but I haven't used it,
>> might be worth checking out or maybe someone else can weigh in.
>>
>> Jon
>>
>> On Wed, Jan 25, 2017 at 7:48 AM Xiaolei Li  wrote:
>>
>>> I'm planning to run "nodetool status -r" on every node every minute,
>>> storing the output in a file, and aggregating it somewhere else for
>>> monitoring.
>>>
>>> Is that a good idea?  How expensive is it to be running status every
>>> minute.
>>>
>>> Best,
>>> x.
>>>
>>
>


Re: Expensive to run nodetool status often?

2017-01-25 Thread Xiaolei Li
Thanks for the advice!

I do export a lot via JMX already. But I couldn't find the equivalent of
the Status column (Up/Down + Normal/Leaving/Joining/Moving) from the status
output. Does anyone know if those are available via JMX?

Thank you.

Best,
x.

On Wed, Jan 25, 2017 at 8:15 AM, Jonathan Haddad  wrote:

> You're about to walk down an unfortunate path.  I strongly recommend
> getting the information you need for monitoring using JMX.  That's actually
> how nodetool gets all it's information.  Instead of parsing output, if you
>  use JMX, you'll have access to a *ton* of useful (and some not so useful)
> information.
>
> If you aren't familiar, run Cassandra locally and type "jconsole" in your
> terminal.  That'll bring up a decent GUI that you can use to browse all the
> available metrics.
>
> You can export metrics a bunch of ways.  Jolokia, mx4j, jmx_exporter (for
> prometheus), and I know there's a collectd plugin but I haven't used it,
> might be worth checking out or maybe someone else can weigh in.
>
> Jon
>
> On Wed, Jan 25, 2017 at 7:48 AM Xiaolei Li  wrote:
>
>> I'm planning to run "nodetool status -r" on every node every minute,
>> storing the output in a file, and aggregating it somewhere else for
>> monitoring.
>>
>> Is that a good idea?  How expensive is it to be running status every
>> minute.
>>
>> Best,
>> x.
>>
>


Re: Expensive to run nodetool status often?

2017-01-25 Thread Jonathan Haddad
You're about to walk down an unfortunate path.  I strongly recommend
getting the information you need for monitoring using JMX.  That's actually
how nodetool gets all it's information.  Instead of parsing output, if you
 use JMX, you'll have access to a *ton* of useful (and some not so useful)
information.

If you aren't familiar, run Cassandra locally and type "jconsole" in your
terminal.  That'll bring up a decent GUI that you can use to browse all the
available metrics.

You can export metrics a bunch of ways.  Jolokia, mx4j, jmx_exporter (for
prometheus), and I know there's a collectd plugin but I haven't used it,
might be worth checking out or maybe someone else can weigh in.

Jon

On Wed, Jan 25, 2017 at 7:48 AM Xiaolei Li  wrote:

> I'm planning to run "nodetool status -r" on every node every minute,
> storing the output in a file, and aggregating it somewhere else for
> monitoring.
>
> Is that a good idea?  How expensive is it to be running status every
> minute.
>
> Best,
> x.
>


Expensive to run nodetool status often?

2017-01-25 Thread Xiaolei Li
I'm planning to run "nodetool status -r" on every node every minute,
storing the output in a file, and aggregating it somewhere else for
monitoring.

Is that a good idea?  How expensive is it to be running status every minute.

Best,
x.