Zabbixを使用した正しい問題検出

アレクセイ・ヴラディシェフ （ alexvl ）

私の名前はAlexey Vladyshevです。私はZabbixの作成者であり、現時点ではそのアーキテクチャとロードマップを担当しています。

これは入門講義であり、最初にZabbixとは何か、次にZabbixが高レベルのアーキテクチャと問題の検出の観点からどのように機能するかを説明します。 Zabbixに関連する問題を検出する方法、Zabbixを使用して問題を検出する方法について説明します。



Zabbixとは何ですか？ このページにアクセスすると、Zabbixがエンタープライズレベルのオープンソース監視ソリューションであることがわかります。 これは、オープンソースのエンタープライズ監視ソリューションです。 ソリューションを既存のインフラストラクチャに簡単に統合できるように、「エンタープライズ」という言葉を理解しています。 つまり 大企業の場合、すでにいくつかの製品（ヘルプデスク、構成管理など）を使用しています。システムは簡単に統合できるはずです。


Zabbixが他の製品と異なる点は何ですか？ 大きな違いとかなり大きな利点は、Zabbixがオープン製品であり、本当にオープンソースであるということです。 クローズドバージョンはありません。24時間年中無休で製品をビルドし、無料で提供しています。 当社のページにアクセスして、当社の製品を使用してください。 他にも利点があります。 私は広告目的ではなく、単に教育的な意味で-私たちはどう違うのですか？ Zabbixはオールインワンソリューションです。 視覚化、問題検出、さまざまな方法での情報収集-これらはすべてZabbixにあり、異なる個別のブロックから監視システムを構築する必要はありません。



Zabbixはどのように機能しますか？ あまり代表的でない人のために、データを収集します。 Zabbixサーバーは、すべてのロジックが含まれるZabbixのコアです。 さまざまな方法でデータを収集します。 このデータ、情報はデータベース、履歴に追加され、情報は視覚化に使用され、コアは情報の流れの分析にも関与します。 問題を検出し、何らかの形で問題に対応します。 問題に対するさまざまなタイプの反応があります。



データ収集に関しては、どのような問題をキャッチできますか？ これらは、パフォーマンス、可用性に関連する問題です-サービスが利用可能かどうか。 システムの動作速度をすぐに判断できます。 これらは、データの整合性に関するパフォーマンスの問題です。 何らかの構成ファイルを変更した場合、またはクラウドで展開したシステムのイメージを変更した場合。 小切手金額が変更されました-Zabbixは、ファイルが変更されたことをすぐに通知します。

Zabbixは、ビジネスレベルの監視の領域もわずかにカバーしています。 実際、ITインフラストラクチャのさまざまなレベルで問題を検出できます。

• これは鉄のレベルです-鉄の一部に何かが起こった場合、私たちはすぐにそれを知るでしょう、
• オペレーティングシステムレベル
• ネットワーク、主にSNMPを介した監視、
• 仮想レベル、つまり たとえば、WMwareインフラストラクチャ、vCenter、vSphereの監視を提供します。
• 次はミドルウェアです。
• ビジネスアプリケーション。

つまり アプリケーションの問題を検出する方法がわかっていて、Zabbixがすぐにサポートされない場合は、スクリプトを使用してZabbixに固定できます。



データを収集するにはどうすればよいですか？ 2つの方法があります。プル-デバイスからデータをプルするとき。 また、Pushメソッドは、デバイス自体が情報を提供し、情報を提供する場合です。 プルは、SSHなどのサービスに接続するときの通常のチェック（SNMP、サービスチェックなど）であり、Webページが正しく応答する場合、すべてが正常です。 プッシュは基本的に、さまざまな種類のトラップおよびSNMPトラップのアクティブなエージェントです。 データ収集は、Pushメソッドを介して機能します。



Zabbixエージェントについては。 エージェントは、Linux、Windows、またはその他のオペレーティングシステムにインストールできるプログラムです。 アクティブモードについてお話ししたかったのです。 問題を検出するという点でその利点は何ですか？ パッシブモードで情報を要求するエージェントに接続している場合、エージェントはプロセッサの負荷などを返し、アクティブモードではエージェント自体がデータを監視サーバーに送信します。 利点は次のとおりです。

• 少なくとも高速で動作します サーバーはデバイスの絶え間ないポーリングに関与してはならず、デバイス自体が情報を送信し、
  
• エージェントはTCP接続またはネットワーク接続をリッスンするべきではないため、エージェントの観点からはより安全です。
  
