Sentry: Feature request: manually add tags

[boxed]

It would be really useful if one could manually add tags to events.

[dcramer]

Could you explain your use case? We're considering adding something similar to GitHub's labels, but it'd be a single value, not key=value pairs.

[boxed]

I don't want to describe our situation too much but we've got a class of problems that are probably related and we're investigating so it would be nice to be able to tag them. Grouping is a much too aggressive action for this.

Single tags instead of key-value would cover our use cases fine.

[izabelavmelo]

I agree with @boxed ! I need it too! For the same context. I would like to classify, without merge, just to investigate.

I would like to put labels to issues (to organize visually). It's difficult to work with the list of issues without a way to organize in a personalized way.

[dcramer]

Just a heads up we're going to be revisiting this in the near future. I do agree that there's a lot of reasons to do this kind of thing, we just need to explore the technical and product implications, and decide if it can be the same 'tags' system we use today or if it needs to be something else.

[CaptObvious]

I could do with this to be able to manually add issue IDs from our internal issue tracker that we can't integrate with Sentry (it's not reachable from the network where we have Sentry deployed).

[marioaa]

+1, There are scenarios where errors come up which we were not expecting. I can then later add a tag to group ones which come up later on. But all the errors which have already been created will not show up in that group/filter. So being able to make sense and organize error which was not expected is really useful (and let's be honest, nobody expects an error).

[fosterbrereton]

+1. We have a JIRA instance internal to our company, and I’d like to have a spot on a given issue where we can refer to a JIRA issue related to the Sentry issue. I’m thinking a custom, manually-managed tag could handle this use case reasonably.

[dcramer]

A few quick questions for anyone paying attention:

1. Do these tags need to exist in search?
2. Do they need to exist in distribution graphs and other tag views on issue details?
3. Do they need graphed (ignoring we dont provide graphs today)?

[dcramer]

1. Do you need more than one of these tags per issue? e.g. limit of one value per key (JIRA_ISSUE=X)

[boxed]

Speaking for myself:

1. Yes
2. Don't understand
3. Don't understand
4. One is infinitely better than zero

[fosterbrereton]

1. Yes
2. No, as long as they're visible on the main issue page
3. No
4. Only one needed at this time (though I could certainly see more being valuable)

[dcramer]

FYI we're going to consider this as part of our incident management product set (Q2 timeline). Will update this thread with what we decide.

[silvainSayduck]

If anyone is interested, here is the workaround I currently use to set tags for individual Exceptions

Sentry.configureScope(scope => {
  scope.addEventProcessor((event, hint) => {
    if (event.extra && event.extra.tagged) {
      return event;
    }
    Sentry.withScope(_scope => {
      const { tagName, tagValue } = getTagFrom(event, hint);
      _scope.setTag(tagName, tagValue);
      _scope.setExtra('tagged', true);
      Sentry.captureException(new Error(hint.originalException));
    });
    return null;
  });
});

[Betree]

Our use case for having a tags system:

1. For grouping issues. For example we got a lot of exceptions from our internationalization system. We'd like to be able to group them to investigate them under a i18n tag and eventually get some statistics to track the evolution of issues related to a specific tag. Same goes with projects, would be useful for bug fixes hackathons and statistics to group by specific sub-projects. Example of tags: projects > gift-cards, projects > events...etc

2. For assigning priorities or link to a roadmap. Example tags: priority > low, priority > high.

3. For having custom statuses over issues. Example: status > investigated, status > to investigate, status > waiting for feedback

---

Based on that, here hare the answers regarding @dcramer's https://github.com/getsentry/sentry/issues/5572#issuecomment-455281295:

• Do these tags need to exist in search?

Ideally, yes.

• Do you need more than one of these tags per issue? e.g. limit of one value per key

Yes.

[raulsann]

Where is this at?

We need to add tags manually because sometimes issues arise by a part of the technology that did not cause the issue. For example, a wrapper in frontend gets an exception but there is a bug in the API. We want to be able to measure how many issues are caused by what parts of the technology. So in the previous example, we'd like to tag manually the issue (once we've found the root cause) with a tag similar to "bug:api".

[liweinan0423]

sometimes we need to manually triage the issues reported by sentry and categorise them into different severities, so manually adding tags/label is required

[webjunkie]

We also have the same requirement in that we want to categorize issues. We might want to say some issues are high priority, others we keep an eye on. Some are easy to solve, some need the most senior person to look into. This is not possible now, unless referencing the issues in something like Jira with extra documentation work.

[jolkkola]

This would be useful for doing some quick and lightweight triage or assessment on Content Security Policy (CSP) violation reports.

We would like to categorise these violation reports according to probable cause - such as a certain plugin or embed, a feature in the web page, or the cause being potential malware etc. Currently this needs to be done in an external system which requires extra work and tends to be cumbersome. It is easy to ignore (or solve) a certain type of issue, but that's not really what we would like to do.

Ideally it would be easy to look up all the issues under a certain manually applied category/tag/label. And it should be easy to add new issues under a pre-existing category, naturally.

This way it would be easy to answer questions like

• how many unique users have potential malware in their browsers
• which category types have most reports/unique users

[jakuub]

We would like to use this for triage between different teams.
The key-value will be good, but we don't necessarily need it.

1. Yes
2. No
3. No
4. currently we need one, but it would be beneficial if we could have more for the future.