[
https://issues.jboss.org/browse/TEIIDSB-23?page=com.atlassian.jira.plugin...
]
Steven Hawkins commented on TEIIDSB-23:
---------------------------------------
I also added how to create the instance
The 3 scale team is promoting a prometheus instance per openshift cluster, then federating
those instances to a master aggregator. I'm not clear yet on the ramifications of
having a proliferation of instances - one per namespace, or even one per deployment
type...
The 30 day retention is also an active topic. Eventually a time-series db will be
included in the mix for longer term storage (the initial target is a year), but the may
need to be some aggregation/retention rules.
I have not modified the "relabel" section either in the
template from that of Syndesis. Take look and modify and add whatever you need to complete
the example with instructions, so that we can showcase this example as a demo.
We need to validate that our pods at host:8778/metrics are exposing the metrics
https://github.com/teiid/teiid-openshift-examples/blob/0a4383e7c9c3514532...
Based upon that we can change the
https://github.com/teiid/teiid-openshift-examples/blob/0a4383e7c9c3514532...
relabel line.
so that we can showcase this example as a demo
The next thing will be some grafana dashboard. The general approach it seems is to keep
things as focused as possible (3-4 metrics per board), and a small number of metrics
overall - as too much can overwhelm the 30 day retention schedule.
I'm not sure yet about the expectation for grafana instances or the delivery for
dashboard definitions.
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)