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

metrics: free inode script code presumes a single mount #245

Open
grahamwhaley opened this issue Oct 25, 2019 · 0 comments
Open

metrics: free inode script code presumes a single mount #245

grahamwhaley opened this issue Oct 25, 2019 · 0 comments
Labels

Comments

@grahamwhaley
Copy link

Testing a PR using a kind (Kubernetes IN Docker) cluster for testing, I hit this error:

INFO: And grab some stats
INFO: idle [94.38] free [23529112] launch [0] node [kind-worker2] inodes_free [30909596
30909596
30909596]
./k8s_scale_nc.sh: line 124: 30909596
30909596
30909596: syntax error in expression (error token is "30909596
30909596")

Tracking that down to the code:

local inode_free=$(kubectl exec -ti $name -- sh -c "df -i | awk '/^overlay/ {print \$4}'" | sed 's/\r//')
...
local inode_used=$((node_baseinode[$node]-inode_free))

The root problem looking like the code presumes there will only be one overlay mount point, but under kind it seems there are three.... from an exec sh into the stats pod, we can see:

/ # df
Filesystem           1K-blocks      Used Available Use% Mounted on
overlay              490818480  23955044 441861504   5% /
tmpfs                    65536         0     65536   0% /dev
tmpfs                 16415596         0  16415596   0% /sys/fs/cgroup
overlay              490818480  23955044 441861504   5% /etc/hosts
overlay              490818480  23955044 441861504   5% /dev/termination-log
/dev/root            490818480  23955044 441861504   5% /etc/hostname
/dev/root            490818480  23955044 441861504   5% /etc/resolv.conf
shm                      65536         0     65536   0% /dev/shm
tmpfs                 16415596        12  16415584   0% /var/run/secrets/kubernetes.io/serviceaccount

Not sure on the best solution here. Looking for input @dklyle @askervin - can we just take the first instance, or should we sum all instances, or should we treat each instance separately?

I'm also wondering if moving from the stats pod to the collectd data would fix this or make the solution better?

@obedmr obedmr added the scaling label Oct 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants