14 Replies Latest reply: Jan 13, 2012 12:04 PM by aLTeReGo RSS

    Application template "description" as a variable in alert trigger

    the_toilet

      Hi Solarwinds

      can you please add the ability to put the application template description as a variable in the alert trigger?  We need to be able to tell the service desk what the application is, and what is means when it is DOWN.

      Ideally we would be able to assign custom properties against applications and application components, but I suspect that is asking for a little too much (or is it?)

      Please advise...

      cheers

      dan

        • Re: Application template "description" as a variable in alert trigger
          KenKasmar

          Add my +1 to the vote count for custom properties on applications and components in APM.

          • Re: Application template "description" as a variable in alert trigger
            chris.lapoint

            can you please add the ability to put the application template description as a variable in the alert trigger?  We need to be able to tell the service desk what the application is, and what is means when it is DOWN.

            We've been talking about this internally so great minds must think alike.  However, we were thinking you also want the ability to place "what this means" text on each specific component and have that info available in alert variables. 

            So, you could do something like the following:

                Application: ${ApplicationTemplateDescription} is down

                Component:  ${MonitorDescription} on Application is down  

            Would that meet your needs?

            Ideally we would be able to assign custom properties against applications and application components, but I suspect that is asking for a little too much (or is it?)

            Not asking too much.   We'll start tracking this request.   Other folks watching, please pile if you care ;-)

            • Re: Application template "description" as a variable in alert trigger
              northben

              This line will give you the functionality since it is not a built in feature

              ${SQL:Select description from apm_Applicationtemplate inner join apm_application on apm_Applicationtemplate.id = apm_Application.templateid where apm_Application.id = '${ID}' }

              • Re: Application template "description" as a variable in alert trigger
                aLTeReGo

                In APM 4.2 the ${UserDescription} and ${UserNotes} macros are available from the APM: Component property of the Advanced Alert Manager. Any information entered into the template for a component monitor in the Description or Notes fields are passed with these variables.

                  • Re: Application template "description" as a variable in alert trigger
                    northben

                    Sadly, I am using a regular "Application" alert instead of an "Application Component" alert to notify me when an application goes down. I am doing this so that I could see what components are having trouble without being bombarded with emails every time an application has trouble.

                    So slightly off topic of the thread, but am I monitoring my servers optimally or would I be better off using Application Component alerts?

                      • Re: Application template "description" as a variable in alert trigger
                        bobross

                        We use both Application and Component alerts as follows:

                        Component Down get rolled into an Application Alert.  As you've found, when an Application goes down you will get flooded with Component Alerts.  This way we just receive the one Application Alert with a list of all Down Components.

                        For Warning and Critical Components we have it set to send individual Component Alerts and no Application Alerts.  In this way we can keep an eye on the individual elements that may be having problems but aren't down.

                        We originally had both Application and Component alerts fully enabled, but the massive amount of alerts that we would receive (and the tickets generated from each) resulted in inefficiencies and impacted our ability to service each issue in a timely manner.  We then tried having just Application alerts, but we found that the missing granularity of the Component alerts led to different issues.  In the end the balance that we have is the best for our shop.

                        Hope that helps.

                          • Re: Application template "description" as a variable in alert trigger
                            Bain_606

                            Hi bobross-

                            You said:

                            Component Down get rolled into an Application Alert.

                            Could you please demonstrate this, in a general way, so we can understand how you did this?  Even after a year with this tool, I still struggle with Component-level alerts.

                             

                            I and the list would greatly appreciate it if you could elaborate on this.

                             

                            Sincerely,

                            Mike  

                              • Re: Application template "description" as a variable in alert trigger
                                bobross

                                Unfortunately, I can't just do a straight export due to some information that we can't share, but this should detail what we have done.

                                Originally, we had an alert setup to trigger whenever a component went down:

                                Alert me when an component goes down

                                 

                                Trigger Alert when all of the following apply
                                    Node Status is equal to Up
                                    Component Status is equal to Down


                                This caused a massive amount of alerts to be generated whenever an application went down.  For some of our applications we have 40+ components, so this quickly became a problem.  The solution was to get rid of the component down alerts and just monitor for when an Application goes down.  An Application will poll down whenever one or more of the components goes down, so in this way we can catch the component alerts without receiving too many.

                                Alert me when one or more components within an application are down

                                 

                                Trigger Alert when all of the following apply
                                    Application Status is equal to Down
                                   
                                    Trigger Alert when all of the following apply
                                        Node Status is not equal to Down
                                        Node Status is not equal to Warning
                                        Node Status is not equal to UnManaged
                                        Node Status is not equal to Unknown


                                The additional triggers checking for node status are so that we don't receive additional alerts for Applications when a Node goes down.  We found that alert suppression simply didn't work, so we used this logic to simulate suppressions.

                                In the email alert that is generated, we included the list of all components that are experiencing issues:

                                 

                                ${Name} is ${Availability}${CrLf}
                                Components with Problems:${CrLf}
                                ${ComponentsWithProblems}${CrLf}


                                Which outputs the following (taken from an actual alert email):

                                 

                                Oracle Database - TEST is Down
                                
                                Components with Problems:
                                
                                 Greatest Tablespace % Used(Down), Blocking Locks(Down), Buffer Cache Hit Ratio(Down),
                                Dictionary Cache Hit Ratio(Down), Library Cache Hit Ratio(Down), Disk Sort Percentage(Down),
                                Total User Connections(Down), Log Switches - Last 1hr(Down), Job Submission Is Running(Down),
                                Number of INB Users(Down), Number of Active SSB Sessions - Last 15 mins(Down),
                                Number of Active SSB Sessions - Last 4 hrs(Down), Greatest Temp Tablespace % Used(Down)
                                


                                Instead of 14 (13 Components and 1 Application) Alerts and their corresponding Tickets being generated, we have one Alert/Ticket that contains all of the pertinent information.  Since the same administrator will be able to handle all of the components everything is all in once nice tidy package.

                                Personally, I miss the mass component alerts because bulk assigning 100+ tickets to an admin that doesn't have bulk modify rights in our ticket system was sometimes the only leverage we had against uncooperative admins.  But that's a whole other issue.

                                Let me know if that helps clear it up for you.  Like I said before, I can't just export the Alert due to some information that is confidential.

                            • Re: Application template "description" as a variable in alert trigger
                              aLTeReGo

                              Sadly, I am using a regular "Application" alert instead of an "Application Component" alert to notify me when an application goes down. I am doing this so that I could see what components are having trouble without being bombarded with emails every time an application has trouble.

                              Understood. I've logged this a feature request under FB99397