[
https://issues.jboss.org/browse/TEIIDSB-23?page=com.atlassian.jira.plugin...
]
Steven Hawkins commented on TEIIDSB-23:
---------------------------------------
I was trying to use what we maybe using in future with syndesis so
that there for a single monitoring solution.
Yes, I'm just questioning dataintegration as the type.
Only thing I want to understand is if there are multiple pods with
"datavirtualization" label, all of them can be discovered and monitored by a
single Prometheus system.
That is correct. The config actually allows for both integration and datavirtualization -
but the actual metrics collection is just Teiid.
I was not saying to dynamically change what is deployed as the
previous example
I'm not talking about dynamic per se. There is the f-m-p approach of
fabric8-includes, and there is a template approach where you can reference the same base
image, but use a new deployment config that sets all of the relevant labels/annotations
and provides a configmap with the prometheus exporter config.
I came across this article
https://www.callicoder.com/spring-boot-actuator-metrics-monitoring-dashbo...
where we could use micrometer with Teiid app and see if we can expose some of readymade
metrics.
There are no shortage of approaches. There's jolokia, the jmx_exporter, and
micrometer. Micrometer is effectively moving the image prometheus config yaml to
annotations and the meter filter properties file - that does have some additional features
like local histograms and other meters that would otherwise be computed on prometheus.
As everything that we're interested in is already in jmx and the jmx_exporter
including jvm metrics micrometer's not doing much for us yet. It's also possible
to have different collection jobs so you could collect whatever from the jmx_exporter and
from micrometer, etc.
Document image generation options
---------------------------------
Key: TEIIDSB-23
URL:
https://issues.jboss.org/browse/TEIIDSB-23
Project: Teiid Spring Boot
Issue Type: Task
Reporter: Steven Hawkins
Priority: Major
Fix For: Q119
We need to document / validate all relevant image options:
- inclusion of agent bond or other mechanism for jmx exposure to prometheus. There may
also be related service annotations
- annotations for 3scale for rest and openapi exposure of odata
- any common config options - disk buffer memory, max active plans / engine threads /
connection pool sizes. Ideally the buffer manager heap should auto-configure and we
should probably always use off-heap for the fixed memory buffer.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)