Red Hat Bugzilla – Bug 1475900
[RFE] Collect the logs from vdsm.log to the metrics store
Last modified: 2017-12-11 11:30:10 EST
Description of problem:
Collect the logs from vdsm.log to the metrics store
Please provide the use cases for using this log.
(In reply to Shirly Radco from comment #2)
> Please provide the use cases for using this log.
Debugging engine-host issues in a single view.
Exploring VMs and tasks bottlenecks on the hosts.
configure_host_logs_processing is set to false by default.
In order to test user can run
/usr/share/ovirt-engine-metrics/setup/ansible/configure_ovirt_machines_for_metrics.sh -e "configure_host_logs_processing=true"
to the /etc/ovirt-engine-metrics/config.yml file.
When updating back to configure_host_logs_processing=false the configuration file is removed from /etc/fluentd/config.d/ and collectd is restarted.
I do not agree with the decision of having it off by default, I see an inconsistency here between 2 collection utilities, log-collector and metrics store.
Log-collector is gathering logs from hosts by default while metrics store is not.
Where did the decision to have it disabled by default come from? Can we change it to be enabled by default?
Since we see that system resources is not affected, let's move to be on by default.
I have updated the default value to true.
vdsm.log will now be collected by default.
Yaniv L requested this to be backport also to 4.1.
Currently index for logs is not being created in ViaQ setup, thus this is blocking this verification.
More over I do not see any parsing information of vdsmd.log so it seems to me like FailedQA. Shirly any advise on verification steps here?
For engine log:
Nov 29 11:55:44 example.com fluentd: 2017-11-29 11:55:44 +0100 [info]: following tail of /var/log/ovirt-engine/engine.log
Nothing for vdsmd.log
ignore the last comment, ofcourse you cant follow both engine.log and vdsm.log on a single machine as they are on different machines (host vs engine)
verified in ovirt-engine-metrics-1.0.8-1.el7ev.noarch
*** Bug 1388611 has been marked as a duplicate of this bug. ***