一歩一歩フロントエンドモニタリングシステムを構築する:リソースロードエラーをどのように監視しますか?
3932 ワード
要旨:リソースのロードに失敗すると、製品の機能とユーザー体験が破壊されます....作者:一歩一歩足跡一つ穴 原文:フロントエンド監視システム(三)静的資源ロード監視編 を構築する
Fundebugは転載を許可され、著作権は原作者の所有となっている.
一歩一歩、フロントエンド監視システムシリーズブログを構築する:一歩一歩フロントエンド監視システムを構築する:JSエラー監視編 一歩一歩フロントエンド監視システムを構築する:どのようにウェブページのスクリーンショットを報告しますか? 一歩一歩フロントエンド監視システムを構築する:インタフェース要求異常監視編 一歩一歩フロントエンドモニタリングシステムを構築する:フロントエンドラインの問題をどのように位置決めしますか? 一歩一歩フロントエンド監視システムを構築する:ユーザーの行為をどのように記録しますか? 一歩一歩フロントエンド監視システムを構築する:どのようにリソースロードエラーを監視しますか?
フロントエンドラインの問題をどのように位置決めするかは、ユーザーの一連の操作の後に発生するため、これまで頭が痛い問題でした.エラーの原因は、機種、ネットワーク環境、インタフェースリクエスト、複雑な操作行為などにある可能性がありますが、解決しようとすると再現しにくく、自然と解決できません.もちろん、これらの問題は克服できないわけではありませんが、線上の問題を監視して位置決めする方法を見てみましょう.
市場のフロントエンドの監視システムはたくさんあって、機能がそろっていて、種類が多くて、あなたが使っても使わなくても、それはすべてそこにあって、びっしりしています.往々にして私が必要とする機能はすべて他の人の家の監視システムの中で、手動で仕方がなくて、ただ、どのようにして1つの個人のカスタマイズのフロントエンドの監視システムを持つことができますか?フロントエンドモニタリングシステムを備えたフロントエンドエンジニアリングライオンを作るのはどんな体験ですか?
これはフロントエンドモニタリングシステムを構築する第3章で、主に静的資源の誤りを統計する方法を紹介し、私について一歩一歩行い、あなたも自分のフロントエンドモニタリングシステムを構築することができます.
役に立つと感じたり、興味があったりしたら、or Star Meに注目してください.
ステップラインを移動してください:フロントエンドモニタリングシステム
前章ではJSエラーモニタリングの方法について説明したが、もう一つのエラーは静的リソースロードエラーであり、多くの場合、リソースロードエラーはフロントエンドプロジェクトにとって致命的である.静的リソースロードエラーのため、フロントエンドページがレンダリングできない可能性があり、ユーザーは空白の画面に向かってぼんやりしているだけで、戸惑う.突然ある日、私达のオンライン环境は大量の白屏の间违いを爆発したため、とても长い时间の调査を経て、ついに问题の原因に位置します:私达の使用するCDNの経路はどのように知らないで、私达のhttpプロトコルをすべてhttpプロトコルに指向して、安全プロトコルの下で非安全プロトコルの资源にアクセスすることができなくて、大量の白屏を招きました.だから私は静的資源監視機能を増やして、将来の未知の状況に対応することにしました.
では、次は本題に入ります.
通常、htmlページに主に含まれる静的リソースは、jsファイル、cssファイル、ピクチャファイルです.これらのファイルのロードに失敗すると、ページに直接影響を与え、麻痺します.私たちは彼らを統計する必要があります.すべての静的リソースファイルのロード情報を統計する必要があるかどうかはよく分かりませんが、ロードに成功した以上、ページが正常になった以上、統計する必要はないはずです.そのため、ロードエラーの状況だけを統計します.
まず監視方法についてお話しします.
1)scriptタグのコールバックメソッドを用いてネットワーク上で検索したところ,onerrorメソッドでエラーをモニタできるという人がいたが,実験後,エラーはモニタされておらず,少なくとも静的リソースがドメイン間でロードされている場合には取得できないことが分かった.
2)performance.getEntries()メソッドは、すべてのロードに成功したリソースリストを取得し、onloadイベントですべてのページリソースセットを遍歴し、除外法を利用して、すべてのセットに成功したリソースリスト、すなわちロードに失敗したリソースをフィルタします.この方法は合理的に見えるが,ロードに失敗した静的リソースも確かに検出できるが,チェックのタイミングが把握しにくく,また,非同期ロードのjsに遭遇すると料理を休む.
3)フロントエンドの異常をキャプチャするためにListener(error)を追加するのも、私が使っている方法で、頼りになります.しかし、この方法は多くのerrorを監視するので、静的リソースロードエラーのerrorをフィルタします.コードは以下の通りです.
エラーが発生したe.targetのプロパティに基づいてlinkラベルなのかscriptラベルなのかを判断します.フロントエンドにクラッシュをもたらすエラーに注目しているため、css、jsファイルのロードエラーのみを監視しています.
まず、私たちはリアルタイムの監視と警報を行い、依然として7日前の同じ時間帯のデータに関連しており、ある時間帯にエラーが急増した場合、警告を出して、タイムリーに制止することができます.
次に、次の図のように詳細な情報を知る必要があります.見ないと分からないので、見てびっくり.オンライン環境ではこれほど多くの問題は報告されていませんが、毎日多くの静的リソースロードエラーが発生していることがわかります.重要な静的リソースファイルの中には、ページレンダリングに失敗するのは必然的なので、解決しなければなりません.
は毎日の量を統計し、毎日のロードエラーの変化をリストし、グラフのbarをクリックすると、毎日のデータの変化を見ることができ、比較することができます. 静的リソースロードエラーが主にどのページで発生するかを分析し、チェックの範囲を縮小します. は、ユーザーに影響を与える人数を分析し、多くのエラーが一人で発生し、盲目的な調査を減らす可能性がある.
静的リソースロードモニタリングが完了しました.ここでは問題の調査を助けるために詳細を処理する必要がありますが、私はしばらく考えられません.しばらくここまで話しましょう.
FundebugはJavaScript、微信小プログラム、微信小ゲーム、支付宝小プログラム、React Native、Nodeに専念している.jsとJavaのオンライン上でリアルタイムBUGモニタリングを適用します.2016年に双十一が正式にオンラインになってから、Fundebugは累計20億+のエラー事件を処理し、有料のお客様はサンシャイン保険、クルミプログラミング、ライチFM、掌門1対1、微脈、青団社など多くのブランド企業があります.無料試用を歓迎します!
Fundebugは転載を許可され、著作権は原作者の所有となっている.
一歩一歩、フロントエンド監視システムシリーズブログを構築する:
フロントエンドラインの問題をどのように位置決めするかは、ユーザーの一連の操作の後に発生するため、これまで頭が痛い問題でした.エラーの原因は、機種、ネットワーク環境、インタフェースリクエスト、複雑な操作行為などにある可能性がありますが、解決しようとすると再現しにくく、自然と解決できません.もちろん、これらの問題は克服できないわけではありませんが、線上の問題を監視して位置決めする方法を見てみましょう.
背景
市場のフロントエンドの監視システムはたくさんあって、機能がそろっていて、種類が多くて、あなたが使っても使わなくても、それはすべてそこにあって、びっしりしています.往々にして私が必要とする機能はすべて他の人の家の監視システムの中で、手動で仕方がなくて、ただ、どのようにして1つの個人のカスタマイズのフロントエンドの監視システムを持つことができますか?フロントエンドモニタリングシステムを備えたフロントエンドエンジニアリングライオンを作るのはどんな体験ですか?
これはフロントエンドモニタリングシステムを構築する第3章で、主に静的資源の誤りを統計する方法を紹介し、私について一歩一歩行い、あなたも自分のフロントエンドモニタリングシステムを構築することができます.
役に立つと感じたり、興味があったりしたら、or Star Meに注目してください.
ステップラインを移動してください:フロントエンドモニタリングシステム
前章ではJSエラーモニタリングの方法について説明したが、もう一つのエラーは静的リソースロードエラーであり、多くの場合、リソースロードエラーはフロントエンドプロジェクトにとって致命的である.静的リソースロードエラーのため、フロントエンドページがレンダリングできない可能性があり、ユーザーは空白の画面に向かってぼんやりしているだけで、戸惑う.突然ある日、私达のオンライン环境は大量の白屏の间违いを爆発したため、とても长い时间の调査を経て、ついに问题の原因に位置します:私达の使用するCDNの経路はどのように知らないで、私达のhttpプロトコルをすべてhttpプロトコルに指向して、安全プロトコルの下で非安全プロトコルの资源にアクセスすることができなくて、大量の白屏を招きました.だから私は静的資源監視機能を増やして、将来の未知の状況に対応することにしました.
では、次は本題に入ります.
フロントエンドの静的リソースのロードを監視する方法
通常、htmlページに主に含まれる静的リソースは、jsファイル、cssファイル、ピクチャファイルです.これらのファイルのロードに失敗すると、ページに直接影響を与え、麻痺します.私たちは彼らを統計する必要があります.すべての静的リソースファイルのロード情報を統計する必要があるかどうかはよく分かりませんが、ロードに成功した以上、ページが正常になった以上、統計する必要はないはずです.そのため、ロードエラーの状況だけを統計します.
まず監視方法についてお話しします.
1)scriptタグのコールバックメソッドを用いてネットワーク上で検索したところ,onerrorメソッドでエラーをモニタできるという人がいたが,実験後,エラーはモニタされておらず,少なくとも静的リソースがドメイン間でロードされている場合には取得できないことが分かった.
2)performance.getEntries()メソッドは、すべてのロードに成功したリソースリストを取得し、onloadイベントですべてのページリソースセットを遍歴し、除外法を利用して、すべてのセットに成功したリソースリスト、すなわちロードに失敗したリソースをフィルタします.この方法は合理的に見えるが,ロードに失敗した静的リソースも確かに検出できるが,チェックのタイミングが把握しにくく,また,非同期ロードのjsに遭遇すると料理を休む.
3)フロントエンドの異常をキャプチャするためにListener(error)を追加するのも、私が使っている方法で、頼りになります.しかし、この方法は多くのerrorを監視するので、静的リソースロードエラーのerrorをフィルタします.コードは以下の通りです.
/**
*
*/
function recordResourceError() {
// window.performance.getEntries ，
window.addEventListener('error',function(e){
var typeName = e.target.localName;
var sourceUrl = "";
if (typeName === "link") {
sourceUrl = e.target.href;
} else if (typeName === "script") {
sourceUrl = e.target.src;
}
var resourceLoadInfo = new ResourceLoadInfo(RESOURCE_LOAD, sourceUrl, typeName, "0");
resourceLoadInfo.handleLogInfo(RESOURCE_LOAD, resourceLoadInfo);
}, true);
}エラーが発生したe.targetのプロパティに基づいてlinkラベルなのかscriptラベルなのかを判断します.フロントエンドにクラッシュをもたらすエラーに注目しているため、css、jsファイルのロードエラーのみを監視しています.
まず、私たちはリアルタイムの監視と警報を行い、依然として7日前の同じ時間帯のデータに関連しており、ある時間帯にエラーが急増した場合、警告を出して、タイムリーに制止することができます.
次に、次の図のように詳細な情報を知る必要があります.見ないと分からないので、見てびっくり.オンライン環境ではこれほど多くの問題は報告されていませんが、毎日多くの静的リソースロードエラーが発生していることがわかります.重要な静的リソースファイルの中には、ページレンダリングに失敗するのは必然的なので、解決しなければなりません.
ソリューション
静的リソースロードモニタリングが完了しました.ここでは問題の調査を助けるために詳細を処理する必要がありますが、私はしばらく考えられません.しばらくここまで話しましょう.
Fundebugについて
FundebugはJavaScript、微信小プログラム、微信小ゲーム、支付宝小プログラム、React Native、Nodeに専念している.jsとJavaのオンライン上でリアルタイムBUGモニタリングを適用します.2016年に双十一が正式にオンラインになってから、Fundebugは累計20億+のエラー事件を処理し、有料のお客様はサンシャイン保険、クルミプログラミング、ライチFM、掌門1対1、微脈、青団社など多くのブランド企業があります.無料試用を歓迎します!