search

atc0005 / go-lockss

Go-based tooling for monitoring and troubleshooting LOCKSS nodes.
MIT License
2 stars 1 forks source link

Develop Nagios plugin #35

Open atc0005 opened 3 years ago

atc0005 commented 3 years ago

Summary

As I've made vague reference to at least once, I plan to include a Nagios plugin in this project. Much of the work for the cmd/hayoh application should be reflected in this new tool, though the overall design of a Nagios plugin will be expected.

As a template, the work I did for the atc0005/check-cert project (specifically the check_cert plugin) can be used.

References

atc0005 commented 3 years ago

My plan was to work on this next, potentially this week or the next. I've since had someone show interest in developing this plugin (or contributing efforts towards it), so I will see where things go. It may be that a synergy of sorts occurs and the results of both efforts are combined into final result. If/when I start work on this I'll post back and reference the branch I'm working on in case it is helpful.

danvixent commented 3 years ago

Hi Adam, i've gone through the references above. But i'm still not clear as to what we want to achieve here. Please further explain. Thanks.

atc0005 commented 3 years ago

Nagios is a monitoring system that calls out to "plugins" to perform actions. Plugins are either command-line applications or shell scripts that take zero or more arguments and return an error code and optionally a text string and performance data.

Nagios (what I refer to as the "console") takes those results and makes a determination regarding the state of the host or service it is monitoring.

I am simplifying, but each plugin is in charge of performing the action and returning a specific error code indicating OK, WARNING, CRITICAL, UNNOWN or a 5th state, which I forget.

The plugins that I linked to are for checking and IMAP account and a certificate, respectively. The IMAP check is the first I wrote and uses a different approach to returning the success/failure state than the cert check plugin, which uses an approach that I think I want to polish a bit and use for plugins going forward. I think. Once I get into implementing the code for this latest plugin I would probably have a good feel for things.

atc0005 commented 3 years ago

After thinking on this a bit, unless a further need pops up on an existing project I plan to work on the atc0005/go-nagios project as my next medium-sized focus item. For the next few days I'll probably spend time on "repo gardening", picking back up on my work to update existing GitHub Actions Workflows to use the Docker containers from the atc0005/go-ci project.

I was working on those tasks (https://github.com/users/atc0005/projects/1) before I got distracted by the work on this project.

All of that said, once I make some progress with the atc0005/go-nagios project it should make work on this specific GH issue easier to implement. If you want, I can ping you here or via Twitter once I've made some progress there and we can take another look at this.

danvixent commented 3 years ago

Adam, i'm going through the code in this repo, i'm still getting it, but no there yet. One thing though, why are you vendoring dependencies manually? go.mod already does this automatically. As regards the milestone we want to achieve, i'm sure i'll be able to reason about them better when i fully understand this codebase.

danvixent commented 3 years ago

Thanks for the above explanations too. And yes ping me. Preferably on twitter so i get it faster.

atc0005 commented 3 years ago

@danvixent: One thing though, why are you vendoring dependencies manually? go.mod already does this automatically.

You're right in that it tracks dependencies and caches them locally. But what if I want to create a code archive that provides a reproducible build that reflects a point in time? For example, I'm (AFAIK) the only person on our team that uses Go, and as you can tell from the quality of the codebase, a fairly new Go developer. Most projects that I work on provide a README with build instructions. I also cache the Go installers on an internal work file server.

Presumably, if I get hit by a bus (an unfortunate stand-in for worst-case scenario that we use) our team will have everything they need between the source archives I download from GitHub and the installers that I cache to reproduce any binaries that I generate and deploy on our systems.

That's my thinking. I understand it's not for everyone (and I hear that large scale projects with many dozens of dependencies can't afford to do this), but I was leaning towards a strict sense of reproducible builds.

EDIT

A good counter-argument (in favor of what you said) for vendored dependencies:

and further discussions in both directions:

danvixent commented 3 years ago

Talking about points in time we have git, don't we? But either way I'm also guessing you're doing this for the convenience of your team. It's a good trade-off then.

Seriously though, consider Go modules. It caches the versions directly for you. See: https://blog.golang.org/using-go-modules

atc0005 commented 3 years ago

Talking about points in time we have git, don't we?

We do, and it works well for code under our own control. Vendoring dependencies puts additional code under our control and (the thinking is) helps with reproducible builds.

I'm also guessing you're doing this for the convenience of your team. It's a good trade-off then.

Correct, though at this point I'll probably continue the practice regardless of the environment, at least for now.

Seriously though, consider Go modules. It caches the versions directly for you. See: https://blog.golang.org/using-go-modules

Acknowledged. I'm actually using Go modules and started off my first project using them. At this point I couldn't imagine not using that functionality.

The nice thing is that using Go modules doesn't preclude you from using vendoring, it actually supports that workflow.

  1. go mod tidy
  2. go mod vendor

This results in a local vendor folder that goes into version control containing the latest dependencies as specified by the project's go.mod file. Go 1.14 even added automatic use of a vendor folder if found, so whereas you had to use go build -mod=vendor to use the vendor folder prior to Go 1.14, you just run go build now and it will automatically use the vendor folder if it is present. This automatic use of a vendor folder also extends to other uses of the go tool, such as vet, test and so forth.

danvixent commented 3 years ago

I'm aware of those features. Anyway, whatever works for you.

atc0005 commented 3 years ago

@danvixent: I'm aware of those features. Anyway, whatever works for you.

Cool, I couldn't be sure we were on the same page, so I figured it would be good to setup a baseline.

I'm going to mark our Go modules conversation as "off topic" (posts that we both have made) in order to collapse the GH issue a little and keep it focused on the implementation work. I don't mind that we got off-topic (some of the best conversations start that way), just pushing them a little to the background (including this follow-up post).