FlantとOkmeter：モニタリングのための共生

Linuxサーバーのシステム管理の長い道のりを経て、統計の収集と監視のための基本的なツールとして、さまざまな実装オプションを試すことに成功しました。 自作のスクリプト（およびWebアプリケーションも）、Cacti、Zabbixは、いつか最も確立されたオプションであり、近年ではOkmeterとPrometheusに置き換えられました。 この記事では、a）協力してくれたOkmeterの印象、b）小規模なものから大規模なもの、かなり些細なWebインストールまで、Okmeterをさまざまなプロジェクトで使用することに関するチームリーダーおよびFlantエンジニアからのフィードバックKubernetesクラスタへのホスティング）。

どうしてOkmeterなのですか？

特定のサービス（Webアプリケーションの正常な機能、バックアップの実行、cronタスクの実行など）の集中監視によって補完される、通常のZabbixセルフホストインストールの代わりに、サードパーティソリューション-Okmeter-の選択はすぐには起こりませんでした。 運用プロセスのこのような重要な部分である「間違った手に渡る」ことに同意するためには、統計を収集し、監視の主要部分に通知するために、たくさんのサボテンを食べなければなりませんでした。 ただし、蓄積されたとげは、この問題を完全に解決する2つの方法があるという理解につながりました：開発を行うか、誠実な残念なことにオープンソース製品ではなく、本当に深刻な要件が提唱されている既製のソリューションを信頼する最低限、SLAに記録される罰則はその品質に依存し、最大で-サービスのレベルと評判全般に依存します）。



小規模なシステム開発部門がありますが、本格的な監視システムの規模で独自のシステムを作成（および最新の状態に維持）することは、優先順位の高い活動ではありません（簡単に言えば、時間と費用がかかります）。 したがって、1年前に2番目のパスが選択されましたが、決定が後悔することはありません。 なぜ具体的にOkmeterなのか？ 簡単な答えはありませんが、一般的に言えば、提供される機会と信頼性のレベル、適切な財務状況、協力の見通し（特に、リクエストの作業を完了する可能性）が気に入りました。



この選択は実際にどのように役立ちましたか？ 衣服で人々に会うのが慣習である場合、管理者は、構成とさらなるメンテナンスの利便性のためにツールに会います。 Okmeterの場合、エンジニアは次のように説明します。

「メトリック（およびグラフ）は簡単に追加できます。Okmeter用にJSONを準備するだけです。 人生の簡素化とは、Zabbixのインストールとメンテナンスを停止したこと、セットアップに時間を浪費しないこと、一部のグラフィックスが突然描画を停止したことを忘れていたことです（より頻繁に曲がった手が非難された） ソフトウェアが検出されると、基本的なアラートが自動的に追加されます-これは非常に便利です。監視の追加を忘れないでください。

「Zabbixでは、テンプレートを自分で作成し、本当に必要なものをさまざまなテンプレートから収集しなければなりませんでした。 -そしてすぐに描かれます。」

「幸いなことに、1つのOkmeterインストールをプロジェクト内の任意のデータベースに接続できます。 私もそこにAWSでRDSを立ち往生しました。」

「私たちとクライアントにとって、データベースメトリックとnginxは非常に指標的であり、よく使用されます。 持っている必要があります。 Zabbixでは、このようなイチジクを描くからです。」

相互作用

これらの技術的アメニティの重要性にもかかわらず、それらが唯一の決定要因ではありませんでした。 私たちの協力の基本的な重要性は、コア活動の結果を相互に有益に交換する機会によってもたらされました。



Flant側から見ると、次のようになります。

• 一部のプロジェクトでは、標準外の問題がありました。
• これらのグラフに基づいて、それを特定することも（完全に/体系的に）理解することもできませんでした。
• 次回、どのような追加の監視機能（どのデータ、どこ、どのような形式）が状況（つまり、行動と理解）を改善するのに役立つかを分析し、この情報をOkmeterに渡しました。
• すべてのプロジェクトに広がっている改善を受けました。

この方法でイベントが複数回展開され、Sphinx、php-fpm、Postfixなどのサービスの動作の監視に追加できるようになりました...



他の相互作用シナリオがありました-たとえば、エンジニアの先端で、MySQLの一部のトリガーが役に立たないことが判明し、同じMySQL、Linux cgroupなどのプラグインで多数のバグが発見され、修正されました。



これにはOkmeterにとって明らかな利点があります。サービス開発者は、多数の異なるクライアントと特定の問題に関する相談のおかげで、知識ベースを積極的に拡大しています。 しかし、技術面に戻ります。Okmeterを正確にどのように使用し、何を特に重視しますか？

操作

1.一般的な診断

最初の最も明白なアプリケーションは、Linuxサーバーの毎日のメンテナンスです。そのために、次のような機能を特に積極的に使用しています。

