Metrics #369
Metrics #369
Conversation
dbos/_sys_db.py
Outdated
| class WorkflowStatusCountOutput: | ||
| def __init__(self, *, status: str, workflow_count: int) -> None: | ||
| self.status = status | ||
| self.workflow_count = workflow_count | ||
|
|
||
|
|
||
| class QueueStatusCountOutput: | ||
| def __init__(self, *, queue_name: str, tasks_count: int, status: str) -> None: | ||
| self.queue_name = queue_name | ||
| self.tasks_count = tasks_count | ||
| self.status = status |
There was a problem hiding this comment.
Could be consolidated 🤷
dbos/_sys_db.py
Outdated
| query = sa.text( | ||
| f""" | ||
| SELECT | ||
| to_timestamp(FLOOR(updated_at / 1000 / {time_bucket_seconds}) * {time_bucket_seconds}) AT TIME ZONE 'UTC' AS bucket, |
There was a problem hiding this comment.
We could also decide to use created_at for everything, which would work for "completion" statuses as well.
Arrival/Enqueue/Dequeue rates are a different query anyways.
Consolidating would make the query building significantly more complicated. Specifically around the group by logic. Also, consider the common case where we want the number of enqueued and running tasks, across all queues, it means that we'd not pass a specific queue name but we'd want
|
|
I am removing rates because they are too complicated. One thing tho is that to compute rate on the observability backend, we'd need to export/expose monotonically increasing counters (what we export are gauges). We don't have the infrastructure to compute them from the database only right now. |
No description provided.