Always happy to take the time to explain things. Any question you have is almost certainly a question that someone else has too - so I've redirected this thread to the mailing list.
There are many kinds of contributions that can be made. Definitely need someone to learn and enhance the Cmake configuration so that we build things including install and so on. In terms of the number of roles in a project, at least half of them are not primarily coding. It is worth noting that I adopted a pretty unusual (but useful) C coding style in this code. Sort of C-with-objects... In terms of having given this some thought -- I've been thinking about it for nearly 2 years, and writing code for it for a year and a half or so - although the majority has been in the last year or so. I've written very successful software for this market in the past. For this tool to be useful in grand scheme of things, it has to not only be useful, but unusually and uniquely useful. Most of the people who might want to use it already have a tool they've been using, and have invested a lot of time and effort in understanding it and getting it up and going in their environment. Those people are only going to replace their existing tool set if we provide something valuable they're not already getting, along with a "sufficient" quantity of basic capability. People are only willing to lose a few minor capabilities to adopt something new -- and only if it provides something far more valuable in return. In terms of getting people to adopt something, it has to have an incredibly easy and impressive out-of-the-box experience for them to bother doing anything much. My current plan is to have you be able to drop it onto a collection of machines /without any manual configuration whatsoever/, and have it provide you basic host monitoring and detailed discovery data out of the box. We need to be able ton convince people that the learning and configuration curve won't be as steep as what they already have. In addition, it should be able to provide some basic monitoring of web servers and maybe common database servers without any further configuration - although you might have to enable auto-configuration - that should definitely be something you can turn on or off. On 08/17/2012 09:27 PM, Robert Holder wrote: > thanks for taking the time to explain. it really does seem like a > useful tool you are making, and I can tell you've given it a lot of > thought. I really do want to make time to look through the code, if > only to learn. hopefully I will be able to do that soon. I wish I > could say I could make some meaningful contribution, but I am really > just beginning to re-learn coding, so what skills I did have are still > very rusty. but I do appreciate the time you've taken to explain > things to me! > >> n 8/17/2012 10:59 AM, Alan Robertson wrote: >> Glad you like the graph. It looks pretty cool to me >> >> Well, you would never look at the whole graph in this much detail >> when you have thousands of drones - or you'd go blind Even a graph >> of 5 servers is pretty hard to figure out - which is why I sent out >> the one of 4 servers... >> >> There is a REALLY OBVIOUS need for a brilliant user interface / user >> experience person (and maybe an aesthetic design person) to handle >> that end of the work. >> >> My netgear switch supports LLDP. The labels on the switch ports came >> from the LLDP information in my switch (which I administered to make >> the graph look cool). My switch is not serving DHCP. One of the >> drones (silas I think) is providing DHCP. It doesn't show as a >> service on the graph, because it's not a TCP service. >> >> I can't put nanoprobes onto things that are "appliances" like >> switches. There is an intent to monitor appliances, but that's not >> the most immediate short term goal. >> >> My current thinking in terms of big picture priorities looks >> something like this >> - server monitoring (is it up?) of "drones" running nanoprobes >> (mostly done - but with a known bug) >> - basic discovery (also mostly done - need to add subnet objects) >> - basic service monitoring >> - monitoring of appliances >> - statistical monitoring (?) >> >> With things like supporting lots of kinds of services, discovering >> more and different kinds of things, adding the 3 levels of rings, and >> so on mixed in along the way somewhere. May eventually add >> non-stealthy discovery too... >> >> Note that when the multiple layers of rings are added, we get basic >> switch monitoring more or less "for free". >> >> >> >> On 08/17/2012 10:18 AM, Robert Holder wrote: >> Nice! I'm wondering what that graph will look like when you have >> thousands of drones. It would be nice to have a viewer application for >> the graph data that allowed you to expand or collapse edges by clicking >> on nodes so you only see the data for drones you are interested in at >> that time... or some other way to navigate that graph so it is usable >> with data from many drones. >> >> So your netgear switch is announcing which port is associated with which >> host? I'm assuming your switch is serving DHCP? I'm just asking >> because the switch does not appear to be part of The_one_ring, and you >> are only running the AMP stuff on your hosts right? AMP is not intended >> to ever run on any pure networking hardware, only on the actual hosts, >> correct? >> >> Looks great! >> >> --Robert >
_______________________________________________ Assimilation mailing list - Discovery-Driven Monitoring [email protected] http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation http://assimmon.org/