• 今日の私たちにとって重要な小さな利点-アクティブモードでは、バッファリングがあります。 何らかの理由でZabbixサーバーが使用できない場合、Zabbixサーバーをアップグレードし、数分間ダウンタイムが発生すると、データはエージェント側に蓄積されます。 サーバーを起動するとすぐに、データはすぐにサーバー側に送信され、処理できるようになります。
  

一般に、問題は次のとおりです。デバイスに問い合わせる頻度、データを収集する頻度。

もちろん、1秒間に1回データをポーリングし、1秒間に1回デバイスをポーリングして、ある種のGBの情報を収集したいと思います。 問題が発生するとすぐに、すぐに、問題があることがわかります。 しかし、そのような原則があります。システムに害を与えるべきではありません。 量子物理学のように、オブザーバーはプロセスに影響します。 何らかの理由で観察した場合、すでにプロセスに影響を与えています。 監視システムでも同じです。 あまりにも多くの情報を収集し始めると、監視システムに監視システムに影響を与えます。 したがって、ここで妥協点を選択する必要があります。一方では害を及ぼさず、他方ではできるだけ早く問題を検出する必要があります。

Zabbixにはいくつかのオプションがあります。 まず、デバイスまたはメトリックをn秒ごとまたは1分間に1回監視して、何らかのチェックを実行できます。 時間間隔に応じて異なる周波数を使用することができます。 システムが営業時間外に機能しないことは重要ではないと仮定します。勤務時間中にシステムが機能することが重要です。 次に、Zabbixに次のように言います。「ワークステーションを9:00〜18:00に確認してください」、それだけです。 そのような機会があります。

Zabbix 3.0では、新しい「仕事の準備完了」、「ビジネスの準備完了」タイプの検証が導入されています。 これは、Zabbixに「特定の時間にこれらのチェックを行う」ことを伝えることができることを意味します。 銀行の支店が午前9時に開き、8時55分にチェックリストがあり、支店が実際に動作する準備ができていること、すべてがワークステーションで正常に動作していること、依存しているサービスがあることを確認します、前のものが正常に閉じられ、新しい金融日が開かれた順序などで つまり Zabbix 3.0以降では、特定の時間にチェックを実行できます。 Zabbixに「8:55にこのサービスを確認してください」と伝えると、Zabbixは8:55にサービスを確認します。 また、これらのチェックを、たとえば9：00、10：00、11：00などの間隔で実行することもできます。これは、前述のとおりです。



情報の流れの問題をキャッチする方法は？ 膨大な情報の流れがあり、Zabbixはパフォーマンス、1秒あたりの可用性の数千、数万のさまざまなテストを実行し、トリガーを提供します。 Zabbixを使用している場合、トリガーとは何かを知っています。 これは本質的に問題の説明です。 問題を定式化します。 最初に、多分私たち自身の言語で、そしてそれをトリガー式のフォーマットに変換しようとします。

単純なトリガー式、たとえば、サーバーのプロセッサー負荷が5より大きい場合：



これは最も単純なトリガーです。 トリガーはさらに複雑になる可能性があるため、算術論理演算を使用できます。 ここでは、1つのメトリックに限定されないことが非常に重要です。1つのメトリックだけでなく、ほとんどすべてを分析できます。 さまざまなデバイスからデータを取得し、問題の説明でそれらを使用します。 Zabbixは、受信したばかりのリアルタイム情報と、データベースにあるいわゆるいわゆる情報の両方を分析することもできます。 履歴情報。



初心者、モニタリングの初心者は通常何から始まりますか？ Zabbixは、問題を検出するための非常に強力なツールであり、すぐにすべてについてすべてを知りたいと考えています。 どこかで何かが起こったら、すぐに電子メールまたはSMSを受け取りたいです。 これは何につながりますか？ すべてが正常に見えるようになり、システムが過負荷になり、「現在のプロセッサの負荷が5を超える」トリガーが作成され、「httpサービスが利用できません」などのアクセシビリティのためにトリガーが作成されます。 最後のチェックでは、Webサーバーが利用できず、問題があると考えています。 なぜこれがあまり良くないのですか？



そのようなトリガー、そのような問題の説明は敏感すぎます。 プロセッサの負荷が5を超えました。システムが過負荷になり、SSH経由で接続し、TOPを起動すると、プロセッサの負荷はすでに4.5であると考えられます。 または、Zabbixは、Webサーバーが機能していない、実際には接続されており、機能していると言っています。 それで何が起こっているのでしょうか？

そのようなこと、この感受性は中毒性があります。 監視システムは非常に多くのメッセージを生成しますが、実際の問題ではないため、応答を停止します。

