From three products to one – why?
Just last week we launched our new product strategy from previous three individual product to one and I just thought about writing a little bit about the reasons for the this decision. Continue reading

From three products to one – why?
Just last week we launched our new product strategy from previous three individual product to one and I just thought about writing a little bit about the reasons for the this decision. Continue reading
Just back from Barcelona and MWC-2011 I would say that we are heading for “The Perfect Storm” (if you recall the movie it did not end so good…). Who will suffer in this storm and why do I make this reference? Continue reading
We are now searching for new innovative colleagues to join us in our quest to offer our customers a high performing and cost effective monitoring solution for IT management.
As you may know op5 monitor recommends a check interval of 5 minutes escalating to once time per minute if a check becomes critical.
Running a critical system it may be of interest to have the check intervals being even faster, the obvious case would be to decrease the check interval but in some cases that might not be sufficient. In these cases you might want to have your backend system send you alerts immediately.
NSCA is an addon available with op5 Monitor and Nagios allowing you to push passive checks from the backend system. Using this in conjunction with triggers gives you a pretty powerful instant notification system.
There’s multiple guides on how to configure NSCA but the essential portion is to modify nsca.cfg and identify the password and descryption_method used, these needs to be entered into send_nsca on the remote server to ensure that the packages are encrypted and authorized. Once finished you’re good to start the nsca service.
The program available below ensures that you can allow any software that usually writes to a file to forward it’s information via NSCA to Monitor. However there’s some preparation needed.
First of you need to create a pipe/FIFO which the log-messages are passed to, this is easily done using mknod.
mknod /var/log/pipe p
chmod 600 /var/log/pipe
Now point your program to log to /var/log/pipe and you’re good to get started.
#!/usr/bin/perl
#
# Copyright (c) op5 AB, Jonathan Petersson <jpetersson@op5.com>
# All Rights Reserved.
#
# This software has only been tested on Fedora 14, modifications
# may be needed for other distributions and operative-systems.
# send_nsca is required to run in the background to forward
# information to the monitor server.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of version 2 of the GNU General Public License as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it would be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#
# Further, this software is distributed without any warranty that it is
# free of the rightful claim of any third person regarding infringement
# or the like. Any license provided herein, whether implied or
# otherwise, applies only to this software file. Patent licenses, if
# any, provided herein do not apply to combinations of this program with
# other software, or any other product whatsoever.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write the Free Software Foundation,
# Inc., 59 Temple Place – Suite 330, Boston MA 02111-1307, USA.
#use warnings;
use Getopt::Long;
use POSIX qw(setsid);my($host,$check,$r_host,$show_help,$pipe);
sub init {
Getopt::Long::GetOptions(‘host=s’ => \$host,
‘check|c=s’ => \$check,
‘remote|r=s’ => \$r_host,
‘pipe|p=s’ => \$pipe,
‘help|h’ => \$show_help,
);if (!defined($host) || !defined($check) || !defined($r_host) || !defined($pipe)) {
$show_help = 1;
}if ($show_help) {
print <<EOFSyntax: $0 –host <host> –check <check>–remote <remotehost> –pipe <pipe> [options]
This utility is used to manage pipes to nsca
Options:
-h|–help : Show thisFlags:
-H|–host : Hostname (Of the server being monitored)
-c|–check : Name of the check
-r|–remote : Hostname or IP of the monitoring server
-p|–pipe : Pipe to be monitoredEOF
;
exit 1;
}
}sub pipe_to_fork ($) {
my $parent = shift;
pipe my $child, $parent or die;
my $pid = fork();
die “fork() failed: $!” unless defined $pid;
if ($pid) {
close $child;
} else {
close $parent;
open(STDIN, “<&=” . fileno($child)) or die;
}
$pid;
}init;
defined(my $pid = fork) or die “Can’t fork: $!”;
exit if $pid;
setsid or die “Can’t start a new session: $!”;$SIG{INT} = \&terminate;
$SIG{HUP} = \&terminate;
$SIG{CHLD} = ‘IGNORE’;sub terminate {
exit 0;
}open(PIPE, “$pipe”);
while (1) {
while(my $line =
) {
if (pipe_to_fork(‘PT_TO_CHLD’)) {
print PT_TO_CHLD $line;
close PT_TO_CHLD;
} else {
while (my $line = ) {
chomp($line);
open(NSCA, “|send_nsca -H $r_host > /dev/null”);
printf NSCA “%s\t%s\t%s\t%s\n”,”$host”,”$check”,”2″,”$line”;
close NSCA;
exit 0;
}
}
}
}
close PIPE;
Now start the program and define what host and service_check it should update
log_to_nsca.pl –host webserver1 –check “Apache errors” –remote monitor –pipe /var/log/pipe
Replace the applicable hostnames and service_check name with your system parameters and you’ll have instant notification if a log appears.
Successful IT consists of three things!
The IT challenge of today and tomorrow is an unfamiliar turf for the legacy IT departments as the way to build successful IT is being questioned and with reasons that can not be answered with new acronyms or complex technical answers.
The money argument. Continue reading
As most of you’ve seen we release op5 Monitor 5.3 today. This would never been possible without the great team we’ve at op5, and we’re looking to expand even further!
We’re expanding our IT-team to further enrich your experience working and interacting with op5 as a company and allow our personnel to interact with you even better.
The following job-postings will become available at http://www.op5.com/op5/about-op5/career shortly.
Location: Stockholm/Göteborg
op5 AB was founded in 2003. Our mission is simply to help our customers stay on top of their IT environment with our easy to use Open Source IT monitoring solution. All products are based on open source which leads to great flexibility and cost efficieny. We strive to deliver the benifits of open source with the comfort and reliability with us as a provider. The primary Open Source IT management line is Network Management Suite, which consists of op5 Monitor for network monitoring, op5 LogServer for log management and op5 Statistics for network data analysis. We’re currently have a workforce of 30 people in addition to our partners and are positioned in Stockholm and Gothenburg. Further information is available at www.op5.com
Your primary task at hand is to manage op5′s IT-applications. Throughout doing so you shall take ownership of application acquisitions, development and and develop requirements for both internally and externally hosted applications. You should’ve a genuine interest and experience developing and integrating applications.
You’ll be expanding and automating data-flows between applications, both internal and external, to enable further functionality and efficiency for our end-customers and op5 personel. You’ll be a part of our IT team working closely with our infrastructure-resources and your internal customers. You’re expected to be capable of translating non-technical requests and convert them into the expected end-result requested.
Experience
Meritorious expierience
For exceptional candidates we’re willing to find ways to let you work from elsewhere too
What we offer you
Joining op5 you’ll have the opportunity to work in an expanding environment with thrilling projects based on Open Source in a role with a great deal of leverage to have the development of op5 further shaped. We offer you to develop yourself in a company with great potentional, short turnovers, happy customers and great co-workers. You’ll be working with a great bunch of people that’s driven to further expand op5′s business.
Placeringsort: Stockholm/Göteborg
op5 AB grundades 2003. Affärsidén är att utveckla och erbjuda användarvänliga, kostnadseffektiva och funktionella produkter inom området it-drift. Vi tar fram, säljer, vidarutvecklar och supporterar produkter som bygger på Open Source.
Företagets målgrupp är företag, organisationer, stat och kommun med större datanätverk med behov av driftövervakning. Huvudprodukterna är op5 Monitor, op5 Statistics samt op5 LogServer. op5 levererar alltid kompletta system för full funktionalitet med support. Företaget är svenskt och har kontor i Stockholm och Göteborg, idag är vi ca 30 medarbetare. Läs mer på www.op5.se.
Din huvudsakliga uppgift kommer att vara att hantera ägandeskap av op5′s IT-applikationer. I och med detta ska du även ta ansvar för inköp, utveckling och kravställning internt och externt för existerande och nya applikationer. Du ska ha en gedigen tekniskt bakgrund med erfarenhet inom applikations-integration och programmering.
I arbetsuppgiften ingår även att utöka och automatisera data-flöden mellan interna och externt from hostade applikationer för att möjliggöra utökad funktionalitet och effektivitet för slutkunder och intern personal hos op5. Du kommer att ingå i ett team och arbeta nära med infrastrukturs-resurser och dina interna slutkunder/krav-ställare. Du förväntas ha erfarenhet av att anamma icke-tekniska kravställningar och leverera dem efter förfrågat resultat.
Vi söker dig som
Det är även meriterande om du har
För exceptionella kandidater är vi villiga att överväga placering utanför de angivna orterna.
Vi erbjuder dig
Hos oss får du möjlighet att jobba i en utvecklande miljö med spännande projekt inom Open Source i en roll med stor möjlighet att påverka kring tekniska vägval och utveckling av nya produkter.Vi erbjuder möjlighet till personlig utveckling i ett företag med stor potential, korta beslutsvägar, nöjda kunder och trevliga medarbetare. Du jobbar i ett glatt gäng som drivs av att tillsammans utveckla starka och unika produkter. Vårt huvudkontor är beläget i Kista.
Only 6 weeks after the last release, we can now present op5 Monitor 5.3! This release brings several nifty capabilities as well as further results of the ever ongoing improvements of performance.
The Configuration tool in op5 Monitor have for a long time had the ability to scan a network and discover hosts that are not monitored, This scan can now be scheduled to run each night. When the scan discovers one or more new hosts the user is notified and presented with a link leading to the configuration tool. This mean you can minimize the risk of forgetting to monitor hosts added to your network.
And so it has come. The day when Merlin outgrows its infancy is at hand.
The rite of passage into adulthood was smoother than expected, but not without minor bumps. As with people, those bumps made the code stronger.
Testing would be most welcome.
Noteworthy bugfixes in 1.0.0 vs 0.9.0:
The protocol has been changed so that Merlin now adds a signature at the start of each packet. If this signature isn’t found, the offending node is disconnected. This will restore synchronization in case the stream ever gets garbled. It also means that older merlin daemons (0.9.x) won’t be able to talk to newer merlins (>= 1.0).
A serious issue has been found and fixed in the event-reading code where one node might experience crashes after some time of running. The crash only happened if the read-buffer gets filled twice directly after each other and a packet is broken in two each time the buffer gets filled. Subsequent reads would then overwrite other segments of memory, causing random crashes later on (or sometimes not at all, depending on the load-order of configuration items; Yes, it was that weird). This issue has been rather rare. In fact, only one customer that I know of have seen it, and even they only occasionally (although with an unacceptably high frequency, such as a few times per week). The symptoms include daemon and module crashing a few seconds apart at most, and usually on the same second.
An issue in the module has been corrected. This issue could sometimes cause Nagios to hang indefinitely when exiting or reloading, and could at other times lead to Nagios crashing on reload or exit. It appears this only happened upon a hard restart (in which case everything worked, although the exit-procedure resulted in a segfault rather than a clean exit), or when the RESTART_PROGRAM command is submitted to the command pipe, in which case it blocked execution indefinitely by either stalling or crashing.
Apart from those two issues, no flaws have been found in either module or daemon during the month that merlin 0.9.0 has been running at most of our customers and a lot of users worldwide.
Some minor issues have also been fixed, such as:
import and showlog have been fixed to be sturdier when looking at broken or borked logs.
A hexlog function is added (although disabled). Users with troubles on systems where I can’t test are welcome to enable hexlog debugging of
inbound (and outbound) events.
Excessive logging for disconnected or unreachable nodes has been fixed.
The binary backlog api has been fortified. There were no issues in it, although I thought there was, so several checks now ensure that it will
always remain in good working order.
Several thousand new tests have been added to ensure receiver stability when facing broken packets.
Some minor memory leaks have been fixed. They were not repetitive and therefore never endangered the runtime stability, and hence they go
under the ‘minor issue’ list.
Features added in 1.0.0:
One can now set “takeover = no” for a poller node and have the master node ignore taking over checks for that node.
There’s now more indexes on the database, which will significantly improve Ninja’s performance. Some query analysis has been done to
verify this and come up with the indexes now added.
Special thanks to the fine folk (yes, it’s autogenerated) for helping us bring Merlin 1.0.0 out the door by testing, reporting bugs and
submitting patches:
Andreas Ericsson <ae@op5.se>
Ken Menzel <Ken.Menzel@fisglobal.com>
Martin Kamijo <mk@op5.com>
Mattias Bergsten <mattias@westbahr.com>
Ola Sandström <ola.sandstrom@WSPGroup.se>
Per Asberg <perasb@op5.se>
Robin Sonefors <robin.sonefors@op5.com>
Stephan Beal <sgbeal@googlemail.com>
For the full list of contributors, clone the git repository and run
make thanks
At op5 we have a wide verity of client-machines for our employees. At this given time we’ve a good third of each major platform, Windows, Linux and OS X actively running. Being in IT you’ve to be able to support all of them and simultaneously have a stable system to manage your servers with, in our case IT has chosen to go with OS X running Linux and Windows virtually.
As all software vendors are expected to we eat our own dog-food running op5 Monitor internally to monitor our servers and services, both internal and customer-facing. Thanks to this we’ve managed to do major improvements and it helps us with pre-emptive failures.
Going back to the client-side there’s numerous ways of getting notification about host-issues varying from email, SMS or blinking lights. Given that IT using OS X we wanted to utilize a popular add-on called Growl which is used by most IM-clients and other software for a popup notification upon changes. For us this was a given to get working with monitor.
Thanks to the perl-community this was made easy using Net::Growl. There’s a couple of steps to get this working with monitor but once you have it it works like a charm.
First of we need to make sure that your local Growl-installation allows network notifications. To enable this open System Preferences, select Growl, go to Network and select “Listen for incoming notifications” and “Allow remote application registration”. Make sure that you set a password so others wont be able to SPAM you.
Once activated you want to create the notification-script, we’ve chosen to put this into /opt/monitor/op5/notify where we keep the rest of the notification-scripts shipped with monitor. This could obviously be expanded but we wanted to keep it simple for a proof of concept. We’ve named the script growl.pl with the following content:
#!/usr/bin/perl
use warnings;
use strict;
use Net::Growl;
use Getopt::Long;
my ($host, $title, $description, $password, $register);
my $result = GetOptions (
"H:s" => \$host, "host" => \$host,
"t:s" => \$title, "title" => \$title,
"d:s" => \$description, "description" => \$description,
"p:s" => \$password, "password" => \$password,
"r" => \$register,
);
register(
host => $host,
application => "monitor",
password => $password,
) if $register;
notify(
host => $host,
application => "monitor",
title => $title,
description => $description,
priority => 1,
sticky => 'True',
password => $password,
);
Once finished we need to make our local growl-installation aware about the application. To do so run the script as follows: ./growl.pl -h <growl-host> -p <password> -r
Once run you should be able to see the monitor application in your Growl preferences, once verified we’re good to move on.
Now we need to create two new notification-command in monitor.
Host notification:
command_name: host-notify-growl
command_line: $USER3$/notify/growl.pl -H $ARG1$ -p $ARG2$ -t “$HOSTSTATE$” -d ”$HOSTNAME$ is $HOSTSTATE$ $HOSTOUTPUT$”
file: etc/misccommands.cfg
Service notification:
command_name: service-notify-growl
command_line: $USER3$/notify/growl.pl -H $ARG1$ -p $ARG2$ -t “$SERVICESTATE$” -d ”$SERVICEDESC$ on $HOSTNAME$ is $SERVICESTATE$ $SERVICEOUTPUT$”
file: etc/misccommands.cfg
Once finished save your configuration.
Now you need to create a new contact related to the service-checks. The easiest way to do this is simply to clone your pre-existing contact and change host_notification_commands and service_notification_commands to host-notify-growl and service-notify-growl.
In addition to this you need to add host_notification_commands_args and service_notification_commands_args with your IP and Growl password “IP!PASSWORD”.
Now add your contact to a contact-group or relate your contact with a host or a service-check and you should get a popup for each alarm that’s triggered.
Running op5 Monitor gives you some nice performance-graphs generated with PNP. The default template however isn’t always as usable as one might want it to be. A good example is load_average where load1,5 and 15 is separated into different graphs making a bit of a hassle to scroll through each independent graph looking at the differences.
However PNP and monitor has a very easy way of modifying this using PNP templates.
First off you want to create a PNP-template, this should be placed in /opt/monitor/op5/pnp/templates, I’ve chosen to call it check_load.php, notice that the check_command i monitor needs to be identical for monitor to pick up the PNP template.
I snagged the template used by check_bind and made some quick modifications.
<?php $opt[1] = "--vertical-label \"Load Average \" -l 0 -r --title \"Load Average for $hostname / $servicedesc\" "; $def[1] = "DEF:load1=$rrdfile:$DS[1]:AVERAGE " ; $def[1] .= "DEF:load5=$rrdfile:$DS[2]:AVERAGE " ; $def[1] .= "DEF:load15=$rrdfile:$DS[3]:AVERAGE " ; $def[1] .= "LINE2:load1#008000:\"load1\\t\\t \" " ; $def[1] .= "GPRINT:load1:LAST:\"%3.4lf\\t\" " ; $def[1] .= "GPRINT:load1:AVERAGE:\" %3.4lf\\t\" " ; $def[1] .= "GPRINT:load1:MAX:\" %3.4lf\\n\" " ; $def[1] .= "LINE2:load5#0C64E8:\"load5\\t\\t \" " ; $def[1] .= "GPRINT:load5:LAST:\"%3.4lf\\t\" " ; $def[1] .= "GPRINT:load5:AVERAGE:\" %3.4lf\\t\" " ; $def[1] .= "GPRINT:load5:MAX:\" %3.4lf\\n\" " ; $def[1] .= "LINE2:load15#E80C3E:\"load15\\t\\t \" " ; $def[1] .= "GPRINT:load15:LAST:\"%3.4lf\\t\" " ; $def[1] .= "GPRINT:load15:AVERAGE:\" %3.4lf\\t\" " ; $def[1] .= "GPRINT:load15:MAX:\" %3.4lf\\n\" " ; ?>
Make sure that the permissions is ok for the file chown monitor:apache check_load.php.
Now go into monitor:
Once the service-check has been done you should have a new graph looking something like this:
