0

私はトランザクションの定義についてある程度の経験があり、トランザクション定義ガイドブックシェルフの両方を確認しました。CA APM リリース 9.1.5 を使用しています。以下の記録セッションでキャプチャした 4 部構成のトランザクションがあります。

記録された取引の結果

記録を促進し、識別トランザクションの一致基準を微調整し、トランザクションからキャッシュ可能を削除した後、次のビジネス トランザクションができました。

ここに画像の説明を入力

モニターを同期した後、結果が表示されています。ただし、キャプチャされたトランザクションごとに、3 つの欠陥が発生しています。すべての非識別トランザクションの欠落トランザクションです。

識別トランザクションは正しく定義されています (このコールチェーンを持たない他のトランザクションからブリードオーバーしていません)。非識別トランザクションも正しく定義されています。これを証明するために、識別トランザクションを registration-form から login.fcc に変更し、このユース ケースに固有のトラフィックをピックアップしましたが、トランザクションごとに 3 つの欠陥がありました (3 つの非識別トランザクションが欠落しており、今回は登録フォームが欠落しています)。 )。最も興味をそそられるのは、今日記録された成功したトランザクションが 1 つあったことです (さらに多くの失敗の中で)。1回成功したので、タイムアウトの定義が短すぎる可能性があると思い、そのまま20秒に増やしました。

潜在的な問題の概要と、それらが原因ではない理由:

  • 変更間で同期していません。
    • すべての変更の間にこれを行うようにしました。
  • あいまいすぎるトランザクションの識別/無関係なトラフィックのキャプチャ。
    • 一致基準は、この定義にのみ適用されます。
  • 非識別トランザクション定義が正しくありません。
    • 一致基準は、この定義にのみ適用されます。
    • 1 つのトランザクションを、その部分だけの正しく一致したトラフィックを識別するものに切り替えます。
  • トランザクション タイムアウトが短すぎます。
    • トランザクションのタイムアウトが 20 秒に増加しましたが、成功しませんでした。
  • トランザクションがキャッシュ可能である必要があるときに、キャッシュ不可とマークされました。
    • 各トランザクションは必須のステップです。キャッシングが関係していたとしても、ほとんどのユーザーはチェーンを 2 回以上実行することはありません (したがって、少なくとも大多数は成功します)。
  • APM は失敗を正しく報告します。
    • 成功したトランザクション チェーンを自分で完了することができ、それが機能しない場合は多くのアラームが鳴ります。

何か案は?必要に応じて詳細を提供できます。

4

1 に答える 1

0

問題を解決しようとして数え切れないほどのエラーが発生した後、私はそれを解決するという希望を放棄しました. これは、CEM が作成した偽のトランザクション シーケンスと相まって、現在のバージョンのアプリケーションに重大な欠陥があるのではないかと疑うようになりました。そして、あきらめてから数週間 (そして楽しい休暇) を過ごした後、偶然に根本的な原因に出くわすことができました。

CEM は、セッション ID ( source )を使用してトランザクションとコンポーネントをバインドします。最近のある時点で、セキュリティ パッチのためにアプリケーション側でこれにわずかな変更を加えました。それだけでなく、元の構成はそもそも正しくありませんでした。セッション ID が適切に設定されていない場合、CEM はトランザクションとコンポーネントを一見ランダムにグループ化します。以下は、2 つの異なるセッション コンポーネントがグループ化されて誤ったタイミング メトリックを取得する 1 つの例です。反対のことも発生する可能性があります。実際に発生しているにもかかわらず、他のトランザクションが要求チェーンにバインドされていないため、トランザクション/コンポーネントが失われます。

取引誤認の例。

私たちの場合、セッション識別構成でSiteMinder 認証とCookie を使用していました。Cookie は存在しなくなり、AND 関係の性質により、セッションのグループ化は行われませんでした。Cookie名を更新した結果、次の構成になりました。

SM と Cookie の存在を AND 演算したセッション構成。

ただし、これはまだ適切に機能していませんでした。まず、SiteMinder 認証の前にアクセスできるサイトの公開部分があるため、認証されていないページでは機能しません。ただし、CPSI Cookie はこれらの公開ページに存在します。それだけでなく、認証されたページも何らかの形で機能していませんでした。認証されたページには両方の部分が存在するはずなので、なぜ認証されたページが影響を受けるのかはまだわかりません. 代わりに OR 関係を使用して、認証されていないページを修正しようとしました。

ここに画像の説明を入力

認証されていないページが適切に時間を追跡し始めました。また、これにより、認証済みページも何らかの形で修正されました。突然、あきらめていた複数ステップのトランザクションが成功を報告し始め、アプリケーション全体の応答時間が大幅に変化しました。CEM が構築していた偽のチェーンが原因で、アプリ全体 (特にトラフィックの多いトランザクション) が誤って報告されていたようです。

TLDR: CEM が不正確な時間を報告しているように思われる場合、マルチステップ トランザクションが機能していない場合、または CEM に成功を報告させるために必要なコンポーネントをキャッシュ可能としてマークしていることに気付いた場合は、セッション ID の構成を確認することをお勧めします (管理 -> ビジネス アプリケーション - > {あなたのアプリ})。(彼らのヘルプ ドキュメント) を参照し、適切な構成を選択するためにアプリ (認証済みか非認証かなど) についてよく考えてください。

于 2015-08-11T21:00:02.517 に答える