<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.3492" name=GENERATOR>
<STYLE>v\:* {
BEHAVIOR: url (#default#vml)
}
</STYLE>
<STYLE>v\:* {
BEHAVIOR: url (#default#vml)
}
</STYLE>
<!--IncrdiXMLRemarkStart>
<IncrdiX-Info>
<X-FID>79F8FDE2-E90C-4120-9A2C-E484CCFAA091</X-FID>
<X-FVER></X-FVER>
<X-FIT></X-FIT>
<X-FILE></X-FILE>
<X-FCOL></X-FCOL>
<X-FCAT></X-FCAT>
<X-FDIS></X-FDIS>
<X-Extensions></X-Extensions>
<X-BG>cid:81339588-2ECE-492A-B0A5-77189BE0F5E3</X-BG>
<X-BGT>repeat</X-BGT>
<X-BGC>#f3eded</X-BGC>
<X-BGPX>left</X-BGPX>
<X-BGPY>top</X-BGPY>
<X-ASN></X-ASN>
<X-ASNF></X-ASNF>
<X-ASH></X-ASH>
<X-ASHF></X-ASHF>
<X-AN></X-AN>
<X-ANF></X-ANF>
<X-AP></X-AP>
<X-APF></X-APF>
<X-AD></X-AD>
<X-ADF></X-ADF>
<X-AUTO>X-ASN,X-ASH,X-AN,X-AP,X-AD</X-AUTO>
<X-CNT>;</X-CNT>
</IncrdiX-Info>
<IncrdiXMLRemarkEnd--></HEAD>
<BODY
style="BACKGROUND-POSITION: left top; SCROLLBAR-FACE-COLOR: #c6d7ff; FONT-SIZE: 12pt; MARGIN: 0px 10px 10px; SCROLLBAR-HIGHLIGHT-COLOR: #ffffff; SCROLLBAR-SHADOW-COLOR: #ffffff; COLOR: #010158; SCROLLBAR-3DLIGHT-COLOR: #7b9ed6; SCROLLBAR-ARROW-COLOR: #4a6184; BACKGROUND-REPEAT: repeat; FONT-FAMILY: Arial; SCROLLBAR-DARKSHADOW-COLOR: #bebebe"
text=#010158 vLink=#0000ff aLink=#0000ff link=#0000ff bgColor=#f3eded
background=cid:159121704@10022009-1596 scroll=yes SIGCOLOR="11031552">
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT size=2>Your comment
reminds me of this </FONT></DIV>
<DIV dir=ltr align=left><A
href="http://www.flickr.com/photos/straup/2247714432/"><U><FONT
color=#0000ff><FONT
size=2>http://www.flickr.com/photos/straup/2247714432/</FONT></U></FONT></A></DIV>
<DIV dir=ltr align=left><FONT size=2></FONT> </DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT size=2>On a more
serious note, I look forward to storing hobbit information in a relational
database.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT size=2>Imagine the
reporting flexibility we could have with SQL.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT size=2>- Give me
all server with root file system smaller than 8gb that have been over 80% in the
last 3 months.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT size=2>- give me a
list of all servers with operating system X that are running custom test
Y.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT size=2>There will
be no limits to the level of reporting.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT size=2>I think it
would be a bad idea to abandon the old RRD in favour of RDB, but to rather have
the ability to use RRD by default, and RDB as an additional reporting
structure.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT size=2>This would
limit the dependency issue.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT size=2>Using an RDB
would also allow for custom defined data points.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT size=2>Currently,
with RRD, we only store 48 hours of data points at 5 minutes
granularity.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT size=2>In an RDB we
could define our own retention period.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT size=2>Because of
the way RDBs work, there would probably need to be a purge job to purge old
data, and accumulate it into data points for the table storing the next
level of granularity.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT size=2>It could be
an interesting project, but would need to be very carefully constructed to
prevent performance issues.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT size=2>Do we have
any database architects on the list?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT
size=2>Regards</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=159121704-10022009><FONT
size=2> Vernon</FONT></SPAN></DIV>
<DIV dir=ltr align=left></SPAN><BR> </DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Brian Catlin [mailto:bcatlin@gmail.com]
<BR><B>Sent:</B> Tuesday, 10 February 2009 11:43 AM<BR><B>To:</B>
hobbit@hswn.dk<BR><B>Subject:</B> Re: [hobbit] Xymon 4.3.0: Beta version
available on Sourceforge<BR></FONT><BR></DIV>
<DIV></DIV>
<TABLE id=INCREDIMAINTABLE cellSpacing=0 cellPadding=2 width="100%" border=0>
<TBODY>
<TR>
<TD id=INCREDITEXTREGION dir=ltr style="FONT-SIZE: 12pt; DIRECTION: ltr"
vAlign=top width="100%">
<DIV>How about you alert on the incoming as usual, then store the events
(batched or not) into the backend database so that reports can be
developed for management, history could use for lookups,
etc... That might make this a little more palatable to you, and a lot
more usable to those of us who have to prove to management that the
time we invest in getting this doing what we want is not a drain on their
resources.
<DIV> </DIV>
<DIV>Reports are management blood, no reports - no use... (for managers) -
I have had managers tell me this in the past. (on the other hand - two
weeks after I installed clients on one department's sun servers, the
manager had some questions about server performance over the past few
weeks = was quite pleased and surprised when I gave him a spreadsheet that
laid out the data for all his servers in 1/2 hour, as was even more please
when I showed him how to view his page of servers.)</DIV></DIV>
<DIV> </DIV>
<DIV>Another thing that using a database to store history in - much better
security for those of us who work in security realms and have to protect
data - alarm history can give a lot of info away to a hacker if they
gain access to the server running the master.</DIV>
<DIV>With a database, it can be secured and only have authorized users
that access it.</DIV>
<DIV> </DIV>
<DIV>One thing everyone should remember - in business, as in life,
perception is 80 % of the way things are seen - think
about it... </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV id=INCREDISIGNATUREID>
<DIV>lurch@inorbit.com</DIV></DIV>
<DIV id=IncrediOriginalMessage dir=ltr><I>-------Original
Message-------</I></DIV>
<DIV> </DIV>
<DIV id=receivestrings>
<DIV dir=ltr style="FONT-SIZE: 11pt"><I><B>From:</B></I> <A
href="mailto:henrik@hswn.dk">Henrik Størner</A></DIV>
<DIV dir=ltr style="FONT-SIZE: 11pt"><I><B>Date:</B></I> 2/9/2009 4:40:49
PM</DIV>
<DIV dir=ltr style="FONT-SIZE: 11pt"><I><B>To:</B></I> <A
href="mailto:hobbit@hswn.dk">hobbit@hswn.dk</A></DIV>
<DIV dir=ltr style="FONT-SIZE: 11pt"><I><B>Subject:</B></I> Re: [hobbit]
Xymon 4.3.0: Beta version available on Sourceforge</DIV></DIV>
<DIV> </DIV>
<DIV>Hi Giovanni,</DIV>
<DIV> </DIV>
<DIV>On Mon, Feb 09, 2009 at 07:21:43PM -0200, <A
href="mailto:giovanni@redix.com.br">giovanni@redix.com.br</A> wrote:</DIV>
<DIV>></DIV>
<DIV>> Hi Henrik,</DIV>
<DIV>></DIV>
<DIV>> I was reading about 4.5 release and maybe
its time to think about store</DIV>
<DIV>> the data into a Database like MySQL/PostgreSQL, if you do that
far more</DIV>
<DIV>> contributors can start to colaborate with customs
web-interfaces, reports,</DIV>
<DIV>> etc etc.</DIV>
<DIV> </DIV>
<DIV>this subject comes up once in a while. I have two problems with
it:</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>1) I've never done any programming that interfaces to a database,
so</DIV>
<DIV>it would mean digging into one more API - but that is something
I</DIV>
<DIV>could probably handle.</DIV>
<DIV> </DIV>
<DIV>2) The real problem is that unless the database is co-located with
the</DIV>
<DIV>Xymon server, then your monitoring suddenly becomes dependant
on</DIV>
<DIV>a remote database-server. So what happens if your database server
loses</DIV>
<DIV>the network connection to the Xymon server ? You won't get any
alerts</DIV>
<DIV>from Xymon, because it has no data available to generate alerts
from.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>It's the same reason that has kept me from using SAN storage for
my</DIV>
<DIV>production Xymon server at work. Much too complex for my taste,
far</DIV>
<DIV>too many ways it can break.</DIV>
<DIV> </DIV>
<DIV>And the time when you need your Xymon server the most is
*exactly*</DIV>
<DIV>when everything else has gone down in flames.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>What I *would* consider is to create a module like the
hobbitd_filestore</DIV>
<DIV>module, except it sends the status-data off to a database
somewhere.</DIV>
<DIV>Or even an external module for hobbitd_rrd that gets all of the</DIV>
<DIV>parsed data we collect and use as the basis of all of the
graphs.</DIV>
<DIV>Such modules would be very easy to write for someone who knows
how</DIV>
<DIV>to do programming with the database API - my guess is that it
wouldn't</DIV>
<DIV>take more than a day or two.</DIV>
<DIV> </DIV>
<DIV>So if you know someone who could voluteer for such an add-on, I
would</DIV>
<DIV>be very happy to work together with him/her on putting such an
add-on</DIV>
<DIV>together.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Henrik</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>To unsubscribe from the hobbit list, send an e-mail to</DIV>
<DIV><A
href="mailto:hobbit-unsubscribe@hswn.dk">hobbit-unsubscribe@hswn.dk</A></DIV>
<DIV> </DIV>
<DIV> </DIV></TD></TR>
<TR>
<TD id=INCREDIFOOTER width="100%">
<TABLE cellSpacing=0 cellPadding=0 width="100%">
<TBODY>
<TR>
<TD width="100%"></TD>
<TD id=INCREDISOUND vAlign=bottom align=middle></TD>
<TD id=INCREDIANIM vAlign=bottom
align=middle></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE><pre>
NOTICE: This email and any attachments are confidential.
They may contain legally privileged information or
copyright material. You must not read, copy, use or
disclose them without authorisation. If you are not an
intended recipient, please contact us at once by return
email and then delete both messages and all attachments.
</pre></BODY></HTML>