Monitoring

[brononius]

Maybe a new feature in linuxmce is a monitoring tool?

I don't know how (if?) you guys check today the bandwidth, disk space, services...?
Personally i use cacti a lot, i'm a network engineer, therefor i use it very much. It's easy to install (through apt-get install cacti), easy to maintain (webinterface / snmp based), nice to see (cool graphs, up/down status).

This way, we could easily manage/troubleshoot/alert some extra stuff:

• Usuage: network bandwidth, internet load, memory use, disk space...
• Status: orbiter ports listening, mysql running, domotica link there, phones up...
• Log: very nice syslog server in there...
• Alerting: send mails/sms when something happens, run scripts...
• ...

And of course, when you've got other devices in your network that are snmp capable (aren't they all these days?), you can add them as well.
I'm thinking about a switch, a modem/router, normal pc's, ip phones, home automation links, power meters, water meters...


One of these days, i'll install cacti on my linuxmce server (I first need to take of backup of it  ).
And after a couple of day, i'll see to extract some graphs as an example.

[tschak909]

We would love more integration like this. As always, we're accepting patches for new features, etc. And we can help you in integrating this if you're willing and able to put in the elbow grease.

-Thom

[brononius]

No problem to help, but to be honest, i'm a network guy with some linux experience and web knowledge.
So don't expect real programming of me. I would like to able to do it. But you can't do everything in your life.

If you can point me on the way how/what/where i should do, i can have a look.

[cfernandes]

Hi brononi,

  i have some Knowledge and free time   to help .


 

[brononius]

Great.
What can/must we do in order to get this up and running?

I see 4 major parts:

• Installation of the soft (cacti + additional plugins, templates...)
  This should be the easiest part
  
  
• Configuration of 'standard' stuff (fe monitoring services, bandwidth, disk usuage...)
  Of course, all configs (=hardware) are different. So it will be more a documentation part?
  
  
• Link with linuxmce
  Webpages links, link with databases (fe user logins?)
  
  
• Packaging
  Don't have a clue how to do this.
  
  

[dextaslab]

Rather than running cacti, I put forward using plain old mrtg as impementing scripts will be easier and lighter, as well as making changes/updates;

example;
-- create core mrtg.cfg --
do for each hdd on core (or mount points) from database - insert basic template filling details.
do for each NIC on core in database - insert basic template filling details.
Insert standard free memory template
Insert standard process template
etc..

--Create MD mrtg.cfg's --
do for each MD in database
   do for each hdd in current MD - insert basic template filling details.
   do for each NIC in current MD - insert basic template filling details.
   Insert standard free memory template
   Insert standard process template
   etc..
loop
 
*Advantages:
 As long as mrtg is installed on all MD's the script just has to create and place/replace the mrtg.cfg on each MD (/usr/pluto/diskless/<md#>/etc/mrtg.cfg
 You just have to create an appropriate place on the core that is mounted on all MD's to store the image and html files; /home/public/data/mrtg ?

[tschak909]

I'm of the opinion that talk only goes so far.

Build a prototype, then figure out what you need to make that prototype into production.

Working models are currency.

-Thom

[brononius]

Rather than running cacti, I put forward using plain old mrtg as impementing scripts will be easier and lighter, as well as making changes/updates;

I don't agree, cacti is installed in about 2 minutes. Without the need of knowledge for any scripts, and cacti does a lot more then mrtg (services, tresholds, syslogging, weathermaps...). The user interface is so great, that you don't want anything else. When i explain my colleagues/customer cacti in 15 minutes, they're off with it, without any linux knowledge! And resources? If you start with 'own script's, at the end, your resources will be must higher then with cacti.

For me? When you want that people use 'your' system, you need to give them something that's simple.
Once they need to start changing config files, they are gone/lost. That's the only reason why windows gains above linux for the normal computer user.  


But of course,everybody his choice.

[brononius]

I'm of the opinion that talk only goes so far.

Build a prototype, then figure out what you need to make that prototype into production.

Working models are currency.

-Thom

My cacti is already running, as a standalone version next to linuxmce. To start, i only monitor some things of the server (processes, diskspace, load & memory), and my switch (bandwidth of all interfaces, cpu)
So not only talking!  

My major question (=problem) is how must i present it? Some printscreens?
Like i wrote before, i'm not a developper/programmer, just a network engineer. So i don't have any clue how i can help you guys to put this into the global project.
I can start trying to change the files like i want (fe change the webmin pages), but with the next release, all my changes can/will be lost. No? And i'm not sure how the dhcp stuff can be added in here. Since with any monitoring tool, you'll need to know the exact ip. Therefor i always use mac-based dhcp...

The installation procedure can already be found on my blog:
http://www.oniria.be/pri/index.php/linux/233-linuxmce#mon

