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

Kernel input giving error: 'parsing "5303043560": value out of range' without further information #1258

Closed
fedwmt opened this issue May 24, 2016 · 2 comments · Fixed by #1266

Comments

@fedwmt
Copy link

fedwmt commented May 24, 2016

Running with:

$ bin/telegraf -config conf/telegraf.config -debug

gives:

2016/05/24 19:53:40 Error in input [kernel]: strconv.ParseInt: parsing "5303043560": value out of range

The above error message is not sufficient to troubleshoot the underlying issue.

Telegraf Version:

$ bin/telegraf -version
Telegraf - version 0.13.0

OS:

$ cat /etc/redhat-release
CentOS release 6.6 (Final)

$ uname -a
Linux <..hostname edited..> 2.6.32-504.30.3.el6.x86_64 #1 SMP Wed Jul 15 10:13:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

The other inputs are fine (if I comment-out the 'kernel' input, they all work).

I suspect the issue is the telegraf expects the interrupts (intr) to be an 'integer' type, but the value is out of range.

$ bin/telegraf -config conf/telegraf.config-test -test || cat /proc/stat
* Plugin: kernel, Collection 1
2016/05/24 20:09:28 strconv.ParseInt: parsing "5303737857": value out of range
cpu  25459482 4014 10792855 6177490251 972295 2683 585014 171996 0
cpu0 3256696 550 1768208 770050017 957037 2683 112203 61922 0
cpu1 2135533 456 1372634 773673825 2011 0 6867 13189 0
cpu2 2008336 518 1221465 773860116 3021 0 6449 12352 0
cpu3 7731978 552 1934412 767445967 1789 0 6652 15707 0
cpu4 3510001 511 1269415 771404341 1835 0 434215 33091 0
cpu5 2829677 528 1124897 773170528 2081 0 6120 12009 0
cpu6 2035603 513 1043280 773911547 2402 0 6199 11808 0
cpu7 1951655 383 1058542 773973906 2116 0 6306 11913 0
intr 5303737897 128 6 0 0 139 0 0 0 0 0 777988 0 104 0 0 547 0 0 0 0 0 0 0 0 0 13528706 0 16526434 0 156307999 2168 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ctxt 7913815629
btime 1456339847
processes 26623502
procs_running 1
procs_blocked 0
softirq 2946952525 0 1197629509 457 207621274 544 0 139 274612973 6015514 1261072115

It would be great to display which stat/measurement exceeded the data type range (as well as supporting a larger integer types, e.g. uint64).

@zstyblik
Copy link
Contributor

zstyblik commented May 25, 2016

@fedwmt, funny thing is the following works at my 64bit machine with golang 1.6.x:

package main

import (
    "log"
    "strconv"
)

func main() {
    foo, err := strconv.Atoi("5303737857")
    if err != nil {
        panic(err)
    }
    log.Print(foo)
}

but doesn't work at golang playground figure#1. The reason might be default value of strconv.ParseInt() which might depend on platform/golang version.

Therefore, my conclusion is that it might be better to specifically call either strconv.ParseInt("123", 10, 64) or strconv.ParseUint("123", 10, 64) ... as you've suggested, sort of ... because such case works in golang playground figure#2. This is also based on discussion at stack-overflow which suggests that "5303737857" is perfectly within range of int64 and uint64, but not in int32 nor uint32 range.

@sparrc
Copy link
Contributor

sparrc commented May 25, 2016

since influxdb doesn't support uint64, I'm going to parse it to int64, because that number is well within the bounds of max int64

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

Successfully merging a pull request may close this issue.

3 participants