On Sep 5, 2011, at 2:47 PM, Lior Okman wrote:
>
> On Mon, Sep 5, 2011 at 3:19 PM, Martin Pala wrote:
>
> Monit has XML interface suitable for integrations like this. In your case you
> can write independent SNMP subagent which will proxy Monit's XML data source
> -> SNMP.
>
>
> Is the XML
On Mon, Sep 5, 2011 at 3:19 PM, Martin Pala wrote:
Monit has XML interface suitable for integrations like this. In your case
> you can write independent SNMP subagent which will proxy Monit's XML data
> source -> SNMP.
>
>
Is the XML schema returned by the _status action guaranteed not to change
On Sep 4, 2011, at 6:56 PM, Lior Okman wrote:
> On 09/04/2011 05:08 PM, Martin Pala wrote:
>> Hi Lior,
>>
>> thank you for explaining the plan, we see the point and undestand that
>> better SNMP support can be useful in SNMP-oriented environments.
>>
>> At this point however, we prefer not to
On 09/04/2011 05:08 PM, Martin Pala wrote:
Hi Lior,
thank you for explaining the plan, we see the point and undestand that
better SNMP support can be useful in SNMP-oriented environments.
At this point however, we prefer not to integrate Monit with Net-SNMP
- our approach is to keep Monit si
Hi Lior,
thank you for explaining the plan, we see the point and undestand that better
SNMP support can be useful in SNMP-oriented environments.
At this point however, we prefer not to integrate Monit with Net-SNMP - our
approach is to keep Monit simple with minimum dependencies on 3rd party
l
Hi,
With regards to the MIB I intend to implement in Monit, attached is the
first draft with initial support for monitored processes and files, that
doesn't yet include any of the notification types in it.
See the output of the "monit status" command and the output of an example
snmpwalk against t
On Sun, Sep 04, 2011 at 12:46:13PM +0300, Lior Okman wrote:
> The problem is that as far as I can tell, the 5.2.x branch
> doesn't have any sort of plugins infrastructure, and adding one
> to Monit is really not in the scope of what I intend to do.
That's what I guessed -- please don't take that c
On Sun, Sep 4, 2011 at 12:32 PM, Michael Shigorin wrote:
>
> It's nice in general, but when packaging, it tends to result
> in "alternative builds". I do understand that it's probably
> not your objective, but knowing this can make further work
> in this direction easier.
>
>
The problem is that
On Sun, Sep 04, 2011 at 09:47:33AM +0300, Lior Okman wrote:
> > So if any sort of plugin or IPC implementation is feasible,
> > that would be a huge improvement over plain configure knob.
> I plan on making it a compile time option, so if you don't want
> SNMP support, just configure monit as usual
On Sat, Sep 3, 2011 at 11:00 PM, Michael Shigorin wrote:
> On Fri, Sep 02, 2011 at 07:47:10AM +0300, Lior Okman wrote:
> > Comments?
>
> Packager's perspective: being able to provide binaries which
> would satisfy both those who need the extended functionality
> and those who oppose lib$yetanothe
On Fri, Sep 02, 2011 at 07:47:10AM +0300, Lior Okman wrote:
> Comments?
Packager's perspective: being able to provide binaries which
would satisfy both those who need the extended functionality
and those who oppose lib$yetanother mapped into a critical
process' address space helps a lot.
So if an
Hi,
It seems to me that Monit is missing the ability to be queried via SNMP
about the state of its monitored services and use SNMP traps or
notifications as alerts.
I'm going to develop support for this, using Net-SNMP's AgentX support with
Monit. Monit would become an SNMP subagent, and if the N
rory wrote:
In our situation, we have our software on an nfs-repository. My monit
startup scripts are dynamically generated via a config file that maps
services to hostnames. Thus my "upgrade" doesn't deal with copying
binaries, rather it just has to manage the symlinks in my
/etc/rc.d/init.d
In our situation, we have our software on an nfs-repository. My monit
startup scripts are dynamically generated via a config file that maps
services to hostnames. Thus my "upgrade" doesn't deal with copying
binaries, rather it just has to manage the symlinks in my
/etc/rc.d/init.d space. I alre
We've been thinking about almost the same functionality for managing
monit upgrades from m/monit.
M/Monit can have repository of various monit binaries (various versions
and platforms) and it could be easily to centrally manage monit agents
from M/Monit this way (upgrade monit with one click).
Jan-Henrik Haukeland wrote:
This is interesting, but could you first provide the code as a patch
so we could see if it is something that would be general enough to be
of common interest to other monit users?
Sure, I plan on implementing next week so I can email sometime next week.
This is interesting, but could you first provide the code as a patch
so we could see if it is something that would be general enough to be
of common interest to other monit users?
On 25. april. 2008, at 23.01, rory wrote:
I'm implementing a feature locally, and was wondering what the
reac
I'm implementing a feature locally, and was wondering what the reaction
would be for me to implement it in the main source.
I'm planning on using m|monit and monit as a service console for our
production service. Besides just stop/start/monitor, I also want to use
it to trigger updates of the
18 matches
Mail list logo