例を挙げてください。 ラトビアでは、少し前にそのようなケースがありました-スーパーマーケットで警報が鳴り、人々はいつものようにこれに反応しませんでした。 すべての人々をスーパーマーケットから連れ出すべきスタッフは、「ああ、アラームが鳴った、大丈夫だ」と思った。 スーパーマーケットにいた人々は、「さて、買い物を終えて出かけます」と考えました。 実際、それはすべての重複が崩壊し、多くの人々が死んだという事実の前兆でした。

なぜこれが起こったのですか？ 人々は警報が鳴ったことに慣れているので、周りを見回したが、火災はなかった。 まあ、私たちは仕事を続けたり、楽しんだりし続けます...しかし、この中毒は非常に恐ろしいものです。 それでも、監視システムに問題があると言われた場合、この問題があるはずです。監視システムの感度が高すぎてはなりません。

どうする？ 問題を正しく定式化し、本質を理解することが重要です。 疑問に思う必要があります。私たちは本当にどのような問題を説明しようとしているのか。 「システムの過負荷」とはどういう意味ですか？「サービスを利用できない」とはどういう意味ですか？



システムが過負荷になっている、たとえば、プロセッサの負荷が5を超えている（今日は非常に単純な例を意図的に使用しています。つまり、例はより複雑になる可能性がありますが、これは単純な例です）。 システムが過負荷になっています-プロセッサの負荷が5になっているわけではありませんが、システムはしばらくの間ロードする必要があります。 そして、ここでストーリーを分析できます。 つまり たとえば、最後の10分間にプロセッサの負荷が5を超えていた場合、はい、システムが本当に過負荷になっているか、プロセスがフリーズしたか、何か他のことが起こりました。

サービスが利用可能な場合、何ができますか？ 同じことは、ストーリーを調べることでもあります。「それまではどうでしたか？」 最後の5分間、システムがhttpが利用できないと答えた場合、おそらく、httpは利用できません。

チェックの本質を理解することは依然として重要です。 Webサーバーがアクセス可能であることをどのように確認しますか？ 次のようにチェックします。TCP接続を確立し、リクエストを取得し、結果をカウントします。ここで何かが間違っている可能性があります。 たとえば、タイムアウトが発生しました。 はい、タイムアウトが発生しましたが、これはWebサーバーがダウンしていることを意味しますか？ いいえ、必ずしもそうではありません。 しかし、次のようにタイムアウトが3回あった場合（＃3）-これは、最後の3つのチェックでサーバーが使用不可であると回答したことを意味し、Webサーバーが実際に使用不可であるか、ネットワークの問題があるなどの可能性が高い。

したがって、まだ歴史を見る必要があります。 ほとんどの場合、最後の値に基づいて決定することは完全に正しいとは限りません。



他に何を話したいですか？ 問題の解決策は、その不在と同等ではありません。 これはどういう意味ですか？

たとえば、十分な空きディスク領域がありません（ここでも、非常に単純な例を取り上げます）。 これはどのように定式化できますか？ 残りの空きディスク領域が10％未満だとします。 問題は、11％の空きディスク容量があるとすぐに、この問題は解決されましたか？ この問題はまだ完全には解決されていないようです。 または、10％と1バイトがあります。

そのため、Zabbixには、問題の状況に対するさまざまな条件を記述し、問題の状況から抜け出すことができるメカニズムがあります。



たとえば、空きディスク領域は10％未満ですが、10％ではなく30％の空きディスク領域が30％ある場合にのみ、この問題のある状況から抜け出したいと思います。 この場合にのみ、誰かが何かをしたこと、誰かがいくつかのファイルを削除したこと、システム管理者が接続したこと、ファイルシステムを拡張したこと、そのサイズを増やしたことを100％確信しています。この場合、これ以上の問題はありません。

このために、ヒステリシスを使用します。 ヒステリシスとは、本質的に次のことを意味します。 車の写真を見てみましょう。 車は立っているように見えますが、その状態はわかりません-立つことができ、前進、後退することができます...前に起こったことの歴史を知らずに、車の現在の状態を言うことはできません。 つまり 過去の出来事の歴史をまだ少し見なければなりません。 そして、さまざまな条件を使用して問題の状態に入り、問題の状態を終了すると、いわゆる 羽ばたき。

