SREWorks v1.5 リリース | リアルタイム ジョブ プラットフォームに基づくオープンソース ログ クラスタリング

v1.0 ～ v1.4 の 4 回の反復を経て、SREWorks のコア ベースは非常に高い安定性と成熟度を示しました。v1.5 バージョンでは、SREWorks 開発チームはコア ベースでデジタル インテリジェンス機能をさらに繰り返し実行しました。同時に、デジタル インテリジェンスの反復プロセスにおいて、SREWorks ユーザーとの高頻度のコミュニケーションも維持しています。一般に人々は監視データに基づくデジタル インテリジェンス機能により注意を払っていることが判明したため、これらの点について詳細な分析を行ったところ、一般的に次の問題に遭遇していることがわかりました。

1. 自社開発の監視システムのデータ量が増加したため、信頼性が低下しました。
2. ログなどのさまざまな種類の非構造化データの導入により、エンジニアリングの複雑さが急激に増加し、リアルタイム パフォーマンスの面で大きな課題が生じています。
3. 単純な表現では、ビジネス多角化の監視ニーズに対応できないことがよくあります。

そのため、多くのユーザーは自社開発の監視システムからフローコンピューティングエンジンFlinkへの移行を選択しますが、Flink Job自体の利用閾値や運用保守が大きな問題となっています。数回の分析と調査の後、SREWorks 開発チームはこれらの問題を 2 つのフェーズに分割することを決定しました。

1. Flink Job を使用するためのしきい値を下げ、SRE が運用とメンテナンスの要件をコンピューティング能力に迅速に変換できるようにし、SRE が真にデータにアクセスできるようにします。
2. SREWorks のエンジニアリング機能を使用して、オープンソースの Flink 運用および保守製品を構築し、Flink の運用および保守の難しさをさらに軽減します。

v1.5版では、まずフェーズ1のオープンソースを完成させます。同時に、リアルタイム運用基盤において、この種のシステムのベストプラクティスとして皆様からご要望いただいているログクラスタリングを導入します。デジタル インテリジェンス機能: Flink ML により、大量のログのリアルタイム集約効率が大幅に向上します。フェーズ 2 に関しては、Flink のインテリジェントな診断ツールである Flink Advisor の概要が近い将来公開される予定ですが、この記事では詳しく説明しません。フェーズ 1 のオープンソース製品であるリアルタイム オペレーション プラットフォームから始めましょう。

リアルタイムオペレーティングプラットフォーム

SREWorks が最初にオープンソース化されたとき、SREWorks には Flink ジョブを管理するための Ververica Platform のコミュニティ バージョンが含まれていたため、しばらくの間、コミュニティ バージョンの vvp の使用に関する質問に答えるのにユーザーとのコミュニケーション時間のほとんどが費やされました。したがって、これらの要件を明確にして洗練した後、リアルタイム処理リンクも運用プラットフォームに統合しました。運用プラットフォームの運用は、スケジュールされた運用とリアルタイム運用に分けられます。

• スケジュールされたジョブは、分単位のジョブ実行スケジュールを提供します。これは、データ量が少なく適時性が低いバッチ処理シナリオに適しています。
• リアルタイム ジョブは、 Flink + Community Edition Ververica プラットフォームに基づいてリアルタイム ジョブ管理を提供します。

多くのユーザー フィードバックを収集した後、SRE の使用の敷居をさらに下げるために、SRE の段階的なオーケストレーション機能をリアルタイム操作に統合することにしました。最終的な機能を次の図に示します。 Flink Job は、管理を容易にするために 3 つの構造に分割されています。

• 入力ソース: Flink のソースソースに対応し、複数の入力ソースが可能です。
• Python 処理: Flink によってまとめられた処理プロセスに対応し、現在は pyFlink をベースとしており、Python スクリプトを直接記述することも、ビジネス ニーズに応じて複数の Python 処理プロセスに分割することもできます。
• 出力: Flink のシンクに対応し、複数の出力が可能です。

入力ソースと出力

入力および出力セクションでは、ユーザーが選択できる Ververica プラットフォームの登録済みコネクタと、パラメーターを構成する際のドロップダウン リマインダーを直接読み取ります。これにより、ユーザーが CREATE TABLE を手動で記述する際のフィールドとパラメーターの省略が大幅に回避されます。

動作環境

Python をよく使用する学生は、Python オペレーティング環境の管理が厄介な問題であることを知っているでしょう。Docker イメージを使用してパッケージ化プロセスを管理すると、時間がかかりすぎます。また、要件を使用して管理すると、次の問題に遭遇することがよくあります。梱包ができないこと。そこで、リアルタイム運用基盤では妥協してPython仮想環境を利用して管理することにしました。

同時に、環境の概念を組み合わせて拡張しました。Flinkのコンテナー イメージや PyFlink のランタイム Jar パッケージなどの一連のオブジェクトは、環境内の設定としてカウントされます。この環境ではすべての可変リソースが統合されるため、SRE メンテナンス操作の複雑さが大幅に軽減され、複数のランタイム リソース間のバージョンの互換性の問題がなくなり、同じ環境内のすべての操作で同じ組み合わせが使用されます。

