XNUMX年前にすでに投稿していました Web サイトのシンプルなフェイルオーバー約オーカー。現在、プロジェクトの開発が進んでおり、私も公開しました okerr サーバー側のソースコード下オープンライセンス、それが、私がこの短いレビューを Habr について書くことにした理由です。

[ 原寸大 ]

誰に興味があるか

これは、小規模なチームまたは一人で作業している場合に興味深いかもしれません。監視機能がなく、本当に必要かどうかわかりません。「偉い人向け」に人気の本格的なモニタリングを試してみたが、どういうわけか「うまくいかなかった」か、ほぼデフォルトの構成で動作し、生活をあまり変えなかったかのどちらかです。また、従業員全体 (または部門) を少なくとも XNUMX 日に少なくとも XNUMX 時間は監視ダッシュボードの監視や設定に割り当てる予定がない場合も同様です。

なぜokerが珍しいのか

次に、オケラを他の監視システムと区別する興味深い特徴を示します。

OKerr はハイブリッド監視です

内部監視中は、監視対象マシン上で「エージェント」が実行され、監視サーバーにデータ (ディスクの空き容量など) を送信します。外部の場合、サーバーはネットワーク経由でチェックを実行します (ping や Web サイトの可用性など)。各アプローチには限界があります。 OKerr は両方のオプションを使用します。サーバー内部のチェックは非常に軽量な (30Kb) エージェントまたは独自のスクリプトとアプリケーションによって実行され、ネットワークチェックはさまざまな国の okerr センサーを通じて実行されます。

okerr は単なるソフトウェアではなく、サービスでもあります

監視のサーバー部分は大規模かつ複雑で、インストールと構成が難しく、リソースが必要です。 okerr を使用すると、独自の監視サーバー (無料でオープンソース) をインストールすることも、クライアント部分のみを使用してサーバーのサービスを使用することもできます。こちらも無料。

監視によってサーバーやアプリケーションの信頼性の欠如を補ったり隠蔽したりできる場合、警備員は誰なのかという哲学的な疑問が生じます。問題自体が何らかの理由で個別に、または他のリソースと一緒に「停止」した場合 (データセンターへのチャネルが切断されたなど)、モニタリングはどのようにして問題を知らせるのでしょうか? 外部サービス okerr を使用すると、この問題は解決されます。サーバーのあるデータセンター全体が停電しているか、ゾンビに攻撃されている場合でも、アラートが届きます。

もちろん、okerr サーバー自体が使用できなくなるリスクがあります。これは事実です (ご存知のとおり、信頼性の 90% は常に簡単かつ「無料」で得られ、99% は最小限の努力で得られ、その後の 99.9 % はすべて指数関数的に難しくなります）。しかし、第一に、この問題が発生する可能性は低く、第二に、問題がサーバーの問題と一致した場合にのみ気付かれない可能性があります。私たちの信頼性が 99.9% で、あなたが 0.1% (それほど高い数字ではない) を持っている場合、検出されない障害の可能性は 0.1%/0.0001% = XNUMX% です。ほとんど労力もコストもかけずに、信頼性にスリーナインを追加できるのは非常に良いことです。

サービスとしてのモニタリングのもう XNUMX つの利点は、ホスティングプロバイダーまたは Web スタジオが okerr サーバーをインストールし、有料または無料の追加サービスとしてクライアントにアクセスを提供できることです。競合他社はホスティングと Web サイトしか持っていませんが、貴社は監視機能を備えた信頼性の高いホスティングを持っています。

OKerr はインジケーターに関するものです

インジケーターは「電球」です。これには、緑 (OK) または赤 (ERR) という XNUMX つの主な状態があります。プロジェクトには、グループ化された (サーバーごとなど) インジケーターが多数含まれています。プロジェクトのメインページでは、すべてが緑色になっているか (閉じることができます)、または何かが赤色に点灯していて修正が必要であることがすぐにわかります。これらの状態間を遷移すると、アラートが送信されます。セットアップ中に XNUMX 日に XNUMX 回、プロジェクトの概要が送信されます。

各 okerr インジケーターには、状態を変更するための組み込み条件があります (Zabbix ではこれをトリガーと呼びます)。たとえば、負荷平均は 2 以下である必要があります (もちろん、これは構成可能です)。そして、内部チェック (負荷平均、ディスク空き容量など) ごとにウォッチドッグがあります。何らかの理由で、指定された時刻に成功の確認を受信できない場合、エラーが記録され、アラートが送信されます。

私たちの通常の仕事パターンは、朝にメールをチェックし、他の手紙に混じって概要を確認することです (仕事の開始時にスケジュールを設定します)。すべてが正常であれば、他の重要な作業を行います (ただし、安全のために、okerra ダッシュボードをすぐに見て、現時点ですべてが緑色であることを確認できます)。アラートが届いたら対応します。

もちろん、単に「情報」インジケーターを保持することも可能です (監視からネットワークの全体像を確認するため)。ただし、すべては、自動監視とアラート送信に特化したインジケーターを簡単、簡単、迅速に作成するために行われます。

okerr を設定する目的はアラートにあるため、インジケーターを XNUMX 分で作成でき、XNUMX 年間は「スリープ」し、更新を受け入れるだけで、XNUMX 年後に何かが壊れたときに点灯して送信することができます。警告。インジケーターの作成に XNUMX 分を費やしたことが功を奏し、誰よりも早く問題をすぐに知ることができました。もしかしたら、誰かが気づく前に修正されていた可能性もあります。 素早く上げたものは落ちたとはみなされません。

セキュリティ

信頼性を高めるために監視を設定したのに、その結果、それを介してネットワーク経由で攻撃を受けたり、さまざまな監視ツールに非常に多くのネットワーク脆弱性が存在したりするのは残念です (ザビックス, Nagios).

エージェント (パッケージからの okerrmod オーケル更新) システム上で実行されているのはネットワークサーバーではなく、クライアントです。したがって、監視対象サーバーには追加のオープンポートはなく、クライアントはファイアウォールまたは NAT の内側で簡単に動作し、原則としてネットワークをリッスンしないため、ネットワーク経由でハッキングすることは非常に困難です (「不可能」と言えます)。ソケット。

完全な監視範囲

現在、私たちのルールは、すべての技術的な問題について okerr から学ぶことです。突然ルールに違反した場合 (okerr は、その差し迫った発生について (可能であれば)、またはすでに発生していることを警告しませんでした) - okerr にチェックを追加します。

外部チェック

非常に典型的なセット:

ping
http ステータス
SSL 証明書の有効性と新鮮さをチェックします (期限切れが近づくと警告が表示されます)
TCP ポートを開き、その上のバナーを開く
http grep (ページには特定のテキストを含めてはなりません)
ページの変更をキャッチするために sha1 ハッシュを使用します。
DNS (DNS レコードには特定の値が必要です)
WHOIS (ドメインが壊れそうになると警告します)
アンチスパム DNSBL (50 を超えるアンチスパムブラックリストに対してホストを一度にチェック)

内部チェック

また、かなり標準的なセットです (ただし、簡単に拡張可能)。

df (空きディスク容量)
負荷平均
opentcp (TCP リスニングソケットを開く - 何かが開始またはクラッシュした場合に通知します)
稼働時間 - サーバー上の稼働時間だけです。ダウン状態に変化した場合 (つまり、サーバーが過負荷になった場合) に通知します。
client_ip
dirsize - 厳密な制限を導入することなく、仮想マシンの rootfs が許容サイズを超えたときと、ユーザーのホームディレクトリのサイズを追跡するために使用します。
empty および nonempty - 空であるべき (または空ではない) ファイルを監視します。たとえば、okerr サーバー自体のエラーログは空である必要があり、その中に XNUMX 行でもあれば、通知を受け取って確認します。ただし、メールサーバー上の mail.log は空であってはなりません (ローテーション後 N 分)。また、システムのアップデート後、logrotate が rsyslog を正しく再起動できなかった場合、空になることがありました。
linecount - ファイル内の行数 (wc -l など)。エラーログがまだ増加する可能性はあるものの、ゆっくりとしか増加しない場合 (たとえば、Googlebot がいくつかの閉じられたページにヒットする場合)、空のよりソフトな代替として使用します。 2分で20回線までという制限があります。それより高い場合はアラートが表示されます

興味深い内部チェック

これまで「斜め」に読んでいた人は、今度はじっくり読んでみるとさらに面白くなります。

バックアップ

ディレクトリ内のバックアップを監視します。バックアップファイルの名前は「ServerName-20200530.tar.gz」のようなものです。 okerr のサーバーごとに、インジケーター ServerName-DATE.tar.gz が作成されます (実際の日付は「DATE」の行に変わります)。新しいバックアップの存在そのものとそのサイズも監視されます (たとえば、以前のバックアップの 90% 未満にすることはできません)。

新しいバックアップを作成してこのディレクトリに配置した後、そのバックアップの追跡を開始するには何をする必要がありますか? 何もない！これは、次の理由から「何もしない」必要がある場合に非常に便利な方法です。

「何もしない」ことは非常に早く、時間を節約できます
「何もしない」ことを忘れるのは難しい
エラーが発生しても、「何も間違っていない」ということは困難です。最も信頼できる方法はありません

新しいバックアップファイルが突然表示されなくなると、警告が表示されます。たとえば、サーバーの XNUMX つを無効にし、これ以上バックアップが必要ない場合は、(Web インターフェイス経由、または API 経由のシェルから) インジケーターを削除する必要があります。

最大ファイル数

最大のファイル (通常: /var/log/*) のサイズを追跡します。これにより、ブルートフォースパスワードやサーバー経由のスパム送信などの予期せぬ問題を捕捉できます。

実行ステータス/実行ライン

これらは、サーバー上で他のプログラムを実行するための XNUMX つの重要なプロキシモジュールです。 Runstatus はプログラムの終了コードをインジケーターに報告します。たとえば、okerr は、systemd サービスが実行されていることを確認するためのモジュールを必要としません。これは runstatus 経由で行われます (以下を参照)。実行ライン - プログラムが生成する行をサーバーに報告します。例えば、 temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" サーバーの Runline 設定で、プロセッサーの温度を示すインジケーター servername:temp が作成されます。

SQL

MySQL に対して数値クエリを実行し、結果をインジケーターにレポートします。単純なケースでは、たとえば「SELECT 1」を実行できます。これにより、DBMS 全体が動作しているかどうかがチェックされます。

しかし、さらに興味深いアプリケーションは、たとえば、オンラインストアでの注文数を追跡することです。 100 時間あたり 100 件以上の注文があることがわかっている場合は、最小制限を 80 または XNUMX に設定できます。そうすれば、売上が突然減少した場合にアラートが表示されるので、それを把握することができます。

これがどのような予期せぬ理由で起こったかは重要ではないことに注意してください。

サーバーが単純に利用できず (電源が供給されていない、またはネットワークがない)、インジケーターが「腐っている」という事実からアラートが発せられました。
サーバーに何らかの過負荷がかかっている、動作が遅い、またはパケットが失われている、ユーザーにとっては不便であり、購入せずに離脱してしまう
サーバーはスパムリストに含まれているため、そこからのメールは受け付けられず、ユーザーは登録できません
広告キャンペーンの予算がなくなり、バナーが回転しません。

理由は数多く考えられますが、そのすべてを事前に予測することはできず、追跡することは技術的に困難です。ただし、最終パラメータ (命令) を簡単に監視し、それらから状況が疑わしく、対処する価値があると判断することができます。

論理インジケーター

モジュール経由でブール式 (Python 構文) の使用を許可します。検証する(ハブレに関する記事）。プロジェクトとその指標からのデータは表現に利用できます。たとえば、上記の SQL チェックに関する章で、弱点に気づいたかもしれません。日中は 100 時間あたり 20 件の売上が得られますが、夜間は XNUMX 件になります。これは一般的なことであり、問題ではありません。どうすればいいですか？インジケーターは夜間に常にパニックになります。

昼と夜の 20 つのインジケーターを作成できます。両方を「サイレント」にします (アラートは送信されません)。そして、日中インジケーターが 00:20 より前に OK であることを要求する論理インジケーターを作成し、00:XNUMX 以降は夜間インジケーターが OK であれば十分です。

論理インジケーターを使用する別の例は次のとおりです。 エスカレーション。たとえば、プロジェクトマネージャーはアラートのサブスクライブを解除しますが (その必要はありません。管理者は通常の問題に対応する必要があります)、割り当てられた時間内にプロジェクト内のいずれかのインジケーターが修正されなかった場合に赤色に変わる論理インジケーターをサブスクライブします。

また、例えば午前3時から午前5時までの間で作業を許可する時間を設定することも可能です。この間にサーバーやサイトがクラッシュしても気にしません。しかし、5時に彼らは仕事をしなければなりません。それ以外の時間でも機能しない場合は、警告してください。論理インジケーターを使用すると、サーバーの冗長性を考慮することもできます。 Web サーバーが 00 台ある場合、管理者はいつでも 5 ～ 1 台のサーバーをオフにすることができます。ただし、戦闘中のサーバーが 2 台中 3 台未満の場合は、アラートが表示されます。

上記の例は、それほど問題のない機能であり、アクティブ化して構成する必要がある一部の機能ではありません。 Okerra にはこれらすべての機能があるわけではありませんが、この機能を実装できる論理モジュールがあります (ほぼプログラミング言語と同じように、算術演算子がある場合は、20% の VAT を計算するための特別な関数は必要ありません)言語から判断して、いつでも自分でニーズに合わせて作成できます)。

ロジックインジケーターは、おそらく okerr の数少ない比較的複雑なトピックの XNUMX つですが、良いニュースは、必要になるまでマスターする必要がないことです。しかし同時に、システム自体を非常にシンプルに保ちながら、機能を大幅に拡張します。

独自のチェックを追加する

私が本当に伝えたいのは、okerr はあらゆる場面に対応する何千もの既製の小切手のセットではなく、その逆で、第一に、独自の小切手を作成する簡単な機能を備えたシンプルなエンジンであるということです。 okerr で独自のチェックを作成することは、ハッカー、システム共同開発者、または少なくとも高度な okerr ユーザーのタスクではありませんが、XNUMX か月前に初めて Linux をインストールした管理者であれば実行可能なタスクです。

最低賃金のチェックはモジュールを通じて行われます実行ステータス:

設定内のこの行実行ステータス /bin/true が突然起動しなくなったり、0 以外を返したりした場合に通知します。

true_OK=/bin/true

たった XNUMX 行で、ここですでに少しの部分が完成しました 拡大した 機能は大丈夫です。

このようなチェックにもすでに価値があります。サーバーが突然クラッシュした場合、okerr サーバー上の対応するインジケーターが適時に更新されず、時間が経過するとアラートが表示されます。

このチェックは、apache2 サーバーがクラッシュしたことを通知します (まあ、それはわかりません...)。

apache_OK="systemctl is-active --quiet apache2"

したがって、何らかのプログラミング言語を話し、少なくともシェルスクリプトを作成できる場合は、すでに独自のチェックを追加できます。

さらに難しいのは、okerrmod 用に独自のモジュールを (任意の言語で) 作成できることです。最も単純なケースでは次のようになります。

#!/usr/bin/python3

print("STATUS: OK")

とても難しくないですか？モジュールは自身でチェックを実行し、結果を STDOUT に出力する必要があります。より複雑なモジュールでは、たとえば次のようになります。

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G used, 13.0G free
STATUS: 49.52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M used, 9.9M free
STATUS: 84.32

複数のインジケーターを一度に更新し (空の行で区切って)、必要に応じて作成し、検証の詳細と、ダッシュボードで必要なインジケーターを簡単に見つけられるタグを示します。

Telegram ボットがあります @OkerrBot。携帯電話を別のアプリケーションで煩雑にする必要はありません (Pyaterochka には地図を備えたアプリケーションが XNUMX つ必要で、Lenta には別のアプリケーションが必要で、MTS には XNUMX 番目のアプリケーションが必要になるのが気に入りません。全員、全員、全員にというように続きます)。電報はXNUMX通で十分です。テレグラムを通じて、アラートをすぐに受信し、プロジェクトのステータスを確認し、問題のあるすべての指標を再確認するように指示することができます。私たちは劇場や飛行機を出て、XNUMX 時間何も気にせず、電話の電源を入れ、チャットボットのボタンを XNUMX つ押して、すべてが正常であることを確認しました。

ステータスページ

現在、ステータスページは、IT を導入し、信頼性に対する責任ある姿勢を持ち、クライアント/ユーザーを敬意を持って扱う企業にとってほぼ必須となっています。

ユーザーが何かをしたり、情報を表示したり、注文したりしたいのに、何かが機能しないという状況を想像してください。彼には何が起こっているのか、問題はどちらの側にあるのか、いつ解決されるのかがわかりません。もしかしたら、あなたの会社の Web サイトが機能していないだけではないでしょうか? それとも半年前に壊れてXNUMX年で直るのか？しかし、あなたは今冷蔵庫を買う必要があります、それはすでにカートに入っています...そして、誰かがあなたに何か問題があると気づいたとき（少なくとも問題が彼の側にあるわけではないことは明らかです）、それは完全に別の問題です。問題が発見され、すでにその問題に取り組んでおり、おそらく修正にかかるおおよその時間を書き留めていることもあります。ユーザーは購読して、問題が解決され、やりたいこと (冷蔵庫の購入) ができるようになったときに電子メール通知を受け取ることができます。

問題やダウンタイムは誰にでも起こります。しかし、ユーザーとパートナーは、これに対するアプローチにおいてより透明性があり、責任を持っている人をより信頼します。

ここでステータスページを作成できる他の 10 個のプロジェクトのレビュー。これらのプロジェクトページがどのようなものであるかの例を次に示します。 Python и ドロップボックス. okarrステータスページ.

フェイルオーバー

この記事がさらに長くならないように、前回の記事をもう一度参照します。 Web サイトのシンプルなフェイルオーバー。複製サーバーを作成し、フェイルオーバーを使用することができれば、基本的に長いダウンタイムは発生しません。問題が検出されるとすぐに、ユーザーは稼働中のバックアップサーバーに自動的にリダイレクトされます。そして、これは、どこにもめったにない、非常に興味深く明るい機能であるように思えます。

低いシステム要件

okerr サーバーの場合、2 GB からの RAM を搭載したマシンを使用します。ネットワークセンサーの場合は、512Mb でも十分です。通常、クライアント部分はほぼゼロです。（ビニール袋オーケル更新重さは 26 Kb ですが、Python3 と標準ライブラリが必要です)。クライアントは cron スクリプトから実行されるため、永続メモリの消費はゼロです。私たちが監視したマシンの中には、センサー (512Mb RAM を搭載した超安価な VPS) と Raspberry Pi があります。クライアント部分がなくても可能更新情報をカール経由で送信する！（以下を参照してください）

これを考慮すると、おそらく大丈夫です 最も自由な Zabbix や Nagios のような別の無料のオープンソースシステムを使用する場合でも、それにリソース (サーバー) を割り当てる必要があり、これにはすでにお金がかかります。さらに、サーバーのメンテナンスも必要になります。オーカーを使えばこの部分を取り外すことができます。または、それを削除せずに、好みに応じて独自のサーバーを使用することもできます。

API と独自のソフトウェアへの統合

シンプルでオープンなアーキテクチャ。 okarr には非常に単純なものがあります API、作業が簡単です。 1000 個のインジケーターを作成する必要がありますか? 3 ～ 4 行の 1000 つのシェルスクリプトでこれを実行できます。 XNUMX 個のインジケーターを再構成する必要がありますか? それもとても簡単です。たとえば、ロシアのセンサーからのすべての HTTPS 証明書を再確認したいとします。

#!/bin/sh

for indicator in `okerrclient --api-filter sslcert`
do
    echo set location for $indicator
    okerrclient --api-set location=ru retest=1 --name $indicator
done

クライアントモジュールを使用しなくても、curl 経由でインジケーターを更新できます。

# short and nice (using okerrupdate and config file)
$ okerrupdate MyIndicator OK

# only curl is enough!
$ curl -d 'textid=MyProject&name=MyIndicator&secret=MySecret&status=OK' https://bravo.okerr.com/

プログラムから直接インジケーターを更新できます。たとえば、ハートビート信号を送信して、okerr が実行中であることを認識し、クラッシュまたはフリーズした場合にアラームを生成します。ちなみに、okerr コンポーネントはまさにそれを行います。okerr はそれ自体を監視し、ほぼすべてのモジュールの問題が検出され、問題に関するアラートが生成されます。 (そして、この「ほぼ」の場合、別のサーバーからクロスチェックされます)

電報ボットのコード (簡略化) は次のとおりです。

from okerrupdate import OkerrProject, OkerrExc

op = OkerrProject()
uptimei = op.indicator("{}:telebot_uptime".format(hostname))
...
uptimei.update('OK', 'pid: {} Uptime: {} cmds: {}'.format(
        os.getpid(), dhms(uptime), commands_cnt))

Python プログラムからインジケーターを更新するためのライブラリがありますオーケル更新他の言語の場合はライブラリはありませんが、okerrupdate スクリプトを呼び出すか、okerr サーバーに対して HTTP リクエストを行うことができます。

okarr がどのように役立つか

オカーは私たちの生活を変えました。確かに。おそらく別の監視システムでも同じことができるでしょうが、okerr での作業は私たちにとって簡単でシンプルで、必要な機能がすべて揃っています (私たちは、持っていないものを追加しました)。ちなみに、不足している機能がある場合は、質問してください。追加します (約束はしませんが、okerr が中小規模のプロジェクトに最適な監視システムであることを望んでいます)。さらに良いことに、自分で追加するのは簡単です。

私たちは「すべての問題についてはケラから学ぶ」という原則に従ってなんとか生きてきました。 okerr からは知らなかった問題が突然発生した場合は、okerr にチェックを追加します。 (この場合、「私たち」とは、共同開発者ではなく、システムのユーザーとしての私たちを意味します)。最初はこれが一般的でしたが、今では非常にまれになりました。

監視

okerr を通じて、すべてのサーバー上のログサイズを監視します。もちろん、ログのすべての行を目で注意深く読むことは不可能ですが、成長率を監視するだけでもすでに多くのことが得られます。これにより、スパムメールとブルートフォースパスワード検索を発見しました。アプリケーションの一部が「おかしくなった」場合、何かがうまくいかず、それを何度も繰り返します（そのたびにログに数行が追加されます））。

SSL証明書。打ち上げ直後 LetsEncrypt 私たちの顧客は、クライアント (約 XNUMX 人) に無料の SSL 証明書を提供し始めました。そして、それは行政にとってまさに地獄だったことが判明しました！実際のところ、サイトは「ライブ」であり、クライアントは定期的にサイトに何かをするよう依頼し、プログラマーがそれを行います。たとえば、サイトを別の DocumentRoot に完全に自由に転送できます。または、無条件の書き換えを仮想ホスト構成に追加します。当然、この後、証明書の自動更新は機能しなくなります。これで、パッケージに含まれる別の便利なユーティリティを使用して、すべての SSL ホストが okerr に自動的に追加されました。 a2conf。さあ、出発しましょう a2okerr.py — そして、サーバー上にいくつかの新しいサイトが表示されると、それらは自動的に okerr に表示されます。証明書の有効期限が切れる XNUMX 週間前に、何らかの理由で突然証明書が更新されなくなった場合、私たちは情報を知っており、更新されない理由を解明します。 a2certbot.py 同じパッケージから - これは非常に役立ちます (最も可能性の高い問題をすぐにチェックし、よくチェックされた内容と、問題がある可能性が最も高い場所を書き込みます)。

当社ではすべてのドメインの有効期限を監視しています。また、メールを送信するすべてのメールサーバーも 50 以上の異なるブラックリストと照合されます。（そして時にはそれらに陥ることもあります）。ところで、Googleのメールサーバーもブラックリストに登録されていることをご存知ですか？自己テストのため、監視対象サーバーに mail-wr1-f54.google.com を追加しましたが、まだ SORBS ブラックリストに載っています。 (これは「スパマー対策」の価値に関するものです)

バックアップ - okerr を使用してバックアップを監視することがいかに簡単であるかについてはすでに書きました。ただし、サーバー上の最新のバックアップと (okerr を使用する別のユーティリティを使用して) Amazon Glacier にアップロードしたバックアップの両方を監視します。そして、はい、問題は時々発生します。彼らが見ていたのも不思議ではありません。

エスカレーションインジケーターを使用します。何らかの問題が長期間修正されていない場合に表示されます。そして私自身も、問題を解決すると、そのことを忘れてしまうこともあります。自分自身を監視している場合でも、エスカレーションは良い思い出となります。

全体として、私たちの仕事の質は一桁向上したと思います。ダウンタイムはほとんどなく（あるいはクライアントがそれに気づく暇もありません。まあ！）、仕事量は減り、労働条件は穏やかになりました。私たちは、テープで穴をふさぐ緊急作業から、多くの問題が事前に予測され、それを防ぐ時間があるときの、落ち着いて慎重な作業に移行しました。発生した問題も修正が容易になりました。第一に、クライアントがパニックになる前に問題に気づくことができ、第二に、問題が最近の仕事に関連していることがよくあります（あることをしている間に、別のことを壊してしまいました）。暑いので痕跡が残りやすいです。

しかし、別の事件がありました...

人気の Debian 9 (Stretch) では、phpmyadmin のような人気のあるパッケージが依然として (何ヶ月もの間!) 脆弱な状態にあることをご存知ですか? (CVE-2019-6798）。脆弱性が明らかになったとき、私たちはすぐにさまざまな方法でそれをカバーしました。ただし、「美しい」ソリューションがいつ現れるかを知るために、okerr のセキュリティトラッカーページの監視を設定しました (コンテンツの SHA1 サムを介して)。インジケーターが何度かぴくぴくと動き、ページが切り替わりましたが、ご覧のとおり、依然として (2019 年 XNUMX 月以来!) 問題が解決されたことを示していません。ところで、このような重要なパッケージが XNUMX 年以上も脆弱なままであるという問題が何か知っている人はいるでしょうか?

また同じような状況が発生しました。SSH に脆弱性があったため、すべてのサーバーを更新する必要がありました。また、タスクを設定したら、実行を制御する必要があります。（部下は誤解、忘れ、混乱し、間違いを犯す傾向があります）。したがって、最初に SSH バージョンチェックをすべてのサーバーの okerr に追加し、okerr を通じて更新がすべてのサーバーにロールアウトされることを確認しました。 (便利です。私はこのタイプのインジケーターを選択しました。どのサーバーにどのバージョンがあるかがすぐにわかります)。すべてのサーバーでタスクが完了したことを確認した後、インジケーターを削除しました。

特定の問題が発生し、その後自然に解決するという状況が何度かありました。（おそらく誰もが知っているでしょうか？）。気づいたときには、チェックするときには、チェックするものは何もありませんが、すべてがすでにうまく機能しています。しかし、その後また壊れます。たとえば、Amazon マーケットプレイス (MWS) にアップロードした商品でこのようなことが起こりました。ある時点で、読み込まれた在庫が間違っていました (商品の数量と価格が間違っていました)。私たちはそれを理解しました。しかし、それを解決するには、問題をすぐに知ることが重要でした。残念ながら、すべての Amazon サービスと同様に、MWS は少し遅いため、常に遅延が発生していましたが、それでも、問題とその原因となっているスクリプトとの関係を少なくとも大まかに把握することはできました (チェックを行い、スタックしました)それをOKERに送信し、すぐにアラートを受信したことを確認しました）。

最近、ヨーロッパの大規模で高価なホスティング業者によって興味深いケースがコレクションに追加され、当社の顧客が使用しています。突然、すべてのサーバーがレーダーから消えました。まず、顧客自身が (オケラよりも早い!) 作業していたサイトが開かないことに気づき、それについてチケットを作成しました。しかし、ダウンしたのは XNUMX つのサイトだけではなく、すべてのサイトでした。（ナターシャ、私たちはすべてを捨てました！）。ここでオカーは、彼のために点灯したすべてのインジケーターを使って長いフットラップを送り始めました。パニック、パニック、私たちはグルグル走ります（他に何ができるでしょうか？）。それからすべてが上昇しました。データセンターでは定期的なメンテナンス (何年に XNUMX 回) が行われていたことが判明しました。当然、警告を受ける必要がありました。しかし、彼らに何らかの問題が起こったのに、彼らは私たちに警告しませんでした。そうですね、心臓発作が増えれば心臓発作は減ります。ただし、すべてが復元された後は、すべてを再確認する必要があります。自分の手でどうやってやるか想像もつきません。オカー氏は数分ですべてをテストしました。ほとんどのサーバーは単に一時的に利用できなくなっていたものの、正常に動作していたことが判明しました。過負荷になっていた人もいたが、正常に立ち上がった人もいた。すべての損失のうち、XNUMX つのバックアップを失いました。クラウンによれば、このフルバナナが実行されている間にバックアップが作成され、ロードされるはずでした。わざわざ作成することさえしませんでしたが、わずか XNUMX 日後に、すべてが正常でバックアップが作成されたというアラートが届きました。私がこの例をとても気に入っているのは、okarr が事前に考えもしなかった状況で非常に役立つことが判明したからですが、それが監視の目的であり、予測不可能な事態に抵抗することです。

Okerr センサーの場合、可能な限り安価なホスティングを使用します (品質と信頼性が重要ではない場合、相互に保証されます)。そこで、最近、非常に優れていて、非常に安価で、ベンチマークが素晴らしいホスティングを見つけました。しかし...場合によっては、仮想マシンからの発信接続が別の (隣接する) IP から行われていることが判明することがあります。奇跡。 Client_ip モジュールと https://diagnostic.opendns.com/myip 間違った IP を取得します。また、インジケーターのサーバーログから、アップデートもこの隣接 IP から送信されたことが明らかです。今すぐサポートに対処しましょう。平時に気づいてよかったです。ただし、たとえば、アクセスが IP ホワイトリストに従って登録されていることがよくあります。サーバーが時々このように短時間点滅する場合は、この問題を非常に長い間検出することができます。

さて、もう 2 つ – ここでは VPS ホスティングについて話しているので、私たちは常に安価なもの (hetzner、ovh、scaleway) を使用しています。ベンチマークと安定性の両方の点で非常に気に入っています。また、他のプロジェクトにははるかに高価な Amazon EC2 も使用しています。したがって、okerr のおかげで、私たちは情報に基づいた独自の意見を得ることができました。二人とも倒れます。そして、私たちの長期にわたる観察を通じて、hetzner のような安価なホスティングが ECXNUMX よりも著しく不安定であることが判明したとは言えません。したがって、Amazon の他の機能に縛られていないのであれば、なぜこれ以上支払う必要があるでしょうか? 🙂

次は何ですか？

この段階でまだ Okerr から怖がらせていないのであれば、試してみてください。このリンクに直接アクセスできます okarr デモアカウント (今すぐクリックしてください!) ただし、デモアカウントは全員に XNUMX つしかないため、何かをすると、同じアカウント内の他の誰かが同時に妨害する可能性があることに注意してください。または、(より良い) リンク経由で登録してください。オフサイトオーカー - SMS なしですべてが簡単です。本物のメールを使いたくない場合は、mailinator などの使い捨てメールを使用できます (私がお勧めします) getnada.com）。このようなアカウントは時間の経過とともに削除される可能性がありますが、テストには問題ありません。

登録後、トレーニングを受けるように求められます (それほど難しくないトレーニングタスクをいくつか実行します)。初期の制限は非常に小さいですが、トレーニングまたは XNUMX つのサーバーの場合は十分です。トレーニングが完了すると、制限 (インジケーターの最大数など) が増加します。

ドキュメントから - まず第一に WIKI サーバー側とクライアント (オーケル更新ウィキ）。ただし、不明な点がある場合は、サポート (okerr.com) にメールするか、チケットを残してください。すべてを迅速に解決するよう努めます。

真剣に使用していて、これらの増加した制限が十分ではない場合は、サポートに手紙を書いてください。制限を（無料で）増加させます。

サーバーに okerr サーバーをインストールしますか? ここ okerr-dev リポジトリ。クリーンな仮想マシンにインストールすることをお勧めします。その場合は、インストールスクリプトを使用して簡単に実行できます。仮想マシン上では - 制限はありません :-)。繰り返しになりますが、何か起こった場合は、いつでも助けようとします。

私たちのおかげで世界がより信頼できるものになるように、このプロジェクトが軌道に乗りたいと考えています。無料のソフトウェアとサービスのおかげで、世界はよりフレンドリーになり、よりダイナミックに発展しています。ソースは無料の github に保存でき、メールには無料の gmail を使用できます。無料で利用しておりますフレッシュワークスサポートのための。これらのいずれについても、サーバーの料金を支払う必要はなく、ダウンロードして構成する必要も、さまざまな運用上の問題を解決する必要もありません。新しいプロジェクトごとに、すべてのチームがすぐにメール、リポジトリ、CRM を利用できるようになります。これらはすべて非常に高品質で、無料ですぐに利用できます。私たちはモニタリングでも同じであることを望んでいます。小規模な企業やプロジェクトが okerr を無料で使用でき、誕生と成長の段階であっても大人の本格的なプロジェクトの信頼性を備えていることを望みます。

出所： habr.com

Okerr ハイブリッド監視システムの概要