🤲🏾 👩🏾‍🤝‍👨🏼 ✍🏼 Pinbaを使用したアプリケーションの監視 🔁 🤼 🧤

こんにちは、Habr！ Badooの私たちは、ITコミュニティの生活に積極的に参加しようとしています。多くのオープンソースの技術とツールを使用し、開発を共有しています。

これらのツールの1つはPinbaです。これは、収集中のオーバーヘッドなしで実行中のアプリケーションからリアルタイム統計を受信するためのサービスです。詳細については、この記事をご覧ください。

私たちは、Pinbaをプロジェクトで使用し、Pinbaに関連するサクセスストーリーを常に喜んで聞いているすべての人を支援するよう努めています。この翻訳は、Dailymotionの開発者による同様のストーリーの1つです。

はじめに

Dailymotionは、StatsD、Graphite、collectd、Datadogなどのさまざまなツールを使用して、アプリケーションを監視、分析、および最適化します。しかし、あまり知られていないものもあります-ピンバ（PHPはもうボトルネックではありません）の略です。

現在、旧式のモノリシックPHPアプリケーションと多くのレガシーコードの移行に取り組んでいます。代わりに、いくつかの最新のマイクロサービスを展開する予定です。ピンバを使用して収集するもの：

現在のPHPアプリケーションに関するデータ。これにより、メンテナンスと展開をより効率的に実行し（パフォーマンスに悪影響を与えるリリースを特定）、考えられる問題を見つけて分析することができます。さらに、取得したデータは、パフォーマンスを最大限に向上させるために、最初にプラットフォームのどのコンポーネントを改善する必要があるかを判断するのに役立ちます。
新しいマイクロサービスに関するデータ。さらに、開発言語（現在はPythonまたはGo）に応じて、さまざまなクライアントを使用します（ただし、すぐに使用できるクライアントがあります-約Per。）。

ピンバとは何ですか？

Pinbaの作成者tony2001は、次のように説明しています。

「これはMySQLをインターフェースとして使用する統計サーバーです。 Pinbaは、UDPを介して多くのPHPプロセスによって送信されたデータを収集して処理し、その後、簡単で理解しやすいレポートの形式で統計を表示します。さらに、特別なインターフェースを使用して、読み取り専用モードで生データにアクセスし、より詳細なレポートを生成できます。

どのように機能しますか？

PHPのPinba拡張機能は、Webファームのすべてのサーバーにインストールされます。各PHPストリームの技術データを収集し、応答がクライアントに送信された後、受信したメトリックをUDP経由で中央のPinbaサーバーに送信します（Google Protobufデータ交換形式が使用されます）。中央サーバーでは、Pinbaエンジンがこれらのメッセージの内容を集約し、MySQLエンジンで読み取り専用のふりをして、既知のMySQLクライアントを使用して表示および選択できるテーブル形式のデータを提供します。便利で効果的。

一般的な誤解にもかかわらず、Pinbaはデバッガーでもグラフィカルツールでもありません。本番環境のアプリケーションで何が起こっているかの写真を作成するのは単なるデータビューアーです（リアルタイムでは、最後の1、2分でスライスが作成されます）。動的メトリックを使用して、パフォーマンスを犠牲にすることなく時系列グラフを作成し、それに応じて、発生する可能性のある問題を時間通りに特定できます。

もちろん、ピンバは万能薬ではなく、すべての問題を解決するわけではありません。よくある間違いの1つは、このサービスを使用して正確なデータを収集することです（たとえば、直前に発生したイベントのカウンターとして）。 Pinbaサービスはこの種のタスクを対象としていません（既にご存知のように、パフォーマンスを向上させるために、protobufメッセージはUDP経由で送信されるため、途中で一部のパケットが失われる可能性があります）。このツールを使用して傾向を追跡しますが、アクションを正確に定量化するには適していません。

私たちの建築

ここに画像の説明を入力してください

サービスを使用してどのようなメトリックを追跡できますか？

すべてのPHPプロセスでデフォルトで追跡される技術的指標の範囲は非常に広いです。

doc_size-応答サイズ。
mem_peak_usage-割り当てられたメモリ（最大サイズ）;
request_time-プロセスの作成にかかる時間（マイクロセンド処理）。
ru_utime / ru_stime-サーバーリソース（ユーザーおよびシステム）の使用に関する統計。
status-HTTP応答コード。
memory_footprint-プロセスが占有しているメモリの量。

