Tisch
Joined 2 years ago
User Profile
User Widgets
Contributions
Re: Can I group devices based on interface alias?
To be honest, a view with instances and a different one with devices would both have value…I’ll check into Service Insight, are you hinting there’s a way to use instance level properties like the aforementioned interface aliases to help group devices as well? Thanks!6Views0likes0CommentsCan I group devices based on interface alias?
Our organization tags WAN interfaces with the name and circuit ID of the provider. I’m looking to see if I can use this informationto create dynamic groups of WAN devices based on provider cloud. Drilling into a relevant device, I can find the the following property/value: auto.interface.alias- ATT-ASE..DJWU.829478..LB (actual circuit ID obfuscated for obvious reasons) My initial reaction was to just do something along these lines: contains(auto.interface.alias,”ATT-ASE..DJWU.829478..LB”) This obviously doesn’t work. I don’t necessarily know why, perhaps the property is too deep into the device, etc. Long story short, is there any way to accomplish what I’m trying to do? Relatively new to the product and not having luck so far… Thanks112Views3likes6CommentsRe: Alert List Dashbaord Widget - Filtering Help Needed
That is certainly a tight edit window... Since I hit Send early on the original post, I'll post the full question here: I am creating two alert dashboards for our Datacenter folks, Unhandled Events and Handled Events. The mechanism I am intending to use to move alerts from one dashboard to the other is the existence of a ticket ID from our integrated ticketing platform (ServiceNow) and/or a Note attached to the alert. Our ticketing integration with ServiceNow is configured as a hybrid manual automation, if you will. We have an escalation chain that is two steps, the first one being blank and the second being to create the ticket. Using an Alert Rule, all alerts kick off this escalation, where it sits at step 1. Our Operators will then manually escalate any alert they want to create a ticket on, which then fires off step 2, the incident creation in ServiceNow. Question 1: Is there any way to filter based on the step of an escalation chain being used for an alert? If so, I would use this to show or hide an alert, indicating it is already being managed. When I select the escalation chain in the filter, it always matches, because everything kicks off step 1. Being able to specify alerts at step 2 (or any specific step, really) would be very useful, but I can't find any documentation if this is possible. Question 2: Is there a way to filter based on the partial content of the ##ExternalTicketID## field? If so, this could be used instead of the above option, and I could show/hide based on the existence of the "SN : INC" prefix on the logged ticket ID (in our environment, this field shows as "no data" or "SN : INC398202"). Question 3: Likewise, is there a way to filter on the existence of any content in the Notes field? Sometimes our Operators need to move tickets over to the "handled" dashboard even if they haven't created a ticket. In these instances, they could simply add a Note and have the alert move screens. Thanks in advance!0Views0likes0CommentsAlert List Dashbaord Widget - Filtering Help Needed
I am creating two alert dashboards for our Datacenter folks, unhandled events and handled events. The mechanism I am intending to use to move alerts from one dashboard to the other is the existence of a ticket ID from our integrated ticketing platform (ServiceNow) and/or a Note attached to the alert. Our ticketing integration with ServiceNow is configured as a hybrid manual automation, if you will. We have an escalation chain that is two steps, the first one being blank and the second being to create the ticket. Using an Alert Rule, all alerts kick off this escalation, Alert Rule11Views1like2CommentsRe: Question: Autobalanced Collectors and Trap/Syslog reception
In my opinion, that is a terrible limitation as it works against the concept of using ABCGs. The only solution is to spam traps to all of the individual collectors in a group, hoping you hit the one that's polling your device. If you ever have to extend your ABCG, now you have to touch all of your infrastructure to add a new trap destination as well.. It shouldn't be difficult to have all Collectors ingest traps and assign them to the proper resource/collector via some back-end mechanism... When I've brought this up to folks at LM, they recommend not using traps in the first place, polling for everything. That's a nice idea, but not exactly feasible to accomplish day 1 when you're moving your whole organization into this product (if it's even truly possible to get away from traps completely).1View0likes0Comments