A framework for notifications a.k.a sending emails, boxcar, notifo, pushover etc


Recommended Posts

 

We should avoid at all costs trying to build a system that monitors any number of log files.

 

This is unavoidable.  Besides, it's easy enough for a plugin to 'add' a log monitor then report it's findings via syslog using specific keywords which would then trigger an alert.

 

This is why I've been fond of the NAGIOS environment.

You create a plugin to monitor something.

That plugin is reported to the core app, which then uses rules to trigger configurable alerts.

 

An author can create an application plugin and another author can create a monitor plugin.

 

a syslog scrapper will no doubt pick up false errors though, unMenu is a perfect example of how false "errors" are flagged. I'd imagine a scrapper will do the same but instead of adding colour ;) , it would send alerts, emails, sms, etc.

 

A log monitor will pick up messages that it is programmed to pick up.

It will take a bit of time, but eventually it will work out.

I've been using logcheck.sh for years with great effect.  When(if) I start to pick up something new. I add a new regular expression. Alert or Ignore.

 

I created a program which was a combination of  logtail

http://linux.die.net/man/8/logtail

 

Then added functionality which would work like fgrep

http://linux.die.net/man/1/fgrep

 

Rules are in a file, sort of an rsync .filter syntax.

 

+ (include lines matching this regular expression)

- (exclude lines matching this regular expression)

 

It works really well for me.

 

It is called ofgrep (offsetable file based grep)

Usage: ofgrep [OPTION]... '[+-] PATTERN'... [FILE]...

 

  -e  use PATTERN as regular expression

      in form of '+ regex'(include), '- regex'(exclude)

  -f  obtain PATTERN from FILE

      in form of '+ regex'(include), '- regex'(exclude)

  -i  Ignore case in pattern matches

  -o  Save/Use offset for each file. named as originalfile.offset

  -O  Save/Use offset for each file. named as supplied offset filename.

  -V  print version information and exit

Link to comment
  • Replies 72
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I think we are diverging slightly here. The system for notifications technically doesn't include a monitor of any sort. Right back in the beginning of this thread I tried to separate the notification system for the generation of alarms.

 

I think we have done quite well but the framework for notifications should only be trigger > verify > notify. Technically it doesn't matter what creates that trigger and we could have several mechanism in place to do so (syslog tail, multitail, transmission sending a log) depending on the user.

 

The real hurdle is the framework to get those alarm out of the box and hopefully the purpose of this thread.

 

Once we have that nailed we can look to what we do to generate these triggers.

 

Edit: I know a montporing system and a notification system are useless without each other but we can look at them as separate deliverables and hopefully finally get one in place

Link to comment
The real hurdle is the framework to get those alarm out of the box and hopefully the purpose of this thread.

 

While I agree with your previous post, I was presenting some idea's for possibility.

 

You need buy in from Tom.  No matter what we choose, it requires some additional facilities.

 

email, perl, curl, php compile time options.

 

We've agreed that email is the most basic necessity. (At least most people who have responded have).

 

Where do we go from there?

Link to comment

We have buy in since it was Tom that asked for this post to happen :)

 

For this thread I think we need to:

 

define and document the inputs

create a proof of concept (POC) input sanitiser

work out how we reliably pass info from the sanitiser to a number of notifiers in parallel

create a POC mail notifier

create a POC pushover or similar technology notifier

 

I also think we should create a second thread and expand on your ideas for a monitoring system.

 

 

Link to comment

We have buy in since it was Tom that asked for this post to happen :)

 

For this thread I think we need to:

 

define and document the inputs

create a proof of concept (POC) input sanitiser

work out how we reliably pass info from the sanitiser to a number of notifiers in parallel

create a POC mail notifier

create a POC pushover or similar technology notifier

 

I also think we should create a second thread and expand on your ideas for a monitoring system.

 

it feels like we're almost reinventing a wheel here or putting the cart before the horse.

>> work out how we reliably pass info from the sanitiser to a number of notifiers in parallel

 

NAGIOS does most of this.

 

