FreeBSD monitoring solution - looking for the interested testers

battleship_potemkin

battleship_potemkin

Hi,

we just made a first public release of the FreeBSD monitoring solution (it's cross-platform, but we consider FreeBSD as one of our primary platform) and I'm looking for the interested testers to give it a try and come back with the feedback. You're only required to register and install the monitoring part on your server - FreeBSD 7.* and higher (which is just 1-2 minutes - depending on how fast you are) and provide your feedback (as much as you'd like).

We are really looking to build a proper, useful full coverage monitoring solution for FreeBSD and need your feedback. Those who interested - please, let me know or, if the moderator will allow, I drop the link here.

Kind regards,
Alexander.
 
Can you give some more information please? Do you intend to monitor local or remote machines? If remote how do you do it? SNMP or by help of agents? Do you offer any advantages against current industry standards? Is your goal to complement or replace them? Where do you stand in relation to Nagios, Icinga, Munin, Cacti, Zenoss, PandoraFMS etc.?
 
Sure, you install the monitoring agent on your machine (via SSH for *nix, GUI for Windows / MacOS X). It installs as a proper service, runs as an isolated daemon (a separate user, having access to it's local directory only). Once per minute it collects and sends system load information to the central server in our infrastructure, where you can work with this information as required.

The benefits against the solutions you mentioned are the following:
  • it's really fast and easy to start using it;
  • we keep working on improving our Web GUI so that you use a modern proper web interface;
  • extendable services monitoring and alarms configuration are coming soon, to match the industry level standards;
  • you shouldn't bother to configure things, it just works.
We just released it as a public tool and we are open for your feedback and your wishes.
 
battleship_potemkin said:
Once per minute it collects and sends system load information to the central server in our infrastructure, where you can work with this information as required.
Click to expand...

That would be a no go for me. What happens if your system gets hacked?

After looking at your download section I noticed that you also don't provide the source code.
 
gkontos said:
I don't think that it would be a problem if you shared your project's link. As long as you don't try to sell anything!

Personally, I am always interested in trying new monitoring solutions.
Click to expand...

Here it goes: http://10bees.com/ - please, let me know your impression, ideas and thoughts - here or via the contacts on the site.
 
gkontos said:
That would be a no go for me. What happens if your system gets hacked?
Click to expand...

It's one-sided communication and no personal / security risky information is sent to the server. The agent is running with the lowest possible privileges.

You can also verify the agent (we will publish the code to Github soon to ease you following the code changes). To see the information that's delivered to the server, you can use the show-collected-data command line switch.

I guess I shouldn't mention that we take our server security quite seriously.

Please, let me know if anything.
 
Hello,

I am new to FreeBSD, but got some experience in ITSEC. How does the agent communicate with the central server? I like the idea, that there is no communication from the management server to the servers, because such central devices are a wonderful target for further hacking (got the firewall rules to the servers).

I am not sure that the information are always without risk, so why not use encryption? I think it would be useful to get integrity and privacy. How do the agents authenticate against the management server and how does the agent make sure to deliver the information only to the configured server (mutual authentication)?

BR
Markus
 
Hi Markus,

Thank you for the feedback and I hope you will fall in love with FreeBSD, just like I did a while ago. It's a wonderful and nice system to stay with.

On your suggestion - we plan to implement traffic encryption, and, I guess, HTTPS will sort out both issues.

Any other feedback and/or impressions from your experience with the system?

Kind regards,
Alexander.
 
Are you planning on doing a paid service? Why not release both the client and server code for those that prefer to have our own private central monitoring solution, and provide hosted monitoring solution for those that just want to get going quick?
 
redw0lfx said:
Are you planning on doing a paid service? Why not release both the client and server code for those that prefer to have our own private central monitoring solution, and provide hosted monitoring solution for those that just want to get going quick?
Click to expand...

Thanks for the suggestions.

Yes, it's going to be a reasonably priced (we spend a lot of time optimizing the software, to optimize the costs), paid service in a moment of time and yes - we are planning to release private solutions as well, just need to ensure we are releasing something really good, stable and enjoyable to use.

For the Open Source / non for profit organisations there will be an option to use it for free.
 
More background information would be nice. Using SNMP or something else, is the transferred data encrypted or not and what might it make better compared to Nagios / Icinga / ... + Cricket / Cacti / ...
 
rghq said:
More background information would be nice. Using SNMP or something else, is the transferred data encrypted or not and what might it make better compared to Nagios / Icinga / ... + Cricket / Cacti / ...
Click to expand...

There are two main advantages over the systems mentioned by you: it's simplicity of the setup and you shouldn't care about having a separated monitoring server. It's just a couple of minutes from the moment you decided to have your server monitored and the fact that it's actually monitored (includes time for a very quick account registration). It saves your time and your computing environment resources.

Apart from that - you have the history and all of the key system information there. Next steps planned: the alarms for the main events you don't want to miss and extended services monitoring - like apache, mysql, etc. (work in progress).

As for the protocol - it's a "signed" binary HTTP traffic and the next enhancement here it is a support of encryption here - we try to keep the balance between the resources efficient and features reach agent. Your server is running to carry on the useful load, not the monitoring agent after all.

Please, let me know if anything.
 
gkontos said:
That would be a no go for me. What happens if your system gets hacked?

After looking at your download section I noticed that you also don't provide the source code.
Click to expand...

Ditto.

That and information disclosure to random unknown third party, which for all we know may be just doing recon for future break-ins.
 
throAU said:
Ditto.

That and information disclosure to random unknown third party, which for all we know may be just doing recon for future break-ins.
Click to expand...

Sounds strong, but not quite true: you are getting source code with the agent.

Let me tell you a bit more about the system and how it works.

Basically the system contains of three parts:

  • Agent - main collector logic, written in Perl;
  • Tiny binary part, implementing the component, collecting comprehensive information about the system load;
  • Central server (we call it collector).

Agent is, once again, written in Perl, which means you get full source immediately.

Tiny binary part (we call it sysinfo) is written on C, because
  • you can't collect quite a lot of the important information about the system load from Perl;
  • it's much more resources efficient in compare with calling multiple binaries, parsing it's output, etc.

To address possible concerns about the sysinfo component and the agent on your system we did the following:
  • on all *nix-es, agent is always running from it's own user (10bees:10bees), which is only having an access to it's own directory and nowhere else;
  • by calling /usr/local/10bees/agent show-collected-data you can always verify the information that is being delivered to the central server.

To save your time that's the following data collected:

  • hostname, uname, w output;
  • CPU load;
  • Memory (including swap) usage;
  • HDDs usage;
  • Statistics on the process (includes top memory and cpu consumers);
  • Network interfaces usages.

Additionally, regarding the source code you might have noticed my sentence earlier:

we will publish the code to Github soon to ease you following the code changes
Click to expand...


And just for your information - as one of the next feature planned - it's a pure Perl agent - it will provide a bit less information, but we are working with the expert in this area, author of the well know monitoring system, so I expect it to be still as good as possible.

Hope that address your concerns. If not, then I understand you have a high security requirements, that will be address by releasing collector as a component, you can setup internally.

Please let me know if anything.
 
Re: FreeBSD monitoring solution - looking for the interested

Hi,

Just to bring an update – we relaunched the service a while ago and recently rolled out an updated version with most of the concerns addressed. You can find the details in our blog (http://blog.10bees.com/), created to keep our customers up to date with the major updates and changes.

The platform is matured and if you are looking for a FreeBSD hosted monitoring solution - please, give it a try and drop us an e-mail if anything we can do for you.
 
You must log in or register to reply here.
Back
Top