Closed oraNod closed 3 years ago
@dmvolod hey, if you have a moment I would like to ask your help/insight here. if you could share any insights or thoughts on how to improve the prometheus docs, please let me know. thanks!
Hey, @oraNod . I'm not sure, but we need to implement #138 before to change Prometheus monitoring docs, as currently only operator metrics are collected. @rigazilla what do you think about this?
@dmvolod #138 is probably not updated. IIRC following the Prometheus setup in the docs user can access infinispan metrics at https://ispnUrl:11222/metrics
Oh, yes, @rigazilla missing this @oraNod as an example of docs related to Prometheus it could take an Strimzi docs https://strimzi.io/docs/operators/master/deploying.html#assembly-metrics-setup-str But we could also add more deep Prometheus integration and automate config and install based on flag inside Infinispan CR
@rigazilla another example, kogito operator installs a set dependents operators (including infinispan). Can we do the same for Prometheus for OperatorHub only and installs it as dependent?
@dmvolod that link to Strimzi docs is good but that's basically documenting Prometheus (3rd party content), which is not something I'm particularly keen on doing. maybe something like that would be good as a short-term solution. I guess the ideal solution would be, as you say, to install Prometheus as a dependency.
we could possibly re-use some bits from here: https://github.com/infinispan-demos/infinispan-prometheus
@rigazilla another example, kogito operator installs a set dependents operators (including infinispan). Can we do the same for Prometheus for OperatorHub only and installs it as dependent?
yeah @dmvolod, @oraNod I think that this is what we need: the operator should have Prometheus as dep and simplify user life as much as possible.
@oraNod can we close this issue?
User experience for setting up prometheus integration involves a lot of trial and error. How can we improve this without explicitly documenting 3rd party procedures?