当社では、DevOpsツールの実装と当社での実践に関する一連の出版物を継続しています。 最近、 ニューラルネットワークとファジーロジックを使用して脆弱性を分析する方法について説明しました。今日は、Zabbixモニタリングシステムを開発およびテストプロセスに導入することについて説明します。
一般的なテストの問題
DevOpsプラクティスの実装を通じて解決したかった重大な問題の1つは、ITシステムを監視する組織でした。 それ以前は、積極的に実装されていませんでした。 これは多くの困難をもたらしました。 たとえば、目的のマシンのディスクがスペースを使い果たし、サービスとアプリケーションの中断によって問題が通知されたという通知に遅れることがありました。 これらはすべて、開発およびテストプロセスにとって深刻な問題です。そのようなエラーにより、製品が不安定になり、バグを見つけるのが難しくなるためです。
製品をテストする場合、ログ、サーバー負荷、内部および外部サービスの可用性など、多くの指標を分析する必要があります。 さらに、バージョンごとに、観察されるパラメーターのリストは異なる場合があります。
これらすべての問題を解決するために、Zabbix監視システムを開発およびテストプロセスに統合することにしました。 これがどのように行われたか、そして最終的に何が起こったかです。
Zabbixの実装方法
一般に、監視システムは機能とタイプによって分けられます。 機能分離は次のように説明できます。
- 状況の監視-重大なイベントとエラーの通知（従来の状況「2泊のSMS」）。
- 傾向の監視-詳細な分析のために情報が収集されます。
- パフォーマンスの監視-システムパフォーマンスの追跡。
タイプ別の監視は次のように分類されます。
- システム監視-OSおよびシステムサービスの状態を分析します。
- アプリケーション監視-アプリケーション内に実装されます。
- ビジネスメトリック-アプリケーション内に実装されます。
使用するメカニズムにより、これらすべての機能を「閉じ」、システム監視を完全に実行し、アプリケーション監視を部分的に実行できます。
テストプロセスを最適化するために、DevOpsチーム、開発者、テスターの責任範囲を区別し、Zabbixと対話する独自のツール（zabbixtools）を作成し、モニタリングをコードとして使用するアプローチに切り替えました。
責任の区分は次のようになります。監視する必要があるホストがある場合、テスターは彼に特定の役割を割り当てます。 各ホストは1つのロールのみを持つことができ、その中には複数のプロファイルが存在する可能性があります-それらはDevOpsチームによって提供されます。 プロファイルは異なる場合があります-プロセス、サービス、APIなどの監視用
zabbixtoolsパッケージには、PythonおよびPowershellスクリプト（ GitHubのプロジェクトリポジトリ ）が含まれており、Zabbixシステムの機能を部分的に拡張します。
- Zabbixエージェントのカスタムチェックとサーバーの外部チェック。
- アラートのカスタマイズ-さまざまなサービスおよびワークフローとの統合。
- APIを介して作業する-たとえば、ホストやその他のエンティティの一括編集。
- 製品またはテストを展開するときに監視を構成します。
監視システムは、柔軟で簡単に構成可能でなければなりませんが、Zabbix Webインターフェースではそうではありません。 そのため、設定を簡素化するために、Zabbixのパフォーマンスに関する可能な限り多くのデータをターゲットサーバーから収集する必要があるシステムを実装することが決定されました。 セットアップを簡素化するために、 zabbixtoolsは低レベル検出 （LLD）機能を使用します。
これにより、Zabbix管理パネルではなく、最も監視されているサーバーで監視設定を行うことができます。
この機能を実装するおおよそのスキームを図に示します。
仕組みは次のとおりです。
- LLDは、 Zabbixエージェントに監視設定を（必須パラメータとともに）要求します。 たとえば、必要な容量のサービス、利用可能なサイトまたはドライブのリスト
- Zabbixエージェントはパラメーターを提供しますが、実際にはyaml形式のファイルからパラメーターを取得します。
- LLDはホスト上で必要なアイテムとトリガーを作成します。 この場合、トリガー条件はエージェント側でも設定できます。
したがって、特定のルールで新しいホストを構成するために、チームは管理インターフェイスを調べる必要はなく、このサーバーに関連付けられるロールに必要なプロファイルのセットを追加するだけです。 Webインターフェイスは、現在のステータス/履歴情報を表示するためにのみ使用されます。
開発/テストプロセスに監視システムを埋め込む例
製品の開発およびテスト中の監視の問題は、バージョンごとに異なる観測パラメータのリストです。
たとえば、2つのリリースで次のインジケータを監視する必要がある場合があります。
1. Release N.0
- HTTP経由でリソースAの可用性を監視する
- 監視サービスB
- 監視サービスC
- リソースXに、クリティカル値Yを設定します
2. Release N+1.0
- HTTPSを介したリソースAの可用性の監視
- サービスCを監視します（ただし、名前は変更されています）
- 監視サービスD
- リソースXに対して、クリティカル値Zを設定します
そして今日、SERVER-1スタンドでは、製品の1つのバージョンがデプロイされ、明日-別のバージョンをデプロイする必要があります。 監視システムでは、静的に指定されたパラメーターを使用して、Webインターフェイスで変更を手動で行います。
zabbixtoolsとLLDを使用すると、次の2つの方法でこの問題を解決できます。
1.監視設定（yamlファイル）は、製品のデプロイ時にデプロイされます（ファイルは製品ソースコードと同じリポジトリから取得されます）。
- 監視構成の関連性を維持することは、開発者のタスクのままです。
- 監視構成は、ブランチごとに/機能ごとに異なります。
- SMOKEテストは、テストを実行する必要がない場合でも、製品の展開時に既に実行されています。
2.製品のテスト中に監視設定（yamlファイル）が展開されます（ファイルはテストのコードと同じリポジトリから取得されます）。
- 監視構成の関連性を維持することは、テスターのタスクです。
- SMOKEテストは、監視システムによって実行できます。
このスキームにより、製品のリリースに応じて監視を構成し、バージョン管理下に置くことができます。 監視システム自体を使用してSMOKEテストを実装することもできます。 さらに、この構成により、DevOps、開発チーム、テストチームの責任を区別することができます。特に、プログラマーとテスターはZabbixとそのAPIの動作を理解する必要がありません。
その結果、特定の間隔でのみ、異なるチームの参加が必要になります。 たとえば、製品を展開する場合、開発者は監視構成の関連性を維持する責任があり、監視構成はブランチごとに機能ごとに異なり、SMOKEテストはテストを実行しなくても展開中に実行されます。
製品をテストする場合、テスターは監視構成の関連性を維持する責任があり、SMOKEテストは監視システムで実行できます。
作業例
以下は、サイト、サービス、プロセス、およびフォルダーサイズを監視するためのサンプル構成です。
内部および外部サイトの可用性を監視する必要がある状況を考えてみてください-それらからHTTP 200 OK応答を受信する必要があります。 これを行うには、
websites.yaml
ファイルに行を追加するだけです。 サービスの動作を監視する場合（サービスを含める必要があります）、それらを
services.yaml
に追加する必要があり
services.yaml
。
特定のプロセスのメモリ消費を監視する必要がある場合は、process.yamlの数行でこれを実行できます。
このツールのもう1つの便利な機能は、メトリックに異なるしきい値を設定する機能です。 たとえば、Cacheフォルダーのサイズが小さく、ログのサイズが大きくなる可能性がある場合、
foldersize.yaml
のフォルダーに異なる
CriticalSize
を追加するだけ
foldersize.yaml
。
PS 2016年秋にモスクワで開催されたDevOpsミーティングの一環として、Zabbixによる監視を開発プロセスとテストプロセスに統合した経験に関するストーリーが紹介されました。
ビデオ：
スライド：
リンクには、イベント中に提示された16のレポートのプレゼンテーションが表示されます。 すべてのプレゼンテーションとビデオの外観は、このトピックの最後にある表に追加されます。
著者 ： アレクセイ・ブロフ