羽ばたきとは何ですか？ フラッピングは、問題の非常に単純な説明が使用される場合です。 たとえば、プロセッサの負荷が5を超えているか、空きディスク領域が10未満です。10％、8％、11％、7％の場合はどうなりますか？ これは羽ばたきです。 問題が発生、消滅、発生、消滅します。 午前中に到着し、受信トレイを開くと、Zabbixから、問題が消えた、消えた、消えた、消えた、というメッセージがたくさん表示されます。 さらに、監視システムを信頼していません。 これは羽ばたきです。 そして、さまざまな条件を使用して問題を入力し、問題を終了すると、フラッピングは完全になくなります。

いくつかの例：



システムが過負荷になり、最後の5分間のプロセッサの負荷が上位3を超えましたが、最後の2分間でプロセッサの負荷が1未満になった場合にのみ問題が解決します。 ここでは、わずかに異なるロジックが使用されます。ここで、最初の条件は問題への入り口、2番目の条件-1以上の値が少なくとも1つある限り、問題の状態のままです。

空きディスク容量がありません。 私の例は10％未満です。 問題は、これは本当に問題なので、ここでは100％確信しています。 そして、過去10分間で30％以上の空きディスク容量があったときに、問題の状態から抜け出します。 システム管理者は、たとえば、あるファイルシステムから別のファイルシステムに大きなファイルを移動し、何かをコピーすることができるためです。 10分以内に、空きディスク領域が30％を超える安定した状態になった場合、問題は解決したと考えられます。

同じ、SSHサーバーは利用できません。 最後の3つのチェックは、サーバーが利用できないことを示しており、サーバーが利用できないと考えています。 ただし、最後の10回のチェックで、サーバーが最終的に利用可能になったことが判明した場合にのみ回復したいと考えています。 現実には何が起きているのですか？ サービスに問題があり、サービスの修復、再起動、古いバージョンへのロールバック、システムの動作、動作していません。 そして、ここでは、この可用性の期間について説明しています。 最後の10回のチェックで問題ありません。今では間違いなく寝ることができます。サービスが問題ないことを知っているからです。



異常。 一般的に、異常とは何ですか？ 異常とは、標準からの逸脱を意味するギリシャ語です。 一定の規範があり、規範から逸脱するとすぐに、これは異常と見なされます。



異常はどのように検出できますか？ Zabbixには、過去のシステムの状態を標準として、現在の状態と比較するときにこのような機能があります。 たとえば、直前の1時間の平均プロセッサ負荷がちょうど1週間前の同じ期間のプロセッサ負荷を2倍にした場合、昨日ではなく、昨日と比較すると、日曜日と月曜日、金曜日、土曜日の比較になる可能性があるため、まったく正しくありません。 今日が木曜日の場合、先週の木曜日に起こったことと比較しましょう。 私たちはこれが標準だと信じています-先週の木曜日に起こったこと。 今日、プロセッサの負荷が増加したことがわかった場合、Zabbixは管理者にメッセージを送信して、「おい、どうぞ、ここでいくつか問題があります。」と言うことができます。 もちろん、必ずしも問題ではないかもしれません。 それは有益なメッセージだからです。 多分彼らはいくつかのシステムをアップグレードし、パフォーマンスの面でリグレッションが現れたかもしれません。おそらく何か他のことです...これは重要です。

良い機能です。どうにかして使い始めることをお勧めします。 それが実際の実用的な利益をもたらすかどうかを言うことは困難ですが、少なくともこれは、より重要な問題、より深刻な問題の前触れを非常に頻繁に反映するものです。 これに注意してください。



そして中毒。 羽ばたき、そのようなすべてのものを取り除きましたが、お互いに依存する問題があることはまだわかっています。

ネットワークレベルでの最も単純な例は、スイッチの背後にデバイスがある場合です。 スイッチの問題により、監視システムはすべてのデバイスが落下したと判断し、多くのSMSメッセージを受信します。 これらすべての問題の根本原因である、実際に何が起こったかを判断することはできません。

Zabbixでは、ある問題の別の問題への依存関係を定義するだけです。 CRMシステムがデータベース、ネットワーク、ミドルウェアなどに依存しているとします。 データベース自体はディスク容量に依存します。 ディスク容量がない場合、ディスク容量がないというメッセージが表示されます。

問題への対応方法



反応は異なる場合があります。 おそらく、常に使用するとは限らないものを使用する必要がありますが、多くの場合、それは良いアイデアであり、依然として問題の自動解決策です。 時々それは可能です

