[Xymon] Ignoring Veeam Backup filesystems

Robert Herron robert.herron at gmail.com
Tue Feb 9 13:32:11 CET 2021


Thanks, Damien and Jeremy for the suggestions.  I'm leery of the wildcard
patterns since there could be a legitimate filesystem starting/ending with
braces in the future.  I'm probably overthinking it.

I added the DISK line yesterday.  I then created a test LV and mounted it
under /tmp with a UUID name.  It was excluded from the disk test and I saw
no obvious errors.

Thanks again.

On Mon, Feb 8, 2021, 5:23 PM Jeremy Laidman <jeremy at laidman.org> wrote:

> I'm with Robert - simple and good enough is often better than perfect but
> unfathomable. Consider how likely it is that you would care about a
> filesystem mounted under /tmp to be full.
>
> Here's a slightly more accurate match, but still very simple:
>
> DISK %^/tmp/\{.*\} IGNORE
>
> This will match any string in the form {*}.
>
> Another option is to add "delayred=disk:5" into the hosts.cfg entry for
> the hosts that get the local backups. This will delay the alert long enough
> for the filesystem to be un-mounted. However, there's a risk that a genuine
> alert for another filesystem is delayed by 5 minutes.
>
> On Tue, 9 Feb 2021 at 02:44, Damien Martins via Xymon <xymon at xymon.com>
> wrote:
>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Damien Martins <damien at makelofine.org>
>> To: xymon at xymon.com
>> Cc:
>> Bcc:
>> Date: Mon, 8 Feb 2021 16:44:22 +0100
>> Subject: Re: [Xymon] Ignoring Veeam Backup filesystems
>>
>> Hello Robert,
>>
>> If you do not expect to mount something else in /tmp, you may use
>> something like:
>> DISK %^/tmp/.* IGNORE
>> seems easier to read and understand, however may be too wide.
>>
>> If you expect to mount something else in /tmp, then your regex seems OK
>> and unavoidable
>> Le 08/02/2021 à 16:38, Robert Herron a écrit :
>>
>> I'm deploying Veeam Backup & Replication to perform systems.  I have a
>> few Linux hosts that require being backed up via the local agent instead of
>> using a VM-based backup.   The backups run in the middle of the night as
>> you might expect.  2AM Sunday, I received a full filesystem alarm on a
>> Linux host I'm testing.  It cleared in the next test sweep 5 minutes later
>> but the unnecessarily alarms woke me up.  I want to minimize that from
>> happening.
>>
>> The Veeam agent creates and mounts devices under /tmp for the backup.
>> The df line from the filesystem alarm looks like:
>> Filesystem       1024-blocks    Used Available  Capacity  Mounted on
>> /dev/veeamimage7     4128448 4026052         0      100%
>> /tmp/{16296b8b-8ad4-6614-6da9-aacdc519bd6b}
>>
>> The actual filesystem name is different on each host.  I assume it's
>> based on the host's BIOS UUID or the block ID.  I don't want to add
>> individual lines for each host.
>>
>> I want to add the following line to my analysis.cfg in the "CLASS=linux"
>> section:
>> DISK
>> %^/tmp/\{[A-Fa-f0-9]{8}-[A-Fa-f0-9]{4}-[A-Fa-f0-9]{4}-[A-Fa-f0-9]{4}-[A-Fa-f0-9]{12}\}
>> IGNORE
>>
>> Questions:
>> 1.)  Is this regex valid for the analysis.cfg?
>> 2.)  Is there a better way to handle this?
>>
>> Thanks,
>> --Robert.
>>
>>
>>
>> Robert Herron
>> robert.herron at gmail.com
>>
>> _______________________________________________
>> Xymon mailing listXymon at xymon.comhttp://lists.xymon.com/mailman/listinfo/xymon
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Damien Martins via Xymon <xymon at xymon.com>
>> To: xymon at xymon.com
>> Cc:
>> Bcc:
>> Date: Mon, 8 Feb 2021 16:44:22 +0100
>> Subject: Re: [Xymon] Ignoring Veeam Backup filesystems
>> _______________________________________________
>> Xymon mailing list
>> Xymon at xymon.com
>> http://lists.xymon.com/mailman/listinfo/xymon
>>
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20210209/d3450a90/attachment.htm>


More information about the Xymon mailing list