アプリケーション内からheroku dynoの名前（web.1、web.2など）を特定する方法はありますか？一意のリクエストID（リクエストスタック全体の統合ロギングのためにウェブとワーカーの間のリクエストを追跡するなど）を生成できるようにしたいと思います.dynoの識別子が適切な出発点になると思います。アプリ内からheroku dyno番号を特定するにはどうすればいいですか？
これを行うことができない場合は、誰にフォールバック勧告がありますか？
私はこのHerokuのサポートの質問をしました。ここに他の人たちも同様の質問をしてくれたので、私はそれを共有するべきだと思っていました。 HerokuのスタッフJDは次のように答えました。
いいえ、この情報はdynoからは表示されません。 これまでにこの機能のリクエストを確認しましたが、 が私たちのスタックで回避しようとしているHeroku固有の変数を導入するため、 を実装しないことを選択しました。そのため、我々は にこの機能を実装する計画はありません。
あなたが同様の結果を達成するためにダイナモのブート時にご使用の環境に固有の識別子（例えば UUID）を追加/生成することができ、あなたが その 時点で、あなたのログにそれを印刷することで、アプリのdynosにこれを関連付けることができます。後でそれを見つける必要がある場合は、 のログを確認することができます（もちろん、Papertrail、 Logglyなど、または自分のサーバーにログを流す必要があります）。
残念ながら私のシナリオでは、UUIDが長すぎます（このような大量のデータが必要だった場合は、まずUUIDを使用して最初のものを追跡します）。しかし、公式の答えがあるのはまだ良いです。
最近、この問題はHerokuチームによって解決されました。
Dyno Managerには、dynoの識別子を保持するDYNO環境変数が追加されています。 web.1、web.2、foo.1などです。しかし、変数はまだ実験中であり、変更または削除される可能性があります。
インスタンスの起動時にフレークIDジェネレータを初期化するために値（実際には1,2などのインスタンスインデックス）が必要でしたが、この変数は完全に正常に動作していました。
Local environment variablesの変数について詳しく読むことができます。
foremanが情報を取得する場所はどこですか？ Procfileと監督と一緒にレールアプリをローカルで実行すると、ログに "web.1"、 "worker.1"などのログが記録されます。 –
ああ、上司がローカルで実行すると、$ DYNOが英雄に置き換えられた$ PSがセットされます。 –
Herokuのは$DYNO environment variableを持っているが、しかしそれに接続されているいくつかの大きな注意点があります
解決しようとしている問題については、router request IDが適切かもしれません。 Herokuは、X-Request-IDヘッダーを介してすべてのWeb要求に一意のIDを渡します。ワーカーに渡すことができ、特定のリクエスト/作業のために情報をログするたびに、Webおよびワーカー・インスタンスの両方にリクエストIDを記録させることができます。これにより、ログ内のインシデントを関連付けることができます。
これは質問に正確には答えられないかもしれませんが、各ワーカープロセス（ps：scale = 1を使用）ごとにProcfileに異なる行を付けることができます。その後、Procfileから環境変数としてワーカー番号を渡すことができます。例procfileから
2行は次のようになります。foreman宝石はまだダイノ名にアクセスし、（foremanを使用した場合）、それはHerokuの上と開発の両方に働く持っているので、$PSを使用しています
worker_1: env WORKER_NUMBER=1 node worker
worker_2: env WORKER_NUMBER=2 node worker
ます最初に$PSを確認してから$DYNOを確認できます。ローカルコンソールのケースを処理するには、その値が一意であることが保証されていないので、それはDYNO環境変数を使用するのは危険だRails.console
dyno_name = ENV['PS'] || ENV['DYNO'] || (defined?(Rails::Console) ? "console" : "")
を確認してください。つまり、同じDYNO変数値を簡単に持つ2つのダイノスを同時に実行させることができます。これを行う安全な方法は、dynoメタデータを有効にして、HEROKU_DYNO_ID環境変数を使用することです。これにより、一意のリクエストIDを生成できるようになります。参照してください：https://devcenter.heroku.com/articles/dyno-metadata
Pfft私はメトリックを取得し、ソース（UUID）が変更されるたびに私のダッシュボードを再構成することができないので、これは受け入れられません。私は再びリクエストを提起します:-) – opyate
私たちは最終的に[snowflake]（https://github.com/twitter/snowflake）を発見し、その後heroku自身の[noeqd]（https://github.com/noeq）ID生成サーバ。 herokuがnoeqサービスをカスタマーに公開していないのは残念ですが、起動と実行が非常に簡単で、各サーバーは毎秒100万を超えるユニークなID値を簡単に生成することができます。要求IDを追跡するのに十分です。 –
これは不合理です。 –