現在、v1.5 では flink-ml とdefault の 2 つの環境が提供されており、環境の自己管理機能は次のバージョンで開始される予定です。

Flinkジョブの運用保守

リアルタイム ジョブ プラットフォームではより抽象化が行われ、ジョブ送信プロセスが簡素化されていますが、Flink ジョブの運用と保守の複雑さは十分に認識しており、実行中の監視として Flink ダッシュボードを直接使用して、過剰なパッケージ化は行っていません。プラットフォーム 。Flink に慣れている学生がすぐに使い始めて問題のトラブルシューティングを行うのに便利です。次の図は、リアルタイム ジョブ プラットフォームでジョブを開始するための Flink ダッシュボード ページを示しています。

ログクラスタリング

この v1.5 バージョンでは、リアルタイム操作プラットフォームにおいて、ログ クラスタリング アルゴリズムもオープンソース化しました。アルゴリズムの原理については、「Flink ML に基づくインテリジェント O&M アルゴリズム サービスとアプリケーション」を参照してください。この記事では、オープン化の実践を中心に説明します。ソースエンジニアリング。

ログ クラスタリングのアルゴリズム コードは、ディレクトリhttps://github.com/alibaba/SREWorks/tree/master/saas/aiops/api/log-clusteringにあります。

├── db-init.py
├── log-clustering-job
│   ├── pythons
│   │   └── log_cluster_pattern.py
│   ├── settings.json
│   ├── sinks
│   │   └── pattern_output.json
│   ├── sources
│   │   └── log_input.json
│   └── template.py
└── ...

カタログは主に次の 2 つの部分で構成されます。

