事例|都市商業銀行のアーキテクチャ共有を監視する Zabbix

編集者のおすすめ:

著者が勤務する都市商業銀行は、アプリケーションシステム監視の Zabbix プラットフォームへの移行を正常に完了しており、アーキテクチャの導入、監視ディメンション、自動化ソリューション、運用管理の側面から Zabbix システムの開発と成長の経験を共有します。。この記事の著者は「Zabbix Technology Exchange Group」にも参加しています。交換への参加を歓迎します。

AcidGo: 都市商業銀行のインフラ運用保守エンジニア

2018年に社内運用環境で複数のストレージデバイス、数千台のOSホスト、各種データベース製品を多次元的に監視する監視システム「Zabbix」の利用・普及を図り、複数のカスタム製品を開発監視スクリプト、アプリケーション監視フレームワーク、およびフロントエンドページ表示。

Zabbix プラットフォームの概要
プラットフォームの概要
Zabbix は、Web インターフェイスに基づいた分散システム監視およびネットワーク監視機能を提供するエンタープライズレベルのオープンソースソリューションです。Zabbix は、さまざまなネットワークパラメータを監視し、サーバーシステムの安全な動作を確保し、システム管理者がさまざまな問題を迅速に特定して解決できるようにする柔軟な通知メカニズムを提供し、運用とメンテナンスにかかる負荷の高いサーバー管理を簡単に軽減します。ビジネスシステムの継続的な運用を確保するための人事業務。バックエンドはデータベースを使用して監視構成と履歴データを保存し、データ分析やレポートのカスタマイズなどのチャネルに簡単に接続でき、サードパーティのプラットフォームを呼び出すための豊富な RESTful API がフロントエンドで開かれます。現在の DevOps トレンドでは非常に優れています。

選定の経緯
2017年からZabbixへの問い合わせを開始しました。これまで運用保守で使用していた主な監視システムはNagiosでしたが、Nagiosのページ表示や監視設定、自動化などの機能はインフラの運用保守担当者にとってあまり使いやすいものではありませんでした。 . そして、今注目を集めているZabbix。インフラストラクチャの運用保守では、PCサーバーの障害灯検査、ストレージデバイスアレイの健全性判定、ミニコンピュータLPARリソースの監視、オペレーティングシステムのマルチパス検査など、さまざまな監視シナリオに直面する必要があります。Zabbix は、SNMP、IMPI、SSH、エージェントなどの組み込みの監視方法を提供し、システムアーキテクチャの各層に適切に適合させることができ、エージェントはカスタムツールもサポートしており、全体的なパフォーマンスは非常に柔軟です。Webフロントエンド管理においては、クラスタ全体から単一監視項目まで細分化して管理できる様々な粒度の監視管理が可能で、カスタマイズされたダッシュボードや履歴データ可視化機能により、Webフロントエンド管理の見直しも大幅に容易になります。運用保守担当者によるデータの監視。上記の考慮事項に基づいて、業界は新しい監視プラットフォームのパイロットとして Zabbix を選択し、基本的なリソースの監視から始めて、まずストレージ、ホスト、オペレーティングシステムの大部分を Zabbix に引き継ぎました。

現在の使用状況
2017 年末にインフラストラクチャの範囲内で試験運用された Zabbix システムは、バージョン 3.2 から現在のバージョン 4.4 まで徐々に進化し、さまざまな監視システムでマイルストーンを経験しました。現在の Zabbix システムも、当初の小規模なトライアルから徐々にハードウェア、アプリケーション、プラットフォーム、ビジネスをカバーする幅広いシナリオに拡張され、アーキテクチャも単一のデータセンターから 3 つのセンターの分散展開へと進化しました。古い監視システムの順次リプレースに加え、自動運用保守基盤、継続リリース基盤、運用保守可視化基盤などのサードパーティシステムもZabbixに接続し始めています。インテリジェントな運用とメンテナンスの作業モードを実現します。

また、この記事を書く少し前に、アプリケーションシステム監視のZabbixプラットフォームへの移行も無事に完了し、Zabbixシステムの推進と導入、開発の自動化に携わった運用保守担当者として、これを目撃できたことは大変光栄です。ここでは、アーキテクチャの展開、監視ディメンション、自動化ソリューション、および運用管理の観点から、Zabbix システムの開発と成長における私たちの経験についても共有します。

ハードウェア監視
データセンターの運用保守管理では、最も基本的なハードウェア機器を含むシステムアーキテクチャの垂直方向の奥行きが非常に深く、運用保守担当者は点検やトラブルシューティングに時間を費やす必要があります。データセンター内の機器の数が爆発的に増加するにつれて、手動検査では現在の監視のリアルタイム性と信頼性の要件を満たすことができなくなります。この種の低レベルの監視では、Zabbix の多次元機能がこの問題をうまく解決し、内蔵の SNMP/IPMI プロトコルにより、関連するハードウェアデバイスの帯域外監視に簡単に接続できます。

現在、SNMP エージェントのパッシブ方式を使用して、障害信号、電源、メモリ情報、ディスクアレイなどのハードウェアデバイスの基本的な指標を定期的に検査しています。この装置はハードウェア情報を収集し、定期的に CMDB に更新します。たとえば、一部の Huawei RH2288 V3 IBMC 監視テンプレートで自動的に検出される構成は次のとおりです。

Zabbixでのハードウェア監視設定の操作手順も非常に便利で、ほとんどがWebインターフェース上で設定され、SNMPエージェント/トラップインターフェースやIPMIセンサーのターゲットポートを定義するだけで監視項目を柔軟に定義できます。IPMI 監視の設定では、主にセンサーの名前を入力します。現在、IPMI 帯域外監視は比較的少量しか使用していません。主に一部の Inspur PC サーバーで使用されています。帯域外管理VMware vSphereのDPMなど。
**ハードウェア監視用の監視プロトコルを選択する場合、守るべき原則の 1 つは、SNMP を使用できる場合は他のプロトコルは必要なく、SNMPv3 を使用できる場合は SNMPv2 は必要ないということです。**SNMP は Zabbix で非常に柔軟に自動検出を実現でき、SNMPv3 はより堅牢な認証メカニズムを提供できるため、ハードウェア監視を開始する際にはネットワークセキュリティリスクも考慮する必要があるためです。単一の SNMPv3 監視項目の構成は次のとおりで、ほとんどのパラメータには入力ウィンドウが用意されています。

