Re: [chrony-users] Monitoring Chrony 4 with Telegraf

[Kevin P. Fleming]

On Mon, Aug 21, 2023, at 04:29, Miroslav Lichvar wrote:
> On Thu, Aug 17, 2023 at 09:48:09AM -0400, Kevin P. Fleming wrote:
>> I recently deployed Telegraf+InfluxDB+Grafana on my network, and couldn't 
>> find any Telegraf input plugins for Chrony that I liked. There is one 
>> included with Telegraf, but it only captures 'chronyc tracking' output (and 
>> doesn't do it particularly well).
>> 
>> I've just published a set of three input plugin configurations which all use 
>> the generic CSV importer, and which capture 'chronyc tracking', 'chronyc 
>> sources', and 'chronyc sourcestats'. They are here:
>> 
>> https://github.com/kpfleming/chrony-telegraf
>
> That looks great. Have you considered submitting a patch for the plugin
> included in Telegraf?

I have not yet; it would not be backwards compatible so would probably have to 
be a new plugin (along with the other two) as well.

-- 
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Monitoring Chrony 4 with Telegraf

[Miroslav Lichvar]

On Thu, Aug 17, 2023 at 09:48:09AM -0400, Kevin P. Fleming wrote:
> I recently deployed Telegraf+InfluxDB+Grafana on my network, and couldn't 
> find any Telegraf input plugins for Chrony that I liked. There is one 
> included with Telegraf, but it only captures 'chronyc tracking' output (and 
> doesn't do it particularly well).
> 
> I've just published a set of three input plugin configurations which all use 
> the generic CSV importer, and which capture 'chronyc tracking', 'chronyc 
> sources', and 'chronyc sourcestats'. They are here:
> 
> https://github.com/kpfleming/chrony-telegraf

That looks great. Have you considered submitting a patch for the plugin
included in Telegraf?

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Monitoring chrony, Prometheus-friendly metrics: redux

[Miroslav Lichvar]

On Wed, Oct 26, 2022 at 10:16:46AM +0200, Holger Hoffstätte wrote:
> The project can be found at: https://github.com/SuperQ/chrony_exporter
> and there are prebuilt binaries, though building it is quite easy as well.
> An unofficial Gentoo ebuild can be found at [2].

Looks great. I added the link to the chrony website.

Thanks,

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

[chrony-users] Monitoring chrony, Prometheus-friendly metrics: redux

[Holger Hoffstätte]

Hello chrony-users -

Some of you may remember past threads about monitoring chrony (e.g. [1]),
preferrably with Prometheus but without adding a hard dependency on
output formats or an http server within chrony itself.
Well..rejoice!

Ben Kochie has started an external exporter project which does not
scrape chrony output but instead uses the proper way of retrieving
any metrics via the protocol. It's fast, small(ish) and already has
replaced the previous script I used for the past few years.

The project can be found at: https://github.com/SuperQ/chrony_exporter
and there are prebuilt binaries, though building it is quite easy as well.
An unofficial Gentoo ebuild can be found at [2].

If there is a particular metric missing that you want to see exposed,
please file an issue, or even better just add it and send a PR.
Adding more metrics is relatively simple; just look at my own contributions
as inspiration. :)

Hopefully some of you find this useful.

cheers
Holger

[1] https://www.mail-archive.com/chrony-users@chrony.tuxfamily.org/msg02175.html
[2] 
https://github.com/hhoffstaette/portage/tree/master/app-metrics/chrony_exporter

--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Monitoring chrony, Prometheus-friendly metrics

[Holger Hoffstätte]

On 4/10/20 12:08 AM, Watson Ladd wrote:

On Wed, Apr 8, 2020 at 3:23 PM Watson Ladd  wrote:


On Wed, Apr 8, 2020 at 5:58 AM Luca BRUNO  wrote:


Hi all,
I'm following up from this old thread from 2016 regarding monitoring
chrony [0], and from this more recent discussion in Prometheus land [1].

[0] 
https://listengine.tuxfamily.org/chrony.tuxfamily.org/chrony-users/2016/02/msg3.html
[1] https://github.com/prometheus/node_exporter/issues/1666


I've got a python script lying around for exactly this. Let me get the
approvals sorted out to submit it/send it to you.


Here is the script. Same licensing terms as Chrony itself. I'll submit
a patch to put it in the contrib section shortly.

Note that we have a framework to turn a tool like this into part of
the scrape, so maybe a standalone monitor suits you a bit better.


And for the cherry on top here's a patch to make it compatible with
python3. Bytes vs. Strings and all that.

enjoy,
Hoplger
--- chrony_metrics.py~	2020-04-10 10:12:04.0 +0200
+++ chrony_metrics.py	2020-04-10 10:15:48.932272177 +0200
@@ -44,7 +44,7 @@ def get_cmdoutput(command):
 if return_code:
 raise RuntimeError('Call to "{}" returned error: \
 {}'.format(command, return_code))
-return out
+return out.decode("utf-8")
 
 
 def printPrometheusformat(metric, values):

Re: [chrony-users] Monitoring chrony, Prometheus-friendly metrics

[Watson Ladd]

On Wed, Apr 8, 2020 at 3:23 PM Watson Ladd  wrote:
>
> On Wed, Apr 8, 2020 at 5:58 AM Luca BRUNO  wrote:
> >
> > Hi all,
> > I'm following up from this old thread from 2016 regarding monitoring
> > chrony [0], and from this more recent discussion in Prometheus land [1].
> >
> > [0] 
> > https://listengine.tuxfamily.org/chrony.tuxfamily.org/chrony-users/2016/02/msg3.html
> > [1] https://github.com/prometheus/node_exporter/issues/1666
>
> I've got a python script lying around for exactly this. Let me get the
> approvals sorted out to submit it/send it to you.

Here is the script. Same licensing terms as Chrony itself. I'll submit
a patch to put it in the contrib section shortly.

Note that we have a framework to turn a tool like this into part of
the scrape, so maybe a standalone monitor suits you a bit better.
#!/usr/bin/env python
#
# Description: Extract chronyd metrics from chronyc -c.
# Author: Aanchal Malhotra 
#
# Works with chrony version 2.4 and higher

import subprocess
import sys

chrony_sourcestats_cmd = ['chronyc', '-c', 'sourcestats']
chrony_source_cmd = ['chronyc', '-c', 'sources']
chrony_tracking_cmd = ['chronyc', '-c', 'tracking']

metrics_fields = [
"Name/IP Address",
"NP",
"NR",
"Span",
"Frequency",
"Freq Skew",
"Offset",
"Std Dev"]

status_types = {'x': 0, '?': 1, '-': 2, '+': 3, '*': 4}

metrics_source = {
"*": "synchronized (system peer)",
"+": "synchronized",
"?": "unreachable",
"x": "Falseticker",
"-": "reference clock"}

metrics_mode = {
'^': "server",
'=': "peer",
"#": "reference clock"}


def get_cmdoutput(command):
proc = subprocess.Popen(command, stdout=subprocess.PIPE)
out, err = proc.communicate()
return_code = proc.poll()
if return_code:
raise RuntimeError('Call to "{}" returned error: \
{}'.format(command, return_code))
return out


def printPrometheusformat(metric, values):
print("# HELP chronyd_%s chronyd metric for %s" % (metric, metric))
print("# TYPE chronyd_%s gauge" % (metric))
for labels in values:
if labels is None:
print("chronyd_%s %f" % (metric, values[labels]))
else:
print("chronyd_%s{%s} %f" % (metric, labels, values[labels]))

def printPrometheusscalar(metric, value):
print("# HELP chronyd_%s chronyd metric for %s" %(metric, metric))
print("# TYPE chronyd_%s gauge" %(metric))
print ("chronyd_%s %f" % (metric, value))

def printPrometheusEnum(metric, name):
print("# HELP chronyd_%s enum for %s" %(metric, metric))
print("# TYPE chronyd_%s gauge" %(metric))
print("chronyd_%s{value=\"%s\"} 1"%(metric, name))

def weight(value):
val_int = int(value, 8)
return bin(val_int).count('1')/8.0

def main(argv):
peer_status_metrics = {}
peer_reach_metrics = {}
offset_metrics = {}
freq_skew_metrics = {}
freq_metrics = {}
std_dev_metrics = {}
chrony_sourcestats = get_cmdoutput(chrony_sourcestats_cmd)
for line in chrony_sourcestats.split('\n'):
if (len(line)) > 0:
x = line.split(',')
common_labels = "remote=\"%s\"" % (x[0])
freq_metrics[common_labels] = float(x[4])
freq_skew_metrics[common_labels] = float(x[5])
std_dev_metrics[common_labels] = float(x[7])

printPrometheusformat('freq_skew_ppm', freq_skew_metrics)
printPrometheusformat('freq_ppm', freq_metrics)
printPrometheusformat('std_dev_seconds', std_dev_metrics)

chrony_source = get_cmdoutput(chrony_source_cmd)
for line in chrony_source.split('\n'):
if (len(line)) > 0:
x = line.split(',')
stratum = x[3]
reach = x[5]
mode = metrics_mode[x[0]]
common_labels = "remote=\"%s\"" % (x[2])
peer_labels = "%s,stratum=\"%s\",mode=\"%s\"" % (
common_labels,
stratum,
mode,
)
peer_status_metrics[peer_labels] = float(status_types[x[1]])
peer_reach_metrics[peer_labels] = weight(reach)
offset_metrics[common_labels] = float(x[8])

printPrometheusformat('peer_status', peer_status_metrics)
printPrometheusformat('offset_seconds', offset_metrics)
printPrometheusformat('peer_reachable', peer_reach_metrics)

chrony_tracking_stats = get_cmdoutput(chrony_tracking_cmd).rstrip()
fields = chrony_tracking_stats.split(",")
printPrometheusEnum("tracking_source", fields[1])
printPrometheusscalar("tracking_stratum", float(fields[2]))
printPrometheusscalar("tracking_ref_time", float(fields[3]))
printPrometheusscalar("tracking_system_time", float(fields[4]))
printPrometheusscalar("tracking_last_offset" , float(fields[5]))
printPrometheusscalar("tracking_rms_offset", float(fields[6]))
printPrometheusscalar("tracking_frequency_error", float(fields[7]))
printPrometheusscalar("tracking_frequency_residual", float(fields[8]))

Re: [chrony-users] Monitoring chrony, Prometheus-friendly metrics

[Watson Ladd]

On Wed, Apr 8, 2020 at 5:58 AM Luca BRUNO  wrote:
>
> Hi all,
> I'm following up from this old thread from 2016 regarding monitoring
> chrony [0], and from this more recent discussion in Prometheus land [1].
>
> [0] 
> https://listengine.tuxfamily.org/chrony.tuxfamily.org/chrony-users/2016/02/msg3.html
> [1] https://github.com/prometheus/node_exporter/issues/1666

I've got a python script lying around for exactly this. Let me get the
approvals sorted out to submit it/send it to you.

-- 
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Monitoring Chrony

[Ben Kochie]

It makes sense, but the real problem is the there are ordering issues with
the way things are processed in most of the stats outputs.

For example in the sources/sourcestats, the code walks each source and
outputs all the stats for each source.

Prometheus expects metrics to be output in order of metric.  For example
all of the offsets for each source.

I had a discussion with another person over the weekend, and I think what
we're going to do is to abandon the text metrics output idea and implement
the chronyd protocol (probably in Go) so that we can build a direct
Prometheus exporter.

- Ben Kochie

On Mon, Feb 29, 2016 at 10:10 AM, Miroslav Lichvar 
wrote:

> (this discussion would better fit the chrony-devel list)
>
> On Sat, Feb 27, 2016 at 03:08:12PM +0100, Ben Kochie wrote:
> > So I started work on adding a "metrics" command to client.c.  It's pretty
> > hacky, but works.
> >
> > https://github.com/SuperQ/chrony/pull/1
> >
> > Comments welcome.
>
> Ok, so you implemented the metrics command as a new function which
> does the same as the serverstats command, but uses a different output
> format. I assume you would extend it later to include also the
> tracking, sources and sourcestats data. That would be a lot of
> duplicated code.
>
> As I said in the previous mail, I'd rather see it implemented as a
> different output format for the existing commands. A new chronyc
> option could be added to select the format, with default being the
> currently used human-readable output. A new printf-like function would
> be added, which would support printing hostnames or IP addresses, time
> intervals, offsets, and all other data that need to be printed.
> Depending on what output mode chronyc was running in, it would print
> the labels, align the columns, print the values with units, print end
> of lines, etc. All functions that implement the individual commands
> would then be modified to use this new function.
>
> I'm planning to look into this in the next few weeks. At this point
> I'm mainly interested in adding the CSV format to allow easy parsing
> in shell, but I think the Prometheus format could be added too.
>
> Does this make sense?
>
> --
> Miroslav Lichvar
>
> --
> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
> with "unsubscribe" in the subject.
> For help email chrony-users-requ...@chrony.tuxfamily.org
> with "help" in the subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>
>

Re: [chrony-users] Monitoring Chrony

[Miroslav Lichvar]

(this discussion would better fit the chrony-devel list)

On Sat, Feb 27, 2016 at 03:08:12PM +0100, Ben Kochie wrote:
> So I started work on adding a "metrics" command to client.c.  It's pretty
> hacky, but works.
> 
> https://github.com/SuperQ/chrony/pull/1
> 
> Comments welcome.

Ok, so you implemented the metrics command as a new function which
does the same as the serverstats command, but uses a different output
format. I assume you would extend it later to include also the
tracking, sources and sourcestats data. That would be a lot of
duplicated code.

As I said in the previous mail, I'd rather see it implemented as a
different output format for the existing commands. A new chronyc
option could be added to select the format, with default being the
currently used human-readable output. A new printf-like function would
be added, which would support printing hostnames or IP addresses, time
intervals, offsets, and all other data that need to be printed.
Depending on what output mode chronyc was running in, it would print
the labels, align the columns, print the values with units, print end
of lines, etc. All functions that implement the individual commands
would then be modified to use this new function.

I'm planning to look into this in the next few weeks. At this point
I'm mainly interested in adding the CSV format to allow easy parsing
in shell, but I think the Prometheus format could be added too.

Does this make sense?

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Monitoring Chrony

[Ben Kochie]

So I started work on adding a "metrics" command to client.c.  It's pretty
hacky, but works.

https://github.com/SuperQ/chrony/pull/1

Comments welcome.

- Ben Kochie

On Fri, Feb 12, 2016 at 10:05 AM, Miroslav Lichvar 
wrote:

> On Thu, Feb 11, 2016 at 02:12:36PM +0100, Ben Kochie wrote:
> > On Thu, Feb 11, 2016 at 1:58 PM, Miroslav Lichvar 
> > wrote:
> >
> > > I looked at the page describing the archicture, but it's not clear to
> > > me how would a support in chrony look like. Would chronyd or something
> > > using the chronyc protocol be listening on a port for requests? Or
> > > would it periodically push data over socket somewhere? The page
> > > listing client libraries does't include a C library.
> > >
> >
> > Typically we do this one of a few ways.
>
> > #2 - We run a side-car exporter.  We do this quite a lot for existing
> open
> > source software, like mysql, that would never listen on http, but can
> > provide metrics with their own protocol.
>
> This one seems most reasonable to me. A separate service that uses the
> chronyc protocol to read the metrics from chronyd.
>
> > #3 - The way we collect metrics for ntpd, is we have a loop script, or
> cron
> > script, that parse output and put that output in prometheus format into a
> > text file.  Then we access these metrics via the node_exporter's textfile
> > reader.
>
> This is probably the easiest way :).
>
> > #4 - We use something like mtail[0] and parse log files.  This is what I
> do
> > for things like apache[1] that have minimal useful internal metrics.
>
> The chrony logs are good in showing when exactly has the state
> changed, but if you are interested in metrics like root dispersion,
> which are constantly changing (in a deterministic way), you would have
> to calculate their current value.
>
> > > > * Is there a mode for the various metrics outputs to be more machine
> > > > readable? (json?)
> > >
> > > No, not yet. I'd like to add a raw mode to chronyc that would print
> > > the values in something easily parseable. I'm not sure about json, I'd
> > > probably prefer something usable even from shell using just sed or
> > > awk.
> > >
> >
> > One idea I had would be to add a "metrics" command to chronyc.  Then you
> > could run a loop/cron job that would be basically "chronyc metrics >
> > chrony_metrics.prom"
>
> Which metrics it would print? With the "clients" command for instance
> there can megabytes of data, which in most cases probably wouldn't be
> useful to collect, but in some cases I think it might, e.g. monitoring
> if clients are alive from the server in a small network.
>
> > The output format would be sed/awk friendly as you always get one metric
> > key and value per line.
>
> If there was just one key/value per line, wouldn't it be more
> difficult for a simple sed/awk parser to group data by source, as in
> sourcestats?
>
> I was considering something like CSV, which can be parsed in shell
> with a single "read" command and can be easily converted to more
> verbose formats like json.
>
> $ chronyc -r tracking
> #refid,address,stratum,...
> 10.16.255.1,10.16.255.1,2,...
>
> $ chronyc -r sources | grep -v '^#' | while IFS=, read mode state ...
> do
> echo $mode $state ...
> done
>
> --
> Miroslav Lichvar
>
> --
> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
> with "unsubscribe" in the subject.
> For help email chrony-users-requ...@chrony.tuxfamily.org
> with "help" in the subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>
>

