Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Used memory field corrected (#4461) #4462

Merged
merged 1 commit into from
Jul 11, 2017
Merged

Used memory field corrected (#4461) #4462

merged 1 commit into from
Jul 11, 2017

Conversation

amandahla
Copy link

Change for correct the used memory field.

@elasticmachine
Copy link
Collaborator

Can one of the admins verify this patch?

@elasticmachine
Copy link
Collaborator

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically on build-eu-00. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

@tsg
Copy link
Contributor

tsg commented Jun 6, 2017

jenkins, test it

@andrewkroh
Copy link
Member

Hi @amandahla, is there a test case you can add for this? It would be nice to have something in place that demonstrates this fixes the issue and prevents future regression.

And BTW if you put "Closes #4461" in the commit message then the issue will automatically be closed when this merges.

@amandahla
Copy link
Author

@andrewkroh hs.Summary.QuickStats.OverallMemoryUsage is a int32 value for memory usage in MB.
When I multiply twice to get bytes numbers without the conversion, it exceeds the int32 maximum and gives a wrong number. We just get this when we saw weird values on dashboard. So I saw that I must convert to int64 to fit the right value.
I don't know how can I test when it's necessary a bigger variable type. Any suggestions?

Thanks for the tip about close issues!

@andrewkroh
Copy link
Member

Any suggestions?

I recommend splitting up the logic from Fetch into smaller functions that can be easily unit tested (without requiring the simulator).

@amandahla
Copy link
Author

@andrewkroh I'm not sure if I get the idea. Is something like this?

@andrewkroh
Copy link
Member

Yeah, sort of. I guess I was thinking more like this (or some other break down of the existing logic to make it unit testable without the use of the data simulator).

func (m *MetricSet) Fetch() ([]common.MapStr, error) {
    ...
    for _, hs := range hst {
        events = append(events, buildEvent(hs))
    }
    ...
}
func buildEvent(hs mo.HostSystem) common.MapStr { ... }
func TestBuildEvent(t *testing.T) {
   var hs mo.HostSystem
   hs.Summary.Hardware.MemorySize = math.MaxInt32
   // set other values

   event := buildEvent(hs)

   // assert correct output w/o overflow
}

@amandahla
Copy link
Author

@andrewkroh Another try :)

Copy link
Member

@andrewkroh andrewkroh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like you got the idea. 👍

@@ -0,0 +1,129 @@
package host
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like this file is only used for testing. If so it should be named with the _test.go suffix so that it is only compiled and used in tests. But I would probably just move the HostSystemTest definition into the data_test.go.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like you could have got away with a much smaller set of stub data for your testing purposes because eventMapping only needs a few of the fields.

cpu := event["cpu"].(common.MapStr)

cpuUsed := cpu["used"].(common.MapStr)
assert.EqualValues(t, 67, cpuUsed["mhz"])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI It should be possible to write this as

value, _ := event.Get("cpu.used.mhz")
assert.EqualValues(t, 67, value)

Personally, I find using the dotted field notational easier to work with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants