元の問題を説明するスクリーンショットを次に示します。
すべての標準スキームで結果が得られなかったため、自分で考えて問題を探す必要がありました。 アナリティクスは役に立たなかったので、Yandex.Metricaをチェックし始めました。 全体的なメトリックはかなり許容範囲でした（最大10％の障害）。 メトリックの失敗が受け入れられる理由に関するいくつかの記事を読んだ後、Analyticsで屋根をくぐると、問題を探す場所が明らかになりました。 要するに、メトリックは、15秒未満継続したすべての訪問が拒否されたと見なし、アナリティクスは、それ以降ページに他の訪問がなかったすべての訪問を考慮します。 そのため、Metric and Analyticsで訪問の継続時間に関するレポートを調べ始め、1日のセッションの最大50％の継続時間0:00秒で非現実的に高い割合の訪問があることに気付きました。 さらにいくつかの記事を読んで、Analyticsフィルターを通過する動作しないコードとボットの仮説を破棄することが可能になりました。 紹介スパムの兆候もありませんでした。
その結果、Webvisorで0:00の期間の訪問を除外し、パターンを見つけることにしました。 ここに私が得たものがあります：
各「訪問者」は、明示的に指定されたユーザーエージェント、画面解像度、およびオペレーティングシステムを使用してサブネットから来ました。つまり、MetricaとAnalyticsでは、ボットとして認識されませんでした。
彼を裏切った唯一のことは、1時間1分ごとの訪問のリズミカルな性質と0の視聴時間でした。 システム管理者のAndreiにスクリーンショットを撮り、サーバーログに基づいてそれが何であるかを確認するように頼みました。 最初のIPshnikは、Ligaサブネットの誰かが私たちのところに行ったという不思議に思いました。
4:56のIPを持っているので、他のコールをチェックします
inetnum：193.150.7.0-193.150.7.255
ネット名：LIGA-UA-NET2
備考：LIGA ZAKON
合計で43のIPアドレスがログによって検出され、さまざまなユーザーエージェントを使用して、さまざまなプロバイダーのサイトのさまざまなページにアクセスしました。
RIPEでは、通常のサブネットからの興味深い、目立たないIPは見つかりませんでした。 ボットが1:01の間隔で歩いているという事実に加えて、ボットは明らかに一般的なものではありませんでした。
iptablesにあるリスト全体をブロックしました。
日中、私たちはまだいくつかの新しいIPをキャッチし、いくつかのボットをブロックした後にそれらが新しいものに置き換えられる場合に備えて、そのようなボットトラフィックを自動的にフィルタリングするアルゴリズムをスケッチしました。 しかし、他に誰も見つかりませんでした。 好奇心User盛なユーザーエージェントは数人しかいませんが、1：01の間隔のユーザーエージェントはいません。
1日後、Googleアナリティクスの直帰率は反発し始め、89％から42.75％に急激に低下しました。
今日、説明されたイベントのほぼ1週間後、故障率は42〜55％の許容範囲内に保たれ、全体的なダイナミクスがグラフで確認できます。 急激な減少がある場合-これはボットをフィルタリングしたことです。
「それが何であったか」についての仮説は2つだけです。
1つ目は、ある種のモニターボットを誤って構成したことです。 かつて、サーバーのステータスを確認するためにさまざまなソフトウェアを使用しました。 彼らは何かをオンにして忘れることができました。 この理論の欠点は、異なるサブネットからのリクエストを異なるユーザーエージェントからサイトの異なるページに送信することを宣言する単一のサービスを覚えていないことです。 したがって、おそらくそうではありません。
2番目の仮説：これは、一般には知られていない何らかの形のボット攻撃であり、バウンス率を高め、その結果、Googleの検索結果の悲観化を正確に狙う可能性があります。
あなたもこれに遭遇した場合、私はコメントしてうれしいです。 検索およびブロックの方法に関する詳細な説明が必要な場合は、こちらにもご記入ください。