Re: [chrony-users] Monitoring Chrony

[Miroslav Lichvar]

On Thu, Feb 11, 2016 at 02:12:36PM +0100, Ben Kochie wrote:
> On Thu, Feb 11, 2016 at 1:58 PM, Miroslav Lichvar 
> wrote:
> 
> > I looked at the page describing the archicture, but it's not clear to
> > me how would a support in chrony look like. Would chronyd or something
> > using the chronyc protocol be listening on a port for requests? Or
> > would it periodically push data over socket somewhere? The page
> > listing client libraries does't include a C library.
> >
> 
> Typically we do this one of a few ways.

> #2 - We run a side-car exporter.  We do this quite a lot for existing open
> source software, like mysql, that would never listen on http, but can
> provide metrics with their own protocol.

This one seems most reasonable to me. A separate service that uses the
chronyc protocol to read the metrics from chronyd.

> #3 - The way we collect metrics for ntpd, is we have a loop script, or cron
> script, that parse output and put that output in prometheus format into a
> text file.  Then we access these metrics via the node_exporter's textfile
> reader.

This is probably the easiest way :).

> #4 - We use something like mtail[0] and parse log files.  This is what I do
> for things like apache[1] that have minimal useful internal metrics.

The chrony logs are good in showing when exactly has the state
changed, but if you are interested in metrics like root dispersion,
which are constantly changing (in a deterministic way), you would have
to calculate their current value.

