We used to have monitoring scripts that parsed the output of nodetool (status, listsnapshots), but these tools have been replaced with using Jolokia (REST interface to JMX) — this is both more powerful and easier to parse for things like monitoring scripts. We *really* would have loved to have JSON output back when we were just starting out, though.
These days we only run nodetool manually by humans from a shell; so changes to the output would not be an issue. - Max > On Jul 10, 2023, at 2:35 am, Miklosovic, Stefan > <stefan.mikloso...@netapp.com> wrote: > > Hi Cassandra users, > > I am a Cassandra developer and we in Cassandra project would love to know if > there are users out there for whom the output of the tooling, like, nodetool, > is important when it comes to parsing it. > > We are elaborating on the consequences when nodetool's output for various > commands is changed - we are not completely sure if users are parsing this > output in some manner in their custom scripts so us changing the output would > break their scripts which are parsing it. > > Additionally, how big of a problem the output change would be if it was > happening only between major Cassandra versions? E.g. 4.0 -> 5.0 or 5.0 -> > 6.0 only. In other words, there would be a guarantee that no breaking changes > in minor versions would ever occur. Only in majors. > > Is somebody out there who is relying on the output of some particular > nodetool commands (or any command in tools/bin) in production? How often do > you rely on the parsing of nodetool's output and how much work it would be > for you to rework some minor changes? For example, when the tool output > prints "someStatistic: 10" and we would rework it to "Some Statistic: 10". > > Would you be OK if the output changed but you would have a way how to get > e.g. JSON or YAML output instead by some flag on nodetool command so it would > be irrelevant what the default output would be? > > It would be appreciated a lot if you gave us more feedback on this. I > understand that not all questions are relatable to everyone. > > Even you are not relying on the output of the tooling in some custom scripts > where you parse it, please tell us so. We are progressively trying to provide > CQL way how to query the internal state of Cassandra, via virtual tables, for > example. > > Regards > > Stefan Miklosovic
