Sentry events coming trought, but not found

I41 · May 31, 2021, 4:59pm

I have updated Sentry to 21.5.1 today and I noticed the new “For Review” tab.

For every new event that happens, they do come up in this tab. And I do get an email of the new event.

However, when I click on the event to see the stacktrace (even when it is a few hours and a few reboots later), I get:

Sorry, the events for this issue could not be found.

This could be due to a handful of reasons:

The events are still processing and are on their way
The events have been deleted
There is an internal systems error or active issue

Also memory usage is constantly at about +/- 13 GB = 90%. Could also be due to the performance tracking. Does disabling performance tracking help to reduce memory usage?

Thank you.

EDIT1: In the error log I see a lot: client request body is buffered to a temporary file /var/cache/nginx/client_temp . Not sure whether this affects performance though.

EDIT2: The weird thing is, in the email I receive the full event details (Exception, etc). But even when I click “View on Sentry” in the email, the event cannot be found.

BYK · June 1, 2021, 6:38pm

This implies a post-processing issue to me. I’m not too familiar with event ingestion but maybe @untitaker knows more.

I41 · June 9, 2021, 2:06pm

I still don’t get the events through. It started as annoying, but now it has actually become unworkable.

The events don’t show up in the issues “All unresolved”, but are visible in the “For Review” tab. And when I click on them, “this issue could not be found”.

Any help on where to look or how to debug from here would be much appreciated.

I41 · June 11, 2021, 1:59pm

I have fixed the error!

In the following 3 lines, the storage changed from event to error. I forgot to change this in my docker-compose.yml file, which was the reason of the error. Happy it is fixed Hope to help anyone with this answer.

github.com

getsentry/onpremise/blob/0cfaa73b0586018c667b0c8cafa2c605a7bf29f5/docker-compose.yml#L181

    
      
            # (image looks for them in separate dirs by default).
            entrypoint:
              ["/usr/bin/geoipupdate", "-d", "/sentry", "-f", "/sentry/GeoIP.conf"]
            volumes:
              - "./geoip:/sentry"
          snuba-api:
            <<: *snuba_defaults
          # Kafka consumer responsible for feeding events into Clickhouse
          snuba-consumer:
            <<: *snuba_defaults
            command: consumer --storage errors --auto-offset-reset=latest --max-batch-time-ms 750
          # Kafka consumer responsible for feeding outcomes into Clickhouse
          # Use --auto-offset-reset=earliest to recover up to 7 days of TSDB data
          # since we did not do a proper migration
          snuba-outcomes-consumer:
            <<: *snuba_defaults
            command: consumer --storage outcomes_raw --auto-offset-reset=earliest --max-batch-time-ms 750
          # Kafka consumer responsible for feeding session data into Clickhouse
          snuba-sessions-consumer:
            <<: *snuba_defaults
            command: consumer --storage sessions_raw --auto-offset-reset=latest --max-batch-time-ms 750

github.com

getsentry/onpremise/blob/0cfaa73b0586018c667b0c8cafa2c605a7bf29f5/docker-compose.yml#L198

    
      
          # Kafka consumer responsible for feeding session data into Clickhouse
          snuba-sessions-consumer:
            <<: *snuba_defaults
            command: consumer --storage sessions_raw --auto-offset-reset=latest --max-batch-time-ms 750
          # Kafka consumer responsible for feeding transactions data into Clickhouse
          snuba-transactions-consumer:
            <<: *snuba_defaults
            command: consumer --storage transactions --consumer-group transactions_group --auto-offset-reset=latest --max-batch-time-ms 750 --commit-log-topic=snuba-commit-log
          snuba-replacer:
            <<: *snuba_defaults
            command: replacer --storage errors --auto-offset-reset=latest --max-batch-size 3
          snuba-subscription-consumer-events:
            <<: *snuba_defaults
            command: subscriptions --auto-offset-reset=latest --consumer-group=snuba-events-subscriptions-consumers --topic=events --result-topic=events-subscription-results --dataset=events --commit-log-topic=snuba-commit-log --commit-log-group=snuba-consumers --delay-seconds=60 --schedule-ttl=60
          snuba-subscription-consumer-transactions:
            <<: *snuba_defaults
            command: subscriptions --auto-offset-reset=latest --consumer-group=snuba-transactions-subscriptions-consumers --topic=events --result-topic=transactions-subscription-results --dataset=transactions --commit-log-topic=snuba-commit-log --commit-log-group=transactions_group --delay-seconds=60 --schedule-ttl=60
          snuba-cleanup:
            <<: *snuba_defaults
            image: snuba-cleanup-onpremise-local
            build:

github.com

getsentry/onpremise/blob/0cfaa73b0586018c667b0c8cafa2c605a7bf29f5/docker-compose.yml#L212

    
      
          snuba-subscription-consumer-transactions:
            <<: *snuba_defaults
            command: subscriptions --auto-offset-reset=latest --consumer-group=snuba-transactions-subscriptions-consumers --topic=events --result-topic=transactions-subscription-results --dataset=transactions --commit-log-topic=snuba-commit-log --commit-log-group=transactions_group --delay-seconds=60 --schedule-ttl=60
          snuba-cleanup:
            <<: *snuba_defaults
            image: snuba-cleanup-onpremise-local
            build:
              context: ./cron
              args:
                BASE_IMAGE: "$SNUBA_IMAGE"
            command: '"*/5 * * * * gosu snuba snuba cleanup --storage errors --dry-run False"'
          snuba-transactions-cleanup:
            <<: *snuba_defaults
            image: snuba-cleanup-onpremise-local
            build:
              context: ./cron
              args:
                BASE_IMAGE: "$SNUBA_IMAGE"
            command: '"*/5 * * * * gosu snuba snuba cleanup --storage transactions --dry-run False"'
          symbolicator:
            <<: *restart_policy

system · June 26, 2021, 1:59pm

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Events seems to be processed, but not showing on web On-Premise	3	2595	May 15, 2021
New events not processed or displayed On-Premise	3	2490	June 2, 2021
Sentry stops registering events after a while On-Premise	4	2426	July 2, 2021
No events on dashboard	1	917	September 25, 2020
Sentry 10 events are not fully processed On-Premise	8	2582	January 29, 2020

Sentry events coming trought, but not found

Sorry, the events for this issue could not be found.

Related topics