> > > * Is there a mode for the various metrics outputs to be more machine
> > > readable? (json?)
> >
> > No, not yet. I'd like to add a raw mode to chronyc that would print
> > the values in something easily parseable. I'm not sure about json, I'd
> > probably prefer something usable even from shell using just sed or
> > awk.
> >
> 
> One idea I had would be to add a "metrics" command to chronyc.  Then you
> could run a loop/cron job that would be basically "chronyc metrics >
> chrony_metrics.prom"

Which metrics it would print? With the "clients" command for instance
there can megabytes of data, which in most cases probably wouldn't be
useful to collect, but in some cases I think it might, e.g. monitoring
if clients are alive from the server in a small network.

> The output format would be sed/awk friendly as you always get one metric
> key and value per line.

If there was just one key/value per line, wouldn't it be more
difficult for a simple sed/awk parser to group data by source, as in
sourcestats?

I was considering something like CSV, which can be parsed in shell
with a single "read" command and can be easily converted to more
verbose formats like json.

$ chronyc -r tracking
#refid,address,stratum,...
10.16.255.1,10.16.255.1,2,...

$ chronyc -r sources | grep -v '^#' | while IFS=, read mode state ...
do
echo $mode $state ...
done

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Monitoring Chrony

[Ben Kochie]

On Thu, Feb 11, 2016 at 1:58 PM, Miroslav Lichvar 
wrote:

> On Thu, Feb 11, 2016 at 10:54:49AM +0100, Ben Kochie wrote:
> > So far, I haven't been able to find a good programmatic way to extract
> > stats with chronyc.  There are a bunch of annoying parsing issues with
> > things like the sourcestats command.  The offset includes a precision,
> so I
> > have to parse the precision and convert that to be all in one precision.
>
> Yeah, I've struggled with that too. I like the human readable format
> when inspecting the chrony state, but it does complicate parsing quite
> a bit.
>
> > A couple of specific questions.
> > * Would chrony be interested in supporting the Prometheus metrics format?
>
> I looked at the page describing the archicture, but it's not clear to
> me how would a support in chrony look like. Would chronyd or something
> using the chronyc protocol be listening on a port for requests? Or
> would it periodically push data over socket somewhere? The page
> listing client libraries does't include a C library.
>

Typically we do this one of a few ways.
#1 - The application listens on a port for http requests, the default is
/metrics.  It then can respond with plain/text in the format I posted
above.  Or it will content negotiate and use grpc, a nice compact protobuf
format.  The grpc format is the most efficient, but we've had few problems
collecting text metrics at scale.

#2 - We run a side-car exporter.  We do this quite a lot for existing open
source software, like mysql, that would never listen on http, but can
provide metrics with their own protocol.

