スリットはPAGERの世界では新しい言葉であり、ログを見る時間を短縮する方法です

たまたま、私は定期的に多くのログを閲覧する必要がありました。 喜ばしいことの1つは、私と一緒に働いている人ほどではなく、時々主な仕事をする人です。 これらのログは中央集中型システムにはありませんが、s3に保存され、出力リダイレクトを使用してダウンロードを監視しています。



lessはすべての人にインストールされ、誰もがそれを操作することに慣れています。彼らは、前後の検索、&によるフィルタリング、ファイルの末尾(G)への移動、先頭(g)への移動などの基本的なことを知っています。



また、誰もが、フィルターを追加するときはいつでも、無期限にフリーズしたり、5秒の行を表示したりできるなどの事実にすでに同意しています。 最終的に、特にstdinでログを読み取るときは、注意する必要があります。 フィルタは機能する場合と機能しない場合があります。



実際、数日以内に数百のログファイルをそのように処理することが私に起こった瞬間-明らかになった-世界をより良く変える必要がある...



猫のデモ(gif 2.2mb)と少しの歴史。



デモ(2.2mb):




以下についての主な不満は3でした:



1)フィルターはいつでも失敗する可能性があります。

2)フィルターは、原則として、特にstdinで、特に5MBを超えるログでは、非常に遅く動作します。

3)複数のフィルターを追加することはできません。



広大なネットを検索したところ、何もないことに気付きました。 「ログナビゲーター」が1つありますが、直感的ではなく、多くの余分なものがありますが、必要なものは非常に不便です。



GoでPAGER-aを書き始めた後、彼は最初にさまざまなアプローチを比較し始めました。



1つ目は、すべての人がマシン上に多くのメモリを持っているという考えからです。ファイル全体をメモリにロードして準備し、すぐにすべてを探します。



すべてがそれほど平凡ではないことが判明した、50MBのファイルで、行ごとの分割、テキストと色を分離する制御文字の認識、結果データのメモリ割り当て(色に関する別個の情報、テキスト内の迅速な検索のための個別のテキスト)-時間がかかった読み取り、中断、検索だけを行いますが、ストレージにメモリを割り当てません。



ストリーミング処理では、スタック上の機能から機能へデータが移動するため、はるかに高速に動作します。



最終的に、メモリは各行のオフセットを保存するためだけに割り当てられ、テキストは色から分離され、完成した既製の行はストリーミングモードでバッファに転送されるという結論に達しました。 バッファには、各方向に2〜3個のウィンドウが常に保存され、追加の読み取りなしですばやく前後に移動できます。 可能であれば、このバッファーで検索が実行されます。これが十分でない場合でも、ファイルは目的の位置から再読み取りされます。



もちろん、このアプローチの利点は、ファイル全体をロードするために最初から待つ必要がないことです。

原則として、将来的には、フラグを追加することを考えています。これにより、いずれの場合でも、ファイル全体をメモリに保持できますが、ストリーム処理を使用できます。 しかし、これが必要かどうかはわかりません:)



一般に、マルチレベルのものを含む検索、フィルタリングは、安定性が低い場合やはるかに速い場合よりもはるかに高速であることが判明しました。 単純な検索の約4倍で、フィルタリングの違いは無限になります。 しかし、そうでなくても、すでに1桁あります



キラー機能といえば



階層型フィルター





これらのフィルターのシーケンスは、画面に必要なものをすぐに残すのに役立ちます。



また、より詳細な調査のために、彼らは積極的に支援します:





別の便利な機能:



Shift + K-キープ。 水平スクリーンシフトで表示される行の先頭からの文字数を指定できます。 このようにして、時間、ハッシュコミットなどをコミットできます。

数字を入力するか、上下の矢印を使用して固定文字の数を調整できます。



-基本的にホットキーは以下に従います

-検索フィルターは、セッション間のストーリーを保存します。 ctrl + rの検索はまだありません。これは計画中です。

-(現時点では)ファイルは一度に1つのみ、またはstdin-aで表示できます

-出力リダイレクトでスリットが開始された場合、着信ストリームはcatやlessと同様に、ロジックなしで単純にリダイレクトされます

-Linux、osx、Windowsで少しテストされていますが、freebsdではまったくテストされていません。