エンジンは、各プロセスのメトリックをリクエストテーブルに保存し、最後のpinba_stats_history秒（この場合は60秒）でPHP応答ごとに1行を強調表示します。

mysql> SELECT script_name, doc_size, mem_peak_usage, status, memory_footprint, hostname FROM request LIMIT 10;

script_name	doc_size	mem_peak_usage	状態	memory_footprint	ホスト名
[PROD] video_item	5.422	10240	200	54728	web-065
[PROD] widget_dispatch_v3	38.056	14848	200	31624	web-031
[PROD] video_list	154.369	20736	200	87176	web-004
[PROD] rest_api	0.235	22784	200	51568	web-128
[PROD] rest_api	9.306	34048	200	55624	web-024
[PROD] rest_api	5.448	35072	200	54676	web-041
[PROD] controller_dispatch	2.003	11776	200	36388	web-033
[PROD] widget_v3_chunks	22.525	12544	200	33544	web-165
[PROD] cdn_director	0	9984	302	42892	web-034
[PROD] rest_api	0.019	20736	200	32500	web-085

要求テーブルには各PHPプロセスのメトリックが含まれており、トラフィックが多い場合は生データへのアクセスが非常に困難になる可能性があります。

 mysql> SELECT COUNT(1) from request;

COUNT（1）
1197502

つまり、1 60秒でWebファーム全体で1 197 502 PHP応答が生成されました。

幸いなことに、エンジンはインスタント集計を並行して実行し、サマリーメトリックをreport_ *テーブルに配置します。 script_nameフィールドの値でグループ化されたメトリックはreport_by_script_nameテーブルにあるため、特定のscript_name値のメトリックを分析できます。たとえば、最も頻繁に呼び出される10個のルートに関する統計を取得できます。

 mysql> SELECT script_name, req_count, req_per_sec, memory_footprint_total, req_time_median FROM report_by_script_name ORDER BY req_count DESC LIMIT 10;

script_name	req_count	req_per_sec	memory_footprint_total	req_time_median
[PROD] rest_api	276508	4608.47	12916600000	0.0514983
[PROD] embed_player	162808	2713.47	8074990000	0.109837
[PROD] cdn_director	122526	2042.1	5103160000	0.0280768
[PROD] widget_dispatch_v3	105822	1763.7	4349350000	0.049904
[PROD] history_logger	98481	1641.35	4060860000	0.0127946
[PROD] video_item	66250	1104.17	3563420000	0.254091
[PROD] autocomplete_list	56313	938.55	2322790000	0.0104993
[PROD] webapp_ads_mopub	52187	869.783	2183980000	0.0326299
[PROD] gravity_report	45992	766.533	1895290000	0.0167253
[PROD] player_data	33584	559.733	1724540000	0.113651

クエリを実行するだけで、割り当てられたメモリの平均量を計算することもできます

 memory_footprint_total/req_count AS avg_mem_footprint

デフォルトでは、エンジンは他のいくつかの便利なテーブルのメトリックも統合します。

report_by_server_name;
report_by_hostname;
report_by_server_and_script;
report_by_hostname_and_server;
report_by_hostname_server_and_script。

詳細については、複数のディメンションのデータを組み合わせたテーブルを使用してください。これらは、たとえば、ホストとサーバーで最も一般的に使用されるスクリプトです。

 mysql> SELECT hostname, server_name, script_name, req_count, req_per_sec, req_time_median FROM report_by_hostname_server_and_script ORDER BY req_count DESC LIMIT 2;

ホスト名	server_name	script_name	req_count	req_per_sec	req_time_median
web-121	api.dailymotion.com	[PROD] api_oauth_token	4144	69.0667	0.0104435
web-038	api.dailymotion.com	[PROD] rest_api	3455	57.5833	0.0441618

独自のメトリックの収集

ご覧のとおり、Pinbaは追加設定なしで多くの有用な情報を提供しますが、それだけではありません！レポートテーブルに加えて、タグレポート *テーブルを使用できます。メトリックは、コードで定義したタグ値に従ってこれらのテーブルに統合されます。

たとえば、古いDailymotionコードベースには、2種類のタグがあります。

I / O：外部からのアクセス、プロセスのブロック（へのアクセス

MySQL、Elastic、Redis、memcached、または外部APIなどのサーバー、