I need to add the plugin module, that something for next week.
Then i can start adding all my devices in my network (power meter, workstations, router, NAS, wireless access point, phones...).

Let me know what i can else do to help...

[dextaslab]

I don't agree, cacti is installed in about 2 minutes. Without the need of knowledge for any scripts, and cacti does a lot more then mrtg (services, tresholds, syslogging, weathermaps...). The user interface is so great, that you don't want anything else. When i explain my colleagues/customer cacti in 15 minutes, they're off with it, without any linux knowledge! And resources? If you start with 'own script's, at the end, your resources will be must higher then with cacti.

For me? When you want that people use 'your' system, you need to give them something that's simple.
Once they need to start changing config files, they are gone/lost. That's the only reason why windows gains above linux for the normal computer user.  


But of course,everybody his choice.

I think maybe we're not quite talking about the same thing... The scripts are written to be generic as a '1 shoe fits all' once deployed they don't even have to know they are there.

This is a proof of concept to auto create a MRTG config file http://www.modlog.net/temp/MRTG_config.sh
example output:

# /usr/pluto/bin/MRTG_config.sh
WorkDir: /var/www/mrtg
LoadMIBs: /usr/share/snmp/mibs/UCD-SNMP-MIB.txt,/usr/share/snmp/mibs/TCP-MIB.txt
EnableIPv6: no

#-----------NEW DEVICE--------------
Target[HDD.174]: `/etc/mrtg/disk_usage.sh` /dev/sdb
MaxBytes[HDD.174]: 100
Options[HDD.174]: gauge,nopercent,pngdate
Title[HDD.174]: Disk usage for /dev/sdb
PageTop[HDD.174]: <h1>Disk usage for /dev/sdb</h1>
YLegend[HDD.174]: Percent
ShortLegend[HDD.174]: %
Legend1[HDD.174]: Total Space
Legend2[HDD.174]: Used Percentage
LegendI[HDD.174]: Total
LegendO[HDD.174]: Free

#-----------NEW DEVICE--------------
Target[HDD.173]: `/etc/mrtg/disk_usage.sh` /dev/md0
MaxBytes[HDD.173]: 100
Options[HDD.173]: gauge,nopercent,pngdate
Title[HDD.173]: Disk usage for Software Raid 5
PageTop[HDD.173]: <h1>Disk usage for Software Raid 5</h1>
YLegend[HDD.173]: Percent
ShortLegend[HDD.173]: %
Legend1[HDD.173]: Total Space
Legend2[HDD.173]: Used Percentage
LegendI[HDD.173]: Total
LegendO[HDD.173]: Free

[dextaslab]

I have spent some more time on it, again, it's dirty bash coding, but makes it show it's very possible (and half done), it can also integrate into the webadmin to show for example disk usage graphs while selecting a raid drive, or CPU usage graph when an MD is selected, etc..

Will put more time into it later next week, and put it forward to see if anyone thinks it's any good or worth continuing.

[dextaslab]

After editing the bash script the only thing left to do is either manually install mrtg:
# apt-get install mrtg

edited " /var/www/lmce-admin/operations/myDevices/editDeviceParams.php"

...
  </script>

        <fieldset>
+            <a href="./mrtg/'.$deviceID.'/index.html">Graphs If Available</a>   
        <legend>'.$TEXT_DEVICE_INFO_CONST.' #'.$deviceID.'</legend>
        <table border="0">
...

(I couldnt get the test to see if the file exists so it'll show on all devices not just MD's)
http://modlog.net/temp/monitoring.png

Only thing left is to integrate it into the core scripts that are used when creating MD's and clean it up, maybe add more graphs, etc.. Any one got any interest in it?

[cfernandes]

I think just make a graphic would not be enough, it is necessary to send alerts when something is wrong.

[dextaslab]

You can set thresholds with mrtg; example:

ThreshDir: /path/to/mrtg/thresh
ThreshMaxI[performance]: 1
ThreshMaxO[performance]: 1
ThreshProgI[performance]: /path/to/mrtg/scripts/alert.php
ThreshProgO[performance]: /path/to/mrtg/scripts/alert.php

For the alert scripts , I'd be looking at something like this, which sends orbiter notifications: http://www.modlog.net/?p=109

[brononius]

I think we need to see this larger then only the server. I agree that if you just want a cpu graph, you can do it manually with hand-written scripts/files/...
But since linuxmce provides a lot more (dhpc, dns, proxy, firewalling...), we can take this up a higher level. If you put in tools like cacti, you can start monitoring your whole network/house. Think about all computers, switches, routers, power-meters... The key-element here is the user-friendly stuff. People need to be able to do it themselves, simple. With this, you gain that more people will use it, less people will ask you questions...
And it must be flexible...

I'll see to create some extra templates. This way, we can monitor a lot more of the server. Think about the statistics of the firewall, dns-request, dhcp-assigment, syslogging of the server/ the network...