問題を特定するのに60秒、プログラマーのデバッグルーチンの10倍

著者：タオJianhui

これは私が2020年5月に書いた社内ブログです。当時、研究開発とテクニカルサポートの学生がユーザーがバグをすばやく見つけて問題を解決するのに役立つことを望んでいました。2020年12月に別のバージョンを繰り返し、これに関する社内トレーニングも実施しました。この間、WeChatグループの質問にも注目しており、TDengineなどの分散システムのログを分析するのは難しいと多くのユーザーが感じていることがわかりました。このブログを公開します。TDengineログの分析を例にとり、一連の方法を紹介します。それをマスターできれば、分散システムのログ分析は非常に簡単になります。

TDengineはクラスターシステムであり、すべての操作にはAPP、taosc、mnode、vnodeなどの論理ノードが含まれます。これらのノード間の通信は、Socketを介して行われます。また、テストでは、TDengineの複数のインスタンスが存在する可能性があり、分析が複雑になります。操作の場合、さまざまな論理ノードのログマッチングを照合し、それを効率的にフィルタリングおよび処理する方法が、問題を分析するための鍵になります。

この記事では、バグがどこにあるかをすばやく見つけることができる一連の方法を要約します。

ログファイル

TDengineは、クライアントとサーバーのログを生成し、それらをログディレクトリに保存します。デフォルトのログディレクトリは/ var / log / taosですが、taos.cfgの構成パラメータlogDirを変更することで指定できます。

クライアントログファイルの名前はtaoslogY.Xです（複数のクライアントを実行できるため、1台のマシンで複数のログファイルを生成できるため）
サーバー側のログファイルはtaosdlog.Xです。

ログファイルのサイズは制御されます。特定の行数（taos.cfgの構成パラメーターnumOfLogLinesによって制御されます）に達すると、新しいログファイルが生成されます。ただし、TDengineは、ファイル名が0または1で終わる2つのログファイルのみを交互に保持します。

ログ形式：

ログファイルは、左から右に4つのブロックに分割されています

マイクロ秒単位の正確なタイムスタンプ
スレッドID、マルチスレッドであるため、このパラメーターは非常に重要です。同じスレッドによって出力されるログのみがタイミングを保証され、設計されたフローに従って出力されるためです。
モジュール名、3文字
各モジュールによるログ出力

ログを分析するためのいくつかのステップ

テストまたは顧客がバグを報告すると、手動または自動にかかわらず、特定のアクションを実行することによって発生します。この特定の操作は通常、SQLステートメントを実行します。この問題は、クライアントが原因であるか、サーバーコードが原因である可能性があります。以下では、ログの分析を説明するための例としてcreate tableを使用しています。焦点を絞った説明を容易にするために、タイムスタンプは図から削除されています。

最初にクライアントを見てください

最初に確認するのはクライアントログです。サンプルのスクリーンショットは次のとおりです。

最初に問題のSQLステートメントを見つけ、クライアントログで「SQL：」を検索すると、それが表示されます（スクリーンショットの2行目）。ログで「SQLresult：」（スクリーンショットの11行目）を検索します。成功した場合は「SQLresult：success」と表示され、そうでない場合は「SQL result：xxxx」と表示されます。xxxxはエラーメッセージです。失敗したSQLをすばやく見つける方法、おおよその時間範囲とSQLステートメントが何であるかを知る必要があるため、検索は非常に高速になります。
taocのログデータでは、非常に重要なパラメータはpSqlです。これは、内部SQLObjに割り当てられたアドレスです。taoscは、このアドレス情報をTSCの直後のすべてのtaoscログの先頭に配置します。この値は重要であり、従来のクライアントおよびサーバーログの鍵となります。上のスクリーンショットでは、背景が緑色でマークされています。
pSqlパラメーターはハンドルとしてRPCモジュールに渡され、RPCはそれをすべてのメッセージに出力します（緑色の背景）。多くのモジュールがRPCモジュールを呼び出すため、RPCは誰が呼び出したかも出力します。たとえば、スクリーンショットでは、TSCによって呼び出され、RPCTSCが印刷されます。
RPCはメッセージcreate-tableをサーバーに送信し、RPCログが出力され（スクリーンショットの8行目）、送信先のdnodeのエンドポイントが示されます。スクリーンショットは、ホスト名に送信されたことを示しています：9be7010a917e、ポートは6030です。問題がある場合は、このエンドポイントが配置されているサーバーログを確認する必要があります。
RPCモジュールがサーバーから応答を受信したことがわかりますが、変換によるリソースの消費を避けるために、ログには16進数のIPアドレス（スクリーンショットの9行目、0x20012ac）とポート番号のみが表示されます。RPCモジュールのログは、論理ノードを結び付けるため、非常に重要です。

サーバーを見てください

クライアントログを分析した後、サーバーログは非常に重要です。以下は、例としてcreate-tableを使用しています。スクリーンショットを参照してください。

