4 Replies Latest reply on Jun 22, 2018 3:36 PM by equalswql

    SAM Threshold Automation: Mapping ThresholdName to ComponentTypes

    equalswql

      Hello Solarwinds Community,

       

      I'm attempting to do a mapping between SAM component types and thresholds, for the purpose of automation.

      If you look at NPM and it's corresponding thresholds, you can get a list of all threshold types by referencing the Orion.ForecastMetrics and Orion.ThresholdsNames tables.

       

      For SAM, this doesn't seem to be as clear. The Orion.APM.ComponentDefinitions table references ComponentType and ComponentEvidenceType.

      ComponentEvidence references the tables where collected data/statistics resides, while ComponentType seems to correspond with thresholds related to each component type.

       

      While thresholds in Orion.APM.Thresholds show different types of thresholds - The ThresholdName column - they are based on active components only, and there doesn't seem to be any table mapping the different types of thresholds that belong to each component type. 

       

      Can anyone stevenwhunt  ? assist with this information internally since it isn't referenced in the tables? The end goal here is to automate the setting of thresholds for each component type (which is another topic).

      Ideally there would be one table mapping each component type to MetricIDs, and another table containing all MetricIDs and their corresponding names (Based on the way I see things have been setup with NPM).

       

      If at a bare minimum I had this mapping, I could find a temporary solution through SQL, however it would really be great if the SAM API was opened up to expand on verbs and CRUD operations as well. tdanner - Is there any plan in the future to do this? I have my methods for performing similar operations through SQL, but it isn't my preferred method of operation (only using this as  my only options are leveraging ASPX pages or using SQL)

       

      Thank you,

       

      Justin Valdez

      Systems Engineer, Tobias International

      justin.valdez@tobiassystems.com

        • Re: SAM Threshold Automation: Mapping ThresholdName to ComponentTypes
          mesverrum

          Building automation and deep reporting from SAM has always been a bit of a struggle.  Would be nice if there was at least some tables with indexes of what things were supposed to mean (for example, theres not list translating componenttypes to a friendly name). I know those tables well from smashing my head against the wall until they sunk in, but it is difficult because their behaviors are pretty different than most of the other tables in Orion.  No tables outlining what all the different values and operator types mean, you just have to guess and check.  I have a notesheet with things like this all over it:

           

          when thresholdoperator = 0 then 'greater than'

          when thresholdoperator = 1 then 'greater than or equal to'

          when thresholdoperator = 2 then 'equal to'

          when thresholdoperator = 3 then 'less than or equal to'

          when thresholdoperator = 4 then 'less than'

          when thresholdoperator = 5 then 'not equal to'

          when thresholdoperator = 6 then 'Less Than'

           

          some of the thresholds default to massive values if you dont set a threshold, some of them seem like they just don't add an entry to the tables.  It's all very murky and not much fun  to decode

           

          Relating to this, the project I'm buried in this week is trying to script out migrating all the overrides and componentsettings/applicationsettings stuff from one instance to another.  So far got the templates moving over pretty painlessly and can apply those templates to the correct nodes in the new instance, tomorrow I'll be tackling moving over the settings.

            • Re: SAM Threshold Automation: Mapping ThresholdName to ComponentTypes
              equalswql

              Hello mesverrum,

               

              Thanks for your input on this. I was having a similar conversation piggybacking on an old thread. Along with tomas.vrabel 's help we documented some things for NPM thresholds (including the threshold operators):Is it possible to update the volume capacity thresholds via the REST API?

               

              I guess my main point is that I COULD go out and figure everything out, even if it meant adding individual component types to my script as needed. However, there is no API support for this, and if any major changes occur, it could break the script and render it useless. If at least there were indexes like you mentioned, and a lasting framework setup in SWIS/SWQL tables (as well as some API) it would be worth writing a script. If I need something that works now I can just use what is available. It is actually fun for me to decode, but just not to the degree which is necessary (58 unique component types). For now, I'll likely just focus on the few types we want to automate.

               

              Thank you,

               

              Justin Valdez

              Systems Engineer, Tobias International

              justin.valdez@tobiassystems.com

            • Re: SAM Threshold Automation: Mapping ThresholdName to ComponentTypes
              pawelk

              Hi Justin,

               

              Thresholds in SAM are defined in Application Templates by Component Templates and they are not strictly related to component types.

              The entity, which you mentioned, Orion.APM.Thresholds includes all the thresholds defined in templates, so not necessarily those which are used for monitoring at a given moment only.

               

              Regards

               

              Paweł

                • Re: SAM Threshold Automation: Mapping ThresholdName to ComponentTypes
                  equalswql

                  Hello pawelk,

                   

                  I understand what you mean regarding the thresholds being based on application templates/component templates.

                  What I mean by thresholds being related to component types is that based on a specific type of component, there will corresponding thresholds related to that component type.

                  Example:

                   

                  A "Process Monitor - Windows" component (ComponentType = 1) will always have the following thresholds available (regardless of its application template/component template)

                   

                  CPU

                  IOReadOperationsPerSec

                  IOTotalOperationsPerSec

                  IOWriteOperationsPerSec

                  PMem

                  VMem

                   

                  In order to know which templates correspond with which component types, I would need some type of index/mapping of thresholds to component types.

                  The below swql query approximates this - It takes one component template ID and joins to the threshold table to show corresponding thresholds.

                  This is a workaround, but would prefer a table that provides that information.

                   

                  SELECT  MIN(ct.ID) as MIN_ComponentTemplateID, ct.ComponentType, cd.DisplayName as ComponentTypeName, t.ThresholdName, cd.ComponentEvidenceType, CASE WHEN ComponentEvidenceType = 1 THEN 'Orion.APM.ProcessEvidence' WHEN ComponentEvidenceType = 2 THEN 'Orion.APM.PortEvidence' WHEN ComponentEvidenceType = 3 THEN 'Orion.APM.DynamicEvidence' WHEN ComponentEvidenceType = 4 THEN 'AppInsight' END AS ComponentEvidenceTable

                  FROM Orion.APM.ComponentTemplate ct

                  JOIN Orion.APM.ComponentDefinition cd ON ct.ComponentType = cd.Componenttype

                  LEFT OUTER JOIN Orion.APM.Threshold t ON ct.ID = t.ID

                  GROUP BY ct.ComponentType, cd.DisplayName, t.ThresholdName, cd.ComponentEvidenceType

                  ORDER BY ct.ComponentType

                   

                  Thank you,

                   

                  Justin Valdez

                  Systems Engineer, Tobias International

                  justin.valdez@tobiassystems.com