この方法で記事を読んでメモを共有したり、学習の進捗を記録したりしても大丈夫です。
Wang Depeng. Zabbix[D] に基づくサーバーの監視と警報、およびパフォーマンスの最適化. 遼寧省: 大連理工大学、2020.
原文： Zabbixに基づくサーバー監視アラームとパフォーマンスの最適化
公式アカウントに注目すると、バックグラウンドでの返信「Zabbix をベースにしてサーバー監視とアラームとパフォーマンスの最適化を実現します」の原文を入手して一緒に学ぶことができます。
論文の主な内容:
Zabbix オープンソース プログラムと Mysql データベースに基づいて、サーバー、スイッチ、ルーター、その他の機器の温度、パフォーマンス、サービス、その他のステータスのリアルタイム監視と警報を実現する、信頼性の高いリアルタイム監視および警報プラットフォームを設計および構築します。この監視および警報プラットフォームは、さまざまな地域に分散されており、企業の情報システムの標準化、プラットフォーム化、自動化を促進する上で非常に価値があります。
革新的な 2 つのポイント:
監視および警報プラットフォームの API インターフェースに接続するための Python プログラムを作成することで、バッチ変更における Zabbix の不足を補います。
監視および警報プラットフォームの処理パフォーマンスを向上させるために、バックグラウンドの Mysql データベース アルゴリズムを分析し、監視および警報プラットフォームに最適なストレージ エンジンとインデックス タイプを選択し、データベースのパラメータを最適化して、パフォーマンスを大幅に向上させます。監視および警報プラットフォームのリアルタイムのパフォーマンスと信頼性の向上。
1 はじめに
さまざまなオープンソース監視システムの比較
この写真はインターネット上のさまざまな場所で見られますが、これが元のソースですか?
2. 関連するテクニカル分析
SNMP、IPMI、JMX プロトコル、MySQL データベース、Python に関する章を書きましたが、この部分の重さを軽減するにはどうすればよいでしょうか? ははは、でも教材としてはいいですね。
3. 監視および警報プラットフォームの分析と設計
同様の要件や原則に加えて、オンラインテキストとの大きな違いは、学術論文のニーズと思われるシステムのブロック図が示されている点です。
プラットフォーム全体のロジック図で、左側の矢印は右側のレイヤー名を指しており、最初はデータの出力かと思いました。
この図は疑わしいです。これはエージェントのデータ フローです。エージェントのデータ送信には Snmpd サービスが使用されますか?
4. プラットフォームの実現と応用
プラットフォームの実装と応用は、Zabbix 監視ソリューションを構築することです。Python を使用して Excel 上のホストを読み取り、一括変更する方法があります。これがこの記事の革新的な点であり、その他は基本的に一致していますマニュアル。
著者は、zabbix API を使用して、付録のすべてのコードを提供しています。これは頻繁に使用できる小さなツールであり、そこから学ぶことができます。
5. 監視および警報プラットフォームのパフォーマンスの最適化とテスト
主に構造の最適化、データベースの最適化、パラメーターの最適化が含まれ、最適化の比較を行います。構造はプロキシを使用します。データベースのチューニングはデータベース エンジンとインデックスの種類から開始し、次にデータベースのパラメーターを最適化します。主に zabbix サーバーの最適化を含みます。プロセスの数、キャッシュ サイズ、リフレッシュ頻度については、画像が 1 つだけ示されており、なぜこの方法で最適化する必要があるのかについては説明されていません。
疑惑の再分析
1. エージェントの処理プロセス
昨夜、論文の図 3.3 が怪しいと述べたのは、SNMPD が snmp のサービスであり、MIB (Management Information Base) が OID を格納するデータベースであるため、SNMP を使用したシステムのブロック図のように見えるからです。データを収集するためのプロトコル。
実際、Agentには以下の3つのプロセスがあることが公式マニュアルで指摘されています。
-
collecter_thread は、共有メモリに保存されている基本情報 (主にメモリと CPU) を定期的に収集します。
-
listener_thread は、サーバーまたはプロキシによって割り当てられた収集タスク、パッシブ収集を受信するために使用されます。
-
active_checks_thread アクティブな収集とレポート
ここでの 3 つのプロセスは理解しやすく、1 つはインジケーターの収集、1 つはサーバーからのタスクの受け入れ、最後はデータのレポートです。
また、インターネット上でエージェントプログラムの構造図も見つけましたので、上記の構造も作成可能です。
2. サーバーの最適設計
昨日の論文では、昨日指定されたサーバー最適化構成は 1 つだけであり、その理由はおろか、その他の構成方法も示されていませんでした。ここでは、他の構成ソリューションについて説明します。これについては、後でさらに詳しく検討します。
Zabbixサーバー設定ファイル
#ListenPort=10051
#リスニングポート
# ソースIP=
#複数アドレスの場合、どのアドレスで通信するかを指定
# ログタイプ=ファイル
#ログを指定する方法はファイルに記録することです
LogFile=/var/log/zabbix/zabbix_server.log
# ログ ファイルの保存パスを指定します。ユーザーはディレクトリへのアクセス許可を持っている必要があります。
# ログファイルサイズ=1
# ログの書き換え、通常はオープンされません
# デバッグレベル=3
#ログ レベル; 間違いを犯す必要がある場合は、デバッグ レベルに調整して、より明確に確認できます。間違いが完了したら、元のログ レベルに戻します。そうしないと、ログがディスク領域をいっぱいにしてしまいます。
PidFile=/apps/zabbix-server/run/zabbix_server.pid
#PIDファイルパス
SocketDir=/apps/zabbix-server/run/
#ソケットファイルのパスを指定
DBホスト=
#接続されているデータベースアドレス
DBName=zabbix_server
#名前データベース
DBUユーザー=
#接続されたアカウント
DBパスワード=
#接続パスワード
Zabbixサーバー最適化構成
# 履歴ストレージURL=
#elasticsearch サーバーのアドレスを指定し、zabbix の履歴データを ES に保存し、zabbix のパフォーマンスを最適化し、サポートするには新しいバージョンの zabbix が必要です
# HistoryStorageTypes=uint,dbl,str,log,text
#elasticsearch のインデックス タイプ
# HistoryStorageDateIndex=0
#履歴データを別の elasticsearch インデックスに保存する
# エクスポートディレクトリ=
#リアルタイムエクスポートトリガーイベント、監視アイテム収集値、およびトレンドデータのディレクトリを定義します
# エクスポートファイルサイズ=1G
#エクスポートされる各ファイルの最大サイズを定義します
StartPollers=6
# エージェント データを収集するために複数のプロセスを開くように指定します。一般的なプロセスの数は CPU コアの数に対応し、範囲は 0 ～ 1000 です。
# StartIPMIPollers=1
# IPMI データを収集するために複数のプロセスを開くように指定します。事前に IPMI を開く必要があります。そうしないとエラーが報告されます。範囲は 0 ～ 1000 です。
StartPreprocessors=6
#zabbix エージェント データを処理するために事前に開始されているプロセスの数。範囲は 0 ～ 1000 です。
# StartPollersUnreachable=1
#到達不能なホストをローテーションで検出するために開始するプロセスの数。範囲は 0 ～ 1000 です。
トラッパーの開始=5
#トリガー関連の操作を処理するために事前に開始されているプロセスの数。範囲は 0 ～ 1000 です。
スタートピンガー=5
#ping 検出のために開始するプロセスの数。ネットワーク デバイスとホストへの ping に使用されます。範囲は 0 ～ 1000 です。
StartDiscoverers=6
#ディスク自動検出、ネットワーク自動検出などの自動検出のために開始するプロセスの数。一般的なプロセスの数はホスト CPU コアの数を超えてはなりません。範囲は 0 ～ 250 です。
StartHTTPPollers=3
#Web アクセスを実行するときに、Web アクセスを処理するために開始されるプロセスの数。範囲は 0 ～ 1000
開始タイマー=3
#タイマープロセス数、タイマーは問題の発生時刻の計算やステップ同期などに使用され、アラーム発生時のメールの再帰送信などに使用されます。範囲は1～1000です。
# スタートエスカレーター=1
#elasticsearch プロセスの初期プロセス番号、アクションの自動ステップの処理に使用されるプロセスの数、0 ～ 100
# 開始アラート=3
#アラームプロセスの事前開始番号、0～100
#Javaゲートウェイ=
#zabbix は php で書かれており、Java プログラムに直接アクセスできないため、javagateway が使用されます。javagateway は、一方の端で zabbix に接続され、もう一方の端で Java 環境に接続され、java 環境のリソース インジケーターを収集します。複数の Java サービスへの接続; Java ゲートウェイ アドレスを指定する
#Javaゲートウェイポート=10052
#javagatewayListening ポート
# StartJavaPollers=0
#ローテーションで Java データを収集するために事前に開始するプロセスの数 (0 ～ 1000)
# StartVMwareCollectors=0
#監視する vmware esxi ホスト インスタンスを設定するために使用されます。0 の場合は使用されません。esxi ホストを監視する場合、最小値は 1 です。監視する esxi の数に応じて、対応する数値を設定しますZabbix は vmware を監視します。vmware を監視するためのテンプレートを使用する必要があります ;0-250
VMware周波数=60
#vmware が最新データを取得する時間間隔を秒単位で監視します。
#VMwarePerfFrequency=60
#vmware パフォーマンス データの時間間隔を監視する
#VMwareCacheSize=8M
#vmware データ キャッシュ サイズは、zabbix サーバー サーバーのメモリを占有します
# VMwareタイムアウト=10
#vmware データ取得のタイムアウト
SNMPTrapperFile=/apps/zabbix-server/run/zabbix_traps.tmp
#SNMPトリガーファイルの一時パス
StartSNMPTrapper=1
#SNMP トリガー プロセス番号、範囲は 0 ～ 1、1 はオープンを意味します
# リッスンIP=0.0.0.0
#zabbix サーバーのリスニング アドレス
# ハウスキーピング頻度=1
#エージェントデータベースの履歴データをクリーンアップする時間、デフォルトは1時間、範囲は0～24、監視項目で定義した履歴データの保存時間とトレンドデータの保存時間が指定時間を超えた場合、クリーンアップされます;トレンドデータは1時間以内のデータの最大値、最小値、平均値を保存します;ヒストリカルデータは各監視項目のデータをクエリしますヒストリカルデータです
# MaxHousekeeperDelete=5000
#毎回履歴データを削除する最大行数。範囲は 0 ～ 1000000 です。
キャッシュサイズ=128M
#ホスト、管理項目、トリガー データの保存に使用されるキャッシュ サイズ。範囲は 128K ～ 8G、通常は 1 ～ 2G で構成されます
キャッシュ更新頻度=300
#zabbix キャッシュされたデータの頻度を秒単位で更新します。範囲は 1 ～ 3600 です。
StartDBSyncers=4
#zabbix がクエリを含むデータとデータベースの同期を開始するプロセスの数; 0 ～ 100
HistoryCacheSize=2G
# 履歴データのキャッシュ サイズ、128K ～ 2G
HistoryIndexCacheSize=128M
#履歴データインデックス情報キャッシュ、128K-2G
トレンドキャッシュサイズ=16M
#これは、計算されたトレンド データをキャッシュするために使用されるシステム共有メモリの量を設定するために使用されます。このパラメータは、データベースの読み取り圧力にある程度影響を与える可能性があり、範囲は 128K ～ 2G です。
値キャッシュサイズ=16M
#プロジェクト履歴データリクエストのキャッシュに使用される共有メモリサイズ、128K-64G
タイムアウト=30
#サーバーによってクエリされたデータをエージェントが返さない時間を指定します。タイムアウトになります。1 ～ 30
トラッパータイムアウト=300
#トリガーがデータを処理する最大時間 (秒単位); 1 ～ 300
到達不能期間=60
#ホストに到達できない状態が何秒続いた場合、ホストが利用できない状態として設定されます。単位は秒、1～3600です。
利用不可遅延=60
#ホストが利用できない場合に、ホストの可用性を確認する頻度 (範囲は 1 ～ 3600)
到達不能遅延=15
#ホストに到達できない場合、ホストの可用性を確認する頻度、1-3600
AlertScriptsPath=${datadir}/zabbix/alertscripts
#監視アラーム スクリプト パスは、コンパイル時の datadir パラメータに依存します (/apps/zabbix-server/share/zabbix/alertscripts など)。
# FpingLocation=/usr/sbin/fping
#fping コマンドの場所を指定します。fping はネットワーク接続のテストに使用されます。apt install fping を使用してインストールできます。
# Fping6Location=/usr/sbin/fping6
#fping6 のコマンドの場所
LogSlowQuery=3000
# 結果が返されない時間を指定します。遅いログ (ミリ秒単位) です。ログ レベルが 3、4/5 の場合のみ、0 は記録なしを意味します。範囲は 1 ～ 3600000 です。
# TmpDir=/tmp
#一時ファイル格納ディレクトリ
StartProxyPollers=1
#zabbix サーバーがプロキシとの通信を開始するプロセスの数を指定します。これはパッシブ プロキシであり、zabbix サーバーはプロキシにアクティブに接続し、プロキシはサーバー接続を受動的に受け入れます。一般に、サーバーがプロセスはプロキシと対話します
ProxyConfigFrequency=60
#proxy パッシブ モード、サーバーが設定ファイル (監視項目) をプロキシに同期する秒数、このパラメータはパッシブ モード プロキシにのみ使用され、範囲は 1 ～ 3600*24*7、新しいエージェント ノードの場合zabbix Web 経由で追加されるまでの期間 設定ファイルを一度にプロキシに同期します。プロキシは設定ファイルを受信した後、再度設定ファイルをエージェント ホストに同期し、エージェント ホストが監視項目を取得できるようにします。設定ファイルに収集されます。
プロキシデータ周波数=60
#パッシブ モードでは、zabbix サーバーがプロキシに履歴データを要求する秒数が決まります。プロキシは、指定された時間 (1 ～ 3600) 以内にエージェントの監視データをサーバーに報告します。
#AllowRoot=0
#rootでのzabbixの起動を許可するかどうか、許可したい場合は1に変更してください
ユーザー=zabbix
#zabbixを起動するユーザーを指定する
# 含める=
#指定したパスの設定ファイルをインポート
# StatsAllowedIP=
#zabbixサーバーへのアクセスを許可するアドレスを設定
読んだあと
記事内では、ある企業のネットワーク監視について何度も言及されていますが、これは具体的なネットワーク監視プロジェクトの概要であるはずです。使用されている技術は難しくありませんが、構造やプロセスなどが明確に書かれているのと、マニュアルやオンライン記事は、監視についてさらに理解するのに役立つ場合があります。
原文： Zabbixに基づくサーバー監視アラームとパフォーマンスの最適化
公式アカウントに注目すると、バックグラウンドでの返信「Zabbix をベースにしてサーバー監視とアラームとパフォーマンスの最適化を実現します」の原文を入手して一緒に学ぶことができます。