Plugin not working - warnings? replied by khudgins @ Tue, 01 Jul 2008 15:22:11 -0000

khudgins — Tue, 01 Jul 2008 15:22:11 -0000

I’ve got a plugin that tests okay (scout -p plugin.rb) but I’m getting a warning. (I’m monkeypatching Time)

Would this cause the plugin to fail in real-world use?

undefined method `[]' replied by cyu @ Sat, 28 Jun 2008 16:10:25 -0000

cyu — Sat, 28 Jun 2008 16:10:25 -0000

I ran into this error while setting up our Scout Client for Skribit:

F, [2008-06-28 09:00:51 #30380] FATAL -- : An HTTP error occurred:  undefined method `[]' for false:FalseClass

If you run into this error, try removing your /home/mongrel/.scout/client_history.yaml file. That worked for me.

Perhaps the client should handle the scenario where a blank client_history.yaml file is created? Not sure how it got that way.

—Calvin

New Scout Gem Released replied by seebq @ Wed, 11 Jun 2008 16:02:32 -0000

seebq — Wed, 11 Jun 2008 16:02:32 -0000

Scout 2.0 has been released!

See our blog post for more details:

http://blog.scoutapp.com/articles/2008/06/09/ev…

Enjoy!

Interruption of Service 06/11/2008 replied by seebq @ Wed, 11 Jun 2008 16:01:00 -0000

seebq — Wed, 11 Jun 2008 16:01:00 -0000

Scout experienced problems collecting data and reporting from 2:30 – 9:30 PM EST (6:30 – 13:30 GMT). During this time, intermittent data was collected from Scout clients and the Scout web interface was not available.

The problem stems from an upgrade we are still working on to provide better resources for the virtualized Scout instances across the data centers. More specifically, we’re experiencing issues running virtualized 32-bit instances on 64-bit hosts. We are now running on much better hardware, and will continue to work towards improving the reliability and speed of the Scout service.

We care deeply about reliability and rely on Scout ourselves to monitor our own servers. While we do not have a Service Level Agreement (SLA), we want to compensate you if were negatively affected by the outage. Please contact us at support@highgroove.com and we’ll take care of it.

Interruption of Service 5/21/2008 replied by seebq @ Wed, 21 May 2008 19:26:33 -0000

seebq — Wed, 21 May 2008 19:26:33 -0000

We had a quick outage of one of the servers in the load balance pool for a few minutes today (around 3:10pm EST / 12:10pm PST lasting for about 10-15 minutes). Technically, the one server did not go down, but rather, became so overloaded that requests timed out. That means a portion of the requests, including reports, alerts, and errors from the client were sent to a server that was unable to respond. We apologize for any inconveniences.

If your client continues to run instead of closing down, due to a hung HTTP connection, please consider upgrading the scout client using:

sudo gem install scout

to get the latest version.

As always, we care deeply about reliability and rely on Scout ourselves to monitor our own servers. While we do not have a Service Level Agreement (SLA), we want to compensate you if were negatively affected by the outage. Please contact us at support@highgroove.com and we’ll take care of it.

Uptime plugin replied by itsderek23 @ Wed, 21 May 2008 05:44:35 -0000

itsderek23 — Wed, 21 May 2008 05:44:35 -0000

Rafi,

Sorry for the delay – currently the uptime plugin doesn’t generate any alerts, so you’ll only get an email notification on an error.

Uptime plugin replied by rafi @ Thu, 15 May 2008 19:02:00 -0000

rafi — Thu, 15 May 2008 19:02:00 -0000

Just checking to make sure the uptime plugin does what I think, b/c I’m not sure I totally understand the email notification thresholds.

If I set up email notification for the uptime plugin (which isn’t parameterized), when will I get emailed by Scout?
Only after a reboot?
All day until uptime is >1?
Something else?

Interruption of Service 5/11/2008 replied by seebq @ Sun, 11 May 2008 13:26:20 -0000

seebq — Sun, 11 May 2008 13:26:20 -0000

The issue has been resolved. Clients were unable to checkin, and data was unable to be collected for about one hour.

