Personal Workflow Blog - Comments

When having good relationships with package maintainers can also be a curse - Krysztof von Murphy

Krysztof von Murphy — Wed, 27 Feb 2013 22:19:54 +0100

Tiens, je savais pas que tu avais pris tant de galon sur un outil qui me sert pas mal à titre pero depuis longtemps ;o) Merci !

Waiting for Munin 2.0 - Performance - Asynchronous updates - Steve Schnepp

Steve Schnepp — Mon, 05 Dec 2011 14:13:00 +0100

@Özgür: via the munin-async-server's little brother : munin-async-client. It spoolfetchs from the spool files back to the master.

It doesn't need to run on the same host : you can even periodically rsync the spool files at a lower interval than 5 min.

Waiting for Munin 2.0 - Performance - Asynchronous updates - Özgür Kuru

Özgür Kuru — Mon, 05 Dec 2011 11:12:19 +0100

munin-async-server is connecting to local munin-node and fetch data after that store data in spool files. every thing okay. But How master server get data from nodes?.

Waiting for Munin 2.0 - Keep more data with custom data retention plans - Steve Schnepp

Steve Schnepp — Tue, 08 Nov 2011 11:07:29 +0100

@Cosimo: not really. It would require a database to store the text notes. And for now, munin tries to be as light-weight to install and use.

Waiting for Munin 2.0 - Keep more data with custom data retention plans - Cosimo

Cosimo — Fri, 07 Oct 2011 00:04:16 +0200

Is also a feature of 2.0 the possibility to annotate graphs to mark specific timestamps or with a text note?

Waiting for Munin 2.0 - Native SSH transport - Matt Kaufman

Matt Kaufman — Sat, 16 Jul 2011 00:42:06 +0200

Perfect! I wasn't too familiar with munin's internal communication and didn't know if I could use it like this.....

I was actually just going to use netcat myself too, to do it. Hehe! However, I hadn't gotten to checking its messagings internally yet. Yay!

Waiting for Munin 2.0 - Keep more data with custom data retention plans - Steve Schnepp

Steve Schnepp — Thu, 09 Jun 2011 20:59:17 +0200

Absolutely :-)

Waiting for Munin 2.0 - Keep more data with custom data retention plans - scott

scott — Thu, 09 Jun 2011 13:19:25 +0200

does "especially useful when zooming" mean that zooming is a feature of 2.0?

CGI on steroids with FastCGI, but on a CGI-only server - The FastCGI wrapper - Mike Robinson

Mike Robinson — Sun, 01 May 2011 21:02:17 +0200

To me, the overwhelming advantage of FastCGI vs. mod_perl comes when the "web pages" on a site begin to vary from trivial, fast-running ones, to reports that might take hundreds of megabytes and hundreds of wall-clock seconds to complete. Suddenly, "an 'httpd' process instance" has ballooned from being a lean-and-mean process, in the eyes of the operating system, to a sluggish thousand-pound gorilla. Operating systems react slowly and awkwardly and inefficiently to such radical changes that come without warning. (They also recover poorly, when the "thousand pound gorilla" that it moved heaven-and-hell to accommodate, suddenly becomes a docile mouse again ... and then, oh my, ANOTHER 'httpd' instance has just turned into a gorilla!)

"Be nice to the operating system, and it will be nice to you." If not (and if you happen to remember this old TV commercial...) "it's not NICE to fool with Mother Nature..." The OS will accommodate you, because that's its job, but you will pay a price.

FastCGI moves the actual processing-work an arm's length away from the 'httpd' processes, allowing 'httpd' to continue to be fast-and-light at all times, and to continually present consistent run-time characteristics no matter what.

Depending on the FastCGI container (application server...) that you use (or build...), you can distribute the requests that the web-server is sending, among a "suitable" mixture of CPUs and service-processes. If you want to build queues, to use batch-processing software and so on, that also is much easier to do with the FastCGI way of doing things.

In short, 'httpd' is now able to remain as what it is best at being: a user-interface of sorts, able to field thousands of requests per second, but no longer -itself- burdened by the responsibility of actually servicing those requests. "It's just the delivery boy." Meanwhile, the FastCGI stream is serviced by a -team- of more-or-less specialist processes that may be running on any number of back-end computers. The results are predictable, debuggable, and scalable.