• プロセス別のシステムリソース（プロセッサ、ディスク、メモリ）の負荷のグラフ、および要求別のトップ（後者は事後の事故の調査に非常に重要です-たとえば、あるプロセスが1時間前にすべてのメモリを消費したことがはっきりとわかります）;
• nginxチャート、サーバーレスポンスタイムチャート、さまざまなURLのリクエストチャート（GETパラメーターなしでグループ化）;
  
  
  
  
• ポートおよびアドレスによる接続の統計。
• 私たちのエンジニアの一人が言ったように、データベースの上位クエリは「神」です。

右上のグラフの年齢（トランザクション期間）の急増は、インデックスなしでデータベースを復元した結果です。

2.監査

Okmeterのもう1つの一般的な使用法は、新しいプロジェクトの監査です。 サービスをまだ開始しておらず、予備のNDAに署名しただけで、クライアントにすべてのサーバーで実行するコマンドを発行します。 結果-自動サービス検出を使用して取得された多くのメトリックが表示されます。



したがって、統計は多数のサーバーにも迅速に追加され、結果の標準グラフにより、インフラストラクチャの状態を理解し、最適化/開発の最初の目標を形成するのに役立つ多くのインジケーターをすぐに見ることができます：

• サーバー上のプロセスと消費されるリソースの量。
• DBMSとWebサーバーの負荷
• データベースサイズ（Elasticsearchに関連）;
• ...など

3.コンテナ

Kubernetesクラスターの特定の操作のコンテキストでは、Okmeterにはそれほど多くのものがありません。 それにもかかわらず、コンテナによるリソース消費のグラフ（またはKubernetesを提供します）は、K8に多数のコンテナが展開されている場合のdocker docker stats



出力が問題であるため、特に関連性があります。





a）コンテナによるリソースの消費





b）ポッドによるリソースの消費



Kubernetesの完全サポートが登場し始めたばかりであるため、K8固有のインジケーターを監視するために、 Prometheus moreを使用しています 。 しかし、この方向でのOkmeterの見通しについても知られています...

OkmeterとKubernetes

FlantとOkmeter全体の相互作用については（上記参照） 、共同利益の特定の最も激しい領域であるKubernetesを意図的に省略しました。 Okmeterのエンジニアは、Kubernetesの知識と経験を使用して、サービスでK8モニタリングを開発します。



まず第一に、これらはライブクライアントです。つまり、本番環境で使用されるK8のクラスターです。 このような各インストールはOkmeterにとって有用なデータソースであり、Kubernetesが実際にどのように機能するか、ユーザーにとって本当に重要なアプリケーションの詳細と問題を確認できます。



第二に、（このような呼び出しが発生したとき）Kubernetesがどのように構成されているか、特定のユーザーがどのように展開するか、「どのように爆発するか」（どの問題が存在し、最初に何を見るか）について話します。



これにより、OkmeterはKubernetesの知識を向上させるだけでなく、このシステムが市場全体で有望であることを確認することができました。 「徒歩圏内」の専門家の存在は、会社が使用しているドッグフーディングアプローチに対応する独自のニーズに合わせてK8を迅速に実装することにつながり 、サービス自体でKubernetesをサポートする作業にも貢献しました。



このサポートで何が約束されますか

1. K8で起動されたサービス間のクラスターリソースの分散。 すべてのメトリックは、K8sエンティティのコンテキストで表示できます： 展開から特定の炉床の特定のコンテナまで。
2. サービスリソースの制限を使い果たすための自動トリガー。
3. サービスの作業における問題：コンテナの再起動、必要な数のインスタンスを起動できないなど。
4. キャパシティプランニング：すでに「予約」されているリソースの数、残されているリソースの数。
5. K8sコンポーネントのステータス：etcd、dns、apiserverなど。

主なアイデアは、Fluantaのエンジニアからの推奨事項に基づいて作成されたKubernetesの基本設定の継続的な監査です。 そしてもちろん、DaemonSetの形式でOkmeterエージェントがデプロイされます。



説明されている機能は既にベータテストに登場し始めており（詳細についてはNikolaySivkoにお問い合わせください ） 、9月までに完全なリリースが予定されています。

まとめ

OkmeterとFlantのコラボレーションの利用可能な結果は、共生と相乗効果です。ビジネスで重要な役割を果たしている（ただし、内部開発には十分ではない）既成のツールを入手しました。特定の技術的問題に関する知識の補充と専門的な支援。 同時に、協力の間、「通常の」プロジェクトからKubernetesクラスターへの運用、および対応する方向へのOkmeterの開発の傾向があります。

PS

ブログもご覧ください。

• “ Kubernetesのプロメテウスオペレーターの操作のデバイスとメカニズム ”;
• “ KubernetesのPrometheusで15分で監視 ”;
• 「 ブラックフライデーのためにオンラインストアのインフラストラクチャを準備する10の明白なステップ 」;
• 「 小規模プロジェクトでのKubernetesでの経験 」 （ビデオレポート、Kubernetesの技術デバイスの紹介を含む） 。
• 「 手頃な価格のサービスとしてKubernetesを使用したインフラストラクチャ 。」