Search the Community
Showing results for tags 'Backup'.
Found 4 results
Monitoring DPM First was a blur to us. To monitor all jobs wasn't the best thing as a multi instance datasource as the jobs were so many the monitoring of them could potentially use all of the backup server compute power. We also tried the batch script collector but we never got that to work for some reason. Then we took a step back sat down and thinking. We don't actually need to see all jobs. It's quite enough just to see which server got problems. So, i wrote this datasource (it's a multi instance datasource) that collect all computer objects and then for each object checks DPM Alerts and send it out to a custom message. Please enjoy, Z9NNJH
There are currently far too many opportunities to commit errors in LM from which is is difficult to recover since there is no version tracking. Ideally, it would be possible to revert to a previous version of any object, but especially very sensitive objects like logicmodules, alert policies, etc. I have created my own method of dealing with this, which leverages the API to store JSON streams of all critical elements regularly, changes committed via git (certain adjustments to the original results are needed to avoid a constant update stream). Recovery would be very manual, but at least possible. This would be far more useful within the system itself. Thanks, Mark
Hi, Every morning i have to clear a couple of hundred alerts from my inbox that come in while our customers servers are running backups. We often get 'disk latency' 'network latency' type alerts while the backups are running. As they are run outside of hours, we do not really need these. Please could you add a way of creating SDT based on alert severity or better yet, build a mechanism to schedule backup window times to filter noise alerts like disk latency. I'm sure I'm not the only one to encounter this issue. Kris
Collector groups were added recently, and are detailed here: https://communities.logicmonitor.com/topic/637-collectors Now let's expand upon that functionality...What if collectors be grouped dynamically? Identically to how Devices dynamic groups work, could I assign properties to collectors, then build dynamic groups based from the properties? Ways that envision sorting collectors: Production/test, primary/backup, collector number (1-99, 100-199, 200-299, etc.), zip code, time zone, alphabetical. In each of these cases, this would give full flexibility on how collector upgrades are scheduled. Currently if we have a mass collector upgrade to a new General Release, it can be a little painful to manage so many upgrades running simultaneously (or at least in very short order). I am most interested in being able to split them up into primary, backup and single collector groups. This way, I know that it's pretty safe to upgrade the collectors that have backups after hours, since there is another collector to failover to. And I surely want to be available staff-wise if I am doing upgrades for those collectors that have no backup collector. Close behind sorting into primary/backup/single is the need to sort them by customer (which currently works fine). The issue is that you can't put a collector into more than one group, which precludes from even setting up these to items manually.