9 Replies Latest reply on Sep 18, 2018 2:21 AM by jmastop

    Calculate additional attribute using supermetrics?

    jmastop Lurker

      Hi all,

       

      In order to check some NUMA/vNUMA behaviour I'd like to have an additional metric or atribute on a Host System object, which basically is the number of KB memory per CPU socket. I think these are the Total Memory (KB) and CPU Packages attributes.

       

      However, if I try to divide both, I get a message "Cannot convert aggregated result to number." Do I misunderstand the concept of supermetrics here? Or do I need to modify the adapter to get these attributes?

       

      Thoughts on my NUMA monitoring goals are welcome, too, but I'd mainly like to get an answer on why the expression is not accepted.

       

      Thanks in advance!

       

      The expression is:

       

      ${adaptertype=VMWARE, objecttype=HostSystem, attribute=hardware|memorySize, depth=1}/${adaptertype=VMWARE, objecttype=HostSystem, attribute=hardware|cpuInfo|numCpuPackages, depth=1}

        • 1. Re: Calculate additional attribute using supermetrics?
          nmanm0305 Novice

          When creating Super Metrics, I've had problems with what vROPS auto-populates when using the native selection tools (in red in the screenshot). It usually populates unnecessary info that prevent s the metric from calculating. For example, your post contains....

           

          adaptertype=VMWARE, objecttype=HostSystem, attribute=hardware|memorySize, depth=1

          adaptertype=VMWARE, objecttype=HostSystem, attribute=hardware|cpuInfo|numCpuPackages, depth=1

           

           

          Try these instead....

           

          this, metric=hardware|memorySize, depth=1

          this, metric=hardware|cpuInfo|numCpuPackages, depth=1

           

           

          This is an example of one of my super metrics (it calculates uptime in days for a VM). When I  first tried to create it using the native selection tools, it auto-populated unnecessary info that prevented the metric from calculating.

           

           

          Auto-populated version (doesn't work):

          Capture1.png

           

          Modified version (works):

          Capture.png

          • 2. Re: Calculate additional attribute using supermetrics?
            sxnxr Expert

            In super metrics Attributes are properties and most cant be used in super metrics.

             

            When you select a host system it showed you two windows

             

             

            The right is the properties/attributes and the left is metrics. Try and use the metrics.

             

            I just want to clear up some miss info. Auto population does work and is needed in some insistence. To explain i will break it down First you need to understand how vrops object levels work. When you select an object there are three things you want specifically in super metrics

             

            1. To manipulate one or more metrics on the object you are selecting. In your case the Host
            2. To get stats on an object further up or down from the object you are selecting
            3. to manipulate a metric on the object you are selecting using a metric from a different object further up or down from the object you are selecting

             

            So lets take the first one as this is the easiest Want you are wanting to do is that the memory in the host and decide it by the number of sockets this is simple as the host has both those metrics.

             

            When creating the metric select the object you what ( hosts) then click the this button from the top next to operators then select the metric. What this is doing is telling the super metric that the metric will be based on the object i am selecting ( this object). This is not bound to the Host because if the metric is present on another object it will show data because you used the "This"

             

            That is why for you the this option is a good fit.

             

            The second one:

             

            Now say you want to select a cluster and want to get the average disk commands per second that metric for all the VMs in the cluster is not present at the cluster level so you cant use the this value at the start that is where the other info is used.

             

            The supre metric needs to know the location of the metric and where is is expected to be. That is why you need the adaptertype=VMWARE, objecttype=VirtualMachine, attribute=virtualDisk|commandsAveraged_average, part.

             

            Looking at the below supermetric it is simply getting the average (avg function) of all the Vms on a cluster. The metric we are looking is 5 levels down from the cluster that is what the depth is for

             

            Avg(${adaptertype=VMWARE, objecttype=VirtualMachine, attribute=virtualDisk|commandsAveraged_average, depth=5})

             

            If you used the this in this SM it would not work because it would ignore the depth value as the this is looking for the metric that does not exist on the cluster

             

            third one

             

            This is one of my capacity SM.

             

            All this is doing is geting the number of cores in a cluster and the taking away the number of cores in one host multiplying it by 7 and then takingaway the vCPUs assigned to all the VMs

             

            ((${this, metric=cpu|corecount_provisioned}-(${this,metric=cpu|corecount_provisioned}/${this, metric=summary|number_running_hosts}))*7)-sum(${adaptertype=VMWARE, objecttype=VirtualMachine, attribute=config|hardware|num_Cpu, depth=2})

             

            Notice the VMs part is not using the this because i needed to go down 2 levels from the cluster to the VM and it is using an attribute that is why i said most dont work as there are some that do

             

            Apologises this went on for so long ( i could go on for longer but wont) and i hope it helps

            • 3. Re: Calculate additional attribute using supermetrics?
              jmastop Lurker

              Tried it and is does get rid of the error. So the syntax is accepted now.

               

              I enabled the metric in the policy but I can't find it on the object, even after a day or so. Could be my misunderstanding of the metrics, so I'll have another look. Otherwise I'll mark the answer as correct. Thanks.

              • 4. Re: Calculate additional attribute using supermetrics?
                sxnxr Expert

                what is you new metric.

                 

                Also a good tip. After you create your new metric, below the super metric screen there is a box

                 

                Make sure to specify the object the SM is for and when you go into the policy enable the SM for that object only and not the all objects one. This will cut down the processing needed during a collection cycle as vrops will try to work out the metric on all objects even if it does not work

                • 5. Re: Calculate additional attribute using supermetrics?
                  jmastop Lurker

                  Still not working. The syntax is accepted, and I added it to the policy (enabled it) and coupled it to the Host Object type. But when I preview the supermetric on a host the data is still null, and I can't find it on any othe the objects in Environment when looking through All Metrics.

                   

                  I think the problem is simple: attributes/properties cannot be used to make supermetrics. And unfortunately for me, the number of CPU packages (physical sockets) is only available as an attribute, not as a metric.

                  • 6. Re: Calculate additional attribute using supermetrics?
                    sxnxr Expert

                    do all your hosts have the same number of scokets

                    • 7. Re: Calculate additional attribute using supermetrics?
                      jmastop Lurker

                      Most of them have two, yes. But some I've found have only one socket populated, and the newer systems have two sockets, but are considered as 4 NUMA nodes. So I might have an issue with using that metric anyway: CPU packages does not imply that the scheduler sees the same number of NUMA nodes.

                       

                      I'll leave it for know and consider the question answered (assuming attributes/properties cannot be used in supermetrics).

                      • 8. Re: Calculate additional attribute using supermetrics?
                        sxnxr Expert

                        How badly do you want this.

                         

                        I have a way using supermetrics but it is complex and requires having a different policy per number of cpu sockets in a hosts and then the hosts in thoes groups using custom groups.

                        • 9. Re: Calculate additional attribute using supermetrics?
                          jmastop Lurker

                          I'm assuming you mean to put the hosts with the same number of physical sockets in the same custom group or policy, and then use a static division value? That could work I supose, but it is a bit more work.

                           

                          I'm more and more inclined to see if I can detect vNUMA issues by tracking remote memory referencing or locality percentage. But those metrics do not seem to be in the policy by default. I've tried to set them to Enabled locally.