Re: Problem with using multiple mail-format

"[email protected]" <[email protected]>
Newsgroups gmane.comp.monitoring.monit.general
Message-ID <[email protected]>
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 <[email protected]> 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:[email protected] <mailto:[email protected]>] On Behalf Of [email protected] <mailto:[email protected]>
> Sent: Wednesday, November 15, 2017 2:27 AM
> To: This is the general mailing list for monit <[email protected] <mailto:[email protected]>>
> 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: [email protected]
> 	    	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 <[email protected]> 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: [email protected]
>>    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: [email protected]
>>    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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.