「Zabbix」の版間の差分

    提供:Tsubopedia
    編集の要約なし
    編集の要約なし
     
    (同じ利用者による、間の3版が非表示)
    1行目: 1行目:
    {{基礎情報 アプリ
    | full_name        = Zabbix
    | owner_department  = 全社
    | published        = 2014/2
    | it_department    = ITC/AO
    | scale            = 極小
    | genre            = Webアプリ
    | platform          = Linux
    | language          = PHP/Apache/MySQL
    | host_ip          = 53.84.10.158
    | operated_by      = 自社運用
    | service_time      = 24時間
    }}
    == 概要 ==
    Zabbixはオープンソースの可用性およびパフォーマンス監視ソリューションである。Zabbixは、商用製品を含めた他の監視システムにはない高度な監視、アラート、可視化機能を有している。下記にZabbixの機能の一部を紹介する。  
    Zabbixはオープンソースの可用性およびパフォーマンス監視ソリューションである。Zabbixは、商用製品を含めた他の監視システムにはない高度な監視、アラート、可視化機能を有している。下記にZabbixの機能の一部を紹介する。  
    *サーバおよびネットワークデバイスのオートディスカバリ
    *サーバおよびネットワークデバイスのオートディスカバリ
    29行目: 14行目:
    *監査ログ
    *監査ログ


    [https://c575100aj01801b.jp575.corpintra.net/zabbix リンクはこちら]'''ID登録が必要です。'''
    <BR>
    == MySQLの監視 ==
    == MySQLの監視 ==
    [[File:MySQL DB Current Lock wait.png|500px|center]]
    [[File:MySQL DB Current Lock wait.png|500px|center]]
    37行目: 20行目:
    [[File:MySQL Select type.png|500px|center]]
    [[File:MySQL Select type.png|500px|center]]
    このグラフは個別クエリに対してEXPLAINすることでどの実行計画を使っているのかの確認出来る。
    このグラフは個別クエリに対してEXPLAINすることでどの実行計画を使っているのかの確認出来る。
    *Select_full_join:2つ以上のテーブルにおいて全件同士で(Indexを使わずに)JOINした回数。最も致命的。*Select_full_range_join:片方のテーブルで全件、もう片方のテーブルで範囲検索を行ってJOINした回数。
    *Select_full_join:2つ以上のテーブルにおいて全件同士で(Indexを使わずに)JOINした回数。最も致命的。
    *Select_full_range_join:片方のテーブルで全件、もう片方のテーブルで範囲検索を行ってJOINした回数。
    *Select_scan:テーブルのデータを全件検索した回数。
    *Select_scan:テーブルのデータを全件検索した回数。
    *Select Range:範囲が限定された探索(WHERE,HAVINGなど)を行った回数。<BR>
    *Select Range:範囲が限定された探索(WHERE,HAVINGなど)を行った回数。<BR>
    53行目: 37行目:
    *Handler Read Rnd Next : データファイルでの次のレコードの読み取り要求の回数。 テーブルスキャンが多く実行されると、この値が大きくなる。この場合、一般的に、テーブルが適切にインデックス化されていないか、クエリがインデックスを有効に利用していないことを意味する。 ⇒ チューニング必要<BR>
    *Handler Read Rnd Next : データファイルでの次のレコードの読み取り要求の回数。 テーブルスキャンが多く実行されると、この値が大きくなる。この場合、一般的に、テーブルが適切にインデックス化されていないか、クエリがインデックスを有効に利用していないことを意味する。 ⇒ チューニング必要<BR>
    <BR>
    <BR>
    == 関連項目 ==
    == 関連項目 ==
    [[Tsubo'tcher]]<BR>
    [[Tsubo'tcher]]<BR>
    [[Tsubopedia:Tsubopedia|Tsubopedia]]
    [[Tsubopedia:Tsubopedia|Tsubopedia]]
    <BR>
    [[category:zabbix]]
    [[category:linux]]
    [[category:SuSE]]
    [[category:Apache]]
    [[category:PHP5]]
    [[category:MySQL]]
    [[category:s575I083]]
    [[category:53.84.10.158]]

    2015年5月7日 (木) 13:54時点における最新版

    Zabbixはオープンソースの可用性およびパフォーマンス監視ソリューションである。Zabbixは、商用製品を含めた他の監視システムにはない高度な監視、アラート、可視化機能を有している。下記にZabbixの機能の一部を紹介する。

    • サーバおよびネットワークデバイスのオートディスカバリ
    • ローレベルディスカバリ
    • 中央のウェブ管理インタフェースからの分散監視
    • ポーリングとトラッピングのサポート
    • サーバソフトウェアはLinux、Solaris、HP-UX、AIX、FreeBSD、OpenBSD、OS Xに対応
    • ハイハイパフォーマンスな専用エージェント(クライアントソフトウェアはLinux、Solaris、HP-UX、AIX、FreeBSD、OpenBSD、OS X、Tru64/OSF1、*Windows NT 4.0、Windows 2000、Windows 2003、Windows XP、Windows Vistaに対応)
    • エージェントレス監視
    • セキュリティで保護されたユーザ認証
    • 柔軟なユーザパーミッション管理
    • ウェブインタフェース
    • 事前定義されたイベントをメールベースの柔軟なアラート機能で通知
    • 監視対象リソースのハイレベル(ビジネス向け)な表示機能
    • 監査ログ

    MySQLの監視

    SHOW ENGINE INNODB STATUSで表示されるTRANSACTIONS情報のうちロックの時間が記録されているTRX HAS BEEN WAITING 【秒】 SEC FOR THIS LOCK TO BE GRANTEDの秒数の合計値で、InnoDBのテーブルもしくは行のロックがかかった時に表示される。該当の数値が増えた場合はSHOW FULL PROCESSLIST;もしくはslow queryログ等でどの部分でロックがかかっているのか確認し対応する必要がある。

    このグラフは個別クエリに対してEXPLAINすることでどの実行計画を使っているのかの確認出来る。

    • Select_full_join:2つ以上のテーブルにおいて全件同士で(Indexを使わずに)JOINした回数。最も致命的。
    • Select_full_range_join:片方のテーブルで全件、もう片方のテーブルで範囲検索を行ってJOINした回数。
    • Select_scan:テーブルのデータを全件検索した回数。
    • Select Range:範囲が限定された探索(WHERE,HAVINGなど)を行った回数。


    ComはCommandの略でCom Select/Delete/Insert/Update/Replaceはその名前のとおりのSQLの実行回数。 Com xxx Multiと付いているのは複数テーブルを一括してUpdateするMySQL 独特の構文。QuestionsはMySQL Serverが発行したクエリの総数で、SET等の補助的なコマンドとエラーの応答もカウントされる。Questionsだけが増加して来たら、サーバ側で何かのエラーを起こしている可能性が高い。

    MySQLクエリ実行後ストレジエンジンAPIを通じて発生しているFileやDisk I/Oの確認が出来る。

    • Handler Read First : インデックスから最初のエントリーが読み込まれた回数。【Full Index Scanした回数】この値が大きい場合、サーバがインデックスのフルスキャンを多く行っている可能性が高い。 ⇒ チューニング必要
    • Handler Read Key : キーに基づくレコード読み取り要求の回数。この値が大きい場合、クエリおよびテーブルが適切にインデックス化されていると考えられる。
    • Handler Read Next : キー値に基づいて行を特定した後、後続の行を読んだ回数
    • Handler Read Prev : キー順序での前のレコードの読み取り要求の回数。これは主に、ORDER BY ... DESC を最適化するのに使用される。
    • Handler Read Rnd : 固定位置に基づくレコード読み取り要求の回数。 結果のソートを必要とするクエリを多く実行すると、この値が大きくなる。
    • Handler Read Rnd Next : データファイルでの次のレコードの読み取り要求の回数。 テーブルスキャンが多く実行されると、この値が大きくなる。この場合、一般的に、テーブルが適切にインデックス化されていないか、クエリがインデックスを有効に利用していないことを意味する。 ⇒ チューニング必要


    関連項目

    Tsubo'tcher
    Tsubopedia