Clever Geek Handbook

リアルタむムログ分析

「すぐに䜿える」最新の監芖システムでは、単䞀のシステムノヌドのほがすべおのむンゞケヌタを远跡できたすが、倚くの重倧な欠点がありたす。





私たちのサむトの最初のサむトには、1,000,000を超えるナニヌクビゞタヌ、1日にフロント゚ンドで1億件たでのhttpリク゚スト、そしおサポヌトに関しおはプロゞェクトの動物園がありたす。 キヌワヌドのセット-nginx、apache、php2぀のバリ゚ヌション、oracle。 執vetな呚期性により、個々の責任ゟヌンで「すべおが私たちのために働く」、たたは珍しいこずではないが「䜕もあなたのために働かない」ずいう状況が生じたす。 責任の境界では、チケットの継続的な転送がありたす。

車茪の再発明を開始するこずはせず、バック゚ンドの応答、および特定の芁求の凊理に関䞎したナヌザヌを远跡しお、ナヌザヌぞの応答の時間ず正確さを監芖するこずにしたした。 たあ、それに加えおボリュヌム-それほど倧きくはありたせんが、プレれンテヌションの過皋でいく぀かのレヌキを瀺すこずができたす。





最終的に埗たもの。







1.゜ヌスデヌタの準備。




システム内に耇数のノヌドがある堎合、システム党䜓を通しお最初から開始する1぀の芁求を远跡する方法があるず䟿利です。 ノヌドが倚数ある堎合、クラむアントIPは圹に立たなくなりたす。 ベヌスが䞋にある堎合、DBAははんだごおず「whose request ???」ずいうフレヌズで実行されるこずがありたす。 たあ、結合された暙準には、バック゚ンドの凊理時間、アップストリヌムによっお遞択されたキャッシュのヒット、デヌタがナヌザヌに送信された時間に関する情報が含たれおいたせん。 暙準のnginxモゞュヌルには、必芁なほがすべおのものが含たれおいたす。 HeadHunterからモゞュヌルを1぀だけ远加したした

github.com/hhru/nginx_requestid。nginxの各リク゚ストに䞀意の識別子を割り圓お、ログに曞き蟌み、ヘッダヌで䞊䞋に転送できるようにしたす。 nginxログの最終圢匏は次のずおりです。







怖い アップストリヌムタむプのフィヌルドには、このリク゚ストを凊理したすべおのバック゚ンドに察しお、「upstream_1Upstream_2」ずいう次のものが存圚するこずができたす。 Request_idはすでに説明されおいたす。最埌の2぀のuid_got、uid_setはngx_http_useridモゞュヌルで、システムCookieをむンストヌルするこずで特定のナヌザヌを远跡できたす。 区切り文字ずしお4぀のスペヌスが䜿甚される理由に぀いおは、解析セクションで説明したす。 Apacheたたはphp-fpmレベルでは、䞊から来たrequest_idをログに曞き蟌み、リク゚ストバランサヌがアップストリヌムずしお指定されおいる堎合はホスト名を枡すのが理にかなっおいたす。 アプリケヌションレベルでは、゚ラヌメッセヌゞでrequest_idを瀺すルヌルを確立する䟡倀がありたす。 芁求デヌタをOracleセッションに転送する方法の1぀は、短いメモで説明したした。 その利点は、開発者に同じ方法で同じこずをするように䟝頌する必芁がなく、すべおのプロゞェクトのデヌタを䞀床に取埗できるずいう保蚌があるこずです。 たた、pinbaたたはxhprofの方向を調べお、各リク゚ストおよびプロゞェクト/サむトの平均的な倖郚リ゜ヌスベヌス、APIサヌビス、システムコヌルのレむテンシを远跡するこずも理にかなっおいたす。 この分野での圓瀟の゜リュヌションは、冬に近づく準備ができおいたす。



さらなる議論は、珟圚のシステムで最も情報量が倚く膚倧なnginxログを䜿甚しおログを分析する詊みに専念したす。



2.単䞀のセンタヌでのログの収集。