It seems like we're designing the output environment before we've defined a monitoring environment or what we want to monitor, how and when.

 

There are also a number of other homegrown monitors that do this too.

I remember working with bigbrother years ago (in fact I probably have the old source code tucked away somewhere).

 

I have the perl version of bigbrother called bigsister. That also was usable and had a clearly defined interface, monitor, event, alert.

 

In some sense it feels like we're defining an alert environment without encompassing the whole interface.

 

How do you send alerts in parallel?

Where do you store them?

 

This is why I've been suggesting email as the common denominator.

 

An alert can be posted, it gets stored in an email archive somewhere.

That email archive can now be inspected (read back) and x number of parallel alerts can be sent out accordingly.

 

Another suggestion is to use the syslog and specific logging facilities. Warehouse the data there in specific text based formats so it can be monitored in a normalized fashion.

 

In any case, it seems like we're all talking about the same thing, but what's being focused on is the warehouse of information and then the output of that.

 

This leads to another option.  if CURL and SQLITE were compiled into unRAID's PHP,  data could be captured by an emhttp interface via some post, (or directly) warehoused in SQLITE and X number of notifiers could monitor the sqlite table which should contain normalized data.

 

What's stopped me most about using NAGIOS to do all of this is emhttp does not support CGI. If it did, we would be ahead of the game.  nagios can easily support multiple notifiers in parallel via external config file.  I've done it. messages to syslog, messages to my soundbridge, messages via email. messages to a home grown notification system in my organization.  A browser interface to acknowledge the messages so they stop. An environment to schedule WHEN you get the notifications, escalation, etc, etc.  Scheduling of the monitors themselves.

 

I'm sure there are other monitoring environments that admins have used.

To that effect, it should be explored further before defining a notification framework.

There may already be great ideas that can be built upon.

 

No matter what we decide, many people will ask for email as a notification output.

 

I'll ask this.

 

Is the goal to have a notification framework that emhttp calls?

Is it to be a framework that uses emhttp for warehousing and triggering the notifications?

Is it to be totally separate from emhttp?

Link to comment

Nagios feels like overkill however I have said all along we should see if there is something we can use. I have very little interest in sqlite type things as for me personally a notifier is something that i get and act on semi real time. If i don't act on it immediately i come back and look at raw logs. This is just me though and I suspect I am an unusual case. This is especially true since I have zero need to for email alerts for much the same reasons.

 

This is beginning to feel bigger than I imagined, perhaps I was being too simplistic basing it on my simplistic requirements of "trip and alerts get an alarm".

 

I will sit back now and see if anyone else has ideas or examples of ready made solutions... and maybe this thread needs put to bed until the monitors are decided.

 

Just lets keep it elegant, most of uNRAID userbase just want an email if a disk or fs error happens. :)

Link to comment

Nagios feels like overkill however I have said all along we should see if there is something we can use. I have very little interest in sqlite type things as for me personally a notifier is something that i get and act on semi real time. If i don't act on it immediately i come back and look at raw logs. This is just me though and I suspect I am an unusual case. This is especially true since I have zero need to for email alerts for much the same reasons.

 

This is beginning to feel bigger than I imagined, perhaps I was being too simplistic basing it on my simplistic requirements of "trip and alerts get an alarm".

 

I will sit back now and see if anyone else has ideas or examples of ready made solutions... and maybe this thread needs put to bed until the monitors are decided.

 

SQLite was just an idea for warehousing the messages in a normalized fashion to do parallel alerts. If we are not doing parallel alerts, there's no need to warehouse the alerts. Trigger the alert plugin and move along.  The real issue is the constant suggestion of parallel alerts. If we go down that road the data(alert) has to be warehoused somewhere. In nagios it's in RAM and a custom data file for all current alerts.

 

For our purposes it could be the syslog as long as the alerts are normalized.

 

I suggested growl because it warehoused the events and with other programs could trigger other events.

 

Just lets keep it elegant, most of uNRAID userbase just want an email if a disk or fs error happens.

 

email is a good option. In itself that can be the warehouse of the alerts (even if local).

