Sentry Concurrency Limits
メンテナーはふだん 2 日以内に返信
評価
この issue はまだ評価されていません。
説明
Problem Statement
What we want to do is be able to use send_event type :none while not risking blowing up the node because too many asynchronous errors are created. At the moment if you use send_event type :none then there are two places where events can start queuing up if they are not processed fast enough and which will eventually lead to an out of memory error. This is in the hackney pool, if there are not enough connections available because they are being used to process requests then requests start queuing up in hackney. Also, a similar thing can happen with Transport.Sender where each sender can only process 1 request at a time and if the incoming request rate is higher than what the Transport.Senders are capable of processing then a queue will form in the Transport.Senders message queues.
Ideally for us we would like to either just start dropping messages once queues begin to form or to limit the size of the queue to something that won't cause a node to run out of memory. One option for us is to just use send_event_type :sync and then just wrap calls to Sentry.capture_message, Sentry.capture_exception to go through some kind of semaphore that would limit the concurrency to X where X is a manageable amount for us. This is fine but it also means we have to rewrite Sentry.LoggerBackend to call our wrapper instead of Sentry as well.
Solution Brainstorm
So I'm wondering if adding some kind of concurrency limit would be something that Sentry would be willing to add to the library. Or alternatively, maybe just adding something to LoggerBackend to allow an alternative wrapped Sentry implementation to be used.
- 主要言語
- Elixir
- スター
- 693
- フォーク
- 219
- 平均マージ
- 3日 14時間
- マージ済み PR（30日）
- 19
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
getsentry/sentry-elixir のほかの issue
-
難易度 3/5 1〜2日 初心者へのやさしさ 64/100
getsentry/sentry-elixir#1233 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 10/100
getsentry/sentry-elixir#1232 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
traces_sampler example doesn't match the actual context provided再び着手できるかも @solnic が 338 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンBug Elixir Traces Waiting for: Product Owner
getsentry/sentry-elixir#945 · コメント 3 件 · 担当者 1 名 ·
メンテナーはふだん 2 日以内に返信
-
Better oban error grouping再び着手できるかも @solnic が 439 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンElixir Errors Improvement
getsentry/sentry-elixir#936 · コメント 1 件 · リアクション 2 件 · 担当者 1 名 ·
メンテナーはふだん 2 日以内に返信
-
Custom fingerprint added to GenServer call crashes by client再び着手できるかも @solnic が 446 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンBug Elixir Errors
getsentry/sentry-elixir#933 · コメント 3 件 · 担当者 1 名 ·
メンテナーはふだん 2 日以内に返信
getsentry/sentry-elixir の issue をすべて見る
似ている issue
-
bug elixir P2 php test-only
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 1/5 1時間未満 初心者へのやさしさ 76/100
edgehog-device-manager/edgehog#1715 ·
メンテナーはふだん 1 日以内に返信
-
30-minutes algorithm any-language codewars dart easy elixir hackerrank hacktoberfest haskell help wanted interview-prep julia leetcode lua open-source r scala students zig
難易度 2/5 1時間未満 初心者へのやさしさ 88/100
Huerte/algo-solutions-python#124 ·