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

Moving Collectors to 'available' so they are not enabled by default #239

Closed
wants to merge 1 commit into from

Conversation

johann8384
Copy link
Member

Closes #190

@johann8384
Copy link
Member Author

@tsuna @vasiliyk I'd prefer one of you weigh in on these rather than merge my own PR.

@johann8384 johann8384 added this to the 1.3.0 milestone Feb 5, 2016
@tsuna
Copy link
Member

tsuna commented Feb 7, 2016

So is the expectation that distributions will package all these collectors using the available directory and that after installation, the system operators will symlink them into the 0 directory to enable the collectors of their choice (perhaps with Puppet or Chef or whatever, or manually)?

@johann8384
Copy link
Member Author

Yes, I think I'll modify it to be a little different, like maybe have an "available", an "osx", a "freebsd" and try to put the current collectors in available and then the os specific ones in the other two folders.

I'm not 100% sure how this one will work out yet, and I need to properly coordinate it with the packaging so that it works.

I'm planning to build a build pipeline that will use Docker to build for RPM and DEB packages. I suspect I can integrate the Arista EOS build into that also.

@johann8384 johann8384 force-pushed the ISSUES-190 branch 2 times, most recently from 8fbcc9b to 908cfd9 Compare February 8, 2016 03:59
@johann8384 johann8384 modified the milestones: 1.3.1, 1.3.0 Feb 8, 2016
@johann8384
Copy link
Member Author

That is the best I layout I have seen so far, but I feel like there is a better way still.

@johann8384
Copy link
Member Author

What about collectors that work on OSX and Linux, but not FreeBSD? (or some such thing)

Edit: Or more likely, base system collectors that work more globally

@johann8384
Copy link
Member Author

I guess the packaging/install script could enable a set of collectors by default based on the OS. Or, we could have:

collectors-available/
┗ global/
  ┗ long-lived/
  ┗ one-shot/
┗ linux/
  ┗ long-lived/
  ┗ one-shot/
┗ freebsd/
  ┗ long-lived/
  ┗ one-shot/
┗ osx/
  ┗ long-lived/
  ┗ one-shot/
┗ softwares/
  ┗ long-lived/
  ┗ one-shot/
collectors-enabled/
┗ 0/
┗ 60/
┗ 3600/
┗ (...)
collectors-etc/

This would leave the collectors that work everywhere in global. We could also encourage collectors to make use of a "get_tcollector_platform()" function in utils that would essentially wrap platform.system().

This way a collector that could do most things on Linux and FreeBSD could politely decline to run on OSX, or if the available metrics were different, on each platform output what it could.

@johann8384 johann8384 modified the milestones: 1.3.1, 1.3.2 Mar 16, 2016
@johann8384 johann8384 modified the milestones: 1.3.3, 1.3.2 Jul 6, 2016
@johann8384 johann8384 removed this from the 1.3.3 milestone Dec 5, 2018
@vasiliyk
Copy link
Member

@johann8384 , thank you for putting it all together!!

I like the proposed structure and idea to enable global + OS specific collectors in packaging/install script.
What help do you need to finalize PR?

@vasiliyk vasiliyk added this to the 1.4.0 milestone May 3, 2024
@vasiliyk vasiliyk self-assigned this May 3, 2024
@vasiliyk
Copy link
Member

vasiliyk commented May 27, 2024

implemented and merged with the commit 881e215

Documentation updated to reflect the change: http://opentsdb.net/docs/build/html/user_guide/utilities/tcollector.html

@vasiliyk vasiliyk closed this May 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Restructure of collectors/*
3 participants