時々、メモリを消費するアプリケーションがあることを知っています。 メモリがすべて消費され、解決策はありません。このアプリケーションは時々再起動する必要があります。 ある種のカーネルパニックが発生したという事実により、状況が発生することがあります。 ここで、時々カーネルパニックが発生するため、このサーバーを再起動する必要があります。 これらはすべて監視システムに委ねることができます。 つまり IPMIを介したカーネルパニックの場合、ハードウェアレベルで自動的にリセットできます。 サービスの場合、自動モードでもサービスを再起動できます。

反応は、ユーザーまたはユーザーグループへの単なるメッセージになります。 また、反応は、ヘルプデスクシステムでのいくつかのチケットのオープンかもしれません。 つまり まったく異なる方法で対処することができます。もちろん、対処方法は問題の深刻さによって異なります。 問題がそれほど深刻ではない場合、翌日の午前10時にこの問題が解決される場合は、午前4時にSMSメッセージをすぐに送信しないでください。



問題をエスカレーションする機会はまだあります。 つまり 問題があったので、私たちは自分自身に尋ねます。それをどうするか、誰に通知するか？ もちろん、管理者にメッセージを送信し、管理者が何かをしますが、非常に効果的なオプションは、問題が官僚的なツリーのレベル、より高いレベル、マネージャー、さらにはマネージャー、さらにはさらにエスカレートするときだと思います- CEO そして、CEOは「何らかの種類のボリュームディスクが落ちた、他の何かがそこにある」といったメッセージを受け取らず、CEOは「最後の30分間、お金を失っています」といったメッセージをZabbixから受け取ります。 そして、それで終わりです。

あなたはすぐに応答することができます-問題があります、私たちはすぐに何かをします。 あなたは遅れて応答することができます、すなわち 問題があったので、5分ほど待ってから、5分後にメッセージを送信します。 そして、ここでは次のことが依然として重要です。 自動化が機能しない場合は警告します。 サービスがあり、それが機能しない場合、このサーバーを自動的に再起動するようにZabbixを設定しました。 この場合、エスカレーションをどのように設定しますか？ 次のように構成します。最初にサービスを再起動し、10分後に問題が解決しない場合は、ユーザーにアラートを送信します。 または、さらに高いレベルにエスカレーションします。

また、特に深刻な問題の場合、アラートの繰り返しも非常に重要です。 簡単にスキップできるもの、SMSをスキップできるもの、電子メールメッセージをスキップできるものもありますが、重要な問題のために、繰り返しメッセージを使用する必要があります。 これは非常に良いインセンティブでもあります。はい、問題が存在することがわかり、できるだけ早く解決するために努力する必要があります。



そして、おそらくそのような結果。 ここで何が重要ですか？

• 物語。 私たちは、リアルタイムの監視、受信したばかりの運用情報だけでなく、履歴も確認します。 あなたは物語を見なければなりません。 これは重要です。
  
  
• 問題がないことは解決策ではありません。 いくつか例を挙げましたが、実際、Zabbixを頻繁に使用しているので、現在持っているトリガーを批判的に見てください。 履歴分析とヒステリシス、問題のさまざまな条件、および問題から抜け出すための条件の組み合わせ-それは実際に驚異的に機能します。 このような非常にスマートな問題検出が判明しました。 この機能を使用する必要があります。
  
  
• 繰り返しますが、これが実際的なメリットをもたらすかどうかを言うのは難しいですが、少なくとも試してみる価値はあります。 異常に関しては、Zabbix 3.0では、おそらくベースライン監視を実装しています。 これはどういう意味ですか？ ベースラインは一定の基準、つまり このベースラインはトレンドから計算されます。 すべてのトリガーが履歴で動作するようになった場合、ベースラインモニタリングでは、トレンドから、トレンドから情報を取得し、たとえば先週の勤務時間中のシステムの動作を今週または今日のシステムの動作と比較することが可能になります。 つまり 通常の状況では何かを基礎として、現在の状況と比較します。 これは、傾向、傾向に基づいたこのような統計分析です。
  
  
• 自動問題解決。 おそらく、監視システムを使用している場合、各自は、この問題が遅かれ早かれ起こることを知っているクラスの問題を抱えており、それについては何もできません。 オペレーティングシステムのランダムクラッシュの例を示しました。このような問題が存在することはわかっています。それぞれいつでも発生する可能性があり、自動問題解決は良い解決策です。
  
  
• . , . , , , , … – , , , , , , , 5 , , . , , , exchange , ? , .

» alexvl
» alex@zabbix.com
» twitter
» Zabbix

— devops RootConf .

RootConf devops, , .

さて、主なニュースは、 RootConfを含む8つのカンファレンスを含む春祭り「 Russian Internet Technologies 」の準備を開始したことです 。

, , — , . , / — . .