using scripts, you can login via pop, imap or inspect a mail file manually.

scrape apart the email keywords and trigger other parallel events.

 

Years ago, we would use email to send administrative events to our servers.

using specifc keywords and procmail we could add users, get information back from the server ,etc, etc.

 

Using cron.hourly scripts this can occur on a regular basis, read the email event/message and trigger another message via growl or whatever is decided.

 

If PHP were compiled in with curl, we could have an emhttp page that accepted and sent out direct messages with another API.

 

Every NAS I've used so far before unRAID used email to alert when an event occurred.

At the very least we should start there and define the requirements for an email framework.

 

FWIW, if we can convince Tom to include CURL, the libraries and compile it in the PHP core he uses, we could add the pushover API pretty easily.  As an emhttp call for posting it or directly.

 

Still there are the three questions I posed.

 

Is the goal to have a notification framework that emhttp calls?

Is it to be a framework that uses emhttp for warehousing and triggering the notifications?

Is it to be totally separate from emhttp?

Link to comment

I cannot see emHTTP being a requirement, it surely can trigger an external event just like anything else? It also allows for the possibitly of the system alarming if emHTTP goes down which is probably a good idea.

 

If it brings something to the table I am missing then sure but I am not sure we want to have to rely on Tom to get this done, or rather we can do this for the project independently.

 

For what it is worth it seems that curl with ssl support can be used to tlak to almost every notification service we have mentioned. This tends to make me think bash + cron might be the way to go rather than php.

 

Any ways my worry is even though I started this thread my requirements are so different to most I end up hindering rather than helping.

Link to comment

For what it is worth it seems that curl with ssl support can be used to tlak to almost every notification service we have mentioned. This tends to make me think bash + cron might be the way to go rather than php.

 

bash + cron + curl is not a framework for notifications.

it is an event monitor, scheduler and external api interface.

 

Wasn't this done with unraid_notify?

 

A frame work consists of.

 

What is it you want to capture?

How will you capture it? (monitor scripts)

How will you store it (if even)? Where does the data go?

How will you warehouse, normalize or utilize the event data?

How will you report it in a configurable manner?

 

In looking at my old bigbrother source code it had all of this framework.

The only thing it did not do is the parallel notifications.

However the notification app was an external program, so the parallel notification could be done there.

 

 

Other ideas I've been toying with is just using directories and VAR=VALUE conf files in those directories.

 

an even monitor can drop a file into a directory.

the directory can be monitored by a daemon or cron.

the .conf file is sourced into a script.

the script takes the data and submits the notification via API call.

 

Much of this can be done with bash, cron, php. Where it falls short is in the external API call.

We need tools for the SMTP and/or CURL for posting the message via well known protocol interface.

 

As far as parallel.  Well you can have multiple directories, one per notification API.

 

using find /var/notifers/growl -newer -exec growlnotifier.sh {} \; and touch you can search for newer files then the last notification.

execute a program using the .conf file as input to the notifier application.

 

Another way is a log scraper off /var/log/syslog remembering the offset of where you last read.

Each notifier API would have to remember it's own offset making them all parallel and independent.

 

While this all works, it's kind of a hodgepodge framework.

 

I suggested nagios even though it may be overkill because it is a framework that does what you are asking for.

 

a monitor plugin is created as a separate entity that does one thing really well.

The monitor plugin returns OK, WARNING CRITICAL UNKNOWN. (smart values on a drive for example).

 

the schedule captures it, then schedules out a notification.

 

The notification configuration file can have one or more notification methods and/or escalation methods.

 

In addition there are events based on the plugin return value.

I.E. say we have a high temperature event. After x number of notifications, an event can be triggered to issue a shutdown.

Link to comment

I cannot see emHTTP being a requirement

(Agreed) Never, it should go out to pasture hopefully sooner than later

 

Any ways my worry is even though I started this thread my requirements are so different to most I end up hindering rather than helping.

It seems like it, but no different than anyone else, WeeboTech wants over kill, same difference.

 

