画像： FlickrHabréのブログでは、会社でのDevOps文化の構築について引き続き話します。たとえば、SaltStackシステムを使用して解決するタスクを
説明した最新のトピックの1つです。 今日は、別の興味深いトピック-いくつかの既成ツールを使用した負荷テストの自動化についてお話します。
前と同じように
負荷テストが実行されたサーバーを監視する必要がありました-プロセッサパフォーマンス、メモリ、オペレーティングシステムなどのメトリックを収集するため また、データベース、バス、およびキューのステータスを監視する必要があり、ログを操作する必要がある場合もありました。 これらすべてのタスクは、当社が開発したPythonスクリプトによって解決され、情報はSQLiteデータベースに保存され、レポートはCSVファイルを使用して生成されました。
以下に図を示します。
このアプローチの短所：
- 中かっこで画像内で強調表示されているすべてのものは、その後、自重によりアーティファクトに格納され、データを分析することは非常に困難でした。
- この機能により、フィルターや相関関係を表示せずに、厳密な形式でのみレポートを作成できました。
- 主なマイナス-レポートはテストの最後にのみ生成されました。
新しい束
最終的に、私たちは自分の自転車を放棄し、他の人の労働力を活用することにしました。 その結果、いくつかのツールの新しい束が生まれました。
データ保存
InfluxDB製品は、データストレージシステムとして使用されました。 これは、時系列（パフォーマンスメトリック、分析、イベント）を格納するために設計された数少ないDBMSの1つです。 オンザフライでデータを集約でき、システムはSQLに似た構文を使用するため、使いやすいです。 他の利点から：
- 正規表現のサポート。
- 古いデータの自動クリーニング。
- スケーラビリティ。
- 一般的な言語のライブラリの可用性。
- 簡単な展開と管理。
測定にInfluxDBを使用する例を考えてみましょう。 時間間隔でタイプXマシンの温度を測定する必要があるとします。
これにはパラメーターがあります。
- 測定：温度;
- タグ：マシン、タイプ;
- フィールド：internal_temperatre、external_temperature。
タグは集約とフィルタリングに使用され、データはストレージのフィールドに格納されます-それらはインデックス付けされず、「測定+タグ+タイムスタンプ」の組み合わせに対して1つの値のみが格納され、時間精度（s、ms、ms、ns）が設定されます。 データの保存期間は、クリーニングポリシーによって決まります。
測定は次のようになります。
temperature, machine-unit42,type=assembly internal=32, external=100 1434055562000000035
簡単に作成、転送でき、大量のリソースを必要としません。
モニタリング
監視の手段として、Zabbixを使用することにしました。 WindowsおよびLinuxホストでクロスプラットフォームエージェントを使用します。 パッシブチェックとアクティブチェックの両方が使用されます。 アクティブなチェックを通じて、閉じたネットワークのホストからメトリックが収集されます。 さらに、ESXiを搭載したホスト上の仮想マシンに対して自動検出機能を積極的に使用しました。
分析
オープンソースのgrafanaプロジェクトは、データ分析のツールとして使用され、ダッシュボードの作成、グラフ作成、クエリおよびダッシュボードのテンプレート作成に最適です。 システムは、異なるデータソース（同じInfluxDB、Zabbix、Elasticsearchなど）のクエリを作成できます。 一般に、この製品は非常に便利です。キャプションとプレイリストを作成し、ダッシュボードで検索し、データをエクスポートおよびインポートできます。
まあ、あなたはあなたの目を出血させないインターフェースに言及せずにはいられません（hello、Zabbix）。
最終構成
システムの要素を検討した後、最終的にすべてがどのように連携するかについて説明します。
重要なオペレーティングシステムとハードウェアのすべてのメトリックは、Zabbixと、アップグレードされたPythonコレクタースクリプトを使用して監視されます。 スクリプトによって収集されたメトリックはInfluxDBに保存され、情報はGrafanaに表示されます。
自動化
インフラストラクチャを準備したら、テストの自動化の問題を取り上げました。 このために、Apache JMeter製品が使用されました。 目的は次のとおりです。
- システムを使用して実際のユーザーの作業を完全にエミュレートできます。この場合、サーバーとブラウザー間のリクエストです。
- システムは、サーバー操作に関する統計を生成します。たとえば、着信要求の処理時間や着信応答の処理などです。
- 結果をInfluxDBに送信し、Grafanaで表示します。
実装の途中で、いくつかの問題を解決する必要がありました。
- ツールをサーバーに展開するための簡単なメカニズムを開発する必要がありました。
- ストレステストを開始して実施する簡単なプロセスを確立します。
- Grafanaでテスト結果の簡単な統合を開発します。
- 負荷テストのオンライン監視を整理します。
ここにそれらを解決するために行ったことがあります：
- すべてのユーザー操作の最大80％をカバーするロードスクリプトを開発しました。
- TeamCityを介してテストを開始するメカニズムを実装しました。
- 製品MaxPatrol UIの操作に関するオンライン統計の表示を実装しました。
- Gitを使用して簡単なスクリプト更新を行いました。
TeamCityでテストタスクを起動するためのインターフェイスは次のとおりです。
Jmeterには、InfluxDBにデータを送信するための組み込みプラグイン（バックエンドリスナー）があります
結論：仕組み
現時点では、負荷テストのプロセスはTeamCityでのタスクの起動です。起動時に必要なパラメーターを選択するだけです。 さらに、UIの操作に関する統計は、既製の対話型グラフの形式ですぐに表示されます。 更新されたスクリプトは、TeamCityのGitを介して自動的に取得されます。
PS SaltStackを使用した当社の経験に関するストーリーは、2016年秋にモスクワで開催されたDevOpsミーティングの一部として発表されました。
ビデオ：
スライド：
リンクには、イベント中に提示された16のレポートのプレゼンテーションが表示されます。 この
トピック発表の最後に、すべてのプレゼンテーションとビデオプレゼンテーションがテーブルに追加されます。
作成者 ：Ivan Ostanin、Sergey Tikhonov