[Feature Request] Expose SDK metric for `worker._count_not_evict_count`
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 35/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- python
- 領域
- backend, observability
調査の方向性
Python worker の実装で worker._count_not_evict_count を見つけ、既存の eviction ループがそれをどのように更新しているかを追跡します。その状態を SDK メトリクスとして公開し、その後、メトリクスが eviction の再試行でスタックしている worker を反映し、監視に利用できることを確認します。
索引モデルが issue の本文から書いたものです。
説明
Is your feature request related to a problem? Please describe.
We have found that periodically (for reasons that we still need to root cause) our workers run into a series of Failed running eviction job for run ID 0196d798-a08b-7a00-9082-353865f449b4, continually retrying eviction. Since eviction could not be processed, this worker may not complete and the slot may remain forever used unless it eventually completes. errors. Then hours later when the pod containing the worker is terminated, we see this log: Shutting down workflow worker, but 46 workflow(s) could not be evicted previously, so the shutdown may hang. For this particular worker, we run 50 concurrent workflows, which if I interpret things correct means that for several hours the worker was in an infinite loop trying to allow 46 workflows to evict and only able to process 4 workflow tasks at a time.
We would like to be able to detect and alert on these situations more proactively. Usually we end up finding out about them because the worker set scales up to the maximum number of replicas for an extended period of time.
Describe the solution you'd like
Since the code already keeps track of when it is in its own infinite loop trying to process the eviction, I think it would be useful to expose that information as a metric so that alerting tools can be used to alert when pods have been in that state for whatever the team monitoring the metric determines to be "too long".
Additional context
If the team is bold enough, it could also be nice to do one or more of the following:
- Provide a setting that forces the worker to shutdown if it has been in an eviction loop for too long.
- Provide more threads than
max_concurrent_workflow_tasksso that the ability to process workflows isn't as likely to be impeded by the infinite eviction loop.
- 主要言語
- Python
- スター
- 1.2k
- フォーク
- 241
- 平均マージ
- 3日 2時間
- マージ済み PR(30日)
- 49
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
temporalio/sdk-python のほかの issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
temporalio/sdk-python#1517 · コメント 10 件 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
temporalio/sdk-python#496 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
temporalio/sdk-python#1890 ·
-
[Bug] Local activity resolutions regrouped on replay since 1.32.0, delivering the wrong payload オープン
難易度 4/5 3〜5日 初心者へのやさしさ 52/100
temporalio/sdk-python#1881 · コメント 1 件 ·
-
bug
temporalio/sdk-python#1817 · コメント 1 件 · 担当者 1 名 ·
temporalio/sdk-python の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100