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

Federation TODO #791

Closed
fabxc opened this Issue Jun 11, 2015 · 5 comments

Comments

Projects
None yet
3 participants
@fabxc
Copy link
Member

fabxc commented Jun 11, 2015

#786 piled up a few TODOs for federation:

  • honor_labels sufficient as final configuration option? Are there other things then label handling that should differentiate a federation target from a regular scrape target?
  • Sorting relevant except for debugging via text protocol?
  • Versioning of federation endpoint? As part of the regular API?
@fabxc

This comment has been minimized.

Copy link
Member Author

fabxc commented Jun 23, 2015

@juliusv If we can agree on the last point I'd close this one.
You suggested to include it into the API, I was for keeping it separated from the API. Do you have a stronger tendency so far?

For reference, my reasoning was that version bumps for the API endpoints and federation are unlikely to line up or be related at all. Plus the fundamentally different output format. I don't think an API client package should be required to interact with /federate to be complete.

@brian-brazil

This comment has been minimized.

Copy link
Member

brian-brazil commented Jun 23, 2015

I think some versioning would be wise, but not tied to the regular API. On the other hand it's only the arguments that should change over time, and that can probably be done in a backwards-compatible way.

@juliusv

This comment has been minimized.

Copy link
Member

juliusv commented Jun 23, 2015

I don't feel strongly... if we start with it outside of the API, we can still decide to move it into the API later (whereas the opposite would be more breaking).

@brian-brazil

This comment has been minimized.

Copy link
Member

brian-brazil commented Dec 16, 2015

I don't think there's anything more to be done here?

@fabxc fabxc closed this Dec 16, 2015

simonpasquier pushed a commit to simonpasquier/prometheus that referenced this issue Oct 12, 2017

Add a PHP-FPM exporter to the list of exporters (prometheus#791)
Currently, there is a large set of exporters available for a lot of different software tools.
However, the popular runtime "PHP-FPM", used for executing PHP script through the
FastCGI protocol, is not listed.

Various exporters currently exist, and the author has not tested any (including the
suggested) extensively. However, a quick review of the available options shows that,
in the authors limited review, this appears to be well constructed, thought out and
documented.

This commit adds the exporter to the canonical list for easy discovery. 

Design Notes:

Alternatives considered were:
- https://github.com/peakgames/php-fpm-prometheus/ (no releases, less docs)
- https://github.com/blablacar/phpfpm-prometheus-exporter (no docs)

* Shift the PHP-FPM exporter to the "misc" section

Previously, the author had added a new section titled "interpreters", and
added the PHP-FPM exporter to this section under the belief that, given there
was none (that is, neither node or python are represented) this could be a
separate class of application. However, with review it looks like the better
place for this exporter is under the "misc" section.

This commit moves the PHP-FPM exporter to this section.
@lock

This comment has been minimized.

Copy link

lock bot commented Mar 24, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Mar 24, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.