[
https://issues.apache.org/jira/browse/HBASE-20904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160287#comment-17160287
]
Nick Dimiduk commented on HBASE-20904:
--------------------------------------
I'm not keen on copying more metrics code from Hadoop in to HBase. I'm also not
keen on expanding our codebase when perfectly good alternatives exist that are
supported by the project with which we're trying to integrate. I'm not saying
-0, I'm just asking for strong justification.
It looks like there's someone [actively
working|https://github.com/prometheus/jmx_exporter/pull/459] on making
Prometheus/HBase integration work better. Why not team up with them to make the
agent more robust for our users?
Also, isn't the Slider project
[retired|https://incubator.apache.org/projects/slider.html]?
bq. we have to dynamically decide the port on which agent listens on as two
server processes (M / RS) can be deployed on a single host (by slider/yarn).
This becomes a burden for the slider user as agent doesn't provide this
funcationality and one cannot choose some random number <64k.
Having the agent support binding to an arbitrary port and advertising it back
to an operator seems like a feature the agent should have, file a feature
request? I haven't used slider so I don't know what limitations are present on
that platform, but any host running multiple JVMs with this agent installed
will have a similar need, so seems like an upstream problem they want to solve
anyway.
bq. Well we can use agent+pushgateways combination but the metrics are
published all the time which may be become unnecessary given the size of
metrics published (prometheus expo format is verbose).
I don't quite follow you here... I see the agent supports allow/deny lists for
metrics, running as an agent or the scraping gateway. Does this not work to
limit the data transferred? To implement this as a servlet, we would be
generating all the metrics (as we do now, with JSON), which ends up
transferring all the data as well.
bq. these dynamically chosen ports have to be (discovered by) / (told to)
prometheus scraper. This is again a burden for the slider user as the HBase can
be run as a
Again, I'm not sure about Slider, but service discovery seems like a problem
that Slider needs to solve in general, so some interface between that mechanism
in Slider and the dynamic port binding improvement in the agent would be
required.
bq. Some customers are skeptical about opening new ports for an agent.
I believe the intended deployment model of the agent to bind to localhost. A
prometheus scraper agent, also running on localhost, can query the data. In
that case, there's no opening a port to the network, just a local socket
between processes.
> Prometheus /metrics http endpoint for monitoring integration
> ------------------------------------------------------------
>
> Key: HBASE-20904
> URL: https://issues.apache.org/jira/browse/HBASE-20904
> Project: HBase
> Issue Type: New Feature
> Components: metrics, monitoring
> Reporter: Hari Sekhon
> Assignee: Madhusoodan
> Priority: Major
>
> Feature Request to add Prometheus /metrics http endpoint for monitoring
> integration:
> [https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Cscrape_config%3E]
> Prometheus metrics format for that endpoint:
> [https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