ログ集玄の事実䞊の暙準は、syslogのさたざたな分岐ず子孫です。 UDPは、接続サポヌトおよび配信保蚌の圢匏でオヌバヌヘッドを回避するためのトランスポヌトずしお䜿甚されたす。 通垞モヌドでは、メッセヌゞの数パヌセントを倱う䜙裕がありたす;より倚くのグロヌバルな損倱は、むンフラストラクチャのグロヌバルな問題に既に関連しおおり、他の゜ヌスから孊習したす。 hh.ru Operations Directorのレポヌト「The Experience to Switching of SOA」 www.slideshare.net/kuchinskaya/sivkoのレポヌトから、倧量のメッセヌゞの萜ずし穎に぀いお詳しく知るこずができたす。ログを1か所で収集するためのいく぀かのオプションに぀いお説明しおいたす。 udp配信に加えお、将来のためにログを単䞀のファむルストレヌゞに収集するこずは理にかなっおいたす。



問題の2番目の郚分は、最初にサむトで解決されたした。すべおのログは、最初にネットワヌク接続ストレヌゞに曞き蟌たれたす。 アナラむザヌのプロトタむプを単玔化するために、nfsログを読み取るだけです。 原理的にこれが悪いのはなぜですかログは24時間システム党䜓のリ゜ヌスを消費し、ログの可甚性はネットワヌクストレヌゞの健党性に䟝存したす仕事䞭にNetAppを削陀したこずがありたすか たた、テキスト圢匏の行がログファむルに曞き蟌たれたす。リク゚ストデヌタがシリアル化された圢匏で送信される堎合、受信偎での解析のコストを回避したす。



2.5ログの解析。




この堎合、パヌサヌはPerlで䜜成され、デヌタはMongoDB 2.2.0に保存されたす。 アルゎリズムは䞍名誉に簡単です-デルタがカットオフよりも倧きい堎合、ファむル内の最埌に凊理された䜍眮を芚えお、珟圚のサむズを比范したす-解析でファむルの解析に送信し、解析でレコヌドの正確さをチェックしたす蚘録のバッファリングに関するすべおを芚えおいたすか 熊手から





これらの魅力はすべお、udpデヌタを送信するこずで回避できたす。



3.コンピュヌティング分析および怜玢甚の䞀時ストレヌゞ。




すべおのデヌタをむンデックスずずもに長時間保存するこずは可胜ですが、非垞に高䟡です。 実際には、䞀時ストレヌゞが䜿甚され、過去数時間-1日のデヌタを䜿甚しお分析を構築できたす。 運甚蚺断の堎合、より倚くのデヌタは意味がありたせん;垞に生デヌタに基づいおグロヌバルな履歎レポヌトを䜜成できたす。



MongoDBを䜿甚するのは、...本圓にしたかったからです。 倧ざっぱですが、そうです-そのようなシステムを実装する準備ができおいる任意のツヌルを遞択できたす。 レコヌドのグルヌプ化ずリポゞトリ内のデヌタの曎新がより䟿利で高速に実装されるほど、より良い結果が埗られたす。



モンゎの非宗教的利益のうち





すくい





2回目のレヌキにもかかわらず、「リク゚スト数、バック゚ンドロヌド、盎前のトラフィックで䞊䜍50のIPを芋぀ける」ずいう比范的耇雑なリク゚ストは、800〜1200ミリ秒で蚈算されたす。 私たちの堎合、鉄の片方がデヌタを蚘録し、それらを匷制的に出力したすマスタヌ、もう片方はレプリカであり、分析蚈算が蚘録を遅くしないようにしたす。



Mail Tarantooltarantool.orgを詊しおみたいずいう芁望もありたす。正芏衚珟を䜿甚しおパヌサヌのレヌキを修正する前に、デヌタの読み蟌み速床に぀いおあたり良い数字を瀺しおいたせんでした。 修正がテストされなかった埌、嬉しい驚きを期埅しおいたす。



タランツヌルの朜圚的な利点の





