手でログに触れないでください。 パート2：統合ログファイルアナライザーの実装方法

前回の記事で、私たちはULA （Unified Logfile Analyzer）と呼ばれる作成したシステムについて話しました-その主な機能は、シングルスアルゴリズムを使用して着信エラーメッセージを収集および集約し、それらを決定して、テスト環境の問題を自動的に通知するアナライザーです。 今日は、このシステムで発生するバグを検出/解決する方法と計画を共有します。











現在、計画されているプロジェクトの半分未満をシステムに接続しています。 なぜすべてではないのですか？ 従業員が十分な情報を取得できなかったのかもしれませんし、製品を信じていなかったのかもしれません。結局のところ、製品についてマネージャーに伝えて、いくつかのプレゼンテーションを行うだけでは不十分です。 ULAの作成者の中から開発者が参加したプロジェクト環境では、成功はさらに高く、最初の実装は多くの労力をかけずに行われました。



管理者およびテスターとのミーティングを通じてULAを実装しました。 彼らはプレゼンテーションでシステムについて話し、基本的な機能を示しました。 セルフテストの開発者とのこのようなセッションを数回行った後、ESFは接続用のアプリケーションを徐々に受け取り始めました。 ユーザーがリリースを待つように、ツールを事前に発表しておけば、より良いスタートを切ることができるかもしれません。



私たちに尋ねられる標準的な質問：



-システムはHP ALMと競合しますか？

おそらく将来的には、自動化されたテストのメトリックを収集するという点で。



-システムは、ESFシステム自体のログを集約する方法を知っていますか？

現時点ではありませんが、将来的にはシステム自体のログの分析を実装します。 このデータは収集され、追加情報の形式でテストに添付されます。



-なぜELKスタック（Elastic Search、Log Stash、Kibana）ではありませんか？

より複雑な処理ロジック、意思決定機能、HP SMとの統合、HP ALM、適切な要求に応じてソースデータを意図的に操作する機能、つまり、 システムログからのデータの一定の流れは必要ありません。



-そして、誰がシステムを使用しますか？

ここではすべてがあいまいです。 主に手動テストを実施し、自動テストを分析するエンジニアのチームがエラーの分析に対処する必要があることが理解されました。 しかし、これは常に発生するわけではありません。完全に新しいプロジェクトでは、自動テスト開発者や他のエンジニアが解析に関与することがよくあります。 したがって、システムを使用するためのトレーニングが必要な人を特定するために、各プロジェクトの状況を明確に理解することが重要です。



次に、いくつかのESFプロジェクトを接続した後に発生した問題について説明します。

自動テストログの品質

基本的なアルゴリズムの変更が必要な主な問題は、自動テストが書き込むログに同じタイプのスタックトレースが存在することです。 多くのテストでTestNGが使用され、エラーが発生した場合、スタッフはログに完全なトレースを書き込み、フレームワークを生成します。 その結果、エラーメッセージの長さの最大80％が同様になります。 これで何かをする必要がありました。 そして緊急に十分。 ログの一部をトリミングし、完全に処理しないことは、根本的に間違っています。 したがって、帯状疱疹の重量を導入することが決定されました。 「ガベージ」のない正規化されたフレーズに重みを導入します。 従来のアルゴリズムにはこのようなアプローチはありません。



将来、十分な統計が収集されたら、重みを決定するために必要な多項式を導き出します。 これまでのところ、数百のメッセージを表示する場合、アークタンジェントのわずかに調整された関数を使用することが決定されました。 メッセージの最初の20から30ワードが主な意味を持ち、その後、わずかな低下が始まります（スタックトレースの始まり）。 トレーステールの重要度は最も低くなります。 将来的には、テストされたサブシステムと使用されたフレームワークへのアルゴリズムパラメータの依存性を導入することが必要になる可能性があります。

性能

システムの開発中、各スプリントで負荷テストが実行されましたが、実際のプロジェクトを接続する際のパフォーマンスの問題を回避するのに役立ちませんでした。 次の事実に直面しています。

• 負荷は非常に不均一に分散されます。
  
  
• 実際のエラーメッセージには、1秒近くの分析でDBMSサーバー上のカーネルを取得できるほどの量がある場合があります。
  
  