Waiting for Munin 2.0 - Native SSH transport - Steve Schnepp

Steve Schnepp — Thu, 07 Apr 2011 13:40:24 +0200

Thanks for your remark : I edited the post to have a correct code example. I also integrated (r4153) the patch you posted in trunk.

Waiting for Munin 2.0 - Native SSH transport - Tenzer

Tenzer — Wed, 06 Apr 2011 19:21:57 +0200

Hi, I just want to let you know that the sample SSH address you have in this post will not work. You should leave out the colon (:) from the string, otherwise the perl URI module will not be able to parse the hostname corretly, and this leaves Munin trying to connect to "host.example.com:" which is not a valid hostname.

I have submitted a patch which enables you to specify the port number of the remote SSH server on this ticket: http://munin-monitoring.org/ticket/...

Otherwise good job on the blog, I couldn't really find much other information on how to set this up :)

Waiting for Munin 2.0 - Performance - Asynchronous updates - Edward Groenendaal

Edward Groenendaal — Fri, 02 Jul 2010 03:10:35 +0200

These are very exciting changes that I'm looking forward to, I think the proxy node is a good compromise on the simplicity vs functionality front. The only reason our company is using munin is the simplicity of the plugins, allowing easy and quick additions.

A Poor Man's Munin Node to Monitor "Hostile" UNIX Servers - Steve Schnepp

Steve Schnepp — Sat, 12 Jun 2010 12:14:44 +0200

Yes, you just have to install the files in a directory. But since it doesn't listen on port 4949 (since port opening is usually restricted on hostile hosts)

So you have to either :

create an SSH pipe like the described inetd+ssh
use the upcoming munin 2.0 SSH-transport feature.

A Poor Man's Munin Node to Monitor "Hostile" UNIX Servers - Sanjay

Sanjay — Sat, 12 Jun 2010 00:06:18 +0200

Is pmmm replacement for munin-node or do I still need to install some thing on node ?
Is installation means just copy files & directory which is mentioned here
http://pwkf.svn.sourceforge.net/vie...

Sed is much slower than Perl, or not... - Steve Schnepp

Steve Schnepp — Fri, 27 Nov 2009 19:51:40 +0100

Thx.

About i18n, I'm wondering if it's the local part or the encoding that cause this massive slowdown...

Sed is much slower than Perl, or not... - Andreas Schamanek

Andreas Schamanek — Fri, 27 Nov 2009 10:53:24 +0100

Indeed a very interesting finding. Thanks for sharing.
One cannot but repeat again and again how important it is to set locales properly with every piece of code. Personally, I am no fan of i18n the command line.

A Simple Dns Server for a SOHO Network - Steve Schnepp

Steve Schnepp — Fri, 21 Aug 2009 14:31:35 +0200

The things I discovered so far are :

ZeroConf based solutions, mostly using UPnP
Have a small server like Pdnsd.

Checked or Unchecked Exceptions for Legacy Code ? - Steve Schnepp

Steve Schnepp — Fri, 21 Aug 2009 14:21:18 +0200

Yeah, same here in Java :

  try {
     processThing();
  } catch (Exception e) {
     // Do nothing
  }

Don't ever underestimate the power of laziness in the same team as ignorance :-)

Checked or Unchecked Exceptions for Legacy Code ? - Krystof von Murphy

Krystof von Murphy — Fri, 21 Aug 2009 14:00:47 +0200

Whatever the choice of the developer, that’as better than these "checked" exceptions:

BEGIN
 (SQL code...)
EXCEPTIONS 
 WHEN OTHERS THEN NULL ;
END ;

(People should be shot for that.)

A Simple Dns Server for a SOHO Network - Krystof von Murphy

Krystof von Murphy — Fri, 21 Aug 2009 13:51:37 +0200

Me too.

A problem: it means a dedicated server, always on, and another point of failure (server down, no network). For a home network, I’d like to see it integrated into the ADSL box (which is a DHCP server already). For the moment, I live with manual hosts files.

Does a distributed DNS exist, where any Linux/Win/Mac on the network can be "the" DNS ?