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

4.0.0-rc2: put the prometheus exporter on a different port #899

Closed
matthewdarwin opened this issue Mar 25, 2023 · 2 comments · Fixed by #939 or #989
Closed

4.0.0-rc2: put the prometheus exporter on a different port #899

matthewdarwin opened this issue Mar 25, 2023 · 2 comments · Fixed by #939 or #989
Assignees
Labels
discussion 👍 lgtm OCI Work exclusive to OCI team
Milestone

Comments

@matthewdarwin
Copy link

When you put plugin = eosio::prometheus_plugin it adds a new /v1/prometheus/metrics URL.

You want this URL to be available to the monitoring system.
But this same port is used for the producer plugin which needs to be highly restricted (and definately not available to the monitoring system).

For security reasons, the prometheus export must run on a dedicated port. Otherwise node operators need to have a proxy server in between to handle the security. This is nonsensical requirement to use a monitoring plugin.

Look at any other blockchain software that has prometheus feature. Always runs on a separate port.

@spoonincode
Copy link
Member

I'm moving this out of actionable to discussion because maybe we want to shoehorn in something special for prometheus in 4.0, but maybe we need to reflect on this a little more as the "run such-and-such-plugin on a separate port" is such a common request (#88, eosnetworkfoundation/mandel#343, eosnetworkfoundation/mandel#360, etc etc). I'd like some consideration given before rushing in to anything that may be short sighted.

@bhazzard
Copy link

This is a missed requirement on my part. @heifner can you propose a solution here and have @huangminghuang immediately start work on it for inclusion in rc3?

We need a solution that is trivial to implement (ideally that can be designed, developed, tested & reviewed in about 1 week).

If there is such a trivial solution that addresses Matt's point about the need for a more general solution, please propose it.

Otherwise, please propose a focussed solution to the immediate problem at hand. Consider how we might move towards a more generalized solution as part of our focussed solution.

@heifner heifner added the OCI Work exclusive to OCI team label Mar 30, 2023
@arhag arhag added this to the Leap 4.0.0 milestone Apr 4, 2023
@arhag arhag linked a pull request Apr 5, 2023 that will close this issue
@stephenpdeos stephenpdeos moved this from Todo to In Progress in Team Backlog Apr 6, 2023
@github-project-automation github-project-automation bot moved this from In Progress to Done in Team Backlog Apr 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion 👍 lgtm OCI Work exclusive to OCI team
Projects
Archived in project
8 participants