Electron-ログとクラッシュ収集

8011 ワード

概要
どのクライアントアプリケーションでも、開発者は、実際の使用状況を理解するために、ユーザーの手に関連情報を記録することを望んでいます.
一般的には、次の2つの情報に分けられます.
  • 通常のログプライバシーにかかわらず、開発者にユーザがクライアントを使用する詳細を理解させ、これらの状況から抽出する情報は、開発者がユーザの使用状況に応じて製品
  • をよりよく最適化することができる.
  • クラッシュログユーザの使用環境は千差万別であり、クライアントをクラッシュさせる場合がある.クラッシュ・ログの収集は、開発者の位置付けを向上させ、問題を解決するのに役立ちます.
    ログの処理については、一般的に収集、報告、分析などの複数のステップに分けられますが、本稿では主にElectronクライアントアプリケーションのログ収集ステップについて細分化して説明します.
    通常のログ収集
    プロセス
    通常ログは,開発者アプリケーションコードによって正常にキャプチャできる動作ログと理解できる.
    Electronアプリケーションの構造に従って、ログ収集の構造は次の図のようになります.
    説明:
  • main processはメインプロセスであり、render processesは各ウィンドウのレンダリングプロセス
  • である.
  • loggerはmain process下のログ収集コンポーネントであり、収集したログ情報をローカルおよびリモートサーバ
  • に保存することができる.
  • Electron.remoteはElectronフレームワークに付属するオブジェクトであり、メインプロセスとレンダリングプロセスのブリッジとして機能し、レンダリングプロセスがメインプロセスのloggerコンポーネントにアクセスできるようにし、下位原理はipc情報に基づくパッケージ
  • である.
  • render processesはElectronを通過する.remoteはloggerにアクセスし、自分のログ情報をloggerによって収集することができる
  • .
  • レンダリングプロセスのworkerとservice workerは特に、レンダリングプロセスとは独立しており、Electronから直接使用することはできない.remoteではloggerにアクセスしますが、ipc messageを介して特定のレンダリングプロセスにログ情報を渡し、その後、レンダリングプロセスを介してloggerを介してログ情報
  • を記録することができます.
  • メインプロセス下のサブプロセスchild processesは、Electronに直接アクセスできない.remoteは、ipc messageにより、収集したログ情報をメインプロセスに渡すことができ、メインプロセスはloggerを介してログ情報
  • を記録する.
    イニシアチブ
  • アプリケーションのニーズに応じて、loggerコンポーネント
    /**
     * @param {string} level
     * @param {string} text
     */
    function log(level, text) {  
      var args = Array.prototype.slice.call(arguments, 1);
      args = args.map(function(arg) {
        return arg instanceof Error ? arg.stack + EOL : arg;
      });
      text = util.format.apply(util, args);
    
      var msg = {
        level: level,
        text: text,
        date: new Date()
      };
    
      var transports = module.exports.transports;
    
      for (var i in transports) {    
        // jshint -W089
        if (!transports.hasOwnProperty(i) || typeof transports[i] !== 'function') {      
          continue;
        }
        if (!compareLevels(transports[i].level, level)) {      
          continue;
        }
    
        try{
          transports[i].call(module.exports, msg);
        }catch(err){
          console.error('Logger Error: ', err);
        }    
      }
    }
    
  • を設定する.
  • loggerオブジェクトをグローバル
    global.log    = require('./src/base/log');
    
  • に暴露する.
  • メインプロセスログ
    // GPU    
    app.on('gpu-process-crashed', function(){
    
      log.error('GPU    ,    ');
    
      app.exit(0);
    });
    
    //          ,  
    app.on('window-all-closed', function() {
      //   OS X  ,           Cmd + Q   
      //          
      if (process.platform != 'darwin') {
        app.quit();
      }
    });
    
  • レンダープロセス記録ログremoteによりloggerオブジェクト
    window.logger = remote.getGlobal('log');
    
    を取得レンダープロセス上でloggerメソッドとconsoleメソッドをバインド
    function extendConsole(){
      const logFn = console.log;
      console.log = function(...args){
    
        logFn(args);
    
        if(logger && logger.log){
          logger.info(args);
        }
      }
      // ...
    }
    
  • .
  • serviceworkerは、ipc message通信記録ログを介して、Service Workerを引き継いだレンダリングプロセスにログ情報
    //service worker
    function sendMsg(type, ...args){
      self.clients.matchAll().then(
        clientList => {
          clientList.forEach(client => {
            client.postMessage({
              event: type,
              data: args
            });
          })
        }
      )
    }
    //      
    navigator.serviceWorker.addEventListener('message', function(swe){        
        // log swe.data
    });
    
  • を送信する.
    クラッシュログ収集
    プロセス
    クラッシュログは、開発者アプリケーションによって制御されないクラッシュと理解できます.
    開発者のアプリケーションでは、このようなクラッシュエラーを直接キャプチャすることはできません.フレームワークとオペレーティングシステムの最下位の収集メカニズムを使用してログの収集を行う必要があります.
    Electronはすでにクラッシュログの収集メカニズムを提供しており、詳細はElectronの公式ドキュメント:クラッシュログを表示することができます.
    大まかな流れは下図の通りです.
    説明:
  • crash reporterはElectronに提供する収集メカニズムであり、アプリケーションが取得できないクラッシュエラーを収集することができ、収集後、情報をローカルに保存したり、指定したサーバ
  • にアップロードしたりすることができる.
  • メインプロセスとレンダリングプロセスのクラッシュエラーは、
  • に正しく収集できます.
  • 注意点:クラッシュ情報を収集するには、プロセス上でcrashReporterを明示的に呼び出す必要があります.startメソッドは、収集処理
  • を初期化する
  • メインプロセスはcrashReporterに直接アクセスすることができ、レンダリングプロセスはElectronを通過することができる.remoteはcrashReporterにアクセスし、サブプロセスはprocessを通過することができる.crashReporterアクセスクラッシュ収集オブジェクト
  • イニシアチブ
  • 各プロセスは、可能な限りクラッシュ収集を追加します.
  • 崩壊して収集した情報は統一的にサーバーに報告され、開発者が統計を収集するのに便利である.次の図(各クラッシュレポートには対応するjsonファイルと対応するminidumpファイルがある):
  • 対応するクラッシュファイルを取得した後、dumpファイルを分析する必要があります.推奨ツールはgoogleのbreakpadです.breakpadについては、プラットフォームによってインストール方法が異なります.公式ドキュメントで注意深くインストールする必要があります(macはxcodeでコンパイルし、windowsはgccを追加インストールする必要があります)
  • breakpadがインストールされていると仮定すると、dump_Symsとminidump_stackwalk、ここではminidump_を使うことにします.stackwalkというツールは、minidumpファイルを次のコマンドラインで解析し、結果をoutput.に格納する.txtにおける
    minidump_stackwalk 15dcad6faa9e9914ae9016d794c391a8 > ./output.txt
    
    の結果は以下の通りであり、出力の詳細により、開発者がよりよく問題を解決できる~
  • 転載先:https://juejin.im/post/5c5ee47be51d457f95354c82