クライアントログからpSqlを見つけます。値は0x5572c4fab3a0なので、taosdlogで0x5572c4fab3a0を直接検索すると、スクリーンショットに緑色の背景のログが表示されます。したがって、pSqlは、クライアントとサーバーのログを一緒に文字列化するための非常に重要なパラメータです。
create-tableの特定の操作には、mnode処理があります。スクリーンショットでは、最初のテーブルが作成されるため、最初にvnodeを作成してから、多くのモジュールを含むテーブルなどの一連の操作を作成する必要があるため、詳細には説明しません。
最後に、mnodeがテーブルを作成した後、RPCモジュール（スクリーンショットの52行目、最後の行）を介して応答を送り返すため、サーバーが正常に動作していることがはっきりとわかります。

注：dnodeモジュールはメッセージを受信すると、メッセージの種類に応じてmnodeとvnodeのメッセージキューにメッセージを配信します。次に、ワーカースレッドはメッセージキュー内のメッセージを消費し、メッセージを処理します。vnodeの場合、サブモジュールtsdb、wal、sync、およびcqはすべて単一のスレッドで実行されるため、pSql（スクリーンショットの2行目）を見つけた後、スレッドIDに従って順番に見下ろす必要があります。あなたは全体を知ることができますプロセスはよく分析されています。

いくつかの重要なポイント

最初に失敗したSQLステートメントを見つけます
pSqlの値を見つけて、xxxxxであると想定してコピーします
grep "xxxxx" taoslogx.x、このSQLに関連するクライアントログを検索し、問題を見つけることができるかどうかを確認します
taosdlogサーバーログを開き、pSqlの値xxxxxを検索し、タイムスタンプをチェックして、失敗した操作かどうかを確認します
次に、サーバーログを分析します

RPCモジュールのメッセージは重要です。各RPCメッセージについて、解析コード：xxが出力されることが非常に重要です。これはプロトコル解析の結果であり、0は問題がないことを意味し、他の値はプロトコル解析が失敗したことを示します。ただし、同時に、メッセージ自体にもコード0xXXが含まれています。これは、送信者によってもたらされたエラーコードであり、通常はサーバーからクライアントに送信されます。正しい場合はコードは0であり、そうでない場合はレポートされます。エラー。

別のログ照合方法

クライアントがRPCモジュールを介してメッセージを送信すると、ログには次のようなメッセージが表示されます。

sig：0x01000000：0x01000000：55893

これは、RPCのソースID、宛先ID、およびトランザクションIDです。これらを組み合わせると、3つのパラメーターでクライアントからのリンクを一意に識別できます。新しいメッセージが送信されるたびに、トランザクションIDが1ずつ増加するため、一定期間一意になります（トランザクションIDは2バイトであり、循環します）。

バージョン1.6は、クライアントログとサーバーログを照合するためにsig文字列のみに依存できますが、多くのコンテキストを確認する必要があるため、面倒で非効率的です。

バージョン2.0はpSqlをサーバー側に転送するため、クライアントとサーバー間のログ照合が大幅に高速化されます。

ログに慣れる方法

まず、TDengineの設計を理解し、各主要操作のフローを理解します。
すべてのログスイッチをオンにし（debugFlagを135に設定）、すべてのSQLステートメントを1回実行し、対応するクライアントとサーバーのログを各SQLと照合します。

クライアントによって実行されたSQLステートメントを表示する

クライアントは、実行されたSQLステートメントを確認するために多くのログを生成します。これは、問題の分析と繰り返しが容易です。システムが実行したSQLステートメントの種類を確認する方法はいくつかあります

クライアントログがオンになっている場合は、次を実行します。grep“ SQL：” taoslog *、実行されたすべてのSQLステートメントがログに表示されます。
taosを使用してSQLステートメントを手動で実行する場合は、ホームディレクトリにある隠しファイル.taos_historyを確認してください。このファイルには、taosによって実行されたすべての履歴コマンドが含まれています。
クライアントを構成します。構成ファイルで、tscEnableRecordSqlパラメーターを1に設定します。つまり、クライアントによって入力されたSQLステートメントを同じディレクトリである別のファイル（tscnote-xxxx.0、xxxxはpid）に出力します。クライアントログとして。
リセット可能なインターフェイスの場合、taosd構成ファイルでhttpEnableRecordSqlパラメーターを1に設定すると、htpp要求がサーバーログと同じディレクトリである別のファイル（httpnote.0）に出力されます。

動的変更ログ

サーバーまたはクライアントを再起動できない場合がありますが、ログ設定が正しくありません。この場合、動的設定が必要です。次の手順を実行します。

showdnodes;//各dnodeのIDを検索しますalterdnodeid debugFlag143 
;//対応するdebugFlagを設定します

2番目のステップのIDは、最初のステップで取得されます。

ログの表示と検索を容易にするために、後続のログを新しいファイルに出力する必要がある場合があります。実行：

dnodeidresetlogを変更します。

シェルをまったくリンクできない場合があります。このとき、次のように、taosdを実行しているマシン上のプロセスにSIGUSR1コマンドを送信できます。

キル-SIGUSR1pidxxx

元のテキストは、https ：//mp.weixin.qq.com/s/LUz1niYajOR35UpOlfszIQで最初に公開されました。