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

boot_time for freebsd #466

Closed
travisghansen opened this issue Feb 15, 2017 · 19 comments
Closed

boot_time for freebsd #466

travisghansen opened this issue Feb 15, 2017 · 19 comments

Comments

@travisghansen
Copy link

It appears most/all the grafana graphs for node_exporter have a server/node selector that uses something like:

  "templating": {
    "list": [
      {
        "current": {},
        "datasource": "${DS_PROMETHEUS}",
        "hide": 0,
        "includeAll": false,
        "multi": false,
        "name": "server",
        "options": [],
        "query": "label_values(node_boot_time, instance)",
        "refresh": 1,
        "type": "query"
      }
    ]
  },

FreeBSD seems to not include the node_boot_time metric rendering the graphs useless (as you can't select a freebsd node) for freebsd nodes.

Thanks!

@SuperQ
Copy link
Member

SuperQ commented Feb 16, 2017

You can use any other metric that does exist.

But it would be good to add this metric for feature parity. I'm not a freebsd expert, do you know where this data is available?

@travisghansen
Copy link
Author

@SuperQ not really a expert myself, more of a linux guy. Currently working on getting this packaged up for inclusion/integration with the pfSense firewall project.

https://forums.freebsd.org/threads/8679/

Also in the name of parity, I've noticed several of the datapoints that do cross paths are name differently such as node_memory_foo etc It would be good to see those synced up.

Likewise, would be great if each system send over common uname-esque data such as arch, kernel, userland, etc. Just a thought.

@derekmarcotte
Copy link
Contributor

derekmarcotte commented Mar 1, 2017

Hi - just wanted to add to this thread. A PR was just merged wrt BSD memory counters. FWIW, I have a swap_used metric that isn't integrated with the meminfo commit, as I'm seeking feedback on some thoughts.

The kernel boot time is in a sysctl. I was going to include this the exec collector that was just merged, but it's in a timeval_t, something that the Go runtime AFAIK doesn't handle natively.

Hoping to build on this more in the short term.

@travisghansen
Copy link
Author

Wow that looks like some great stuff! I'm not at my desk currently to review naming parity but I'll review and provide feedback as soon as I can.

Looking forward to the boot time metric as well to make these dashboards work out the box.

Thanks!

@travisghansen
Copy link
Author

I see now there is already a uname_linux file WRT my earlier comment. Not sure how easy that one would be to replicate on BSD.

@travisghansen
Copy link
Author

OK, I reviewed the names of them (can't really speak to the values per-se) and here is what I've found:

none of the linux items have 'bytes' in the name (from what I can tell..or at least none of them that match up with the bsd provided items)

linux -> bsd
wire -> wired
Buffers -> buffer
? -> size
SwapTotal -> swap_size?
swappgsin -> swap_in_bytes_total
swappgsout -> swap_out_bytes_total

Thanks!

@juliusv
Copy link
Member

juliusv commented Mar 13, 2017

Here's some background on why it's difficult to sync up names between metrics for different OSes: #150

@travisghansen
Copy link
Author

Yeah I read through that a while back. I understand the technical issues at hand.

I'm not really in a position to say but feel the only path forward is to unify. The problem is mostly unique to this exporter as most are not interacting with underlying os. The work is worth it.

@jtakkala
Copy link
Contributor

@travisghansen anywhere I can follow your work on getting node_exporter integrated into pfSense? We could really use this too. Thanks!

@travisghansen
Copy link
Author

@jtakkala I'm not currently working on it directly but rather have offered a 'bounty' for it's integration. We have running binaries but the interface is still being discussed pretty heavily. If you'd like to provide input hop on the irc channel and hit me up (thansen).

I'll be sure to share progress as it moves along though.

@derekmarcotte
Copy link
Contributor

@travisghansen - FYI #550 adds exec_boot_time

@travisghansen
Copy link
Author

Excellent! That will make the available dashboards much easier to use.

@derekmarcotte
Copy link
Contributor

@SuperQ aside from the metric name discussion (which is probably fleshed out in greater detail elsewhere), #550 resolved this issue, and could be closed.

@hbokh
Copy link
Contributor

hbokh commented Feb 12, 2018

Forgive my ignorance, but I am still under the impression there is no node_boot_time to be found at all in any of the node_exporter output from a FreeBSD-node.
A Linux-node shows: node_boot_time 1.51570171e+09; the closest a FreeBSD-node comes is node_exec_boot_timestamp_seconds 1.514366253244949e+09.
This comes close to what is in sysctl:
kern.boottime: { sec = 1514366253, usec = 244949 } Wed Dec 27 10:17:33 2017

FYI I recompiled node_exporter from v0.15.2 instead of using the FreeBSD-port, which is still on v0.15.0.

@SuperQ
Copy link
Member

SuperQ commented Feb 12, 2018

@hbokh We're standardizing on node_boot_time_seconds, but it seems like we add an exec subsystem to the BSD metrics. We may want to remove this subsystem prefix, atleast for boot time.

@hbokh
Copy link
Contributor

hbokh commented Feb 12, 2018

Thanks for the quick reply. And next to exec, the stamp in node_exec_boot_timestamp_seconds will be removed too, to get to the "final" node_boot_time_seconds?

@SuperQ
Copy link
Member

SuperQ commented Feb 12, 2018

Yes, and replace timestamp with just time.

@discordianfish
Copy link
Member

Yeah I think this issue should be closed since we merged #550.
@SuperQ Should we open an new issue for dropping exec_ for this?

@SuperQ
Copy link
Member

SuperQ commented Feb 12, 2018

@discordianfish Yes, please do.

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

No branches or pull requests

7 participants