Interruption of Service 5/11/2008 replied by seebq @ Sun, 11 May 2008 13:07:36 -0000

seebq — Sun, 11 May 2008 13:07:36 -0000

On Sunday May 11 2008 at around 8:00 am EST (5:00 am PST), we had a minor issue with one of the mysql db masters. We are working to resolve the issue.

Batch plugin updates replied by itsderek23 @ Fri, 09 May 2008 02:38:11 -0000

itsderek23 — Fri, 09 May 2008 02:38:11 -0000

Will,

Currently, you have to make the change on each plugin – here’s an idea though:

What if in the plugin settings, we add a checkbox that says “Update All Plugin Installations”. When checked, it will update all plugins that match this plugin’s URL.

Would that meet your needs?

Plugin security replied by rafi @ Thu, 08 May 2008 18:44:36 -0000

rafi — Thu, 08 May 2008 18:44:36 -0000

A couple of ideas:

A. Have the plugin read the password from a file off the disk. For each machine Scout is monitoring, put that password file somewhere only the Scout client user has access to.

B. Set the DB password in an environment variable in the Scout user’s crontab, or just in the crontab line for Scout. Use the password from env in your plugin script.

Plugin security replied by wkoffel @ Wed, 07 May 2008 21:32:17 -0000

wkoffel — Wed, 07 May 2008 21:32:17 -0000

Of course, I found the “How does Scout approach security?” mere minutes after posting this. :-) I think that answers most of my questions. Still not quote confident that I want DB passwords in my plugins. Anyone else have a favorite solution to that issue?

Plugin security replied by wkoffel @ Wed, 07 May 2008 21:23:23 -0000

wkoffel — Wed, 07 May 2008 21:23:23 -0000

What can the admins tell us about plugin security? For example, I’d like to execute some DB queries directly in a plugin (not necessary to load my whole Rails environment). But to do that, I’d need a DB password in the plugin.

I haven’t sniffed to see, but are the connections that the scout client makes encrypted?

How about the security of the plugin store at scoutapp.com? Would it be inadvisable to store proprietary information in a plugin to be distributed by the scout server?

Batch plugin updates replied by wkoffel @ Wed, 07 May 2008 19:40:51 -0000

wkoffel — Wed, 07 May 2008 19:40:51 -0000

Is there a way in the web interface (or planned support for) batch updating plugin settings?

For example, I have 13 clients set up, monitoring disk space. I’d like to change all my capacity alerts to come at 80% instead of the default 90%, or I want a plugin running on a bunch of machines to run every 5 minutes instead of the default 10 minutes.

Ideally, my account would have plugin configs for each plugin, and I could assign those configs to machines, in batch.

Do I currently need to go through each machine’s plugins and make the change individually?

Interruption of Service 4/28/2008 replied by seebq @ Fri, 02 May 2008 22:45:30 -0000

seebq — Fri, 02 May 2008 22:45:30 -0000

Just a follow up—we now have a solution in place to ensure that if the server hosting the community plugins becomes unavailable, we can keep on chugging!

cron interval replied by seebq @ Fri, 02 May 2008 22:44:22 -0000

seebq — Fri, 02 May 2008 22:44:22 -0000

Randy, that’s an excellent suggestion. It will work now, but we may in the future decide not to accept report data on the time interval. Thanks!

cron interval replied by randy @ Sat, 26 Apr 2008 20:54:37 -0000

randy — Sat, 26 Apr 2008 20:54:37 -0000

I am on the free plan but have cron set up to run every 10 minutes. It seems to be working, what happens if we leave it this way? It would be nice if we could run it more frequently to take advantage of scripts that monitor and restart services, but have it only accept reports at the time intervals allowed.

Scout Performance Impact replied by seebq @ Sat, 26 Apr 2008 02:00:23 -0000

seebq — Sat, 26 Apr 2008 02:00:23 -0000

Also, if you’re worried about CPU cycles being stolen by Scout, you can always run scout using nice to give it a low priority:

/usr/bin/nice -n 10 /usr/bin/scout

We’ve found the performance impact to be very very low, nonetheless.

Interruption of Service 4/28/2008 replied by seebq @ Sat, 26 Apr 2008 01:56:19 -0000

seebq — Sat, 26 Apr 2008 01:56:19 -0000

Just to clarify—only one instance of the scout virtualized setup experienced problems and had to be rebooted. Only community plugins were affected by the downtime, which happens to be a majority of the plugins, and thus a majority of clients did not run plugins during this time. Clients were still checking in, thus monitoring still functioned. We are currently working on a solution to make sure this does not happen again.

Interruption of Service 4/28/2008 replied by itsderek23 @ Fri, 25 Apr 2008 22:13:03 -0000

itsderek23 — Fri, 25 Apr 2008 22:13:03 -0000

Scout was inaccessible from 1:50 – 2:28 PM PST (20:50 – 21:28 GMT). During this time, no data was collected from Scout clients and the Scout web interface was not available.

We have a load-balanced setup that is designed to handle a failure like this. Obviously, it did not perform. We will update this thread when we determine the cause.

Scout Performance Impact replied by itsderek23 @ Wed, 23 Apr 2008 14:59:53 -0000

itsderek23 — Wed, 23 Apr 2008 14:59:53 -0000

Christian,

We built Scout so that it’s impact on performance would be very small. Here’s the basics:

In our tests, the Scout client used btw 5-15 MB of memory when running
The Scout client only runs when it’s executing the plugins (ex: every 30 minutes on the free plan) so it doesn’t use resources when it’s not active.
The impact on the server load wasn’t detectable

The client is extremely light – most of the work is done by the plugins. You could build a plugin that is extremely intensive – one that requires a lot of libraries maybe – and it will certainly use more resources. So in the end, it’s up to you.

Also note that you can use Scout to monitor itself – you can use the server load plugin and monitor the memory usage of the “ruby” process to get a feel.

Scout Performance Impact replied by christian @ Tue, 22 Apr 2008 21:46:29 -0000

christian — Tue, 22 Apr 2008 21:46:29 -0000

I have a basic question about scout that I didn’t find in the help section.

Given a web app on a server that doesn’t use Ruby, what the performance impact of installing not just the Scout Client, but also the Ruby engine as well? Can you give us some numbers so we have a sense of it?

Plugins WANTED! replied by seebq @ Tue, 22 Apr 2008 16:27:12 -0000

seebq — Tue, 22 Apr 2008 16:27:12 -0000

Matt—

I haven’t checked out m|monit, but I actually do use monit to keep all the components running for Scout. Unfortunately though, getting an e-mail about a process ballooning in memory and then restarting doesn’t really help me diagnose why it did it in the first place, or what was going on at the time. I’m with you (and probably preaching to the choir about how Scout helps to alleviate this problem by showing you what other factors could have contributed to this), though!

And having a scout plugin that works in conjunction with monit is a fantastic idea. Brilliant, even.

I am testing a new plugin called, simply enough: Keep Process Running and it couldn’t be simpler. I think interrogating the monit file is an awesome idea too.

Keep ‘em coming! Thanks for the feedback!

Plugins WANTED! replied by Matt @ Sat, 19 Apr 2008 20:49:37 -0000

Matt — Sat, 19 Apr 2008 20:49:37 -0000

What about an interface to monit? The monit folk recently released their “m|monit” project (http://tildeslash.com/mmonit/).

Scout looks a heck of a lot cooler, has a great, defined plug-in interface, is much further along, and doesn’t require another process running (should monit monitor m|monit, too??)—in short, it seems like a far superior solution.

What about a plugin that lets you interface with the monit process already running on our servers? I see the plugin library already has a simple script to restart mongrel. But the monit process monitoring/restarting syntax is significantly more advanced: why re-invent the wheel?

It could start out simply enough: interrogate the monit conf file and execute commands held within, but seems a short hop to then replace all that m|monit does.

Interested in the everyone’s thoughts!!

Thanks,

—
Matt

Graphs not in my timezone replied by itsderek23 @ Fri, 18 Apr 2008 19:53:28 -0000

itsderek23 — Fri, 18 Apr 2008 19:53:28 -0000