github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-06 03:27:53 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

[GH-ISSUE #1906] Task status for metrics #6510

New Issue
Open
opened 2026-04-20 17:06:38 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-04-20 17:06:38 -05:00
Owner
Copy Link

Originally created by @hslabbert on GitHub (Nov 28, 2025).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/1906

Description

I know this is incredibly silly, but it would be neat if the vikunja_task_count metric included a label for the task status. At the moment it's just an ever-growing counter; it could actually be neat if it could be filtered by labels to "active" (done = false) tasks.

Currently running v1.0.0-rc3

Which alternatives did you consider using instead?

No response

Originally created by @hslabbert on GitHub (Nov 28, 2025). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/1906 ### Description I know this is _incredibly_ silly, but it would be neat if the `vikunja_task_count` metric included a label for the task status. At the moment it's just an ever-growing counter; it could actually be neat if it could be filtered by labels to "active" (done = false) tasks. Currently running [v1.0.0-rc3](https://github.com/go-vikunja/vikunja/releases/tag/v1.0.0-rc3) ### Which alternatives did you consider using instead? _No response_
GiteaMirror added the area/apiarea/task-metadata labels 2026-04-20 17:06:39 -05:00
GiteaMirror commented 2026-04-20 17:06:40 -05:00
Author
Owner
Copy Link

@hslabbert commented on GitHub (Nov 28, 2025):

I should definitely see if I can just hack this in myself. It is definitely not something that should be high on anyone's urgency list compared to other work!

<!-- gh-comment-id:3590371905 --> @hslabbert commented on GitHub (Nov 28, 2025): I should definitely see if I can just hack this in myself. It is definitely not something that should be high on anyone's urgency list compared to other work!
GiteaMirror commented 2026-04-20 17:06:40 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Nov 29, 2025):

Happy to take a PR for that!

<!-- gh-comment-id:3591491874 --> @kolaente commented on GitHub (Nov 29, 2025): Happy to take a PR for that!
GiteaMirror commented 2026-04-20 17:06:41 -05:00
Author
Owner
Copy Link

@hslabbert commented on GitHub (Dec 1, 2025):

Grand, thanks. Will take a look.

At first glance, this looks like we'll need to update bits of registerPromMetric() for the TaskCountKey, but it seems like things might get a bit tricky here around NewGaugeFunc() being in there and needing a GaugeVec rather than a Gauge to support the labels. I'll dig in there, though, as perhaps for some basic things like task status we could use constLabels, whereas if we were to also include e.g. the project name or assignee then we'd need variablelabels.

Are there other labels that could be helpful here? Off the top of my head I'm thinking:

  • task status (done true/false)
  • created_by user
  • assignees? Though as an array, this might be a bit tough
  • project_id (would be great if we could somehow resolve this to the actual project name or such)
<!-- gh-comment-id:3598750887 --> @hslabbert commented on GitHub (Dec 1, 2025): Grand, thanks. Will take a look. At first glance, this looks like we'll need to update bits of [registerPromMetric()](https://github.com/go-vikunja/vikunja/blob/035a85d9aec2278c3629bcfb80b3b7127bdb06f4/pkg/metrics/metrics.go#L51-L62) for the [TaskCountKey](https://github.com/go-vikunja/vikunja/blob/035a85d9aec2278c3629bcfb80b3b7127bdb06f4/pkg/metrics/metrics.go#L33C2-L33C14), but it seems like things might get a bit tricky here around `NewGaugeFunc()` being in there and needing a `GaugeVec` rather than a `Gauge` to support the labels. I'll dig in there, though, as perhaps for some basic things like task status we could use constLabels, whereas if we were to also include e.g. the project name or assignee then we'd need variablelabels. Are there other labels that could be helpful here? Off the top of my head I'm thinking: * task status (done true/false) * created_by user * assignees? Though as an array, this might be a bit tough * project_id (would be great if we could somehow resolve this to the actual project name or such)
GiteaMirror commented 2026-04-20 17:06:41 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Dec 1, 2025):

I think task status, maybe created_by_id and project_id would be a great start.

