[omd-users] Monitoring Disks that are not always attached

Steve Grzywinski steveg at i2m.solutions
Tue Apr 21 14:02:50 CEST 2020


We don't want to ignore any of this, the engineering folks want to see these filesystems monitored while they are attached.


On 4/20/20 6:35 PM, Matthew.Stier at fujitsu.com<mailto:Matthew.Stier at fujitsu.com> wrote:
Add a disabled service for “Filesystem C:/Users/”

This will ignore all filesystems mounted under C:/Users/

Matthew Stier : Unix Team Lead : Storage Administrator
Fujitsu Network Communications : 2801 Telecom Parkway : Richardson, TX 75082
Office: (972) 479-2137 : Mobile: (214) 422-3337 : E-mail: Matthew.Stier at fujitsu.com<mailto:Matthew.Stier at fujitsu.com>

This e-mail and any attached files are only for the use of its intended recipient(s). Its contents are confidential and may be privileged. Fujitsu does not guarantee that this e-mail has not been intercepted and amended or that it is virus free. If you have received this e-mail and are not the intended recipient, please contact the sender by e-mail and destroy all copies of this e-mail and any attachments.


Steve Grzywinski
president & chief technical officer
484.433.7136
steveg at i2m.solutions
600 west germantown pike . suite 400 . plymouth meeting, pa 19462
phone/ fax : 888.991.3814 . web : i2m.solutions
From: omd-users <omd-users-bounces at lists.mathias-kettner.de><mailto:omd-users-bounces at lists.mathias-kettner.de> On Behalf Of Steve Grzywinski
Sent: Monday, April 20, 2020 4:45 PM
To: omd-users at lists.mathias-kettner.de<mailto:omd-users at lists.mathias-kettner.de>
Subject: [omd-users] Monitoring Disks that are not always attached

We have a few windows servers that dynamically mount drives as part of a backup process (veeam) and RDS farms that dynamically mount filesystems to user directories

So a server will have drive letters appear and disappear as drives are mounted to backup and the RDS users have filesystems mounts to C:/Users/<user>  appear and disappear.

When they are attached, all good, when they are not they go into an UNKNOWN state.

We have discovery running (every 4 hours) and it will eventually clean this all up automatically.

We thought we can just increase discovery times for these servers, but how often is too much?  If we re-inventory every :15 on this subset of servers is that too much (about 25 servers)?

Is there a better way to have these drives/filesystems monitored?
[cid:part1.9F4843D4.BDC702F0 at i2m.solutions]
Steve Grzywinski​
president & chief technical officer
484.433.7136<tel:484.433.7136>
steveg at i2m.solutions<mailto:steveg at i2m.solutions>
600 west germantown pike . suite 400 . plymouth meeting, pa 19462
phone/ fax : 888.991.3814 . web : i2m.solutions<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.i2m.solutions_&d=DwMFaQ&c=09aR81AqZjK9FqV5BSCPBw&r=_SdnJx6ElYZR_PnpLjF43SWpy9INwIUCE0XeiwamRXU&m=fqwrsun9r_hQs7mzxzbuwecMj6GPNfNnjj_cdJHxvHc&s=B96s4xCNUmxqOns1HpwK0J_p22-eiFFvtS3HWBayHkg&e=>

[Facebook]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_i2m.solutions_&d=DwMFaQ&c=09aR81AqZjK9FqV5BSCPBw&r=_SdnJx6ElYZR_PnpLjF43SWpy9INwIUCE0XeiwamRXU&m=fqwrsun9r_hQs7mzxzbuwecMj6GPNfNnjj_cdJHxvHc&s=yaGLBqPt6JStM1ZVoV5a1mM4CnhcjzSquOQ0gOQ96BU&e=>
[LinkedIn]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_i2msolutions-3Ftrk-3Dpublic-5Fprofile-5Fexperience-2Ditem-5Fresult-2Dcard-5Fsubtitle-2Dclick&d=DwMFaQ&c=09aR81AqZjK9FqV5BSCPBw&r=_SdnJx6ElYZR_PnpLjF43SWpy9INwIUCE0XeiwamRXU&m=fqwrsun9r_hQs7mzxzbuwecMj6GPNfNnjj_cdJHxvHc&s=FgpoGRhkVRDq0-TuqAr5Zo79g923rp6yMwlFCzUrFz0&e=>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mathias-kettner.de/pipermail/omd-users/attachments/20200421/b58a9497/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1240 bytes
Desc: image001.png
URL: <https://lists.mathias-kettner.de/pipermail/omd-users/attachments/20200421/b58a9497/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 621 bytes
Desc: image002.png
URL: <https://lists.mathias-kettner.de/pipermail/omd-users/attachments/20200421/b58a9497/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 610 bytes
Desc: image003.png
URL: <https://lists.mathias-kettner.de/pipermail/omd-users/attachments/20200421/b58a9497/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image042125.png
Type: image/png
Size: 1240 bytes
Desc: image042125.png
URL: <https://lists.mathias-kettner.de/pipermail/omd-users/attachments/20200421/b58a9497/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image306990.png
Type: image/png
Size: 621 bytes
Desc: image306990.png
URL: <https://lists.mathias-kettner.de/pipermail/omd-users/attachments/20200421/b58a9497/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image307052.png
Type: image/png
Size: 610 bytes
Desc: image307052.png
URL: <https://lists.mathias-kettner.de/pipermail/omd-users/attachments/20200421/b58a9497/attachment-0011.png>


More information about the omd-users mailing list