クラスタービジネスログコレクション
古いログ収集アーキテクチャには、実際にはいくつかの問題があります。
Logstashがハングすると、ログが失われるという問題があります。メジャーバージョン間でLogstashをアップグレードする前に、ログは一定期間失われます。
Logstashの背後にあるコンシューマープログラムの1つがハングすると、たとえばESがハングすると、ファイルへのログの書き込みとInfluxDBへの書き込みで問題が発生します。Filebeatは引き続きログをLogstashにプッシュし、ログが失われます。
上記の2つの問題は、コンポーネント間の結合が深刻であることを示しているため、Kubernetesを移行するときに、アーキテクチャにいくつかの調整を加えました。調整されたログ収集アーキテクチャを図2に示します。
KafkaがFilebeatとLogstashの間に追加され、ログを一時的にキャッシュし、ログコンシューマーを分離します。
複数のLogstashインスタンスを起動してファイルの書き込みを処理し、ESを接続し、InfluxDBを書き込んでログ消費プログラムを切り離します。
ビジネスの移行には高速で短時間が必要であり、コンテナstdoutにすべてのログを印刷する時間がないため、コンテナログはホストマシンにマップされ、Filebeatによって収集されてKubernetesでビジネスログの収集が実現されます。
ポイント1と3
の構成変更は次のとおりです 。ポイント1によってもたらされた構成変更は、図3に示すように比較されます。
は3番目の変更の共有に焦点を合わせます。最初に、社内の新しいサービスは、サービスのすべてのログタイプの収集ルールをfilebeat.ymlファイルに直接書き込み、Ansibleを使用して送信する必要があります。すべてのビジネスマシンで再起動してFilebeatします。これにより、filebeat.ymlファイルがますます長くなり、保守が困難になります。また、構成が正しくないと、Filebeatの起動に失敗し、ログを時間内に収集できなくなります。後で、各ビジネスログ収集ルールを小さなyamlファイルに分割し、それらを/etc/filebeat/inputs.d/に保存します。ビジネスFilebeat収集ルールは、自動生成された構成スクリプトによって生成され、Kubernetesクラスターからビジネス名前付けとサービスログを取得します。ビジネスFilebeat構成を自動的に生成し、Ansibleを介して指定されたディレクトリに構成を送信するためのパス。3番目のポイント構成の変更は、以下の図4の3つの部分と比較されます。
上記の点を変更した後、Kubernetesクラスターでのビジネスログの収集を迅速に完了し、ログシステムの安定性を向上させました。これにより、将来のログシステムの定期的なアップグレードが容易になります。
もちろん、システムにも欠点があります。FilebeatはSystemdで起動されます。新しいノードを追加するたびに、Filebeatを一度インストールし、自動スクリプトでこのノードを取得して構成をノードに送信する必要があります。後でKubernetesを使用する予定です。 DaemonSetモードは、Filebeatをデプロイし、新しいサービスが追加されたときにFilebeat構成を自動的に更新し、Kubernetesメソッドを使用してFilebeatのインストールと構成の更新を完了するために使用されます。
クラスターステータスの監視とビジネスステータスの監視
まず、各コンポーネントの役割を紹介します。
Prometheusオペレーター：Prometheusが主導権を握って監視データをプルします。Kubernetesでは、Podにより、スケジュール上の理由でIPが絶えず変化します。手動で維持することはできません。自動検出はDNSに基づいていますが、追加はまだ少し面倒です。Prometheus Operatorの仕事は、ユーザー定義のCRDリソースとコントローラーのセットの実装です。PrometheusOperatorのコントローラーはRBAC権限を持ち、これらのカスタムリソースの変更を監視し、PrometheusServer自体やこれらのリソースの定義に従って構成などを自動的に完了します。自動管理作業。
Kube-state-metrics：ポッド、デプロイ、サービスなど、ほとんどの組み込みKubernetesリソースに関連するデータを収集できます。同時に、独自のデータ、主にリソースコレクションの数とコレクション内の異常の数の統計も提供します。たとえば、いくつのレプリカをスケジュールしますか？現在、いくつ利用できますか？いくつのポッドが実行/停止/終了していますか？ポッドは何回再起動しましたか？などなど、これらのステータス値は、Prometheusルールを追加して、運用および保守担当者と開発者に時間内に通知することで警告できます。
Prometheus：クラスターコンポーネントメトリックとクラスター内のさまざまなリソースステータスメトリック、およびカスタム実装された監視メトリックデータを収集するために使用されます。
AlertManager：Prometheusサーバーなどのクライアントから送信されたアラートを処理します。重複データの削除、グループ化、および電子メールやWebhookなどの正しい受信者へのアラートのルーティングを担当します。
Kubernetesに事業を展開する前に、事前に監視システムとログ収集システムをインストールする必要があります。事業部門等の理由により、当社には複数のクラスター環境があり、クラスター展開エリアごとに一貫性がないため、監視サービスを展開する場合は、採用されたソリューションは、各クラスターに完全な監視システムを作成することです。私たちのビジネスは、PVが大きいビジネスに属しておらず、クラスターサイズが小さいため、クラスターごとの監視システムがより合理的です。監視システムのコンポーネントサービスは別の名前名に保存され、helmの代わりにYAMLを使用して直接インストールされます。クラスター監視アーキテクチャを図5に示します。
からわかるように、主に監視データの3つの側面を収集しました。
クラスターコンポーネント：API、コントローラー、スケジューラー、Kubelet、CoreDNSの5つのコンポーネントのメトリックを収集しました。クラスターはバイナリモードでインストールされるため、一部のコンポーネントメトリック（コントローラー、スケジューラー）データを取得するには、エンドポイントを構成し、サービスと連携する必要があります。 ServiceMonitorを使用した完全なメトリック収集。コントローラのエンドポイント、サービス、およびServiceMonitorの構成を以下の図6に示します。
図6コントローラーの構成
ポッドステータスとリソースステータス：これら2つの側面のメトリックは、kube-state-metricsコンポーネントによって収集されます。kube-state-metricsの機能については、インターネットと公式Webサイトではこれ以上紹介しません。
Prometheus Operator、Prometheus、Alertmanager、およびkube-state-metricsの展開に関するオンラインチュートリアルも多数あります。問題を自分で作成して解決するのも非常に楽しいです。GitHubリポジトリ（https：// github）も確認できます。 com / doubledna / k8s-monitor、インストールを参照してください。
ここでは、Prometheusストレージに焦点を当てます。PrometheusはKubernetesクラスターにデプロイされ、ポッドはいつでも停止しているため、直接ローカルストレージは適切ではありません。もちろん、PVはストレージにも使用できますが、優れた完全なPrometheusリモートが多数あります。ストレージスキームが利用可能であり、リモートストレージスキームが推奨されます。当社はPrometheusリモートストレージソリューションとしてInfluxDBを使用しています。シングルマシンのInfluxDBのパフォーマンスはすでに非常に強力で、基本的に日常のニーズを満たしていますが、彼のクラスターソリューションはオープンソースではないため、単一の障害点の問題があります。したがって、この問題を回避するために他のリモートストレージソリューションを選択できます。図7に示すように、PrometheusはInfluxDB構成に接続します。
アラームの読み取りと書き込み。社内のさまざまなアラームリソースとアラーム情報フォーマットを統合するために、建築部門はアラームAPIプログラムを開発しました。他の部門がそれを使用する必要がある場合は、アラームコンテンツを特定のJson形式に変換し、それをアラームAPIに送信して、アラーム情報を個人にプッシュするだけです。電話、電子メール、SMS、企業のWeChat。したがって、Alertmanagerでは、Webhookモードを使用してJson形式のアラームデータを指定されたAPIに送信します。有能な学生は、デフォルトの構成方法を使用して電子メールやWeChatを送信するのではなく、このモードを使用してアラームデータを自分で処理することをお勧めします。デフォルトのアラーム形式はあまり美しくありません。
グラファナはもちろんデータ表示に使用されます。グラファナの効果を図8と図9に示します。私のグラフィック構成も公式グラファナテンプレートの他の学生のテンプレートに基づいています。あなたに合ったテンプレートを公式ウェブサイトからダウンロードできます。
要約すると、中小企業がオープンソースのPrometheus Operatorパッケージツールを使用してKubernetes監視システムを迅速に構築するのに適しています。このシステムは基本的にKubernetesのビジネスステータスとコンポーネントステータスを監視できます。もちろん、これはシステムにはいくつかの欠点もあります。
イベントの監視/収集：Kubernetesでは、ポッドの展開プロセスでいくつかのイベントが生成されます。これらのイベントは、ポッドのライフサイクルとスケジュールを記録します。また、イベントはクラスターに永続的に保存されません。クラスター内のポッドのスケジュールを把握し、監査やその他の目的でイベントを収集する必要があり、クラスター内のビジネスがますます増えると、クラスター内のイベントをリアルタイムでチェックできない場合、イベントの監視/収集は非常に重要です。 。最近、アリのイベント収集ツールkube-eventerについて知りました。見た目はかなり良いです。興味のある学生は、その作成方法について話し合うことができます。
場合によっては、Prometheusが生成するアラームが多すぎて、頻度が高すぎます。Prometheusルールの一部を調整し、ルールのアラーム頻度を変更しましたが、実際のアプリケーションでは、ノードに障害が発生したときに多数のアラームが発生することがあります。情報の問題。これらのアラームメッセージは便利ですが、情報が多すぎるとトラブルシューティングに支障をきたします。
JVMモニタリング
：古いJVMモニタリングの簡単な紹介図のアーキテクチャ：現在、マイクロサービスの人気により、多くのバックエンドサービスがあり、新しいバックエンドサービスがすぐに追加されます。prometheus.ymlでサービスIP + JVMポートを直接構成することは賢明な選択ではありません。そのため、Consulを使用して自動登録サービス機能を実行し、マシンにデプロイされたすべてのサービスJVMポートアドレスを各ビジネスマシンのPythonスクリプトを介してConsulに送信することを選択します。PrometheusはConsulからサービスJVMメトリックアドレスを取得してサービスを取得します。 JVMデータ。Kubernetesクラスターがなくなる前は、PrometheusはDockerを使用して起動し、リモートストレージはClickHouseを使用していました。ただし、Promehteusに接続されたClickHouseはprom2clickを使用してデータ変換を行う必要があるため、もう1つのコンポーネントのメンテナンスコストが高くなり、このコンポーネントが完全に機能しなかったため、KubernetesクラスターのPrometheusリモートストレージが変更されました。 InfluxDBに。JMXエクスポーターインジェクションサービスも非常に便利に起動できます。ここでは、JMXエクスポーターのjarパッケージと構成ファイルをプログラムの起動コマンドに入れ、JVM関連のメトリックデータを取得するためのポートを指定するだけです。サービス開始コマンドは次のとおりです。
java -javaagent：/data/jmx_prometheus_javaagent-0.11.0.jar=57034：/data/jmx_exporter/jmx_exporter.yml -jar -DLOG_DIR = / log path / service name / -Xmx512m -Xms256m service name.jar
Consulは、図11に示すようにPrometheusで構成されます。PrometheusがビジネスJVMメトリックデータを収集すると、Grafanaで集計表示、アラーム、およびその他の機能を実行できます。
サービスがKubernetesクラスターに移行されると、JMX Exporterの展開方法が変更されました。JMXExporterは、initContainerを介してjarパッケージと構成をビジネスコンテナーと共有します。これにより、jmx_exporterjarパッケージのアップグレードと構成の変更が容易になります。YAMLの構成はここでは具体的に示されていませんが、JVM収集では、Consulによる以前の自動登録方法を廃止し、ServiceMonitor with Serviceを使用してJVMメトリックデータを取得しました。図12に示すようにYAMLを構成し、図13に示すようにGrafanaを構成します。
Kubernetesでは、JVMモニタリングでもいくつかの問題が発生しました。たとえば、プログラムが以前にビジネスマシンに直接デプロイされ、ホストIPが修正されました。JVMがハングすると、プログラムが自動的に再起動します。プログラムがGrafanaでハングしていることがわかります。その時点でのJVMの状態は失われ、マシン上のビジネスイメージは継続的であり、クラスター内では、ポッドIPとポッド名が変更されてサービスポッドがハングするため、Grafanaで以前に停止したポッドを探します。面倒で、グラフがタイムライン上で連続していません。以前、StatfulSetモードを使用して名前を修正することを考えていましたが、最終的にはステートレスの原則に反していると感じ、採用しませんでした。この問題はまだ解決されていません。
Q＆A
Q：インターフェースの応答時間の増加やより頻繁な呼び出しなど、ビジネス監視アラームを実現するにはどうすればよいですか？ A：当社のアプローチは、プログラム自体のインターフェース応答時間を記録し、メトリックデータに公開した後、Prometheusを介して収集し、対応するルールを構成し、アラームメッセージをAlertmanagerにプッシュしてから、設定された応答時間後に運用および保守担当者に送信することです。
Q：クラスターが大きい場合、久部状態は簡単にOOMできますが、どのように解決しますか？ A：クラスターノードはまだ非常に少なく、kube-state-metric OOMの問題は発生していません。クラスターが大きく、kube-stateが大量のデータを収集するため、メモリを増やしても問題ありません。の。
Q：内部アプリケーションのhttp呼び出しはどのように調整されますか？サービスドメイン名を直接使用しますか？または、イントラネットに入力コントローラーはありますか？または他のオプション？ A：サービスの登録と発見にはEurekaを使用していますが、Kubernetesのサービスを使用できることを願っています。Eurekaの呼び出しは少し問題です。
Q：Kubernetesロギングシステムのマルチテナントモデルに関する提案はありますか？ A：マルチテナントがナノスペースを区別する場合は、ログパスまたはkafkaトピックに名前を追加して、区別できるようにすることを検討できます。
Q：クラスターとコンピュータールーム全体のデータ集約を監視することを検討しましたか？ A：以前はプロメテウス連邦法を使用していましたが、国を超えたネットワークに多くの制限があるため、この方法を断念しました。あなたのビジネスが中国にあるか、クラウドサービスプロバイダーまたはネットワーク条件が許せば、あなたはそれを行うことができます。