Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

…ted in the main thread

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

…on functions

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

…egator_add_data_point()

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

This is metric that stores a time_t value and is formatted as the number of
seconds before the time it is queried (e.g. age in seconds).

This can be used to represent absolute time values irrespective wheather our
clock is right.

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

This patch implements the syslogng_output_message_delay_sample_seconds, which
shows the delay incurred between the message being received and
then sent out by syslog-ng.

Please note that this is the delay associated with one specific message that
was recently sent out, e.g. this is a sample, rather than the average
of a series of messages. It is believed that the delay incurred is not
a volatile value, rather messages sitting in the queue in close proximity
have very similar delay values.

Thus, we only sample this delay once every second.

There's also another associated metric, called output_message_delay_sample_age_seconds,
which shows when the delay metric was last sampled. It contains the
age of the sample relative to the current time. This contains this
relative timestamp so that the actual clock accuracy of the syslog-ng
host does not matter.

To come up with an alertable metric for message delays, the following
algorithm is recommended:

We need the values for these metrics which are scraped at the same time:
  * output_message_delay_sample_seconds
  * output_message_delay_sample_age_seconds
  * syslogng_output_events_total{result="queued"}

After every scraping iteration:
1) check if the delay_sample_age is recent (e.g. happened between
the last two scrape periods), if it was then the delay can be considered
current.
2) if the age is older than that, look at the length of the associated queue

  - 2a) if the queue is empty, then our delay can be considered zero, as any new messages would
        be sent immediately.
  - 2b) if the queue is not empty, it means that even though we would have data to send,
        we did not (as if we were our age would be recent), our delay building up
        The expected delay value would be the sum of the last delay sample plus
        its age value.

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

Signed-off-by: Balazs Scheidler <balazs.scheidler@axoflow.com>

Signed-off-by: Attila Szakacs <attila.szakacs@axoflow.com>

Signed-off-by: Attila Szakacs <attila.szakacs@axoflow.com>

Signed-off-by: Attila Szakacs <attila.szakacs@axoflow.com>

Signed-off-by: Attila Szakacs <attila.szakacs@axoflow.com>

Signed-off-by: Attila Szakacs <attila.szakacs@axoflow.com>

Signed-off-by: Attila Szakacs <attila.szakacs@axoflow.com>

This intends to fix the y2038 problem on 32bit machines in cases
where we can guarantee to use only positive values.

Signed-off-by: Attila Szakacs <attila.szakacs@axoflow.com>

Signed-off-by: Attila Szakacs <attila.szakacs@axoflow.com>

Signed-off-by: Attila Szakacs <attila.szakacs@axoflow.com>

Signed-off-by: Attila Szakacs <attila.szakacs@axoflow.com>