Description of problem: 'postgres' process metrics are needed, please add is to the Processes plugin confdiguration for the engine machine. Expected results: postgres process metrics is collected Additional info: Might this be redundant because of the postgres plugin?
Should we see the results for all postgresql threads together or do we want to monitor specific threads? Example threads: postgres: logger process postgres: checkpointer process postgres: writer process postgres: wal writer process postgres: autovacuum launcher process postgres: stats collector process postgres: engine engine ::1(45418) idle postgres: engine_history ovirt_engine_history 127.0.0.1(44808) idle postgres: autovacuum worker process ovirt_engine_history
(In reply to Shirly Radco from comment #1) > Should we see the results for all postgresql threads together or do we want > to monitor specific threads? > > Example threads: > postgres: logger process > postgres: checkpointer process > postgres: writer process > postgres: wal writer process > postgres: autovacuum launcher process > postgres: stats collector process > postgres: engine engine ::1(45418) idle > postgres: engine_history ovirt_engine_history 127.0.0.1(44808) idle > postgres: autovacuum worker process ovirt_engine_history I would do both collect per thread and use aggregation plugin for the group.
(In reply to Yaniv Lavi from comment #2) > (In reply to Shirly Radco from comment #1) > > Should we see the results for all postgresql threads together or do we want > > to monitor specific threads? > > > > Example threads: > > postgres: logger process > > postgres: checkpointer process > > postgres: writer process > > postgres: wal writer process > > postgres: autovacuum launcher process > > postgres: stats collector process > > postgres: engine engine ::1(45418) idle > > postgres: engine_history ovirt_engine_history 127.0.0.1(44808) idle If possible, separate between engine PG and history PG. > > postgres: autovacuum worker process ovirt_engine_history > > I would do both collect per thread and use aggregation plugin for the group. Per process, not thread. And I agree about aggregation.
BTW, how do we handle remote db installations in ovirt-engine-metrics? in case missing this should be included as well.
(In reply to Roy Golan from comment #4) > BTW, how do we handle remote db installations in ovirt-engine-metrics? in > case missing this should be included as well. I don't see how this can be reported in a remote use case. If process runs on a separate machine there is no way to collect it with the process plugin.
(In reply to Shirly Radco from comment #5) > (In reply to Roy Golan from comment #4) > > BTW, how do we handle remote db installations in ovirt-engine-metrics? in > > case missing this should be included as well. > > I don't see how this can be reported in a remote use case. > If process runs on a separate machine there is no way to collect it with the > process plugin. By 'included' I mean to install collectd, fluentd on it as well - but I'm still not sure we _should_ do it because it is a less common setup, and in fact even not recommended.
I would disagree with Roy here that it is less common setup. For bigger scale environment I would prefer remote DB. Thus this BZ should consider running collectd and fluentd on the remote machine as well. We already require ovirt repositories for pg95, thus I see no reason to have this.
(In reply to Lukas Svaty from comment #7) > I would disagree with Roy here that it is less common setup. For bigger > scale environment I would prefer remote DB. Thus this BZ should consider > running collectd and fluentd on the remote machine as well. Why would you prefer a remote DB? Do you have evidence it improves the performance or resiliency of the setup? Also, note that we do not monitor remote DB (that we did not set up).
Separation of data from the process (oVirt). In case I'm running more products requiring database I would want the data from databases to be grouped, preferably with redundancy, high availability and on a machine where admins do not need to connect all the time. However, if we do not monitor yet *any* remote DB, I agree there is no need for starting now.
This RFE adds postgres statistics: pg_writer, pg_wal_writer, pg_checkpointer_process, pg_autovacuum, pg_stats_collector, pg_engine, pg_ovirt_engine_history. pg_engine and pg_ovirt_engine_history postgres processes do not support non default db names. If db name are different then "engine" and "ovirt_engine_history" metrics will be empty for the ovirt-engine and ovirt-engine-dwh in the processes plugin. Added bug #1511549 to handle non default db names.
verified in ovirt-engine-metrics-1.1.1-0.3.beta2.20171114114644.el7ev.noarch
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.