1秒間に最大200件のメッセージがキューに入り、蓄積し始めます。 その結果、もちろん、すべてが重大な状況なしで処理されますが、100％ビジーなプロセッサーはWEBサービスの動作に影響を与えます。 これがパフォーマンスの問題を解決するためにこれまでに行ったことです。

• エラー処理を並列化できるように、データベースサーバーにいくつかのCPUを追加しました。
  
  
• エラー処理のみを処理し、それ以上の処理は行わない独自のプロシージャを使用して、個別のOracle AQサブスクライバを介してシングル処理を行いました。 この機能に関係なく、自動テストの手順に関する情報が挿入され、起動の終了時にデータの同期が行われます。
  
  
• メッセージをダウンロードするためのアルゴリズムの変更に取り組みました。バッチモードからオンラインに遅滞なく切り替えます。
  
  

それでも、パフォーマンスの問題は完全には解決されておらず、チームは引き続き作業を続けています。

DBMSスレッドの同期

Oracle AQキューは、サブスクライバーに関連付けられているプロシージャによって解析されます。 DBMSはマルチスレッドを管理しますが、負荷が大きいと問題が発生しました。



実際には、システムに入るメッセージのカウンターを保持する必要があるということです（私たちにとっての1つのメッセージは、テストステップの記録です）。 カウンターは、一意のトリガーIDによってグループ化されます。 これは、着信メッセージの数と予想されるメッセージの数を比較し、起動が完了したかどうかを理解し、テストツリーを構築し、集計されたエラーの表を表示するために必要です。 フロー同期要素がないと、このようなカウンタを入力できません。 まず、「自転車」を発明し、MUTEXテーブルを作成しました。このテーブルは、カウンター値の計算の間、一瞬ブロックされました。 重い負荷の下で、彼らはデッドブロックをキャッチし始めました。 次に、DBMS_LOCKパッケージを使用して、カウンターで機能するコードにロックを作成しました。 長い間、彼らは時々カウンターが間違った値を示した理由を理解できませんでしたが、最終的に彼らは同期の問題を解決しました。 興味のある方は、ロックの落とし穴に関するこの記事を読むことをお勧めします。

汎用性

私たちはシステムを普遍的なものとして位置付けています。あなた自身の自動テストレポートパーサーを書くだけです。 しかし実際には、同じ魅力に対して、それを行うのは非常に難しいことが判明しました。 実際には、同じことをさまざまな方法でレポートに書くことができ、一般的な規則はありません。 その結果、2週間にわたって絶えず改善する必要があり、おそらくこれで終わりではありません。 アリュール自体のコードにまで入りましたが、それについては後で詳しく説明します。

システムの制限と設計エラー

• 類似性アルゴリズムには制限があります。システムは、4ワードを超えるエラーでのみ機能します。 ESFではこのような短いテキストにまだ出会っていませんが、念のため、新しいアルゴリズムを選択しています。
  
  
• ESFのロギングルールが最後まで機能していないため、ESFサブシステム自体のログの集約はまだ行われていません。 現在、たとえば、レコードがどのセッションに属しているかなど、テキストログファイルから有用な情報を常に抽出できるとは限りません。 最初に、システムは、自動テストで検出されたエラーに関するこの情報データのみを強化します。
  
  
• システムを設計する際、HP ALMとフィールドの次元（テストID、テスト名、ステップ名）に焦点を当てました。 しかし、GUIとESFテストAPIに加えて、モバイルアプリケーションの自動テストの作業を開始しました。この情報はJiraに送信され、フィールドの次元はALMよりもはるかに大きくなります。 さらに、テストIDフィールドはテキストです。 しかし、この記事の執筆時点では、問題を修正して生産性の高いデータに影響を与えるパッチをすでに準備しています。
  
  

誘惑

最初に遭遇したAllureの問題は、異なるフレームワークのアダプターの違いです。 これは自動テストの特異性ではなく、通常の慣行です。 テストを定義するために使用されるtestClassおよびtestMethodラベルは、機能testNGアダプターに属していましたが、他のアダプターはデフォルトではそれらを提供しませんでした。 モデル（AllureModelUtils）には次のメソッドがあるため、2つのラベルを追加することは難しくありません。