私は彼のためにそれを集めましたが、チェックするものは何もありません。 アイデアによると動作するはずです



このプロジェクトは非常に初期の段階であり、私は個人的にシステムのPAGERを置き換えました。 しかし、おそらく誰かが明らかなように見える何かを見逃しています。 黙ってはいけない:)



いくつかの計画があります:



-大文字と小文字の区別の切り替えを追加します。 現時点では、大文字と小文字を区別する検索のみ。

-切り替え検索タイプ(正規表現/プレーン/拡張グロブ)を追加します。

-選択的な削除と切断で現在利用可能なものを確認するためのフィルターメニューを追加します。

-複数のファイルのサポートを追加します。 lessのようにそれらを切り替えることから始めます。

-CTRL + R履歴検索。

-各行から部分文字列を削除して、行自体を削除せずにノイズを削除します。

-テキストが画面より小さい場合(less-eの-Fフラグのアナログ)、おそらくLESS環境変数からの-Fのサポートにより、端末への直接出力。



問題は何ですか:

-標準入力全体を読むかどうか 個人的には、それが必要だと判断する前であっても、すべて読んでおくことができます。 しかし、通常、PAGERはそうではありません。

-時間を扱う簡単な機会、つまりタイムスタンプを認識し、それらによるフィルタリングを有効にします。 ログで誰かがこれを必要としているかどうかはわかりません



機能の追加にもかかわらず残るために必要なもの:

-ターミナルから1行以内

-ファイルを開くのに費やす時間は、以下の場合よりも多くないはずです



囲aboutについて



これはGoでの私の2番目のプロジェクトで、最初のプロジェクトはここにありました



悪名高いジェネリックなどのさまざまな機能の欠如、時には一見当たり障りのないもの(原子ブール)を実装する必要性は、時にはイライラさせられます。 Pythonでは、もっとたくさん書いていますが、触れるたびに、私に課せられた制限を本当に楽しんでいます:)



しかし何よりも、エコシステムは私を喜ばせます。 何らかの理由で、それを適切に言及し、言語を比較またはscるのを忘れることがよくあります。 おそらく、言語は、実行ボタンを最初に押すまで書き込みを遅くします。 彼女の後、すぐに急いで行きます。



1) ビルド/実行/インストールに行く--race

アプリケーションは競合状態検索モードで実行され、同期せずに異なるストリームのデータにアクセスします。 実際には、キャッチするのが非常に難しいバグをキャッチするのに役立ちます。 そして、時には、ストリームを介してアプリケーションの部分間の通信の追加レベルを追加せずに、簡単な方法でポインターを渡すことにしたことが無駄になったことは明らかです



2) net / http / pprofで問題ありません 。 単純なインポート、ローカルポートの登録、およびデッドロックが発生した場合、ブラウザーを介して選択したポートに移動し、現在実行中のgoroutine-sに関するすべての情報を表示できます。



3) クロスコンパイル 。 もちろん、これについてはもっと言われていますが、毎回喜ばれることはありません。 追加の依存関係を置くためにタンバリンと踊る必要がない-それはちょうど動作します



4) Goglang 、Jetbrainsがすべてをまとめてくれてありがとうなど。



次の言語の選択の前に、彼は物事が他のいくつかの上行言語とどのようにあるかを比較し、それらがまだ成長する余地があることが明らかになりました...



そして、主なものについて、どこで入手できます:



Go環境がすでに設定されている場合は、単純にコンパイルするのが最善です。



go get github.com/tigrawap/slit
      
      





既製のバイナリが必要な場合は、 リリースページから。



そして質問はスタジオにあります。新しいバージョンがあることをユーザーに何らかの形で通知したいと思います。 リリースを行うのは不快です。5分後に新しいリリースをリリースしましたが、すでにダウンロードされているため、突然ミスに気付きます。 目立たないがわかりやすい通知のオプションは何ですか?



これまでのところ、ナビゲーションパネルにメッセージを表示するアクションが実行されるまで、1時間に1回以上、起動時にネットワークにアクセスすることを考えています。 もっとエレガントなアイデアがあるかもしれません。



また、改善する価値があるというアイデアも嬉しく思います。 しかし、私はすべてを約束しません:)



All Articles