Simon icon Simon
Flexible server monitoring

New Feature Requests: Test Service and Notifiers

New Feature Requests:

- For monitoring for malware attacks, some attacks install an initial file, run it, which then deletes itself in a fairly quick time frame. So knowing what that file name is and its contents is important. For (S)FTP Services, it would be nice to have a download option when a new file is found.

- With Notifications, there are several "insert variables" that would be nice to have:
+ (S)FTP Path of Test (e.q. {TestingFTPPath}, {TestingSFTPPath})

- With Notifiers, can there be an option to have "Only notify once after a Change for Time Frame given between checks). The service test still can continue and report, but just don't repeatedly notify.

- With Notifiers, I am making setting a number of notifications for the same Test, so can there be an insert variable option for {NotifierKindsSent}, to show all the notifications given for the Test.

- With Notifiers, can there be insert variables for:
+ {TestLastChangeDate} {TestLastChangeTime}
+ {TestLastRecoveryDate} {TestLastRecoveryTime}

- Simon does have "insert variable" fields for {NotifierForChange}, {NotifierForFailure}, {NotifierForFailure} that produces "yes/no" answers, but can you also just have an insert variable for {TestResultType} or {TestResultKind} that is results in one of the following options: "Change/Failure/Recovery". With this type of variable, you can have one notifier type for all three types of test results.

David Sinclair's picture

Re: New Feature Requests: Test Service and Notifiers

You could write a script to download files, though it might not be easy.

Service-specific variables aren't currently supported, since it would complicate things... though I'll certainly consider that for the future.

You can have a notifier only notify once per error. Adding a timeframe as an additional limit is an interesting idea.

A variable for the assigned notifier kinds could be useful. Not sure how it'd be formatted, though... perhaps a comma-separated list? What would you use that for?

{TestLastChangeDate} etc are available for notifiers. See the Notifier Variables page.

For your last point, see {TestStatusType} or (perhaps better) {TestStatusPhrase}.

Hope this helps.

Re: New Feature Requests: Test Service and Notifiers

Re:
Q: A variable for the assigned notifier kinds could be useful. Not sure how it'd be formatted, though... perhaps a comma-separated list? What would you use that for?
A: Comma separated makes the most sense. The reason for this {NotifierKindsSent} field would be if you are notifying multiple people that aren't normally the "monitors", so they are informed about all the notification formats and persons involved.

Also notifying about all the people notified would also be useful. e.q. {NotifierEmailTo}, {NotifierEmailFrom}, {NotiferEmailCC}, {NotifierEmailSubject}. Although this information is obvious in the normal places of an email, the reason for these additional fields would be to have them in the email BODY text for easy copy and paste or database import (yes I know there are direct more efficient database methods such as MySQL options, but some people do it the old ways too on non-net connected databases).

David Sinclair's picture

Re: New Feature Requests: Test Service and Notifiers

A comma-separated list of notifiers used (listing the notifier names) could be doable. I've made a note of that idea.

Notifier-specific values like {NotifierEmailTo} etc would be harder. The notifiers (and services) are implemented as plugins, so Simon doesn't know what values they have. I could add an API to expose that information, but it'd be quite a lot of work, so I'd only do so if there were significant demand or usefulness.

If, however, you're talking about having Email fields as variables only within the Email plugin (so you can use them in the body of your email message), that would be more feasible... though I'm not sure why that would be useful, since they are fixed values for that notifier anyway.