public static Label createTestClassLabel(String testClass) {        return createLabel(LabelName.TEST_CLASS, testClass);    }    public static Label createTestMethodLabel(String testMethod) {        return createLabel(LabelName.TEST_METHOD, testMethod);    }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パーサーのロジックを書き直すのではなく、これら2つのラベルを追加する独自のリスナーを作成することにしました。



2番目の問題はtestNGです。 アダプターは、実行中にエラーが発生した場合、 beforeメソッド用に個別のテストを作成します。 テスト自体はキャンセル状態になります。 したがって、システムで重複したテストを受け取りました。



このAllure機能の修正はRoadMap Allure 2.0でフラグが立てられましたが、これまでのほとんどのプロジェクトではバージョン1.5以下を使用していました。 パーサーは主にこれらのバージョン用に作成されました。 待つことができなかったので、再びリスナーを修正しました。

マルチブラウザ

設計時には、React JSを選択し、Google Chromeでの作業に焦点を合わせました。 彼らはそれを経営陣に見せ、他のブラウザーでテストを開始しましたが、実際には何も機能しないことが判明しました。 将来的には、マルチブラウザの問題により多くの時間を費やす必要があります。 現時点では、システムのWEB部分はGoogle Chrome、Mozilla Firefox、MS IEの最新バージョンで動作します。

靴なしの靴屋

私たちは他の人のログに夢中になり、自分のログを忘れてしまいました。 もちろんそうでしたが、詳細は不十分でした。 実際の操作が開始され、問題が降ったとき、数日を費やし、すべての機能を実行し、システム自体で通常のログを記録する必要がありました。 ログは、解析キュー、呼び出されたプロシージャ、およびシステムサービス自体にエラーとともに書き込まれます。 すべてのユーザーアクションがログに記録されます。

速攻

システムの生産的な運用への出力を加速するために、通常のbashを使用して、ESFテスト環境のファイルシステムで必要なログの断片を見つけました。 ディレクトリを通過し、必要なファイルを展開し、入力に転送されたセッションのエントリを探し、中間結果を一時ファイル（十分な大きさ）に書き込むスクリプトを作成しました。 最後のアクションは間違いでした。 この決定はシングルスレッドであり、私たちには受け入れられないことが判明しました。 現時点では、Javaのほぼすべての機能を書き直し、中間結果は完全にメモリに保存されています。

今後の計画

近い将来、次のことを計画します。

• ネットワークにシステムを展開してモバイルデバイスをテストする
  
  
• Jiraと統合して、モバイルアプリケーションに欠陥を確立します。
  
  
• ユーザーが次の開始時にテストのリストを調整できるように、オープンブロッキング障害の自動通知を実装します。
  
  
• 事前入力フィールドのアルゴリズムを開発します。これにより、新しい欠陥を導入する際に時間を節約できます。
  
  
• 管理者がテスト環境にサービスを提供するアプリケーションを自動的に作成するためのアルゴリズムを開発し、作業を合理化します。
  
  
• ファジー一致を検索するためのアルゴリズムを改良し、柔軟性を高めて、エラーの集約中にシステムがミスを減らすようにします。
  
  
• 自動分類エラーを作成します。 システムは、以前に行った決定と手動で入力されたルールに基づいて、起動時にエラーメッセージをカテゴリにすぐに分類します。これにより、ユーザーは主に重要な問題に注意を払うことができます。
  
  
• APIテストのリクエストとレスポンスのネットワークトラフィックでデータを充実させます。
  
  
• 起動全体の自動スキャンの機能を作成します。セッション内のすべてのシステムログをスキャンします。 ユーザーは、自動テストの開発者の観点から正常な起動をクリックし、システム自体のエラーの自動分析を実行できます。
  
  

すべてのバグにもかかわらず、私たちは楽観的であり、開発はエンジニアが結果を分析する時間を大幅に短縮し、分析の品質を向上させるのに役立つと考えています。 現時点では、膨大なバックログを蓄積しており、その実装により、新しい興味深い体験が得られ、製品が改善されます。 トピックに関するご質問にお答えし、あなたの実践と事例について学びます。