例：FacebookまたはTwitter）;
algo：私たちが見たいアルゴリズム。

たとえば、memcacheの場合、次のようにタグを使用します。

顧客コード

 $pinbaTimer = $this->pinbaService->startTimer([ 'group' => 'memcached', 'memcached' => $this->pinba_pool, 'method' => 'get', 'namespace' => 'dm_cache' ]); $value = $this->memcache->get($this->prefix . $key); $this->pinbaService->stopTimer($pinbaTimer);

ピンバサービス

 public function startTimer(array $tags) { if (!$this->isPinbaInstalled) { return null; } $timerId = 't' . ++$this->incr; $this->timers[$timerId] = pinba_timer_start($tags); return $timerId; } public function stopTimer($timerId) { if ($this->isPinbaInstalled && isset($this->timers[$timerId])) { pinba_timer_stop($this->timers[$timerId]); unset($this->timers[$timerId]); } }

次に、Pinbaデータベースにユーザーテーブルを作成し、コメントを使用してエンジンに格納する内容を説明します。

たとえば、memcachedの使用を説明するメトリックを保存するテーブルは次のようになります。

 CREATE TABLE `tag_report_memcached_method_namespace` ( `script_name` varchar(128) DEFAULT NULL, `memcached` varchar(64) DEFAULT NULL, `method` varchar(64) DEFAULT NULL, `namespace` varchar(64) DEFAULT NULL, `req_count` int(11) DEFAULT NULL, `req_per_sec` float DEFAULT NULL, `hit_count` int(11) DEFAULT NULL, `hit_per_sec` float DEFAULT NULL, `timer_value` float DEFAULT NULL, `timer_median` float DEFAULT NULL, `index_value` varchar(256) DEFAULT NULL ) ENGINE=PINBA DEFAULT CHARSET=latin1 COMMENT='tagN_report:memcached,method,namespace';

そして-アプリケーションのI / Oパラメータに関するメトリックを保存するためのテーブル：

 CREATE TABLE `tag_report_group_method` ( `script_name` varchar(128) DEFAULT NULL, `group` varchar(64) DEFAULT NULL, `method` varchar(64) DEFAULT NULL, `req_count` int(11) DEFAULT NULL, `req_per_sec` float DEFAULT NULL, `hit_count` int(11) DEFAULT NULL, `hit_per_sec` float DEFAULT NULL, `timer_value` float DEFAULT NULL, `timer_median` float DEFAULT NULL, `index_value` varchar(256) DEFAULT NULL ) ENGINE=PINBA DEFAULT CHARSET=latin1 COMMENT='tag2_report:group,method';

ご自身への注意：次回、列名として予約済みのSQL語（グループ、...）を使用しないでください。

これらのテーブルにより、たとえば、特定のルートのすべてのI / O操作に関する詳細な統計を取得できます。

 mysql> SELECT `group`, SUM(req_count) AS req, AVG(timer_median) AS timer_median, SUM(timer_value)/SUM(hit_count) AS tph, SUM(timer_value)/SUM(req_count) AS tpr, SUM(timer_value) AS timer_total FROM tag_report_group_method WHERE script_name='[PROD]video_item' AND `group` != "int_api" GROUP BY `group` ORDER BY timer_total DESC;

グループ	必須	timer_median	tph	tpr	timer_total
mysql	118124	0.009819403290748596	0.003329653064723691	0.05909533790217434	6980.5776943564415
memcached	188049	0.00976656749844551	0.0003179184672595343	0.01067464985796328	2007.3572311401367
弾性	32049	0.011334048118442297	0.016838098360988627	0.026841974640797184	860.2584452629089
レディス	48999	0.009611431136727333	0.011986066101148827	0.012204265879965226	597.9968238524161
Dmx	61436	0.009767306968569756	0.0016191925102048436	0.0073448760845254615	451.23980712890625
カール	24882	0.06987743234882753	0.008533559191620778	0.008533559191620778	212.3320198059082
クレング	50	0.12915635108947754	0.1352721940790749	1.0902938842773438	54.51469421386719
Facebook API	22	0.5436198115348816	0.5515929568897594	0.5515929568897594	12.135045051574707
ライブAPI	1	0.01953125	0.0049230000004172325	0.0049230000004172325	0.0049230000004172325

MySQL SELECTの詳細：

 mysql> SELECT mysql, method, timer_value, timer_value/req_count AS avg_timer_value, hit_count/req_count AS avg_op_count, timer_value/hit_count AS avg_op_value, hit_count, req_count FROM tag_report_mysql_method WHERE method='select' AND script_name='[PROD]video_item' AND req_count > 200 ORDER BY avg_op_count DESC LIMIT 4;

mysql	方法	timer_value	avg_timer_value	avg_op_count	avg_op_value	hit_count	req_count
ビデオ	選択する	3971.99	0.10144789052722653	16.6880	0.006079103953896177	653384	39153
video_view_summary	選択する	264.027	0.007824405328308366	12.6024	0.000620868312581275	425254	33744
static_asset_video_sprite	選択する	15.4905	0.022613802443455604	7.6496	0.0029561936400318875	5240	685
video_has_repost	選択する	1468.93	0.027541118671605483	6.7955	0.0040528553527407	362444	53336

選択クエリの使用を追跡します。それらの数が非常に大きくなると、キャッシュが非効率になる可能性があります。

追加機能

また、Pinbaの別の興味深い機能-タグを使用して、異なるタイプのリクエストを区別できます。要求には、定義したタグがタグ付けされます。たとえば、次のクエリにタグを使用します。

形式：応答形式（html、rss、atom、...）;
site_content：サイトのコンテンツの言語（en、de、fr、jp、ru、...）;
ボット：実際のクライアントまたはボット？（はい/いいえ）;
auth：ユーザー認証（ログイン）？（はい/いいえ）;
プロバイダー：PHPのバージョン間の違いを判断します：標準のPHPまたはHHVMなど。

次に、テーブルを作成し、エンジンのコメントで何をどこに保存するかを示します。たとえば、report_by_script_nameに基づいてテーブルを作成できます。このテーブルでは、リクエストタグボットの値がnoで、リクエストタグ認証の値がnoのPHPプロセスのデータのみがエンジンによって保存されます。言い換えれば、これらはログインしていない実際のユーザーです-これは一般的な状況です。

 CREATE TABLE `auth_no_bot_no_report_by_script_name` ( `req_count` int(11) DEFAULT NULL, `req_per_sec` float DEFAULT NULL, ... `req_time_median` float DEFAULT NULL, `index_value` varchar(256) DEFAULT NULL ) ENGINE=PINBA DEFAULT CHARSET=latin1 COMMENT='report1::tag.auth=no,tag.bot=no';

プロット

ピンバは、受信したメトリックをわずか1〜2分で保存します。したがって、グラフを作成するには、データを外部リソースに統合する必要があります。ここでは、MySQLプラグインとペアになったcollectdを使用します。この場合、クエリはPinbaデータベースに対して行われ、結果はWhisperに保存されます。次に、WhisperをGraphiteとTesseraまたはGrafanaでクエリします。

おわりに

古いPHPアプリケーションでPinbaを使用すると、次のことが可能になりました。

アプリケーションの問題の考えられる原因を検出します。
エラーを検出します（一部のルートで不当に多数のサーバー要求）。
チャートを作成し、アラートを設定して、リリース後のパフォーマンス低下のインシデントを検出します。

PythonプロジェクトでもPinbaを使用しています。 Pynbaの特殊バージョンは、旧友（現在は同僚）のjohnnooneによって作成されました。

Pinbaの使用中に気づいた唯一のこと：拡張機能は、古いリクエストに関する情報を常に「忘れる」わけではありません。時々、レポートテーブルには幻の結果が含まれます-1分以上前に発生したアクティビティに関するデータ。 Pinbaを使用して何かが発生していないことを確認する必要がある場合（通常、新しいコードを実稼働環境に展開した後）、これは問題になる可能性があります。これは、エラーの原因がコードにない数少ないケースの1つです。

これを修正する最も簡単な方法は、Pinbaエンジンを再起動することです。その結果、グラフに小さなギャップが表示されますが、ファントムデータは間違いなく消えます。（注：TRUNCATE TABLEはMySQLエンジンではないため、適切ではありません。）

Pinbaユーザー向けの有用なリソース

GitHub： https : //github.com/tony2001/pinba_engine
ドキュメント： https : //github.com/tony2001/pinba_engine/wiki
Pinbaを使用したPHPコードパフォーマンスの監視：

https://habrahabr.ru/company/badoo/blog/149695/

Pinbaを使用したアプリケーションの監視