Google App Engineでのログインを改善するためのアドバイスはありますか？私は現在SplunkStormを使おうとしていますが、入力に関しては気が利いていて、頻繁にダウンします。他の誰かがこれに遭遇し、何らかの形でそれを解決しましたか？
現在、LogServiceから読み取り、RESTAPIを介してログをSplunkStormにパイプするバックエンドで実行されるプロセスがあります。多くの場合、これは失敗するか、ストームがダウンするか、バックエンドIPが変更されます。
私の問題は、App Engine内で提供されるログにあります。新しいバージョンがプッシュされるとログが消え、提供されたダッシュボードでログをクエリすることはほとんど使用できなくなります。Splunkは潜在的なソリューションでしたが、クラウドソリューションには多くの課題が残されています。
私のログへのより良いインターフェースを提供するものは何でもありがたいです。
GAE から、非常に有能なクエリ言語を備えたBiqQueryにログをエクスポートできます。すでにこれを行っているオープンソース プロジェクトであるMacheを使用できます。関心のあるフィールド (列) を公開 (およびクエリ可能にする) には、独自の exporter を作成する必要があります。
Splunk (または別の外部サービス) を永続的なストレージとして使用することを決定したため、ログが App Engine のログ サービスに書き込まれてから、Splunk がログを受け入れることができるようになるまでの間、ログをバッファリングする場所が必要なようです。 . バージョン チャーンによってログが App Engine から失われる前にログが失われないようにするには、このバッファが高速で高可用性である必要があります。
合理的な選択肢の 1 つは、AE データストアです。サードパーティへの信頼性の低いホップはなく、可用性 SLA があり、書き込みをシャーディングすることで任意にスケーリングできます。マイナス面は、R/W 操作のコストと処理中のログのストレージ フットプリントですが、別のバッキング ストアに匹敵するコストが発生します。
どのサービスを選択しても、1 つのバッチ プロセス (バックエンドや cronjob など) がログ リーダー API からバッファに書き込むようにします。アプリの更新よりも頻繁に実行される限り、ログは常に耐久性のあるストレージに存在します。次に、Splunk が使用可能になるまで別のバッチ プロセスを待機させ、バッファからアップロードし、Splunk から受信確認を取得したら削除します。