#3 - The way we collect metrics for ntpd, is we have a loop script, or cron
script, that parse output and put that output in prometheus format into a
text file.  Then we access these metrics via the node_exporter's textfile
reader.

#4 - We use something like mtail[0] and parse log files.  This is what I do
for things like apache[1] that have minimal useful internal metrics.

[0]: https://github.com/google/mtail
[1]:
https://github.com/google/mtail/blob/master/examples/apache_metrics.mtail


> > * Is there a mode for the various metrics outputs to be more machine
> > readable? (json?)
>
> No, not yet. I'd like to add a raw mode to chronyc that would print
> the values in something easily parseable. I'm not sure about json, I'd
> probably prefer something usable even from shell using just sed or
> awk.
>

One idea I had would be to add a "metrics" command to chronyc.  Then you
could run a loop/cron job that would be basically "chronyc metrics >
chrony_metrics.prom"

The output format would be sed/awk friendly as you always get one metric
key and value per line.


> > * Is there documentation for the chronyc protocol outside the code?
>
> No, unfortunately not. FWIW, the protocol is quite simple, almost all
> information you would need to implement a new client is contained in
> candm.h.
>

Ok, I will take a look.


>
> > * Are there any non-C chronyc client implementations?
> (python/ruby/whatever)
>
> Probably not, at least I've not seen anything. At some point I'd like
> to split chronyc into a library and a client application. Bindings for
> other languages could then be easily created.


