Sentry allows adding additional context to error events. This document aims to standardize our use of these features for consistency and reliability in searching/filtering Sentry events.

Definitions

Tags are key/value pairs which generate breakdowns charts and search filters. You can see all tags for the given Sentry project here. Tags will also be used in the Sentry alert sent to Slack.

Extra context is unstructured and difficult to use as a search/filter metric. Use sparingly.

Automated tagging in vets-api

  • every controller action in vets-api that inherits from ApplicationController is tagged with:

 def user_context
    {
      uuid: current_user&.uuid,
      authn_context: current_user&.authn_context,
      loa: current_user&.loa,
      mhv_icn: current_user&.mhv_icn
    }
  end

  def tags_context
    {
      controller_name: controller_name,
      sign_in_method: sign_in_method_for_tag
    }
  end

  def extra_context
    {
      request_uuid: request.uuid
    }
  end
RUBY
  • Sidekiq jobs are automatically tagged by code in lib/sidekiq/error_tag.rb with the job's class name.

Manually tagging in vets-api

The following tags are available and encouraged for use in your code.

If you add a new tag in a pull request, please make sure to explain the reason(s) for needing the new tag so that it is easier to approve the change.

feature

  • Represents a specific, pre-defined feature. E.g., pension_burial or vic.

  • The current approach is to follow the SentryTag template as seen in lib/vic/tag_sentry.rb.

external_service

  • Name of an backend/external service, i.e. evss or search.

  • Currently, this is used in multiple ways, we should standardize on external_service.

    • This one would be great to extract to common class it's better implemented in the evss module as external services, with sub-classes.

validation

  • This tag represents a validation failure in a given controller/transaction.

  • The current approach is to include this as a tag if a validation error occurs. See example.