Analytics task_state_id

[RogerBeanPool]

Looking through the QEM analytics database for the task state, I see the following:

> select name, min(task_state_id), max(task_state_id) from aem_task_state
where name in ('STOPPING', 'ERROR', 'RECOVERY', 'STOPPED', 'RUNNING', 'STARTING')
GROUP BY name;

name | min | max
----------+------+------
STOPPING | 1961 | 7724
ERROR | 2 | 2
RECOVERY | 4 | 4
STOPPED | 3 | 3
RUNNING | 1 | 1
STARTING | 5 | 1960

Can someone tell me why there is a range of numbers for both STOPPING and STARTING?  If there are 5763 possible STOPPING states, what are they (for example)?

[Alan_Wang]

Hi @RogerBeanPool 

Those are just ids assigned to a stop action that was executed. All stopping states are the same. These ids are not really used anywhere else as far as I know. They are just used to keep track of how many times you stopped, and started tasks. 

[RogerBeanPool]

Hi Alan, thanks for your reply.

That doesn't make sense.  The aem_task.task_state_id is an implicit foreign key to aem_task_state.task_state_id.  

I stopped/started a task a couple times to see what task_state_id was populated and here's the output:

# select retrieval_time, task_state_id from aem_task where task_name_id in (select task_name_id from aem_task_name where task_name = 'example_oracle_task-bq') order by retrieval_time desc;

retrieval_time | task_state_id
-------------------------+---------------
2023-04-15 07:36:53.631 | 1
2023-04-15 07:34:53.63 | 2
2023-04-15 07:32:53.627 | 7724
2023-04-15 07:30:53.63 | 1960
2023-04-15 07:28:53.623 | 1

Starting at the bottom:

* the task was running;

* The next two show the task_state_id for when I issued a 'Stop'.  This seemed to hang for a while.

* I killed the PID on the server which is why it went into ERROR

* I then started the task.

None of those are incrementing counters.

[Alan_Wang]

Hi @RogerBeanPool 

It's not documented in terms of how these IDs are assigned. They are most likely not incremental. Is there a particular use case for the use of these IDs for you?

There's currently no API for Qlik Enterprise Manager or Replicate that logs the number of times a task has been stopped or started. For this type of information, the best you can get is exporting the Audit trail in QEM and checking the amount of times the task has been stopped from there.

[RogerBeanPool]

Hi Alan.  I don't need a counter - you mentioned they were used as a counter:

> They are just used to keep track of how many times you stopped, and started tasks. 

I use pg_exporter with some custom SQL to scrape the aem_taskv view in order to get some metrics into Prometheus.  One of the metrics I'm gathering is 'task_state'.  I have a corresponding rule to alert me if the task_state is in state 2 (ERROR).

I'm just trying to understand if QEM has certain conditions where a task would be STOPPING/STARTING and that condition would be a specific integer in the range I posted above.  

[Alan_Wang]

Hi @RogerBeanPool 

The starting and stopping of tasks are done on the Replicate Server. QEM relays API calls to Replicate if any action is done from QEM. The only conditions that stop and start a task are the following:

Manually by Run and Stop Buttons

API calls (Replicate or QEM)

Scheduler function

Task-setting behaviors (Errors and data conflicts)

Process crashes 

The exact use of the IDs isn't disclosed and if you have very specific use cases, you're encouraged to open a case so this can be asked of R&D instead. They are tied to the Analytics features and don't appear to be used outside of it. 

[RogerBeanPool]

Thanks, Alan.  Just so I'm clear, the answer to my original question:

>Can someone tell me why there is a range of numbers for both STOPPING and STARTING?  If there are 5763 possible STOPPING states, what are they (for example)?

Is to open a support ticket so that R&D can investigate and inform?

[Alan_Wang]

Hi @RogerBeanPool 

R&D will investigate if there are specific problems and use cases that they can address. A case will not make it to R&D until a problem and use case can be identified.

As previously mentioned, there is only 1 stop state. These IDs are used internally for the QEM Analytics tables. Mostly likely to correlate data with the additional columns of the relevant Analytic objects. All the tables/objects and brief descriptions can be viewed at this link:

https://help.qlik.com/en-US/enterprise-manager/November2022/Content/EnterpriseManager/Main/Analytics...

The original question alone does not specify a problem that needs to be fixed.