I think all this NAGIOS, SQL, etc., etc.. is all way to much. Say its SSMTP, PHP can be enabled to use it no?

 

By default most PHP configurations use sendmail.  You can establish how PHP is setup to handle mail

You should edit /etc/php/php.ini and replace the sendmail_path with this line: sendmail_path = /usr/sbin/ssmtp -t

 

Is this not the foundation this thread is about. Then build on this while Tom works on getting this into the source?

Link to comment

My understanding is Tom is going to add a base mail client, with (assumption) a New base emhttp settings page with a few simple options

1) enabled/disable mail support

2) settings to send mail

3) and a few monitors (disk temp, parity, etc...)

 

After that, people can get as creative as they want, so in this example they have ssmtp (w/openssl) and PHP configured to use it, as unRAID's default. (ex. 5.0.3 anything new/patch/bug fixes, and a 5.0.3.1-> same but with mail support for first round of QA by the community. This way if there is an issue I can use 5.0.3 not 5.0.3.1 and not lose the new and/or bug fixes from 5.0.3)

 

Is this not what the thread is about? This is for the masses, customers that are not techies, just as they would have if they bought a simple NAS device. Click, click, click, click, test, all good, done. Never have to spend a day in the forums to have it work.

 

P.S. I use Blat (http://sourceforge.net/projects/blat/?source=navbar ) on windows (for scripts, logs, etc), self contain .exe, supports everything, including attachments, html if you want to get fancy, and much more (or just keep it plain and simple, ur choice with blat). I bet there has to be something just like it for linux.

 

Link to comment

I agree that a simple email system should be the next thing implemented, in my mind I would love to see the following options / items within.

 

Basic settings:

1) enabled/disable mail sending

2) settings to send mail along with how often

3) when to send, every (user specified time) hrs or when there a problem with a disk or on UPS.

 

Report Options (simple tick boxes y/n):

Display Array status

Display UPS status

Display Disk Number (slot 1,2,3 etc)

Display Disk Serial

Display Disk Capacity / free space

Display Disk Status

Display Disk Temp

Display SMART Status

SMART Attribute 1 (select)

SMART Attribute 2 (select)

SMART Attribute 3 (select)

 

Layout:

 

Array status (OK or NOT)

---------------------------------------

UPS status (Online or Batt)

---------------------------------------

Display Disk Number (slot 1,2,3 etc)

Display Disk Serial

Display Disk Capacity / free space

Disk Temp

SMART Status (OK or NOT with a couple of attributes like Reallocated Sector Ct and Current Pending Sector displayed for example)

SMART Attribute 1

SMART Attribute 2

SMART Attribute 3

---------------------------------------

Display Disk Number (slot 1,2,3 etc)

Display Disk Serial

Display Disk Capacity / free space

Disk Temp

SMART Status (OK or NOT with a couple of attributes like Reallocated Sector Ct and Current Pending Sector displayed for example)

SMART Attribute 1

SMART Attribute 2

SMART Attribute 3

---------------------------------------

etc etc for each disk

 

Something clean and easy to read, can be formatted in html or just plain text that would be emailed to me say once every 6 hours or upon the event there was a problem. I particularly like the idea of having the status of my disks and a few attributes displayed for each though at a glance, I could then create a rule in my mail client and archive the reports so I could track back to when a problem arrived, bit like a smart history.

Link to comment

Any ways my worry is even though I started this thread my requirements are so different to most I end up hindering rather than helping.

It seems like it, but no different than anyone else, WeeboTech wants over kill, same difference.

 

I think all this NAGIOS, SQL, etc., etc.. is all way to much. Say its SSMTP, PHP can be enabled to use it no

Actually I don't want overkill, I want something simple.  It was the request for a 'framework' and the request for parallel delivery of notifications I was trying to answer.

 

Once you add parallel delivery, it requires caching of the data somehow.

It needs to be cached somewhere so each message delivery agent doesn't drop messages.

 

This information can be cached in individual files, one large text file or a easily accessible SQLite database.

 

I looked at a few freeware monitoring solutions today.

So far monit was the most self contained solution.

 

None of them supported a full, easily programmable, parallel notification framework like nagios.

 

MONIT was the nicest self contained one. It only supported email. It was cool in the fact that it did the SMTP notification directly inside the monit daemon.  No need for an external mail too. it handled the caching of events too. All self contained in one config file.

 

I think the initial request for a framework was ambitious.

 

Is this not what the thread is about? This is for the masses, customers that are not techies, just as they would have if they bought a simple NAS device. Click, click, click, click, test, all good, done. Never have to spend a day in the forums to have it work.

 

Then there is no need for a framework for notifications to use all, or any, of the API's per the original post.  SMTP and be done with it.

 

Or drop a mail message in a directory and have some type of scanner that reads this queue and SMTP's it out of the system or calls some program that reads this standard format message and operates on it... I.E. A cache directory of notifications.  like a sendmail queue.

 

Frankly, the framework could consist of "call notify program" with these options and the drop in program it decide how to notify the user.

 

Boom, api solved, now people use drop in API's for their own use.

The most simple API being SMTP a message out of the system somewhere.

Link to comment

lets not got hung up on defining the word framework :)

 

Af ramework for notifications can easily be cron + bash + curl in its simplest form... I am not sure this could be called ambitious ... all we are talking about is a a bunch of notifiers, a documented set of variables and a way to trigger them a.k.a a notification system that forms the frame for further work

 

Several of the notifiers would be one line of bash each i.e. notifo, pushover, boxcar etc

 

As far as I can see it the only real unknown here is the correct mechanism for decoupling the notifiers after the sanity checker has run...

 

unless we want to go for something far more feature rich such as monit etc I am in 2 minds although I am tempted to say the most basic form is the most likely to be implemented in any reasonable time frame.

 

i get the sinking feeling we might be falling into the engineers trap of considering so many variables we dont get anything done.

 

 

 

Link to comment

I dont know weebotech, how much Tom does or does not want to add. The way I see it (and can easily be wrong) it what type of mail support does he add. Sendmail/ssmtp/etc... and enable some components like say PHP to use it and lastly some options for default alerts. Then thats the mail client for plugin author to use if they wish.

 

Example#1, speeding_ant, adds additional alert options or enhancement to what is supplied by unRAID (Simple Features), you would use the default unRAID settings page to then enable email and required settings to receive email but not enable Toms default alerts and use the alert settings Simple Features offer's.

 

Example#2 Someone created or updates an existing plugin, say sickbeard, they do the same, they rely on you enabling email and settings by unRAID but there plugin send commands to ssmtp to have them delivered; alerts around sickbeard stuff.

 

Example#3 Someone creates a plugin the adds a different mail client as they believe ssmtp is not satisfactory, you would use their plugin page to configure everything to get alerts.

 

The value here is someone wants to just have plain vanilla unRAID which sends them health status of unRAID and their hardware thats it and nothing more. This is not available today and what has been requested for years. My understanding is that the thread is about Tom finding out what plugin authors or advance users may want to be the default mail client in unRAID...

 

Link to comment

good sentiment but I want to add one thing...

 

mail is just a single flavour of notification and IMHO not a very good one.

 

Any system proposed should be delivery system agnostic or for me at least (the guy who started this thread) we will end up with a system of limited use.

Link to comment

Im confused, did you start the thread on behave of Tom, or since you started it than "email" (the standard base of notification) is off the table?

 

All appliances and enterprise monitoring suites all base off of email, not growl, etc... As simple end users can get a free email account, the ability to read email can be from a browser which comes with any OS or device. Anything else requires installation of software and/or agent (whether free or not); which some may not want to do.

 

So for you to make that statement

mail is just a single flavour of notification and IMHO not a very good one.
Seems selfish, since we have no form whatsoever from unRAID today and you propose the first base notification by unRAID should be something other than email because
for me at least (the guy who started this thread) we will end up with a system of limited use.
Nice, why bother opening a thread, tell Tom what you want so you're not limited. Because we have ZERO notification as it stands today, thats pretty limited.
Link to comment