This would be pretty nice.


>
> --
> Miroslav Lichvar
>
> --
> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
> with "unsubscribe" in the subject.
> For help email chrony-users-requ...@chrony.tuxfamily.org
> with "help" in the subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>
>

Re: [chrony-users] Monitoring Chrony

[Miroslav Lichvar]

On Thu, Feb 11, 2016 at 10:54:49AM +0100, Ben Kochie wrote:
> So far, I haven't been able to find a good programmatic way to extract
> stats with chronyc.  There are a bunch of annoying parsing issues with
> things like the sourcestats command.  The offset includes a precision, so I
> have to parse the precision and convert that to be all in one precision.

Yeah, I've struggled with that too. I like the human readable format
when inspecting the chrony state, but it does complicate parsing quite
a bit.

> A couple of specific questions.
> * Would chrony be interested in supporting the Prometheus metrics format?

I looked at the page describing the archicture, but it's not clear to
me how would a support in chrony look like. Would chronyd or something
using the chronyc protocol be listening on a port for requests? Or
would it periodically push data over socket somewhere? The page
listing client libraries does't include a C library.

> * Is there a mode for the various metrics outputs to be more machine
> readable? (json?)

No, not yet. I'd like to add a raw mode to chronyc that would print
the values in something easily parseable. I'm not sure about json, I'd
probably prefer something usable even from shell using just sed or
awk.

> * Is there documentation for the chronyc protocol outside the code?

No, unfortunately not. FWIW, the protocol is quite simple, almost all
information you would need to implement a new client is contained in
candm.h.

> * Are there any non-C chronyc client implementations? (python/ruby/whatever)

Probably not, at least I've not seen anything. At some point I'd like
to split chronyc into a library and a client application. Bindings for
other languages could then be easily created.

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Monitoring Chrony

[Ben Kochie]

Log parsing is possible, there is a tool called mtail that can parse logs
to collect metrics. It is generally recommend to ask services directly
about their current state rather than regexping logs.

This way the stats are read in a more on-demand way.
On Feb 11, 2016 11:35 AM, "Bryan Christianson"  wrote:

>
> > On 11/02/2016, at 10:54 PM, Ben Kochie  wrote:
> >
> > So far, I haven't been able to find a good programmatic way to extract
> stats with chronyc.  There are a bunch of annoying parsing issues with
> things like the sourcestats command.  The offset includes a precision, so I
> have to parse the precision and convert that to be all in one precision.  I
> haven't seen much documentation on the protocol between chronyc and chronyd.
>
> Take a look at the chronyd log files. The data is more amenable to machine
> reading than the chronyc output.
>
> >
> > - Ben Kochie
>
> Bryan Christianson
> br...@whatroute.net
>
>
>
>
> --
> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
> with "unsubscribe" in the subject.
> For help email chrony-users-requ...@chrony.tuxfamily.org
> with "help" in the subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>
>