DWH Analytics collect data but dont calculate Hours Views etc

Hi,
I use Kaltura Video Platform - Community Edition 12.3.0 in a cluster.

Since we installed our System we cannot use the Analytics.
But it seems a little bit confusing to me.

But the Bandwidth Chart seems normal. (Only the Bandwidth Chart!)

It seems that the DWH Server dont “calculate” the Information from the dwh_fact_* Tables to the dwh_hourly_*

I reinstall both DWH Server Multiple Times and also reset the Database from DWH but until now no Sucsess.

The SQL User (etl and kaltura) has been granted write-rights to all Tables(For testing)
Also I rerun all Cronjobs Manually.

Some Ideas ?

Hi @Raumen837,

Start by making sure Apache access files are correctly rotated to /opt/kaltura/web/logs, that they contain records like:

GET /api_v3/index.php?service=stats.*&action=collect

and that /opt/kaltura/web/logs is accessible by the ‘kaltura’ user on the server running the DWH scripts.

Then, run each script from /etc/cron.d/kaltura-dwh, manually from the shell and be sure to do so as the ‘kaltura’ user.
After each execution, check /opt/kaltura/dwh/logs for strings that begin with “ERROR”.

Hi @Jess,

I already check that.

The Access Log rotate every day from both Servern.
They also Include a lot of this kind of Records.

The kaltura User dont have own rights. But the Kaltura User can Read them.

-rw-r–r-- 1 root root 5133490 Jan 26 03:24 xxx-xxx-xxx-kaltura_apache_access_ssl.log-20170126-03.gz

[changed@changed logs]$ cat * | grep ERROR
ERROR 25-01 12:30:07,222 - Lock is already seized - Row nr 1 causing abort : [retention_lock], [1], [0], [null]
ERROR 25-01 12:30:07,223 - Lock is already seized - Aborting after having seen 1 rows.
ERROR 25-01 12:30:07,223 - seize_lock_by_name - Errors detected!
ERROR 25-01 12:30:07,223 - seize_lock_by_name - Errors detected!
ERROR 26-01 12:30:07,301 - Lock is already seized - Row nr 1 causing abort : [retention_lock], [1], [0], [null]
ERROR 26-01 12:30:07,301 - Lock is already seized - Aborting after having seen 1 rows.
ERROR 26-01 12:30:07,302 - seize_lock_by_name - Errors detected!
ERROR 26-01 12:30:07,302 - seize_lock_by_name - Errors detected!
ERROR 24-01 14:00:07,805 - Lock is already seized - Row nr 1 causing abort : [update_dims_lock], [1], [0], [null]
ERROR 24-01 14:00:07,805 - Lock is already seized - Aborting after having seen 1 rows.
ERROR 24-01 14:00:07,807 - seize_lock_by_name - Errors detected!
ERROR 24-01 14:00:07,807 - seize_lock_by_name - Errors detected!
ERROR 24-01 16:00:06,751 - Lock is already seized - Row nr 1 causing abort : [update_dims_lock], [1], [0], [null]
ERROR 24-01 16:00:06,752 - Lock is already seized - Aborting after having seen 1 rows.
ERROR 24-01 16:00:06,753 - seize_lock_by_name - Errors detected!
ERROR 24-01 16:00:06,753 - seize_lock_by_name - Errors detected!
ERROR 26-01 12:00:07,102 - Lock is already seized - Row nr 1 causing abort : [update_dims_lock], [1], [0], [null]
ERROR 26-01 12:00:07,102 - Lock is already seized - Aborting after having seen 1 rows.
ERROR 26-01 12:00:07,104 - seize_lock_by_name - Errors detected!
ERROR 26-01 12:00:07,104 - seize_lock_by_name - Errors detected!

I already run the script manually (multiple Times)

Thu Jan 26 16:54:28 CET 2017
start dwh triggers
2017-01-26 16:54:28 [require_once] INFO: Starting script
2017-01-26 16:54:28 [require_once] INFO: Initializing database...
2017-01-26 16:54:29 [require_once] INFO: Database initialized successfully
2017-01-26 16:54:29 [KalturaPDO->__construct] DEBUG: conn took - 0.0067801475524902 seconds to     mysql:host=gfhl-aok-li183;port=3306;dbname=kaltura;
2017-01-26 16:54:29 [Propel::initConnection] NOTICE: total conn took 0.0092217922210693 mysql:host=gfhl-aok-    li183;port=3306;dbname=kaltura;
start dwh wrap
end dwh

This can happen if the operation was stopped brutally at mid run [intentionally or just because it crushed] or if you have several machines that have crontabs with these scripts. Only ONE machine in the cluster should be running them.

See first item here about how to clear the old locks:

I already take a look on the locks.

Every time I take a look in the database all Locks are clean.

(i only changed the Hostname for this screenshot )

More crasy stuff is going on.
Since the new Month begin the system starts to “calc” the Analytics.
But something i dont understand.
Why calculate the system only from 2017.02.02 11:00 to 2017.02.03 0:00.
I took this screen at 2017.02.03 12:38.
And one more Question.
How can i add the “old” data (before 2017.02.02 11:00)?
The System already use all Logs and write the Data in the dwh_fact_* tables.
But don’t calc them in the dwh_hourly_partner table.

Like in this Post Click I checked all you tell in this post. In all Logs are no Errors. (also in the Cron.log)