The term "analysis paralysis" was coined for threads such as these  :)

 

It's been a long time since I got my hands dirty with coding but as a now ex-geek, I think much like unRAID itself, it needs to be simple.  I'd even go as far as saying let's just do email first and then later look at a more feature rich solution or framework.

Link to comment

The term "analysis paralysis" was coined for threads such as these  :)

 

It's been a long time since I got my hands dirty with coding but as a now ex-geek, I think much like unRAID itself, it needs to be simple.  I'd even go as far as saying let's just do email first and then later look at a more feature rich solution or framework.

 

+1

 

When I was planning my build a year ago, I was trying to avoid was making any one component overly complicated.  Makes system troubleshooting much easier.  Hence unRAID will never host any plugin applications on my setup.  If I want a certain application I will create another VM and set it up for my needs.  I expect unRAID to just provide its base functionality.  I expect nothing more or less from it. 

 

As such I am not in the habit of checking up on it (unRAID) on a daily even weekly basis.  But I do check my email many, many times a day.  If unRAID should detect a problem, this is how I would want to be notified. 

 

All I want to be able to do is check off what I want monitored, when a notification should be sent, and where the notification is to be sent to. 

 

Apply the K.I.S.S principal and move on.  This is what is needed now.  I am sure Tom has more than enough higher priority needs and requests to keep him busy for some time to come.  (Just getting the documentation caught up with the product would be nice :))

 

And yes, I am an EX programmer/hardware type from some time back (Alpha Micro Systems) - now just a very novice Linux user.

 

 

Link to comment

lets not got hung up on defining the word framework :)

 

Af ramework for notifications can easily be cron + bash + curl in its simplest form... I am not sure this could be called ambitious ... all we are talking about is a a bunch of notifiers, a documented set of variables and a way to trigger them a.k.a a notification system that forms the frame for further work

 

Several of the notifiers would be one line of bash each i.e. notifo, pushover, boxcar etc

 

As far as I can see it the only real unknown here is the correct mechanism for decoupling the notifiers after the sanity checker has run...

 

unless we want to go for something far more feature rich such as monit etc I am in 2 minds although I am tempted to say the most basic form is the most likely to be implemented in any reasonable time frame.

 

i get the sinking feeling we might be falling into the engineers trap of considering so many variables we dont get anything done.

 

I apologize. I'm used to writing interfaces and frameworks for production systems that stay in place and are extensible.

I  asked questions, did some research and presented ideas.

 

Doing this is pretty easy for me. I've done it many times in my organization, for clients and for clients of clients.

It requires a few support tools and the rest falls into place.

 

I guess part of the issue is what is being asked for, then it's considered to be too much work or overkill.

 

You can't ask for a framework with all sorts of message delivery options, request parallel delivery of them, then turn around and say it's overkill. It was someone else who suggested a daemon to capture these messages.

 

I'm not misinterpreting this.

What I've said is, you're not looking at the whole picture, and opened discussion on them.

 

In many of the responses, we talk about notifications, but no where is it defined how are these notifications going to occur. Yet it's being discussed what people want to see in the notifications.

 

"trip and alerts get an alarm".

 

And this is not what it's growing into.  The easiest form of this is a syslog scraper using my ofgrep tool and a mail delivery agent. Done.

 

engineers trap of considering so many variables we dont get anything done.

There's no trap. There are software packages out there that provide frameworks.

There are software packages that handle notifications.

Look at a few of them to get ideas.

 

The issue we keep coming back to is.

 

Yes, let's use mail, how are we going to deliver?

Oh wait.. i want to use this other tool too. So, these notifications need to occur in parallel.

 

So now you have to step backward and figure out how you're going to call an API that can do both without dropping messages.

 

A Framework for notifications can easily be cron + bash + curl in its simplest form... I am not sure this could be called ambitious ... all we are talking about is a a bunch of notifiers, a documented set of variables and a way to trigger them a.k.a a notification system that forms the frame for further work

 

It is interesting in that nagios does provide exactly this.