前述の SNMP 設定の自動検出の柔軟性については、SNMP 設計の原理にも依存します。ツリー構造インデックス方式の助けを借りて、インデックスフィールドに従って既存の要素の数を列挙し、次の要素を列挙できます。要素は、layer 要素の数の長さに応じてトラバースできます。この種のトラバーサルのために、Zabbix 自体は、内部の共通の自動検出データ構造にシームレスに接続されて完了するためのフレンドリーな検出 [{#SNMPVALUE},OID] 関数を提供します。SNMP 自動検出メカニズム全体の原理は次のとおりです。Zabbix
の初期パイロットプロジェクトはインフラストラクチャの運用と保守から始まり、Zabbix は SNMP/IPMI プロトコルの設定に非常に便利であるため、多くの場合、MIB に基づいて行うことができます。製造元が提供するファイルおよび MIB ドキュメントを使用して、カスタマイズが必要な監視をフィルタリングして除外できるため、収集を減らすことで管理システムの負荷を軽減し、監視品質を最適化できます。たとえば、以下は、Lenovo XCC アウトオブバンド管理システムの MIB 記述に従ってカスタマイズおよび構成された ThinkSystem SR650 の SNMPv3 監視効果です (http://www.circitor.fr/Mibs/Html/L/LENOVO- XCC-MIB.php):

上図の電源、アレイ、ディスクなどはすべて自動検出ルールによって生成されており、アレイカード番号、ネットワークカード番号、チャネル番号が異なる XCC アウトオブバンドサーバーにも同じテンプレートを使用できます。デバイスの変更は Zabbix によって完全に保守されます。さらに、SNMP 監視プロセスのカスタマイズの経験を共有するには、まず MIB ファイルで監視する必要があるすべてのインジケータを収集し、フィルタリングされたインジケータをグループ化し、各グループの最上位の親インデックスの OID を見つけてから、snmpwalk を使用します。 Zabbix プロキシは、この OID を走査してすべての OID コンテンツを検索し、インデックスと詳細を区別し、定期監視と自動検出監視を分割し、最後に snmpget を使用して OID 値を 1 つずつ取得し、Zabbix 上で対応する値のタイプを決定します。snmpwalk はトラバーサルであり、OID の完全な値を必要としないのに対し、snmpget は完全な OID に基づいて取得されるという事実に特別な注意を払う必要があります。Zabbix に対応して、snmpwalk は自動検出に似ており、snmpget は通常の監視に似ています。アイテム。

ストレージの監視
データセンターでは、ストレージデバイスは非常に中核となる重要なインフラストラクチャであり、関連するアラームは運用および保守担当者に警告します。Zabbix のストレージ監視を推進する過程で、非常にやっかいな困難に気づきました。それは、ストレージは単なるハードウェアデバイスではなく、SNMP プロトコルではインバンドのパフォーマンス情報を取得できませんが、主流のオペレーティングシステムのように Zabbix エージェントをインストールすることはできません。データ収集に使用されます。この種の問題に対処するには、当社の蓄積された経験では、監視データを取得するには RESTful などの外部インターフェースが推奨されます。この条件がサポートされていない場合は、カスタム監視パッケージのメーカーが推奨するツールまたは方法を使用して、Zabbix Proxy サーバー上で監視します。

Zabbix エージェントは、O&M 担当者による監視のカスタマイズをサポートし、実行コマンドを Zabbix が呼び出すための Zabbix アイテムキーにカプセル化します。また、追加のセキュリティポリシーもサポートします。たとえば、AllowRoot は root にエージェントの実行を許可するかどうかを設定でき、UnsafeUserParameters パラメータはフィルタリングできます。特殊シンボルの挿入。カスタム構成の標準では、例として RedHat ベースラインを取り上げます。/etc/zabbix/zabbix_agentd.d ディレクトリ内の監視クラスは、ClassA_ClassB_Detail.conf という名前の conf ファイルの形式で保存され、定義された実行ファイルが配置されます。 /usr/local/zbxexec/ClassA/ClassB/xxxx.xx にあります。

監視項目のカスタマイズ方法としては、各種ストレージメーカーの製品監視方法と連携し、メーカーが提案する監視コマンドをZabbixの監視項目としてカプセル化すると便利です。このようなカプセル化された方法は主に CLI、RESTful、SSH であり、現在各製品で使用されている次の監視方法などがあります。
ここに画像の説明を挿入

メーカーとのコミュニケーションによるZabbix接続だけでなく、実はオープンソースのエコロジーやZabbixの共同推進も活用でき、多くの企業がZabbixの経験やテンプレート、ツールをZabbix Shareに共有し、検討の上利用できるようになります。。同時に、Zabbix は、DELL EMC が Zabbix 上で立ち上げた各製品の監視テンプレートなど、各メーカーの公式監視テンプレートを Zabbix 上で共同で立ち上げるために、他のメーカーと協力することに熱心に取り組んできました (https://www.zabbix) .com/integrations/emc)。

上記の監視方法により、運用環境のストレージデバイスに対するZabbixの監視効果は、運用保守担当者に非常に満足されており、エージェントレスアーキテクチャにより、重要なデバイスへの侵入を回避すると同時に、関連するストレージアラームをトリガーすることもできます。時間を短縮し、ストレージ管理者が問題や場所の理由を迅速に発見できるようにします。

ホスト監視
現在のホスト監視はPowerミニコンピュータやx86 ESXiが中心ですが、これらのオブジェクトは数や情報が固定されていないという非常にわかりやすい特徴があります。ミニコンピューターでは、新しくデプロイされたデータベースの物理パーティションまたは仮想パーティションを分割したり、特定のデータベースの CPU 割り当てを調整したりする必要がある場合があります。vSphere クラスターでは、ESXi ホストまたはリソースの数を拡張したり、新しいクラスターを作成したりする必要があります。このような変化する環境では、最初に考慮すべき点は、Zabbix の自動検出を使用して適応することです。このシナリオには非常に明らかな同様の機能があります。つまり、ホストリソースプール全体を管理するためにマスター制御端末が必要です。したがって、ホストの監視では、主制御端末を監視することによってホストを自動的に検出し、検出されたホストに対応するテンプレートを自動的に使用させるという原則がよく採用されます。

上記の監視処理は主にZabbixの自動登録ホストによって実現されており、ハードウェア監視で述べた自動登録監視項目とは異なり、ここでの自動登録はマスタから取得したリソースリストに基づいて直接監視対象ホストを自動登録します。 . 、ホスト名、表示名、エージェントインターフェイスなどを含む関連するホスト構成はマスターコントロールを継承し、ホストごとに事前構成された監視テンプレートをバインドします。制御側は、前回収集したリソースリストに特定のホストが含まれていないことを検出した場合、リソース保持ポリシーの時間が経過した後、そのホストを自動的に削除します。自動検出された ESXi ホストの例:

ここに画像の説明を挿入

OSの監視 OS
の監視は非常に多く、OSの種類が豊富なだけでなく、OSごとの監視項目の数も多岐にわたり、物理マシンと仮想マシンの数を掛け合わせると、全体の監視が可能になります。面積は非常に大きくなります。また、各サーバーをZabbixにホストする作業は非常に煩雑になりました。この点に関して、私たちのアイデアは、サーバーが自動化された手段を通じて自動的に Zabbix にレポートできるようにし、テンプレートを最適化して繰り返しの監視を減らし、トリガーの依存関係をカスタマイズすることです。

オペレーティングシステムの監視は、Zabbix エージェントソリューションを使用して実装されており、Zabbix はさまざまなオペレーティングシステム用のエージェントも起動しており、コンパイルせずに直接実行できます。この点に関して、すべての仮想マシンベースライン、ミニコンピューターバックアップ、および物理マシンの Ansible デプロイメントスクリプトでは、オペレーティングシステムに対応するエージェントのインストールと構成が事前に準備されます。このうち、パッシブ方式を使用し、主にエージェント設定の以下の内容を変更することをお勧めします。

# ...
# 众多 Zabbix Proxy 中的两个
ServerActive = 10.10.32.1,10.10.32.2
# 其中 10.10.32.0/24 为当前机房的 Zabbix Proxy 节点网段
Server = 127.0.0.1,10.10.32.0/24
# Hostname 是这台服务器的管理 IP
Hostname = 10.10.33.1

この構成は主に、複数のプロキシ間でのエージェントの変換を容易にするためのもので、障害回復や Zabbix アップグレードなどのシナリオでエージェントの継続的な有効性を確保するのに非常に便利です。さらに、ローカルループバックアドレスもサーバーに書き込まれるため、後でこのオペレーティングシステムのエージェントを通じてローカルスクリプトを呼び出す必要があります。パッシブモードではホスト名は必要ありません。構成管理 IP により、アクティブモードと構成管理の利便性が確保されます。

上記はあくまでエージェントの設定基準であり、Zabbix への自動報告が必要な場合は別途手順が必要となります。現在、物理マシンおよび仮想マシンのx86オペレーティングシステムのホストを自動レポートする仕組みを実装しており、毎日午前8時にレポートが行われ、その後、新しいホストが自動的にメンテナンスモードに追加され、リスクを回避します。導入段階でのさまざまな非クリティカルな例外アラームストームが発生し、システムが安定するまでメンテナンスモードは終了しません。物理マシンの展開では、自動化された RAID 構成および PXE インストールシステムの完全なセットに加えて、オペレーティングシステム構成ベースライン用の Ansible ソリューションも用意されています。各オペレーティングシステムの役割には、Zabbix エージェントのインストールとレポートがあります。 .タスクを実行して、構成された適切な変数を実装することで、このホストを標準の名前で Zabbix に追加できるようにします。多数の仮想マシンについて、各コンピュータルームの vCenter で仮想マシンをスキャンして仮想マシンの日次差異を取得し、CMDB 内のその属性と vCenter のコメントを使用する一連の Python スクリプトを作成しました。ビジネスシステム、アプリケーションクラスター、サーバーの説明などを入力し、最後に Zabbix に登録します。このメカニズムにより、運用保守担当者が新しいシステムのホストの監視と登録から大幅に解放されるだけでなく、さまざまな追加の期待目標を達成するための管理戦略がスクリプト内で指定されます。

· ネットワークセグメント情報に従って、コンピュータルーム内のトラフィックの交差を避けるために、同じコンピュータルームのサーバーインターフェースを同じコンピュータルームのプロキシに接続します。

・Zabbix上で各Proxyのvpsを判定し、低負荷で新規ホストをProxyに接続します。

・登録ホストのタグと資産情報にCMDBの既存情報を記入します。

そのアーキテクチャのトポロジは次のように単純化されます。

この自動メカニズムにより、運用保守担当者による構成の監視に対する嫌悪感が大幅に軽減され、CMDB との関連付けも追加され、将来の作業指示システムのアーキテクチャ基盤が確立されます。しかし、監視システムの分析と調査はこれで終わりではなく、オペレーティングシステム監視のトリガーによって多数のアラームが発生することを考慮して、広範すぎるアラームの発生を回避するための追加の対策も検討しました。
まず、テンプレートを基本クラスのテンプレートとしてカテゴリごとに細分化し、アプリケーションのシナリオに応じて、上位レベルのテンプレートがどの基本クラスで構成されるかを指定します。これにより、類似したクラスの監視によって引き起こされる繰り返し監視が回避されます。カスタマイズされたテンプレートの機能が多すぎます。次に、各テンプレートのトリガーに厳密な依存関係を指定して、アラームの同時トリガーによって引き起こされる嵐を回避します。たとえば、Linux システムのパーティション容量監視トリガーの場合、いくつかのウォーターマーク間の依存関係を定式化しました。

データベースの監視
データベースの監視も運用保守担当者にとって非常に重要な項目であり、通常のテーブルスペース使用量、セッション数、SGA使用量、ASM使用量、キャッシュヒット、クリーニング頻度などのステータスチェックも行われます。ダウンタイムとスイッチングとして。近年の分散データベースの導入や国内データベースの試行も相まって、Zabbixとの接続が必要なデータベース製品が増えています。現在、当社のデータベース監視では、さまざまな監視アイデアを組み合わせ、さまざまなデータベース製品の監視指標を策定しており、パフォーマンスデータのトレーサビリティや障害アラームのシナリオで優れたパフォーマンスを示しています。

金融業界の従来のアーキテクチャでは、Oracle データベースが不可欠なベースであることが多く、テンプレートのカスタマイズを通じて、Sinlge-Instance、RAC、DG、F5 などのさまざまなアーキテクチャ用のテンプレートを提供し、Oracle DBA の懸念事項のほとんどをカバーします。アイテム。高性能プロキシは、カスタム監視を通じて Oracle 監視スクリプトを実行するために、Zabbix で特別に使用されます。緊急障害アラームに加えて、Zabbix は現在、DBA がデータベースのパフォーマンスを分析し、履歴データを比較してデータベースの問題をトラブルシューティングするためのツールとなっています。これは、Zabbix によって保存された大量の監視情報にも依存しています。以下に、データベースのパフォーマンスと RAC の監視指標の一部を示します。

従来のアーキテクチャのデータベースに加えて、他のデータベース製品の包括的な監視も提供します。この監視にはルートサービス (RootService) のアイデアを採用し、データベースをより自動的に監視に組み込みます。この方法の利点は、Zabbix の自動ホスト登録のメカニズムを完全に実証し、データベースを監視に追加し、自動登録監視プロトタイプを使用して監視する必要があるデータベースの詳細を特定できることです。現在、OceanBase、Sequoia Database、MySQL、DRDS、その他のデータベース製品の監視スクリプトを作成し、新しいデータベース監視アーキテクチャを使用して Zabbix で自己管理を実行しています。このフレームワークのワークフローは次のとおりです。

MySQL 監視を例として、プロセス全体を詳細に説明します。以下の図を参照してください。

MySQL インスタンスの構成 zbx_mysql.py ファイルに、testenv_zabbix データベースインスタンスを追加します。このファイルは、acl 設定を介して zabbix ユーザーによってのみ読み取られます。MySQL RootService としてのホストが自動検出ホスト監視を実行すると、新しく追加されたインスタンス構成により Zabbix 自動検出 JSON ルールが生成され、構成情報に従って監視インスタンスが作成され、さらに MySQL 基本テンプレートが使用されます。MySQL 基本テンプレートでは、一連の特別な監視自動検出ルールが設定されています。たとえば、Discovery MySQL Replication Enable は、検出されたインスタンスで show smile status コマンドを実行しますが、MySQL RootService のスクリプトはここでも呼び出されます。ターゲットインスタンスがマスター/スレーブを有効にしていることが判明した場合、自動検出によって返される josn に {#REPLICATION}: “enabled” フィールドが含まれ、マスター/スレーブレプリケーション監視項目が有効になります。

メインの制御サービスとして論理ホストを作成し、チェーン分岐伝播モードでホストを自動登録し、テンプレートの自動検出に基づいて追加の監視構成の追加が必要かどうかを判断するという、今回の監視方式です。優れた結果により監視システムがよりインテリジェントになり、データベース監視のように接続ユーザーとパスワードを Zabbix マクロに書き込む必要はありませんが、読み取られる設定ファイルが ACL 上で最小であることを確認するだけです。ファイルシステムのアクセス許可が十分であるため、データベースのアクセスセキュリティが向上します。もう 1 つのポイントは、現在多くの分散データベースが制御 + コンピューティング + ストレージのアーキテクチャを採用していることです。たとえば、TiDB の PD はメタデータ管理を担当し、DB は SQL 分析と計算を担当し、KV は基礎となるキーと値のペアのストレージを担当します。コピーに関係なく、最も効果的な監視方法は、その制御コンポーネントに直接接続し、Zabbix マスター制御サービスの開始点をデータベースクラスターの制御にマッピングし、アーキテクチャを継続的に階層化することです。各コンポーネント間の監視項目を自動検出ルールに固定化し、正確かつ効果的な監視範囲を実現します。現在の OceanBase 分散データベース監視を例にとると、OB ゾーン、OB テナント、OB サーバー、OB パーティションなどの監視の詳細は、次のように OB RootService から自動的に配信されます。

監視アーキテクチャの継続的な柔軟性に加えて、より詳細な監視効果も考慮しています。データベースの監視とトラブルシューティングでは、DBA は、関連するすべてのアラームが同じ時点にあり、水平方向の参照に便利であることを望んでいます。この出発点に基づいて、運用および保守担当者は「スナップショットの監視」というアイデアを使用して、できるだけ多くの監視項目を同じ時点に集中させます。これにより、監視時の頻繁な対話によって引き起こされるパフォーマンスの損失も大幅に削減できます。データベース。これは主に、Zabbix 監視項目のカスタムスクリプト仕様と関連するプロジェクトの依存関係機能を利用して実現されます。Jushan データベースの監視を例にとると、対話の頻度を減らすことの重要性は、Jushan データベースのスナップショットアクションには一定のパフォーマンスの消費があるという事実によって説明できます。

このテスト環境の Sequoia データベースクラスターの Coord ホストには、合計 56 個の監視項目があります。各監視項目を調整ノードの 1 つに個別に接続し、対応する監視インジケーターを取得するためにスナップショットを作成する必要がある場合、クラスターはこのような頻繁なスナップショットに応答しないため、この操作により非常に大きなパフォーマンスコストが発生します。しかし、実際には、実際の監視項目は 3 つだけであり、スクリーンショットの multi_snapshot_SDB_SNAP_* で始まり、残りはこれら 3 つの監視項目から派生しています。つまり、インタラクションの数は 56 から 3 に削減できることになります。このスキームの実装では、カスタムスクリプトまたは LDD マクロを通じて各サブ監視項目を含む JSON を生成し、履歴レコードを保存しないように設定します。サブ監視項目は親監視で生成されるため、これは非常に重要です。また、アイテムがダンプされる前に分割され計算される大量の冗長な JSON 文字列を保存することも無意味です。副監視項目の生成では主にZabbix監視項目の前処理操作を利用し、JSONPathを用いて対応するK/Vを抽出し、倍数/秒間変化/正則化により最終的な副監視値を取得します。前処理によって Zabbix の CPU が消費されますが、StartPreprocessors パラメータを増やしても CPU は大幅に増加することはなく、Zabbix プロキシは分散型でスケーラブルであり、このボトルネックも拡張によって非常に簡単に解決できます。包括的な評価の後、このソリューションによってもたらされる利益はかなり大きくなります。データベースの問題が発生すると、おそらくより多くの DBA が監視履歴を振り返りたいと考えます。そこで確認できるのは、次のような同じ時間平面上の指標です。

アプリケーションの
監視監視の考慮事項がアプリケーションコンポーネントにまで及ぶ場合でも、私たちは依然として自動化された方法を使用して目まぐるしい監視要件に対処し、アプリケーションの監視をより重要なものにする方法を検討し、過去に Nagios を使用した際のアプリケーションの監視も分析することを主張しています。直面した問題点を解決するには、最終的にはアプリケーションの監視ライフサイクルを引き継ぐフレームワークレベルのツールを作成します。このフレームワークは内部的には zbx_app と呼ばれ、ファイルサーバーとアプリケーション監視ガイドラインを通じて実行され、カスタムスクリプトのプル、バージョンの反復、監視項目の自動登録などを自動的に完了できます。運用保守担当者はアプリケーション監視宣言ファイルを作成するだけで済みます。、他の作業は完全にフレームワークによって実行されます。

このフレームワークの内部原理は主に、構成を更新する信号として Zabbix を通じて特定の監視項目と自動検出を送信し、基本環境を自動的にチェックすることであり、ファイルサーバーの関連モジュールバージョンが更新されたことが判明した場合は、積極的に更新されます。ファイルをプルして自己管理操作を実現します。特定のシグナルを受信し、独自の環境を管理するこのモジュールは、内部的には基本クラスと呼ばれます。すべてのモジュール監視には、基本クラスと対話するための自動検出ルールがあります。基本クラス宣言ファイルに要求された自動検出モジュールが含まれている場合、応答します。、Zabbix が返された結果を認識して使用し、このモジュールの監視項目を生成します。対応する監視項目が生成された後、各監視項目はスナップショット方式を使用して監視対象を一度キャプチャし、その後、監視関連項目が同じ時点で各サブ項目を分割します。この呼び出し段階では、基本クラスとも対話しますが、基本クラスは、そのモジュール名に従って、同期されたモジュールメソッドの固定インターフェイスを呼び出します。これらのインターフェイスは、そのようなモジュールを作成するための開発ガイドラインであり、その目的は、基本クラスがスムーズに呼び出され、解析できることを確認します。

考慮対象を 1 つのホストに限定してプロセスを簡略化すると、上から下に時間の進行方向を示す次のようなタイムラインが得られます。

Zabbix プロキシは Discovery APP を呼び出して自動的に検出し、ホストが現在の zbx_app 基本クラスを 1 回初期化するようにトリガーします。また、基本クラスはシグナルの受信後に環境をスキャンし、主に各ディレクトリ内のステートメントファイル (lps.cfg) を収集します。、ステートメントファイルに従って実行します。基本的な環境設定をプルし、Zabbix プロキシ関連の情報を返します。

Zabbix プロキシは基本クラスを受信して有効になり、他のモジュールの自動検出がホストの検出に続いて、独自の自動検出信号を送信します。

基本クラスが宣言ファイル内に redis モジュール宣言があることを検出すると、内部情報が自動検出の戻り構造に統合され、Zabbix プロキシがそれを感知して対応する監視項目を生成します。

Redis モジュールは引き続き監視スナップショットリクエストを基本クラスに送信し、基本クラスは HTTPFileServer から取得された Redis モジュールを呼び出して監視リクエストを実行し、結果セットを返します。

アプリケーションのメンテナがプロセス中に URL モジュールの監視要件を宣言ファイルに書き込むと、次回 Discovery APP シグナルを受信したときに、基本クラスが新しい宣言を見つけて、すぐに HTTPFileServer に移動して、指定されたバージョンの宣言ファイルを取得します。 URL監視モジュール。後続の URL の監視は、宣言ファイルが削除されるかモジュールにアノテーションが付けられるまで、Redis と同様に引き続き有効になります。

自動化開発者がプロセス中にバージョンライブラリ内の Redis モジュールのコードを更新した場合、基本クラスは次回 Discovery APP シグナルを受信した後、MD5 列も比較してバージョン更新を見つけ、それを取得して置き換えます。最新バージョン。

自己管理基本クラスは、アプリケーション監視の閉ループ管理を実現するために使用され、監視操作に関して、自動化開発者の開発モジュールの機能が細分化され、アプリケーション保守担当者がより自由に宣言できるようになります。必要なアプリケーションの監視。さらに、基底クラスの動作も監視項目に含まれるため、基底クラス自体の安定性を確保できるため、ストライキ後は誰にも分からなくなります。
このフレームワークにより、アプリケーション監視を前世代のNagiosシステムからZabbixシステムへ移行することに成功し、保守コストの低減と動作モードの安定化が実現しました。

ビジネス監視
強力なアプリケーション監視フレームワークのサポートにより、運用保守担当者も上位レベルのビジネス監視に注意を払うようになり、ビジネスの特性はアーキテクチャ全体の安定稼働を最も端的に表します。Zabbix はデータベース監視を提供し、Web インターフェイス上で SQL ステートメントを直接書き込み、プロキシ/サーバーが unixodbc 経由で対応するドライバーをロードしてターゲットデータベースに接続し、最終的に実行結果を返します。現在、この方法を使用して、業務ステータス情報、トランザクションの成功率、機器の起動、バッチの実行などのデータベースをクエリし、Zabbix のアラームチャネルを通じて、この業務システムを契約している技術者にアラーム情報を送信します。銀行全体で。Webインターフェース上で直接SQLを記述することで業務クエリの変動に対応でき、監視対象業務にサブシステムを追加した場合、カスタムスクリプトを変更することなく監視項目に新規テーブルを接続するだけで済みます。さらに、この方法により、カスタムスクリプトのメンテナンスコストを削減できます。ODBC には、さまざまなデータベースドライバーが用意されています。Web ページでは、最下層のすべてがパッケージ化されています。接続の初期化方法、作成方法を考慮する必要はありません。カーソルやセッションの解放方法など。各業務の監視データを取得した後は、Zabbixのダッシュボードとスムーズに連携し、業務ごとに監視パネルを作成し、大画面表示の効果を発揮します。

実際には、この便利な監視方法では、いくつかの点に特別な注意を払う必要があります。

ファイルシステム上の odbc 接続構成ファイル odbc.ini の権限を減らし、zabbix ユーザーのみがアクセスできるようにし、特別なユーザーがファイルを変更できるようにします。

SQL 記述ルールを標準化し、実行コストの高いステートメントを許可しないようにするため、DBA との良好なコミュニケーションも必要になります。

可能な限り、結果セットが 1 行、または 1 行と 1 列を返すようにします。

データ計算操作を Zabbix 前処理に割り当て、あまりにも多くの計算操作をデータベースレベルにプッシュすることはできません。

上で説明したさまざまな監視次元の観点
から、ハードウェア監視からビジネス監視まで、運用と保守の垂直座標上で、最下位層から最上位層までのあらゆる側面の監視カバレッジを実現し、複数の層で監視を確実にします。システムは問題や障害を迅速に発見し、正確なアラームを送信できます。しかし、運用保守担当者のモニタリングに関する思考はまだ終わっておらず、そのモニタリングポイントが縦軸上に移動するだけでなく、「将来」の時点に進むのに十分であるかどうかという問題について考えます。たとえば、障害が発生するのは、ユーザーがトランザクションを実行するためにシステムにログインした後だけではなく、トランザクションの前提条件を定期的に検出するために監視対象データが生成されるためです。トランザクションを実行すると、Zabbix はトランザクションページで必要なリソースが利用可能かどうかを検出します。このようにして、一部の取引プラットフォームのページ異常が実際の顧客よりも早く発見されることが保証され、「予測」の効果が論理的に実現されます。また、複数のオペレータ回線を利用してページ監視を行うことで、より包括的に顧客事例をカバーすることができ、異常が発見された場合には、CDNやブラックリストなどのオペレータネットワークに問題がないかを他の回線と比較することも可能です。

Zabbix Webの監視手法を利用し、ファイアウォールとNATによるネットワーク分離を実現し、Squidを利用した回線選択を実現し、Seleniumなどの自動化ツールを利用してページアクションをシミュレートし、社内外のネットワークとオペレータ回線の監視を実現します。オンラインバンキングシステムのレベル。

プラットフォーム監視には、上記の監視に加えて、運用保守担当者にとって回避が難しい特殊なシナリオがあります。つまり、一部のシステムには監視プラットフォームが付属していますが、現在使用されている主流の監視では互換性がなく、置き換えることもできません。この問題は、コンポーネントが導入され、製品が徐々に増加するにつれてより顕著になります。例えば、モバイル開発プラットフォーム mPaaS には、mPaaS プラットフォーム全体の運用において非常に重要な役割を担う、monitorkernel、corewatch、monitorguard などの監視コンポーネントが付属していますが、他の監視システムへの置き換えを検討するとコストがかかります。技術的な適応は膨大なものとなり、プラットフォーム自体の安定性も失われます。この点で、私たちは独自に構築した外部チャネルと Zabbix Sender を使用して、監視フローの形式で Zabbix に接続する外部プラットフォームを実現することにしました。これにより、元のサードパーティ監視システムの侵入を回避できるだけでなく、監視データを Zabbix に収束できるようにします。
まず最初に、Zabbix Sender の原理について説明します。監視対象ホストがZabbixでアクティブモード（ほとんどのホストはパッシブモード）の場合、ホストは既存の監視項目データを構築してZabbixに送信することができ、Zabbixはホストの監視項目データとしても機能します。リアルタイムモニタリング。ドッキングホストの上流がサードパーティの監視プラットフォームである場合、プロセス全体は、上流から Zabbix に継続的に流れる動的なデータフローのように見えます。アップストリームのサードパーティプラットフォームの実装については、現在次のソリューションがあります。

· 外部プラットフォームが HTTP RESTful モニタリング接続をサポートしている場合は、そのようなアラームの受信を特に担当する HTTP サーバーに接続し、そのプラットフォームに対して独立したリソースパスハンドラーを設定します。

· 外部プラットフォームがモニタリングドッキングをサポートしていないが、アラームプッシュをサポートしている場合、受け入れられるアラームレベルを最小値または最大量に調整し、HTTP サーバー、TCP/UDP サーバー、またはメールサーバーに送信できます。

· 外部プラットフォームに情報を送信するチャネルがない場合、Web クローラーやデータベース監視などの方法が選択されますが、これも監視フローの特徴を失います。

現状では、3 番目の状況はほとんどありません。一般的に、HTTP 外挿監視またはアラームが提供されるため、このタイプは Golang で書かれた専用の HTTP サーバーに接続されます。ドッキングプラットフォームを追加するたびに、OtherReader を追加するだけです。および ZBXSender インターフェイスは対応するハンドラーに実装されます。ただし、この方法のトリガーでは、同じ監視項目をプッシュする頻度が非常に高くなる場合があるため、change()/diff() 関数の依存関係に注意する必要があることに注意してください。
前述の mPaaS を例に挙げると、この方法でコア監視プラットフォーム corewathc とドッキングすることで、このプラットフォームのすべてのアラーム監視を取得できます。

アラーム通知
監視対象範囲のトピックはここで終了です。次のリンクとして、監視によってトリガーされたアラームを、アラームを受信する必要がある技術担当者にプッシュする方法について説明します。実際、Zabbix 自体も非常に多様なアラームプッシュチャネルを提供しており、アラームコンテンツを処理してチャネルにプッシュするスクリプトをカスタマイズすることもできます。ただし、アラームがより多くの役割を果たすことができるように、プッシュチャネルを少し長くすることにしました。
アラームを押せなければ監視の意味は半減しますが、押しすぎればアラームの価値は全くありません。Zabbix のアラームメッセージ構造は単なる文字列であり、いくつかの特殊記号が混合されていると後続のシリアル化アクションで例外がトリガーされるか、アラームを送信するプロキシがダウンしているにもかかわらず、大量のアラームを送信できません。これによって引き起こされるあらゆる種類のトラブル、おそらく警報器に触れたことのあるすべての技術者は深く感動するでしょう。こうしたラスト100メートルの問題を解決するために、私たちは常にさまざまな方法を試し、突破口を探し続けています。
私たちは、Zabbix アラーム文字列に従って JSON 解析を実行できる Zabbxi Robot という内部ツールを作成しました。前処理の後、アラームを抑制する必要があるかどうか、収束する必要があるジッターであるかどうかを判断します。 then put アラームが下流にプッシュされます。さらに、Zabbix のアーキテクチャ設計では、メインアラームのプッシュを担当するプロキシとサーバーが相互に監視するように構成されており、サーバーにはメインチャネルに障害が発生したときに通知する 2 つのプッシュチャネルがあり、それによってブランクアラームが回避されます。

ここでのショートメッセージ猫は、gnokiiを利用してシリアルインターフェースを呼び出してショートメッセージの送信を実現していますが、送信効率は非常に低く、Zabbixアーキテクチャに重大な障害が検出された場合にのみ、複数の運用保守員に送信することになります。システムの監視を担当します。バックアップチャネルとメインドライバーの実装メソッドは両方とも、curl POST の形式でアラーム情報を Zabbix Robot に送信します。違いは、両者が異なるヘッダーを使用して Zabbix Robot 内の特定のチャネルを区別し、フィルタリングすることです。Zabbix Robot は Golang を使用して当社が開発した HTTP サーバーで、現在 2 つのモジュールがあり、抑制モジュールが最初にトリガーされ、収束モジュールが後でトリガーされます。ここでの抑制操作は、LimitUnitGroup を使用して有効になります。現在のトリガー条件は、各グループのトリプレット ({フラグ、番号、秒}) を満たします。フラグを使用して InhibitionUnit のゴルーチンを導出し、フラグが InhibitionUnit に存在する場合は、それが実行されます。抑止状態と判断され、送出されません。
InhibitionUnit も 3 値 ({フラグ, 数値, 秒}) であり、フラグのアラームと判定された場合は、数値を受信するか、秒秒を超えると抑制を解除します。Zabbix-Robot の設定ファイルでは、各フラグとその属性が細分化されています。一般的に、現在一般的に使用されているフラグは、Zabbix の TRIGGER.SEVERITY、つまりアラームレベルです。
コンバージェンスモジュールは現在テスト段階にある機能で、最初にアラームと過去 30 分間 (調整可能) から受信したサンプルのホスト ID X+itemidを判断する Weights メソッドを実装します。Y+triggerid*Zの合計スコアが所定値Kを超えた場合はジッターと判定し収束します。ここでの X/Y/Z はカスタマイズ可能な重みです。たとえば、X を大きくして収束重みをホストに近づけると、同じホストから送信されたアラームの数が最初に収束します。さらに、文字列特徴や機械学習などの他の収束手法もあり、これらも私たちが試みている方向です。
抑制と収束が完了すると、アラームは当社の自動化プラットフォームに流れ、プラットフォームが作業指示を導き出すかどうかを判断し、サブスクリプションシステムを通じて指定された担当者にアラームを送信し、担当者は作業指示システムの処理ステータスをフィードバックします。ここでのサブスクリプションシステムは、Zabbix の一部のメタデータにも接続されています. Zabbix 4.0 以降で開始されたタグ機能 (タグ) は、アラームのスクリーニングに非常に便利です. K8S を使用したことがある場合、このスクリーニングプロセスはラベルとセレクターとして理解できます。

現在のアラームプッシュプロセスにより、元の問題のほとんどが解決され、Zabbix が作業指示システムとサブスクリプションシステムに強力なサポートを提供できるようになり、将来的にはデュアルノードを展開して高可用性を実現できるようになります。

レポートの生成
Zabbix にさらに多くのレポート表示機能を提供できるようにするために、一般的に使用されるいくつかのレポートを Zabbix に接続するようにフロントエンドもカスタマイズしました。同時に、Zabbix はアセットリスト、カスタムトポロジ、ダッシュボード、その他の機能も提供し、特定のレポート生成機能も備えています。
上で説明したページ監視は、実際には内部ネットワークと外部ネットワークのフロートポロジであり、あらゆるレベルのページを前後に接続できるため、優れた問題位置特定機能を提供できます。

さらに、毎日更新される容量リスト、ハードウェア情報、検査レポートなどもあります。VMwareの仮想マシン相互排他チェックを例に挙げると、各業務システムのアプリケーションモジュールをツリー図で表示し、冗長ノードが間違ったリソース（ESXi、LUN、クラスタ）に導入されているかどうかを判定します。このようにして、仮想マシン管理者にとって、関連する仮想マシンを分離し、HA 発生時に影響を受けるシステムモジュールを削減し、同じ都市内でのディザスタリカバリの構築が期待どおりであることを確認するのに便利です。

高可用性
5.0 より前には、公式の Zabbix 高可用性ソリューションは存在せず、データベースレベルの回復ソリューションを使用していました。タイミングスクリプトを使用して、毎朝 (ここでハウスキーピングをできるだけ時間差で実行する必要があることに注意してください)、Zabbix 内の履歴* を除くテーブルと zabbix Web フロントエンドファイルを災害復旧コンピュータルームにバックアップします。回復不可能な障害が発生した場合は、Zabbix Server を再デプロイしてデータベースを復元できますが、履歴データや傾向は失われますが、監視操作のステータスを迅速に復元できます。
さらに、プロキシに障害が発生したときに他のプロキシにすぐに移動できるように、Zabbix エージェントのパッシブモードのサーバーアドレスをプロキシのネットワークセグメントとして構成することをお勧めします。

今後の計画
Zabbixを導入してから2年が経ち、運用保守も完全に自動化され始めており、その中で監視の価値をますます認識しており、監視は単なる警報放送ではなく、より高度なインテリジェンスが必要となります。モニタリングの可能性を活用します。この 2 年間で、Zabbix システムの機能をさまざまな面で拡張してきましたが、今後のさらなる発展が期待されます。さて、今後の計画、カウントダウンですが、以下の点があります。

Zabbix データベースの選択
現在運用環境で使用されている Zabbix データベースアーキテクチャは、Zabbix 4.4 + Percona 8.0 + OkuDB です。TokuDB は主に履歴* テーブルに使用され、履歴* テーブルはパーティション化されていますが、他の構成テーブルは引き続き Innodb、TokuDB を使用します。 QUICKLZ を使用します。圧縮アルゴリズム。また、データベースの構成も最適化されており、例えば2倍1など性能コストがかかる設定はすべて性能重視の設定に変更されています。このアーキテクチャに移行した当初は履歴データの圧縮率やQPSが大幅に向上しましたが、監視項目の増加に伴い徐々にボトルネックやプレッシャーを感じるようになりました。ヒストリカルデータを圧縮しても上昇傾向を抑えることはできず、ハウスキーパー有効化後に毎回期限切れデータを削除することで発生するCPU iowaitも煩わしく、大量のコールドヒストリカルデータをクエリする場合には読み込み時間が長くなり、もクラッシュします。
テスト環境の Zabbix プラットフォームは、運用環境の数倍のホストを管理します。これは、実際のストレステストシナリオとみなすことができます。ベストプラクティスを見つけるために、TokuDB、RocksDB、TiDB、Elasticsearch、TimescaleDB などのデータベース製品をテスト環境でテストしました。その中で、Zabbix 4.8 バージョンをベースに TiDB 3.0 と互換性のあるバージョンを若干変更しました (https ://github.com /AcidGo/zabbix_tidb)、残念ながら、TiDB の外部キーのサポートは期待を満たしていませんが、歴史的なライブラリをアーカイブするには良い選択かもしれません。テストの結果、Zabbix 5.0 + PostgreSQL TimescaleDB 12 が理想的な効果を発揮することがわかり、時系列データベースソリューションとして、履歴* テーブルの追加および範囲検索のアプリケーションシナリオに非常に適しており、圧縮もサポートしています。現在使用されているTokuDBソリューションとの全体的な比較は優れています。さらに、アーカイブされた履歴データとしてデータベースを使用し、より高い圧縮率を有効にし、個別のウォームデータにアクセスするために読み取り専用の Zabbix サーバーを導入することも検討します。

Oracle データベースの監視変換は
、MySQL やその他の軽量データベースとは異なります。Oracle 接続には、巨大な外部ドライバーだけでなく、F5 アーキテクチャでのパス選択、さらに膨大な監視項目など、膨大なコストが必要です。一部のモニターは、多くの場合、混雑しているように見えます。タスクキュー。現在、アプリケーション監視の変革が実現しており、MySQL、OceanBase、Jushanデータベースなどの監視もより軽量かつ自動化されたソリューションに置き換えられており、Oracleデータベースの監視手法の変革も計画されています。1 つ目は、各ライブラリの接続セッションを管理する接続プールミドルウェアを作成することで、Zabbix Agent がデータベースを検出すると、RPC 経由でミドルウェアを呼び出し、結果を返すため、セッションの作成と破棄のオーバーヘッドが削減されます。次に、できるだけ多くのバッチデータを取得するクエリを計画します。たとえば、Zabbix の監視項目関連項目と前処理を利用して、すべてのテーブルの現在のテーブルスペース使用量を一度に取得して、ある時点で複数の監視を取得します。により、RPC 呼び出しの頻度が減少します。

アラームの自己修復
現在、当社の自動化は目覚ましい成果を上げています。自動化ツールライブラリは、処理操作のためのさまざまなソリューションを提供します。将来的には、低レベルのアラームがこの強力な自動化機能を使用して、自動回復メカニズムを実現できるようになると期待しています。。

ネストされたホストの自動検出
一部の連鎖アーキテクチャシナリオでは、Zabbix の自動ホスト検出機能の助けを借りて、アーキテクチャ層に沿って継続的に分岐して、新しいホストまたはホストグループ (Sequoia データベースのドメインなど) を導出できることを強く望んでいます。 > データベース -> CollectionSpace -> コレクションチェーン検出メカニズム。ただし、実際のテストでは、ホストの自動検出機能は 1 回しかトリガーできず、次の層の自動検出では選択したテンプレートが失われます。関連する問題は、Zabbix フォーラム (https://www.zabbix.com/forum/zabbix-help/404802-how-to-nesting-automatically-discovers-hosts-did-i-encounter-a-bug) でも報告されています。。私たちは、アーキテクチャのコンテキストを拡張するこの方法で、あらゆるレベルでのホスト監視の作成を実現できる、同様の柔軟なソリューションが将来登場することを期待しています。

コンテナプラットフォームと分散アプリケーション監視
近年、コンテナの開発は飛躍的に進み、さまざまなオーケストレーションプラットフォームが次々に登場し、SwarmからKubernetesに至るまで、コンテナ監視も徐々に進化しています。Zabbix は 4.0 以降の Prometheus データ収集をサポートしており、コンテナ監視にしっかりと取り組んでいます。LDD マクロと組み合わせることで、より柔軟に JSON 形式に接続できます。将来的には、この 2 つを組み合わせて、自動化されたコンテナレベルのインテリジェントなデータ収集を実現することもできます。モニタリング。

他の運用保守ツールを作成した経験から、Golang は、強力な同時実行機能、静的言語の安定性と信頼性、学習コストの低さにより、運用保守管理用のバイナリツールの開発に非常に適しています。すべてがツールの品質を向上させ、大幅に改善されました。Zabbixが最近提供を開始したagent2もGolangによって開発されており、運用保守担当者が最適なZabbix Agentをカスタマイズできるようにインターフェース仕様が提供されています。この点についてもテスト環境で検討し、開発プロセスを徐々に理解していき、近い将来本番環境のZabbixが5.0にバージョンアップした際には強力なagent2を推進していきたいと考えています。

Zabbixシステムの推進、支援ツールの開発、監視の依存関係の細分化、旧監視システムからの移行の推進は、すべて過去2年間で蓄積してきた多くの運用保守担当者の成果です。運営・保守関係者の皆様のご尽力に心より感謝するとともに、今後計画されている監視システムのビジョンの実現に確信を持っております。