21 Replies Latest reply on Nov 1, 2019 9:26 AM by feltonlewis

    Alert organizing question

    feltonlewis

      Since SolarWinds suggest using OOB alerts at template and you cannot modify them anyway, do you think it's a good idea to disable all of the OOB alerts that you may use, make copies of them, and then apply the copied alerts to the environment?  The SW best practice is to use OOB alerts as templates so I'm thinking of disabling all of the alerts and using any of them I need as templates.  This would allow anyone coming after me to modify the alerts as needed while keeping all of the original alerts in their original state.

        • Re: Alert organizing question
          wluther

          feltonlewis That's pretty much how we do it. Make a copy of the alerts we need to use, then modify those copied alerts to fit our needs. We only use the alerts we need, and everything else is disabled.

          1 of 1 people found this helpful
            • Re: Alert organizing question
              nato

              @wluther So you make a copy of teh OOB alert then edit it and use it??? So you dont use any OOB alerts?

                • Re: Alert organizing question
                  wluther

                  nato, yes, that is correct. We make copies of the OOB alerts we want/need to use, then disable all OOB alerts. We only use the copies we made.

                   

                  We feel, as do many others, it is better practice to use the OOB alerts simply as a template. Everyone has a different environment, so each environment needs its own modifications.

                  3 of 3 people found this helpful
                    • Re: Alert organizing question
                      nato

                      Thanks wluther. I would to see the variables you use alerting in email...

                        • Re: Alert organizing question
                          wluther

                          nato Well, unfortunately, it's pretty plain and simple for the most part, and nothing fancy going on. The most important change we made was jumping onto the dynamic To/CC/BCC bandwagon a while back.

                           

                          By adding these custom properties to the nodes/interfaces/volumes/etc., you are able to send your alerts dynamically, based on the values provided on the element.

                           

                          This prevents you from needing multiple copies of the same, or similar, alerts, each copy going to different email addresses. Now, we can have a single node down alert, but it will send it to the various folks depending on the node custom property values.

                          So, our "Lab" nodes are sent to the person working on them, as their email address is added to the node. The server nodes have the server engineer email on them, and the various network devices are split up among the network ops and engineers accordingly.

                           

                           

                          In general, custom properties are really the key to many workflows, if not all of them. Besides emails, I use custom properties to build our tabs, or add numerous graphs to a view. I have also used custom properties to automatically provision specific values into other custom properties.

                           

                          I think, as with most things, if you spend enough time planning things out around some basic custom properties, you will find a severe increase in efficiency later on down the road. It's definitely one of those things where a little extra time up front can deliver big savings later on.

                           

                           

                          Thank you,

                           

                          -Will

                          2 of 2 people found this helpful
                            • Re: Alert organizing question
                              nato

                              wluther I am saving this method and will institute it. I have alot of work to do !

                              But honestly- when I started with this 3 months ago, I wanted to establish a baseline- so that I could learn from an established base. I used OOB. I still am- there's nothing wrong with them- but for future use if editing is required I would be stuck.

                              So my plan is now to duplicate the OOB alerts and enable them.

                              Your email suggestion- will be usable after that.

                              Thanks again.

                            • Re: Alert organizing question
                              medleyp812

                              nato this may help with using custom properties:

                              Success Center  - Use Custom properties when sending email alerts

                              2 of 2 people found this helpful
                        • Re: Alert organizing question
                          medleyp812

                          feltonlewis We do the same thing. Too many alerts and too many messages make people ignore whatever is going on making them pointless.

                          1 of 1 people found this helpful
                        • Re: Alert organizing question
                          sturdyerde

                          Yes. Very yes. My primary reason (but not only) for saying so is that most customization that you make to the OOB alert configurations are lost every time you upgrade Orion. For example, if you put useful information (please do) in the alert message field, most upgrades will reset this to the default, and you'll have to redo every alert configuration.

                          2 of 2 people found this helpful
                          • Re: Alert organizing question
                            bobmarley

                            We have always disabled all of them and then copied the ones we want to use. We also came up with a naming scheme for them so for example if it's a SAM alert it is indicated in the name and then there is an associated number with it so we can match up a SAM template with an alert name.

                            Also in the alert actions we always include the alert name somewhere in the alert. This was done so that later down the road when someone sends you the email alert they received you can match it up with an alert.

                            Once you get several hundreds of alerts built going to different teams its a great time saver.

                            2 of 2 people found this helpful
                              • Re: Alert organizing question
                                wluther

                                bobmarley We do something very similar with the naming convention too.

                                 

                                2 of 2 people found this helpful
                                  • Re: Alert organizing question
                                    sturdyerde

                                    We use a company-specific suffix on our alert configurations. When using a prefix, sorting by alert name becomes much less helpful unless you are already filtering by object type, etc.

                                    1 of 1 people found this helpful
                                    • Re: Alert organizing question
                                      feltonlewis

                                      Luther -

                                       

                                      So in your image, each number corresponds to a prefix number corresponds to a different module within SW is that correct?  And what is the suffix for?

                                        • Re: Alert organizing question
                                          wluther

                                          feltonlewis Before rebuilding our latest Orion environment, we had previously had several hundreds of alerts. While I wanted to have all of our alerts streamlined and using custom properties, I also wanted a better way to sort through and identify them. I ended up going with a prefix number and a suffix number to help keep them in categories. I do not like how the default "Group By" options display the alerts, breaking simple groups down into overly specific sub-groups. I do, however, like the simplicity of the "Manage Custom Properties" page, where it groups by the most simplistic of categories. (Alerts, Apps, Groups, Nodes, Ints, etc..)

                                           

                                          Basically, yes, the idea was to just keep similar alert types grouped together. (all node alerts with the a prefix in the range of 100-199, interface alerts start with 200-299, and so on).

                                          The suffix was mainly just for me when I need to go in and update the alerts, or make any major changes. I prefer to keep old alerts for reference rather than delete or change them altogether. So, whenever I need to update/change an alert, I simply copy it, make my changes, and increase the suffix.

                                           

                                           

                                           

                                          Group By Object - Manage Alerts

                                           

                                          Group By Object - Manage Custom Properties

                                           

                                           

                                           

                                           

                                          It's nothing more than a personal preference. I'm sure there are much better ways to do this, but it was simple enough, and works for us, so I went with it.

                                           

                                           

                                          Thank you,

                                           

                                          -Will

                                          1 of 1 people found this helpful
                                      • Re: Alert organizing question
                                        feltonlewis

                                        Bob -

                                         

                                        Can you share your naming convention?  Thanks!

                                          • Re: Alert organizing question
                                            bobmarley

                                            Here is an example of an alert name

                                            Splunk-0132-BAM-Info-Routing Change-Alert text, this is what the alerts says

                                            The way this name is broken down in our environment is shown below. We separate the fields with a '-' so we can regex them later if needed.

                                            (1.System that generated the alert)-(2.Unique Number Identifier)-(3.Three letter initials of alert author)-(4.Alert Severity)-(5.Alert Name)-(6.Placeholder for the text that will be passed on from the alert)

                                            In our environment we pass alerts around between systems so the six fields are used for different reasons for different systems.

                                             

                                             

                                             

                                            3 of 3 people found this helpful