Yes, the new event types will be more descriptive ... i'm busy with other stuff 
now, the extended event types may be available probably during Q1 2018.

Best regards,
Martin


> On 15 Nov 2017, at 15:03, Mancillas, Paul <pmancil...@eprod.com> wrote:
> 
> Martin,
> 
> You are correct. I am trying to make the email subject line more descriptive 
> (CPU, memory, etc.) instead of all of the emails saying "Resource limit 
> matched". When are you planning on extending the event types? Will the new 
> event types make the $EVENT more descriptive? In other words, when the CPU 
> usage exceeds the threshold is $EVENT going to say something like "CPU limit 
> matched" or maybe "CPU limit exceeded"? If not then will there be a way for 
> me to customize the value of $EVENT for each resource type?
> 
> Thanks,
> Paul
> 
> -----Original Message-----
> From: monit-general 
> [mailto:monit-general-bounces+pmancillas=eprod....@nongnu.org 
> <mailto:monit-general-bounces+pmancillas=eprod....@nongnu.org>] On Behalf Of 
> mart...@tildeslash.com <mailto:mart...@tildeslash.com>
> Sent: Wednesday, November 15, 2017 2:27 AM
> To: This is the general mailing list for monit <monit-general@nongnu.org 
> <mailto:monit-general@nongnu.org>>
> Subject: Re: Problem with using multiple mail-format
> 
> Hello,
> 
> the "set mail-format" statement can be used only once - if you use it 
> multiple times, only the last one of them will be used. Also one "check 
> system" can be used only once.
> 
> It is possible to override the mail-format for each recipient in the service 
> context (however in this case in won't help because of multiple "check 
> system" statements):
> 
> check system $HOST
>       if cpu usage > 50% for 1 cycles then alert
>       alert foo@bar with mail-format {
>               From: mo...@eprod.com
>               Subject: [$HOST] CPU $EVENT
>               Message: $DESCRIPTION
>               $DATE
>       }
> 
> It seems to me that the reason for your configuration is to differentiate the 
> catch-all "resource" type event, which is used for cpu, memory and other 
> resource usage tests. We plan to extend the event types (cpu will have its 
> own event, ditto for memory, space usage, etc) - i think this change will 
> solve your problem as well (no need to override the mailformat - the event 
> type will be more specific).
> 
> Best regards,
> Martin
> 
> 
> 
>> On 14 Nov 2017, at 16:09, Mancillas, Paul <pmancil...@eprod.com> wrote:
>> 
>> I am trying to setup system performance alerts using Monit 5.14. I have 
>> created several configuration files in /etc/monit.d like “cpu_alert” and 
>> “mem_alert”. Each of these files has a different mail-format section because 
>> I want the subject of the alert mail to show which resource is being 
>> overloaded. So the cpu_alert file looks like this:
>> 
>> set mail-format {
>>    From: mo...@eprod.com
>>    Subject: [$HOST] CPU $EVENT
>>    Message: $DESCRIPTION
>>             $DATE
>> }
>> check system $HOST
>>  if cpu usage > 50% for 1 cycles then alert
>> 
>> And the mem_alert file looks like this:
>> 
>> set mail-format {
>>    From: mo...@eprod.com
>>    Subject: [$HOST] Memory $EVENT
>>    Message: $DESCRIPTION
>>             $DATE
>> }
>> check system dvoellab01corp
>>  if memory usage > 20% for 1 cycles then alert
>> 
>> But when I tested this configuration by putting a high CPU and memory load 
>> on the server all of the email alerts say that they are “CPU” alerts. It’s 
>> like monit is using only the mail-format definition from the cpu_alert file 
>> and ignoring the mail-format from the mem_alert file. Has anyone seen this 
>> before? How can I fix this? The reason that I am using multiple 
>> configuration files is because I want to be able to use a different subject 
>> line and email destination for each type of resource bottleneck.
>> 
>> 
>> This message (including any attachments) is confidential and intended for a 
>> specific individual and purpose. If you are not the intended recipient, 
>> please notify the sender immediately and delete this message.
>> -- 
>> To unsubscribe:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.nongnu.org_mailman_listinfo_monit-2Dgeneral&d=DwIGaQ&c=6zpojTjipf-nAlEmob0p1NKp0XhcK4Iau5zCDf5n3i4&r=VeywB-hbcQt2LM4ijEWtPDNhH3TLuCcS99DFc5jxsSA&m=W4aE0LG9FDrpApN8PUgp6MufEipp9Y3EUHRo6kU1d_M&s=i6c3eqPDAadB9kNJ88ylJJkK3rpQ-3SivxMC7acHVsg&e=
>>  
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.nongnu.org_mailman_listinfo_monit-2Dgeneral&d=DwIGaQ&c=6zpojTjipf-nAlEmob0p1NKp0XhcK4Iau5zCDf5n3i4&r=VeywB-hbcQt2LM4ijEWtPDNhH3TLuCcS99DFc5jxsSA&m=W4aE0LG9FDrpApN8PUgp6MufEipp9Y3EUHRo6kU1d_M&s=i6c3eqPDAadB9kNJ88ylJJkK3rpQ-3SivxMC7acHVsg&e=>
> 
> 
> -- 
> To unsubscribe:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.nongnu.org_mailman_listinfo_monit-2Dgeneral&d=DwIGaQ&c=6zpojTjipf-nAlEmob0p1NKp0XhcK4Iau5zCDf5n3i4&r=VeywB-hbcQt2LM4ijEWtPDNhH3TLuCcS99DFc5jxsSA&m=W4aE0LG9FDrpApN8PUgp6MufEipp9Y3EUHRo6kU1d_M&s=i6c3eqPDAadB9kNJ88ylJJkK3rpQ-3SivxMC7acHVsg&e=
>  
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.nongnu.org_mailman_listinfo_monit-2Dgeneral&d=DwIGaQ&c=6zpojTjipf-nAlEmob0p1NKp0XhcK4Iau5zCDf5n3i4&r=VeywB-hbcQt2LM4ijEWtPDNhH3TLuCcS99DFc5jxsSA&m=W4aE0LG9FDrpApN8PUgp6MufEipp9Y3EUHRo6kU1d_M&s=i6c3eqPDAadB9kNJ88ylJJkK3rpQ-3SivxMC7acHVsg&e=>
> -- 
> To unsubscribe:
> https://lists.nongnu.org/mailman/listinfo/monit-general 
> <https://lists.nongnu.org/mailman/listinfo/monit-general>
-- 
To unsubscribe:
https://lists.nongnu.org/mailman/listinfo/monit-general

Reply via email to