<!-- gh-comment-id:3599137011 --> @kolaente commented on GitHub (Dec 1, 2025): I think task status, maybe created_by_id and project_id would be a great start.
GiteaMirror commented 2026-04-20 17:06:42 -05:00
Author
Owner
Copy Link

@hslabbert commented on GitHub (Dec 7, 2025):

Looking into it a bit more, it looks like these all being set up as key-value pairs is fairly embedded in the whole path, from metrics.GetCount() and metrics.SetCount() to a memory or redis kv store, to models.GetTotalCount() and that x.Count() usage there.

To filter by some labels I'm thinking we'd need to either update models.GetTotalCount() to allow for adding in a x.Where() filter, or maybe add some discrete functions there for the more targeted lookups (IOW leave models.GetTotalCount() alone to return the full counts, but then add a separate filtered lookup function). There is already some discrete logic for the Active Users and Active Link Shares metrics, so I would guess it's okay to extend things here a bit, but I don't want to make any assumptions. Any preferences or concerns there?

For the k/v side, since we're adding more than just flat counts but need more complex information for the labels, I suppose we could either use hashmaps or create a unique/discrete key for each label combination. The former seems more sensible?

Which I guess also raises whether you'd want to still leave a "total" tasks count and similar, without any labeling by status or created_by or such, and then add separate metrics that have the labels sliced in, or have only the labeled counts. I'd lean towards the latter, and structuring things such that a promql sum() still is sensible and adds to the total task count. That would be a behaviour change, though, if anyone is already picking up that vikunja_task_count metric and would now have that yield the split out / labeled series.

<!-- gh-comment-id:3621542370 --> @hslabbert commented on GitHub (Dec 7, 2025): Looking into it a bit more, it looks like these all being set up as key-value pairs is fairly embedded in the whole path, from [metrics.GetCount()](https://github.com/go-vikunja/vikunja/blob/4a4cd72a0b3be5fe81fd69a3d935c4fbb37e44f7/pkg/metrics/metrics.go#L79-L96) and [metrics.SetCount()](https://github.com/go-vikunja/vikunja/blob/4a4cd72a0b3be5fe81fd69a3d935c4fbb37e44f7/pkg/metrics/metrics.go#L98-L101) to a memory or redis kv store, to [models.GetTotalCount()](https://github.com/go-vikunja/vikunja/blob/4a4cd72a0b3be5fe81fd69a3d935c4fbb37e44f7/pkg/models/models.go#L99-L102) and that `x.Count()` usage there. To filter by some labels I'm thinking we'd need to either update `models.GetTotalCount()` to allow for adding in a `x.Where()` filter, or maybe add some discrete functions there for the more targeted lookups (IOW leave `models.GetTotalCount()` alone to return the full counts, but then add a separate filtered lookup function). There *is* already some discrete logic for the Active Users and Active Link Shares metrics, so I would guess it's okay to extend things here a bit, but I don't want to make any assumptions. Any preferences or concerns there? For the k/v side, since we're adding more than just flat counts but need more complex information for the labels, I suppose we could either use hashmaps or create a unique/discrete key for each label combination. The former seems more sensible? Which I guess also raises whether you'd want to still leave a "total" tasks count and similar, without any labeling by status or created_by or such, and then _add_ separate metrics that have the labels sliced in, or have _only_ the labeled counts. I'd lean towards the latter, and structuring things such that a promql `sum()` still is sensible and adds to the total task count. That *would* be a behaviour change, though, if anyone is already picking up that `vikunja_task_count` metric and would now have that yield the split out / labeled series.
GiteaMirror commented 2026-04-20 17:06:43 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Dec 7, 2025):

It sounds like having only the labelled counts makes it easier to implement and maintain, so let's go with that.

I’m not committed to the KV logic, we can change that as well.

<!-- gh-comment-id:3623408857 --> @kolaente commented on GitHub (Dec 7, 2025): It sounds like having only the labelled counts makes it easier to implement and maintain, so let's go with that. I’m not committed to the KV logic, we can change that as well.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label area/api area/task-metadata
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#6510
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?