Plugins that use a specific API. They can be in bash, perl, C or any language.

They get scheduled.

They get stored.

They trigger notifications which are external plugins.

There is a specific API for the CHECK plugin, There is a specific API for the notification plugin.

A person can easily write a check plugin or a notification plugin to satisfy their needs.

The status can be reviewed with a birds eye display.

 

I'm not saying we have to use this. However, don't reinvent the wheel either.

Look at what these tools provide and build the API/Framework to suit the needs.

 

http://nagios.sourceforge.net/docs/3_0/pluginapi.html

http://nagios.sourceforge.net/docs/3_0/macros.html

 

From what I've seen in my code review today, big brother also does this.

monit does it nicer in that it's all self contained. Even the outbound SMTP is contained within the daemon that calls the external monitor scripts.  The issue here is, it does not have an API for calling other message notification applications.

 

From what I see so far needs/requirements haven't fully been flushed out.

 

In the simplest form at the current moment.

 

We require a mail delivery agent.

 

To support other network API's, CURL (libcurl and compilation into the PHP core is a big plus).

 

Keep in mind once we have curl and libcurl in PHP. emhttp pages can be used to do lots of other cool things such as post syslogs automatically, download packages from emhttp. scrape directories of plugins to provide a menu of downloadable packages.  But that's bigger then this discussion. Don't jump on my case about it. ;)

Link to comment

I understand nagios but I cannot get out my head that with its flexibility comes complication. It is simply a beast.

 

I am not saying it does fit the requirements exactly (as it does) but last night i got a dual pushover/mail critical syslog alert prototype solution working with 20 odd lines of code and the only requirements were curl and mailx.

 

Edit: seems the mail part doesn't work from unRAID (was prototyping on a Debian box, its some surmountable gotcha though, I just wanted to prove the concept so I knew i wasnt talking out my arse)

Link to comment

I do think this is beginning to sound a bit ambitious for a basic NAS.  We're not monitoring a major power plant, an extensive data center, or a telecommunications center => UnRAID is, at its core, a simple NAS with a few key parameters.

 

There ARE a fair number of events that most of us would like to know => drive failure; fan failure; parity error; drive overheating; and perhaps a "power failure" message sent before a UPS shutdown.    I can't think of much else.    And I can't think of any notification method besides e-mail that's really needed.    If this gets too involved, it'll be yet-another add-on that tends to reduce the potential stability and reliability.

 

 

Link to comment

I understand nagios but I cannot get out my head that with its flexibility comes complication. It is simply a beast.

 

I am not saying it does fit the requirements exactly (as it does) but last night i got a dual pushover/mail critical syslog alert prototype solution working with 20 odd lines of code and the only requirements were curl and mailx.

 

Edit: seems the mail part doesn't work from unRAID (was prototyping on a Debian box, its some surmountable gotcha though, I just wanted to prove the concept so I knew i wasnt talking out my arse)

 

The problem with the parallel pipe approach via syslog is if the client hangs for some reasons, messages may be dropped. if that's OK, then it's not a problem.

 

With a log scraper, this becomes a non issue.

 

I've written many log scraper applications. In fact I have one just about to go into production today.  Files come in on an FTP server and are then forwarded internally to another box all with dynamic regular expressions and client control.

Link to comment

I do think this is beginning to sound a bit ambitious for a basic NAS.  We're not monitoring a major power plant, an extensive data center, or a telecommunications center => UnRAID is, at its core, a simple NAS with a few key parameters.

 

There ARE a fair number of events that most of us would like to know => drive failure; fan failure; parity error; drive overheating; and perhaps a "power failure" message sent before a UPS shutdown.    I can't think of much else.    And I can't think of any notification method besides e-mail that's really needed.    If this gets too involved, it'll be yet-another add-on that tends to reduce the potential stability and reliability.

 

People want to monitor different things. In addition there is hint to have some apps report certain messages back to the notification framework.

 

From what I've seen previously, people want to monitor a few more attributes about the drives and array status.  Not a big deal. It seems everyone's needs vary.

Link to comment