TIMESTAMP TEST is ambiguous and not flexible

[Don]

1.

https://mmonit.com/monit/documentation/#TIMESTAMP-TEST It may look to you totally clear, because, you already know correct meaning, but for a new person definition is ambiguous and unclear, even if new person thinks he got it clear he may be wrong.

Problem is you never explain explicitly what time stamp tested against which date in what way.

For example test if timestamp < 1 day then alert could be interpreted as 'this file timestamp is older than one day in compare to now, because, it's smaller value', but from stated example:

For example testing directory for file addition or removal:

 check directory bar path /foo/bar
       if timestamp < 1 hour then alert

it could be understood that < 1 meant fresher, so it could be inferred as 'time difference is smaller than 1 hour'. See, these are completely opposite meanings to compare operators.

It seems also naming timestamp is confusing, because, it's not time stamp, but time delta.

2.

It never stated which timestamp is checked, it's confusing, because, there is many timestamps in filesystem. Person could download file from other server, updating ctime on each download, but mtime is not changed. But person may be interested in checking exactly mtime to see if file is stale, old, obsoleted, not updated. It is not possible with monit to select which timestamp to check.

I feature request possibility to select which timestamp (mtime, ctime, or atime) to test. And if not specified it could fall back to default behavior (whatever it is, I didn't understand from the docs too).

[Don]

I just realized that state it's time delta would be also ambiguous for user, because, time delta could be calculated in two ways, for example, mtime - now or now - mtime. What you actually seems to have (I infer from example) is measure of oldness. So, it could be read as 'if timestamp oldness is smaller than 1 day (then alert)'. (Testing for future dates would be weird, though.)

Ambiguity of saying oldness is in multiple actual timestamps, what you (seems) testing is not oldest timestamp, but freshiest timestamp (max of mtime and ctime). So, better would be to say that file/timestamp freshness is tested. But that would invert current compare operators.

I think better (unambiguous and clean) test phrasing would be something like this: IF MTIME IS OLDER THAN 1 DAY AGO THEN ALERT. 'OLDER' and 'AGO' can not be omitted w/o losing meaning. Keyword OLDER could be paired with NEWER, and AGO with FUTURE (or HENCE). And, MTIME, with CTIME, ATIME, and maximum of any TIME.

I think explicit phrasing is very important, because, admin must understand exactly what he is testing on the time when he writes a test, not after he missed important alert, because of misunderstanding of ambiguous statements. In general I think that explicit, clean and simple phrasing is important or at least beneficial for monitoring software, because of need to capture admin's intent of test, and not to put burden of solving logic puzzles on human.

[Tildeslash]

Fixed Issue #582: Added support for explicit access, change and modification timestamp type tests. If the type is not specified, the original timestamp test is performed, which checks the latest of change and modification timestamps. It is also possible to use "newer" and "later" operators in the test now. Syntax: IF [ACCESS|CHANGE|MODIFY] TIMESTAMP <operator> <time> THEN <action> Example for sending alert if the file was not updated within last hour: if timestamp is older than 1 hour then alert

→ <<cset 8a6855244c0f>>

[Don]

Thanks!

[Tildeslash]

Issue #153 was marked as a duplicate of this issue.