• db-init.py : 特徴エンジニアリングのためのデータベース初期化。少数の典型的なログ サンプルを使用して、ログ キーワード リストとログ テンプレート機能を初期化する必要があります。
• log-clustering-job/*: ログ クラスタリング アルゴリズム ジョブ。v1.5 バージョンではデフォルトでジョブ プラットフォームにインポートされており、手動で zip パッケージにインポートしても同じ効果が得られます。

次に、このオープンソース プロジェクトに基づいて完全なログ クラスタリングの実践を完了します。この実践の入力は Kafka (SREWorks の組み込み Kafka) のログ ストリームであり、出力は MySQL の機能ライブラリです。

STEP 1 特徴量エンジニアリングの初期化

この演習では、SREWorks のアプリケーション エンジン (AppManager) ログを例として取り上げます。

まず、ラベルname=sreworks-appmanager-server を使用して、AppManager ポッドの名前をクエリします。このラベルは、コレクションの後半で使用されます。

$ kubectl get pods -l name=sreworks-appmanager-server -n sreworks
NAME                                         READY   STATUS    RESTARTS   AGE
sreworks-appmanager-server-c9b6c7776-m98wn   1/1     Running   0          5h39m

次に、Pod の少量のログを初期化ログ サンプルとして抽出し、ファイル名を example.logとして保存します。

kubectl logs --tail=100 sreworks-appmanager-server-c9b6c7776-m98wn -n sreworks > example.log`

example.logのログの内容はおおよそ次のとおりです。

[2023-05-26 21:46:02 525] DEBUG [http-nio-7001-exec-6][o.s.web.servlet.DispatcherServlet:119]- GET "/realtime/app-instances?stageIdList=prod&appId=&clusterId=1id&optionKey=source&optionValue=app", parameters={masked}
[2023-05-26 21:46:02 526] DEBUG [http-nio-7001-exec-6][o.s.w.s.m.m.a.RequestMappingHandlerMapping:522]- Mapped to com.alibaba.tesla.appmanager.server.controller.RtAppInstanceController#list(RtAppInstanceQueryReq, HttpServletRequest, OAuth2Authentication)
[2023-05-26 21:46:02 527] DEBUG [http-nio-7001-exec-6][o.s.w.s.m.m.a.RequestResponseBodyMethodProcessor:268]- Using 'application/json', given [*/*] and supported [application/json, application/*+json]
[2023-05-26 21:46:02 527] DEBUG [http-nio-7001-exec-6][o.s.w.s.m.m.a.RequestResponseBodyMethodProcessor:119]- Writing [TeslaBaseResult(code=200, message=SUCCESS, requestId=null, timestamp=1685137562527, data=Pagination( (truncated)...]
[2023-05-26 21:46:02 527] DEBUG [http-nio-7001-exec-6][o.s.web.servlet.DispatcherServlet:1131]- Completed 200 OK.
..

db-init.pyを使用して、特徴エンジニアリング データベースを初期化します。このアクションにより、データベースにテーブルが追加され、  example.log内のログが特徴行に処理されて、テーブルに保存されます。

pyon3 ./db-init.py example.log --host *** --user *** --password *** --database *** --table***

このデータベースの接続変数を覚えておいてください。次のステップで使用されます。

STEP 2 ジョブパラメータの実行設定と開始

SREWorks でリアルタイム ジョブ プラットフォームを開き、ジョブ「ログ クラスタリング パターン抽出」に対応する [パラメータの実行] ボタンをクリックし、起動パラメータの STEP1 のデータベース接続パラメータを入力します。

入力が完了したら、ジョブを直接クリックして開始できます。ジョブの開始後、[実行中] のステータスをクリックして Flink ダッシュボードに直接ジャンプし、ストリーム コンピューティング処理リンク全体の準備ができていることを確認できますが、まだログ入力がありません。

STEP 3 ログ収集入力とクラスタリング

ilogtail は、Alibaba Cloud のオープンソースの監視可能なツールであり、Alibaba Cloud の収集シナリオで広く使用されています。ilogtail はクラウドネイティブにも非常によく適応しており、DaemonSet の方式を採用して各 Node にプルアップし、Pod に対応するラベルが含まれていれば収集されます。

そのため、ilogtail は運用保守市場を通じて簡単にクラスタにインストールすることができ、同時にインストール時にアプリケーションエンジンからログを収集するための対応する収集ラベルがname=sreworks-appmanager-serverとして設定されます (アプリマネージャー）。

ログ収集が開始されると、Flink ダッシュボードを通じて、元々空いていたリアルタイム処理リンクが突然ビジー状態になり、工場の組立ラインのように各コンピューティング ユニットが常に処理データを送受信していることがわかります。MySQL のパターン テーブルを見ると、ログ機能が処理された後、STEP 2 で定義した MySQL テーブルにドロップされたことがわかります。

特徴テーブルのいくつかの重要なポイントに注目してください。

• 特徴テーブルはログ特徴を収束させたもので、初期段階ではデータ量が急激に増加しますが、一定期間が経過すると新しい特徴がなくなるとデータ量は安定します。
• 特徴テーブルの フィールドパターンは この行のログの概要であり、フィールド top_pattern はクラスタリング後の中央のログの概要です。**top_pattern** を通じて、ログの種類の合計を簡単にカウントできます。また、クラス ログの下にあるそれぞれのログが何かもわかります。

以下の図に示すように、非常に似ているが異なるテキストを持つこれらのデバッグ ログが、同じ **top_pattern** の下に収集されていることがわかります。

ログクラスタリングの実用化

ログ クラスタリング アルゴリズムを中心に、多くのデータ インテリジェンスを実行できます。「Flink ML に基づくインテリジェントな運用および保守アルゴリズム サービスとアプリケーション」の公開事例に焦点を当て、上記のエンジニアリング実践と組み合わせて、完全なリンクを確認できます。

• STEP 3 で確認した機能 (パターン) テーブルは、運用と保守の経験に基づいて SRE がラベルを付けるようガイドするログ ナレッジ ベースにさらに進化させることができます。
• ログナレッジベースに蓄積されたログはQ&AコーパスとしてQ&Aロボットに入力され、ユーザーの問題を迅速に解決し、作業指示を削減します。

ログ クラスタリング アルゴリズムの統合と使用後のフィードバックを楽しみにしていると同時に、SREWorks チームは内部運用効果とフ​​ィードバックに基づいてデジタル インテリジェンスの運用および保守アルゴリズムを磨き続けます。

強化されたエンタープライズ アプリケーションの開発と展開

v1.5 バージョンでは、以下の機能を含む、ベースのアプリケーション開発機能も強化されました。

• エンタープライズ アプリケーションには、企業のマルチバージョン反復ニーズに適応するマルチブランチ開発機能が追加されています。
• エンタープライズ アプリケーション インスタンスは、完全な OAM 視覚化を展開します。

エンタープライズ アプリケーションに関しては、SREWorks の最前線ユーザーの声を組み合わせて、製品の磨き上げと最適化を通じて内部使用のための強力な機能を SREWorks ユーザーに提供することがよくあります。また、クラウドネイティブ アプリケーション開発モデルとデジタル インテリジェンス運用保守システムによって、企業がビジネス価値に焦点を当て、迅速な機能製品開発の繰り返しを実行できるようになることを期待して、この状態を維持していきます。

現在のバージョンから v1.5 にアップグレードする方法

• アップグレードにはベースが含まれており、ページには 5 ～ 10 分間アクセスできなくなる場合がありますので、ご注意ください。
• ユーザーが開発したクラウドネイティブ アプリケーションは影響を受けず (再起動はありません)、SREWorks ゲートウェイからアプリケーションへのトラフィックは中断されます。

git clone http://github.com/alibaba/sreworks.git -b v1.5 sreworks

cd sreworks
./sbin/upgrade-cluster.sh --kubeconfig="****"

使用中に問題が発生した場合は、GitHub で問題やプル リクエストを提起してください。

SREWorks オープンソース アドレス: https://github.com/alibaba/sreworks

共有やコミュニケーションのために、DingTalk グループ (グループ番号: 35853026 ) に参加することも歓迎します~

{{名前}}

{{名前}}