4.単䜍、パヌセンタむル...




前の段階で、システムのノヌドのログファむルからレコヌドの配列を受け取り、必芁なルヌルに埓っお迅速な怜玢ずグルヌプ化を行うこずができたした。 Perlのテストスクリプトは、次の郚分のデヌタを準備したす 



my $res3=$slave->logs2->run_command( { aggregate=>'lines', pipeline=>[ {'$match'=>{'tstamp'=>{'$lt'=>$i,'$gte'=>$i-1}}}, {'$project'=>{ 'gf'=>1, 'upstream_time'=>1 ,'resp_time'=>1 ,'size'=>1 } }, {'$group'=>{'_id'=>'$gf',total=>{'$sum'=>1},traffic=>{'$sum'=>'$size'},'times'=>{'$push'=>'$upstream_time'},'response'=>{'$push'=>'$resp_time'}}} ] } );




gfフィヌルドはどこですか 



 $inf{gf}=join(' ',($inf{upstream},$inf{code},$inf{host},$inf{backend},$inf{frontend},$inf{cache_status},$inf{content_type},$inf{url},$inf{upstream_code}));




出力では、事前にグルヌプ化されたデヌタの配列ぞのリンクを取埗したす。これは埌で有限メトリックに倉わりたす。 このケヌスでは、クヌルネス=サむトの負荷、゚ンドナヌザヌの䞀般的な応答時間むンゞケヌタ/コンテンツタむプ、キャッシュの有効性、゚ラヌ数の䞀般的なメトリックに関心がありたす。 サむト党䜓の抂芳図は、投皿の冒頭のスクリヌンショットのように芋える堎合がありたす。 プロゞェクトベヌス/システム党䜓のメトリックのセットは、運甚サヌビス、管理者グルヌプたずえば、異なるプロゞェクトからのフルテキストむンデックスのリク゚スト専甚の別の画面があり、サむトの負荷の゜ヌスを確認するため、開発者、サむト所有者、および盎接管理から圢成されたす。 最初のデモの埌、私たちの願いから週に1぀たたは2぀の画面が圢成され始めたした。



重芁な蚈算芁件は、時間間隔の蚈算時間ず監芖システムぞのロヌドがこの間隔よりも短いこずです。



この時間は、1秒あたり100〜200ミリ秒の間隔です。 2番目の間隔は、最も厳しい条件ですべおを壊すために、コンストラクタヌのアセンブリの段階で遞択されたす。 実際の条件䞋では、平均で5/10/30/60秒の方が生呜に察する暩利が倚くなりたす。



5.蚈算したしたか




たず、デヌタは䜕らかの圢でうたく衚瀺される必芁がありたす。 前の手順をデバッグする段階で、highchartsラむブラリが䜿甚され、デヌタはMongoDBから取埗され、ポむント4からのスクリプトによっお远加されたした。









将来的には、デヌタをアップロヌドするモニタリングシステムの䞻芁な芁望が策定されたした。







タむトル画面に衚瀺されるzabbixは、それほど倚くありたせんでした。 ここでは、mongoず同様に、個人的な奜みや特定の状況にすべお䟝存しおいたす。 それらのメトリックはzabbixトラッパヌタむプで開始され、デヌタはzabbix_senderナヌティリティによっおバッチモヌドでmysqlベヌスずしおロヌドされたす。 数癟の倀のダりンロヌドには1〜2ミリ秒かかりたす。



6.たずめ




バックグラりンドで玄1か月かかった䜜業が完了した埌、





開発パスぞ





トピックをさらに詳しく掘り䞋げたいずいう芁望がある堎合-過去1幎間のハングアりトで、コメントずそのような出版物ぞのリンクがある堎合、監芖ずプロファむリングのトピックが繰り返し提起されたした-嬉しいだけです。



この蚘事では、具䜓的になり始めたばかりのシステムの䞻芁な茪郭を抂説したす。 最初のステップは最も重芁であり、私はあなたのシステムの基本である原則ず技術を聞いおうれしいです。


More articles:


All Articles