5 ms·

Sure. We use Prometheus exporters, most of the exporters are written in Go. And this is a snip from the vmware-exporter for our VMware estate. metrics.go

Sure. We use Prometheus exporters, most of the exporters are written in Go. And this is a snip from the vmware-exporter for our VMware estate. metrics.go The first throw was this: import ( "context" "github.com/prometheus/client_golang/prometheus" log "github.com/sirupsen/logrus" "github.com/vmware/govmomi/find" "github.com/vmware/govmomi/view" "github.com/vmware/govmomi/vim25/mo" "github.com/vmware/govmomi/vim25/types" So as it currently stands I have no idea what those modules are and what I am loading. Browsing each of those repos sure will tell me, but that's not my role. My role is to make X operational. And if that repo doesn't exist anymore and you go to compile, it fails. More overhead if I need to make changes to any of those modules. I would need to git clone it somewhere, make the change and then either recommit it to git, or do something to make it locally available. At least with NPM, CPAN they are local to the file system. So lets start: var ( prometheusHostPowerState = prometheus.NewGaugeVec(prometheus.GaugeOpts{ Namespace: namespace, Subsystem: "host", Name: "power_state", Help: "poweredOn 1, poweredOff 2, standBy 3, other 0", }, []string{"host_name"}) I understand all of that. Power_state, display the help, power status description etc, however prometheus.NewGaugeVec -- Sounds great. What is it? Where do I find this? What module is this related too? That's where it falls down for me. I now have to duck in to the rabbit hole of github to find out where that function is phrased and in this sense "under-the-hood" could also count for library .pm files in perl, but now having to navigate GitHub really messes with my workflow.

sleepybrett 6y ago
godoc, same problem with any language that uses any kind of modules, you need to consult the documentation for that module. https://pkg.go.dev/github.com/prometheus/client_golang/prometheus https://pkg.go.dev/github.com/prometheus/client_golang/prome... .. if fount that by googling `godoc prometheus newgaugevec` .. or you could just use `godoc` Your argument seems to be, "I don't like reading documentation." Then by all means don't and write your own prometheus metrics module shrug
- doublerabbit 6y ago
  > Then by all means don't and write your own prometheus metrics module shrug I'm a sysadmin, not a programmer. So I don't code for business operations. I compile them to make them work. I don't have time to read all the schematics of the application to make it work, but when it comes to perl, or TCL for that matter. All files are local, if my box has air-gapped and no access to github. Then what? > Your argument seems to be, "I don't like reading documentation." Not at all. I have limited time to spare on documentation. It's easier for me to read the code in front in practical form then it is to read documentation written on some wiki.
  - BenTheElder 6y ago
    `go mod vendor` will populate all dependency sources into `./vendor/` in a modules project for easy grepping. Some projects still use this to ensure sources work airgapped as well. https://golang.org/cmd/go/#hdr-Make_vendored_copy_of_dependencies https://golang.org/cmd/go/#hdr-Make_vendored_copy_of_depende...
  - Seb-C 6y ago
    > I'm a sysadmin, not a programmer. So I don't code for business operations. I compile them to make them work. Sounds like you have an organizational problem, not a programming language problem. I would expect developers to provide you with an actual application or at least automated way to build it, and you to deploy and handle the given application. Instead you have developers providing source code and you trying to understand how to make it work. There are plenty of tools, methods and ways to get a repeatable build process, including docker, CI, bash scripts... Even a README file can contain a valid and repeatable build process. Even a process called 'ask to Robert how it works' would provide you with the information you need It's hard to imagine that this is not scripted or at least documented somewhere.
q3k 6y ago
> So as it currently stands I have no idea what those modules are and what am I loading? vim25? Is that the text editor vim? Take any of these imports, append it to https://godoc.org/ https://godoc.org/, and see. For example, github.com/vmware/govmomi/ becomes http://godoc.org/github.com/vmware/govmomi/ http://godoc.org/github.com/vmware/govmomi/ , which tells you: govmovi: A Go library for interacting with VMware vSphere APIs (ESXi and/or vCenter). Everything underneath govmovi is subpackages of it, so `find`, `view`, `vim25/mo`, and `vim25/types` are all govmovi packages. You can also visit them on godoc to read documentation, if the code authors followed documentation best practices. These are imports like in any other language. They are, however, nearly always based on a global URL, and thus have a godoc page that you can visit and read the docs for immediately. They are also always qualified, so if you wanna find all all uses of govmovi/vim25/mo, just C-f for "mo." in your codebase. No `from foo import *` equivalent exists in Go, which is one of my favourite features of this language.
- doublerabbit 6y ago
  Sure. Fair to say that godocs is to cpan of perl. But Go doesn't present you the code on disk. I have to hunt somewhere else with a reference. With a library file, I know that prometheus::exporter::blah is related to the perl module prometherus, exporter subroutine blah I need the code in front of me to understand how it's interacting; the whole github ruins that for me.
  - hnlmorg 6y ago
    > But Go doesn't present you the code on disk. Yes it does. You couldn't compile the modules if they weren't on disk :)
    - doublerabbit 6y ago
      But only at compile time.
      - q3k 6y ago
        `go mod download`, if you're using go modules, will fetch you the deps. This is no different, to me, than downloading a tarball of Python software with requirements.txt and not running setup.py or pip install. I don't understand the problem.
hnlmorg 6y ago
That's no different to importing a module in Perl. If you want to know what's in that module then you read the source of it. > I understand all of that. Power_state, display the help, power status description etc, but prometheus.NewGaugeVec -- great. What is it? Where do I find this? It's a function in the module `prometheus`: "github.com/prometheus/client_golang/prometheus" It's the same thing as the following Perl code: use Prometheus; use Prometheus::Log; use Prometheus::Find; use Prometheus::View; use vmware::govmomi::vim25::mo; use mware::govmomi::vim25::types; my %prometheusHostPowerState = prometheus::NewGaugeVec(prometheus->GaugeOpts{ "Namespace" => $namespace, "Subsystem" => "host", "Name" => "power_state", "Help" => "poweredOn 1, poweredOff 2, standBy 3, other 0", }, @("host_name"); As you can see the code is actually really similar between the two languages in that regard. Bare in mind I'm not suggesting that the languages themselves are similar, eg how modules are created, methods written and arrays are handled are clearly different. But the concept of reusable imported modules and properties in a struct/hash are ostensibly the same. Disclaimer: I've not written much Perl in the last 3 years so I might have gotten some of the syntax slightly wrong. But it should be close enough for demo purposes.
- doublerabbit 6y ago
  Then it would be fair to say I can't grasp the new-modern use of github module method then the traditional where prometheus.pm exists on disk and I can trace,trap and edit on the fly. With the line above, prometheus::NewGaugeVec. I know it's related to the Prometheus module, NewGaurgeVec subroutine. I'm not a programmer, I'm a systems admin who job is to take requests of such "we need a vmware exporter, I have this. Make it work".
  - hnlmorg 6y ago
    The "new-modern use of a github module" is the same as for Perl. If a module isn't in CPAN you have to manually download and place in your project directory. Go just does this for you. And the module files in Go are on disk -- there's no way you could compile the project if half the source code wasn't on disk. I think you'd probably have enjoyed Go more in the "old" days when $GOPATH was required and all modules were downloaded into your $GOPATH as it was more explicit were modules were and in a way it felt a little more like Perl with the file system being a more prominent part of modules. This was a very unpopular pattern for developers so things have moved on somewhat with modules now being pulled into a package directory. Personally I preferred the $GOPATH days too but it's fair to say the modules are still on disk.
BarkMore 6y ago
You do not need to go down the Github rabbit hole. The symbol prometheus is from the package github.com/prometheus/client_golang/prometheus. Use go doc github.com/prometheus/client_golang/prometheus to read the documentation from your local copy of the package. Use go list -f {{.Dir}} github.com/prometheus/client_golang/prometheus to find out where your local copy is located. If there is only one prometheus.NewGaugeVec in your workspace, then the command go doc prometheus.NewGaugeVec shows the documentation for function and reports the package where it's defined.
- doublerabbit 6y ago
  Yes, it states the obvious, but I'm trying to point out what I mean. It's not always so golden as such.

sleepybrett 6y ago

godoc, same problem with any language that uses any kind of modules, you need to consult the documentation for that module. https://pkg.go.dev/github.com/prometheus/client_golang/prometheus https://pkg.go.dev/github.com/prometheus/client_golang/prome... .. if fount that by googling `godoc prometheus newgaugevec` .. or you could just use `godoc` Your argument seems to be, "I don't like reading documentation." Then by all means don't and write your own prometheus metrics module shrug

doublerabbit 6y ago
> Then by all means don't and write your own prometheus metrics module shrug I'm a sysadmin, not a programmer. So I don't code for business operations. I compile them to make them work. I don't have time to read all the schematics of the application to make it work, but when it comes to perl, or TCL for that matter. All files are local, if my box has air-gapped and no access to github. Then what? > Your argument seems to be, "I don't like reading documentation." Not at all. I have limited time to spare on documentation. It's easier for me to read the code in front in practical form then it is to read documentation written on some wiki.
- BenTheElder 6y ago
  `go mod vendor` will populate all dependency sources into `./vendor/` in a modules project for easy grepping. Some projects still use this to ensure sources work airgapped as well. https://golang.org/cmd/go/#hdr-Make_vendored_copy_of_dependencies https://golang.org/cmd/go/#hdr-Make_vendored_copy_of_depende...
- Seb-C 6y ago
  > I'm a sysadmin, not a programmer. So I don't code for business operations. I compile them to make them work. Sounds like you have an organizational problem, not a programming language problem. I would expect developers to provide you with an actual application or at least automated way to build it, and you to deploy and handle the given application. Instead you have developers providing source code and you trying to understand how to make it work. There are plenty of tools, methods and ways to get a repeatable build process, including docker, CI, bash scripts... Even a README file can contain a valid and repeatable build process. Even a process called 'ask to Robert how it works' would provide you with the information you need It's hard to imagine that this is not scripted or at least documented somewhere.

q3k 6y ago

> So as it currently stands I have no idea what those modules are and what am I loading? vim25? Is that the text editor vim? Take any of these imports, append it to https://godoc.org/ https://godoc.org/, and see. For example, github.com/vmware/govmomi/ becomes http://godoc.org/github.com/vmware/govmomi/ http://godoc.org/github.com/vmware/govmomi/ , which tells you: govmovi: A Go library for interacting with VMware vSphere APIs (ESXi and/or vCenter). Everything underneath govmovi is subpackages of it, so `find`, `view`, `vim25/mo`, and `vim25/types` are all govmovi packages. You can also visit them on godoc to read documentation, if the code authors followed documentation best practices. These are imports like in any other language. They are, however, nearly always based on a global URL, and thus have a godoc page that you can visit and read the docs for immediately. They are also always qualified, so if you wanna find all all uses of govmovi/vim25/mo, just C-f for "mo." in your codebase. No `from foo import *` equivalent exists in Go, which is one of my favourite features of this language.

doublerabbit 6y ago
Sure. Fair to say that godocs is to cpan of perl. But Go doesn't present you the code on disk. I have to hunt somewhere else with a reference. With a library file, I know that prometheus::exporter::blah is related to the perl module prometherus, exporter subroutine blah I need the code in front of me to understand how it's interacting; the whole github ruins that for me.
- hnlmorg 6y ago
  > But Go doesn't present you the code on disk. Yes it does. You couldn't compile the modules if they weren't on disk :)
  - doublerabbit 6y ago
    But only at compile time.
    - q3k 6y ago
      `go mod download`, if you're using go modules, will fetch you the deps. This is no different, to me, than downloading a tarball of Python software with requirements.txt and not running setup.py or pip install. I don't understand the problem.

hnlmorg 6y ago

That's no different to importing a module in Perl. If you want to know what's in that module then you read the source of it. > I understand all of that. Power_state, display the help, power status description etc, but prometheus.NewGaugeVec -- great. What is it? Where do I find this? It's a function in the module `prometheus`: "github.com/prometheus/client_golang/prometheus" It's the same thing as the following Perl code: use Prometheus; use Prometheus::Log; use Prometheus::Find; use Prometheus::View; use vmware::govmomi::vim25::mo; use mware::govmomi::vim25::types; my %prometheusHostPowerState = prometheus::NewGaugeVec(prometheus->GaugeOpts{ "Namespace" => $namespace, "Subsystem" => "host", "Name" => "power_state", "Help" => "poweredOn 1, poweredOff 2, standBy 3, other 0", }, @("host_name"); As you can see the code is actually really similar between the two languages in that regard. Bare in mind I'm not suggesting that the languages themselves are similar, eg how modules are created, methods written and arrays are handled are clearly different. But the concept of reusable imported modules and properties in a struct/hash are ostensibly the same. Disclaimer: I've not written much Perl in the last 3 years so I might have gotten some of the syntax slightly wrong. But it should be close enough for demo purposes.

doublerabbit 6y ago
Then it would be fair to say I can't grasp the new-modern use of github module method then the traditional where prometheus.pm exists on disk and I can trace,trap and edit on the fly. With the line above, prometheus::NewGaugeVec. I know it's related to the Prometheus module, NewGaurgeVec subroutine. I'm not a programmer, I'm a systems admin who job is to take requests of such "we need a vmware exporter, I have this. Make it work".
- hnlmorg 6y ago
  The "new-modern use of a github module" is the same as for Perl. If a module isn't in CPAN you have to manually download and place in your project directory. Go just does this for you. And the module files in Go are on disk -- there's no way you could compile the project if half the source code wasn't on disk. I think you'd probably have enjoyed Go more in the "old" days when $GOPATH was required and all modules were downloaded into your $GOPATH as it was more explicit were modules were and in a way it felt a little more like Perl with the file system being a more prominent part of modules. This was a very unpopular pattern for developers so things have moved on somewhat with modules now being pulled into a package directory. Personally I preferred the $GOPATH days too but it's fair to say the modules are still on disk.

BarkMore 6y ago

You do not need to go down the Github rabbit hole. The symbol prometheus is from the package github.com/prometheus/client_golang/prometheus. Use go doc github.com/prometheus/client_golang/prometheus to read the documentation from your local copy of the package. Use go list -f {{.Dir}} github.com/prometheus/client_golang/prometheus to find out where your local copy is located. If there is only one prometheus.NewGaugeVec in your workspace, then the command go doc prometheus.NewGaugeVec shows the documentation for function and reports the package where it's defined.

doublerabbit 6y ago
Yes, it states the obvious, but I'm trying to point out what I mean. It's not always so golden as such.