[AGENT++] AgentX design question

Dave Mason dmason at transat-tech.com
Mon Aug 23 18:42:47 CEST 2004


Hi,
Thanks both of you for good advice.  In our case, our agent is very 
lightly loaded, used mostly for configuration and to send some traps, so 
I dont see a big benefit from multiprocessing.  We've been doing fine 
with a non-AgentX monolithic agent, so for now I'll take Frank's advice 
and leave it that way.  We're mainly interested in AgentX to incorporate 
RADIUS or other servers that have SNMP subagent capability built in.  
This is a sharp contrast to the agent I built at my last job, which was 
responsible for multiple target devices.  Each device was accessed with 
a unique SNMPv3 context, and had it's own subagent to act as a protocol 
gateway between SNMP and a real-time database running on the device 
itself.  We had all these subagents, the master agent, and even some 
management applications running in one box, but in theory we could have 
moved them anywhere without changing our architecture.  That was pretty 
slick.  In my current case, I wanted to make sure a monotholic agent in 
an AgentX environment isnt breaking some convention or rule of thumb, or 
that I wasnt forgetting something.

As for my search question, I can get to 
_http://agentpp.org/mailman/listinfo/agentpp_ but I dont see the search 
link.  Is it under something else?  I saw the archives page where you 
can view by thread, subject, author, or date, but I remember there used 
to be a way to search all the message bodies.

Regards,
Dave

Bob Natale wrote:

>Hi,
>
>While I believe that a reasonable case can be made for Frank's advice 
>here, I would have suggested otherwise.
>
>In the general case, in my view, the modularity benefits of the 
>subagent approach outweigh the hypothesized performance benefits of the 
>monolithic approach.
>
>Indeed, depending on the specific nature of the MIBs and of the 
>requests from management applications, it could well be that the 
>subagent approach could allow for a less complex method of multi-
>processing the instrumentation interfaces to satisfy the requests than 
>would a monolithic agent application.
>
>However, in the absence of concrete scenarios to analyze it is truly 
>difficult to say for sure.  And it is also true of course that specific 
>implementations of master agents and subagents could determine actual 
>performance irrespective of the theoretical behaviors.
>
>Cheers,
>BobN
>
>---- Original message ----
>  
>
>>Date: Sat, 21 Aug 2004 00:22:21 +0200
>>From: Frank Fock <fock at agentpp.com>  
>>
>>Hi Dave,
>>
>>Dave Mason wrote:
>>
>>    
>>
>>>Hi,
>>>I have a monolithic agent with some proprietary MIBs that I'm 
>>>converting to use with AgentX.  The reason is that I may have other 
>>>subagents that need to attach to a master agent.  One approach is to 
>>>leave my proprietary MIBs in the master agent, and not use subagents 
>>>unless I need to connect another one for some reason.  The other 
>>>      
>>>
>would 
>  
>
>>>be to keep the master agent small, and put my proprietary MIBs in a 
>>>new subagent which would run all the time.  Which do you like?
>>>      
>>>
>>I would leave the code in the master agent, except if one of your 
>>    
>>
>tables
>  
>
>>should be extended by a subagent using the AgentX shared table
>>mechanism. The advantage of leaving the instrumentation in the
>>master is performance. The disadvantage is less flexibility and 
>>    
>>
>probably
>  
>
>>less availability (a subagent might be easier rebooted).
>>
>>    
>>
>>>While I'm here, I took a look at the mailing list archive for the 
>>>first time in a while, and I dont see how to search it like you used 
>>>to.  Is that still possible?
>>>      
>>>
>>There is direct search function, but Google or another search engine 
>>    
>>
>should
>  
>
>>work too.
>>
>>Best regards,
>>Frank
>>
>>
>>_______________________________________________
>>AGENTPP mailing list
>>AGENTPP at agentpp.org
>>http://agentpp.org/mailman/listinfo/agentpp
>>    
>>
>
>
>  
>



More information about the AGENTPP mailing list