Loki からのログの収集

Badoo では、新しいテクノロジーを常に監視し、それらが当社のシステムで使用する価値があるかどうかを評価しています。 私たちはこれらの研究の XNUMX つをコミュニティと共有したいと考えています。 ログ集約システムである Loki 専用です。

Loki はログを保存および表示するためのソリューションであり、このスタックはログを分析して Prometheus にデータを送信するための柔軟なシステムも提供します。 XNUMX 月には、クリエイターによって積極的に宣伝されている別のアップデートがリリースされました。 私たちは、Loki が何ができるか、Loki が提供する機能、そして現在使用しているスタックである ELK の代替としてどの程度機能できるかに興味がありました。

ロキとは

Grafana Loki は、ログを操作するための完全なシステムのコンポーネントのセットです。 他の同様のシステムとは異なり、Loki はログのメタデータ、つまりラベル (Prometheus と同じ) のみをインデックス化し、ログ自体を個別のチャンクに圧縮するという考えに基づいています。

ホームページ, GitHubの

Loki で何ができるかを説明する前に、「メタデータのみにインデックスを付けるというアイデア」が何を意味するのかを明確にしたいと思います。 nginx ログの行の例を使用して、Loki のアプローチと、Elasticsearch などの従来のソリューションでのインデックス作成のアプローチを比較してみましょう。

172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

従来のシステムは、多数の一意の user_id および item_id 値を持つフィールドを含む行全体を解析し、すべてを大きなインデックスに保存します。 このアプローチの利点は、ほぼすべてのデータがインデックス内にあるため、複雑なクエリを迅速に実行できることです。 ただし、これにはインデックスが大きくなり、メモリ要件が増大するという代償が伴います。 その結果、フルテキスト ログ インデックスのサイズはログ自体と同等になります。 インデックスをすばやく検索するには、インデックスをメモリにロードする必要があります。 また、ログが増えると、インデックスの成長も速くなり、消費するメモリも増えます。

Loki のアプローチでは、値の数が少ない文字列から必要なデータのみを抽出する必要があります。 このようにして、小さなインデックスを取得し、時間とインデックス付きフィールドでフィルター処理してデータを検索し、正規表現または部分文字列検索で残りをスキャンできます。 このプロセスは最速とは思えませんが、Loki はリクエストをいくつかの部分に分割して並列実行し、短時間で大量のデータを処理します。 シャードとその中の並列リクエストの数は構成可能です。 したがって、単位時間当たりに処理できるデータの量は、提供されるリソースの量に直線的に依存します。

大規模で高速なインデックスと小規模で並列的な総当たりインデックスの間のトレードオフにより、Loki はシステムのコストを制御できます。 ニーズに応じて柔軟に構成・拡張が可能です。

Loki スタックは、Promtail、Loki、Grafana の XNUMX つのコンポーネントで構成されます。 Promtail はログを収集し、処理して Loki に送信します。 ロキがそれらを保管します。 また、Grafana は Loki にデータを要求して表示できます。 一般に、Loki はログの保存と検索だけではありません。 スタック全体は、Prometheus の方法を使用して受信データを処理および分析するための優れた機会を提供します。
インストールプロセスの説明が表示されます ここで.

ログから検索する

特別な Grafana インターフェイスである Explorer でログを検索できます。 クエリは LogQL 言語を使用します。これは Prometheus で使用される PromQL によく似ています。 原理的には、分散 grep と考えることができます。

検索インターフェイスは次のようになります。

リクエスト自体は、セレクターとフィルターの XNUMX つの部分で構成されます。 セレクターは、ログに割り当てられたインデックス付きメタデータ (ラベル) を使用した検索であり、フィルターは、セレクターによって定義されたレコードをフィルターで除外する検索文字列または正規表現です。 以下の例では、中括弧内にセレクターがあり、その後はすべてフィルターです。

{image_name="nginx.promtail.test"} |= "index"

Loki の仕組み上、セレクターなしでクエリを作成することはできませんが、ラベルは必要に応じて一般的に作成できます。

セレクターは、中括弧で囲まれたキーと値の値です。 セレクターを組み合わせて、演算子 =、!=、または正規表現を使用してさまざまな検索条件を指定できます。

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev 

フィルターは、セレクターが受信したすべてのデータをフィルターで除外するテキストまたは正規表現です。

メトリクスモードでは受信データに基づいてアドホックグラフを取得することが可能です。 たとえば、文字列インデックスを含むエントリが nginx ログに表示される頻度を確認できます。

機能の完全な説明はドキュメントにあります。 LogQL.

ログの解析

ログを収集するにはいくつかの方法があります。

• ログを収集するためのスタックの標準コンポーネントである Promtail を使用します。
• Docker コンテナから直接使用して Loki Docker ロギングドライバー。
• Loki にデータを送信できる Fluentd または Fluent Bit を使用します。 Promtail とは異なり、ほぼすべての種類のログに対応する既製のパーサーがあり、複数行のログも処理できます。

通常、Promtail は解析に使用されます。 次の XNUMX つのことを行います。

• データソースを検索します。
• ラベルを貼り付けます。
• ロキにデータを送信します。

現在、Promtail はローカル ファイルと systemd ジャーナルからログを読み取ることができます。 ログが収集される各マシンにインストールする必要があります。

Kubernetes との統合: Promtail は Kubernetes REST API を通じて自動的にクラスターの状態を認識し、ノード、サービス、またはポッドからログを収集し、Kubernetes からのメタデータ (ポッド名、ファイル名など) に基づいてラベルを即座に投稿します。 。

Pipeline を使用して、ログのデータに基づいてラベルを貼り付けることもできます。 Pipeline Promtail は XNUMX 種類のステージで構成できます。 詳細については、 公式ドキュメント、すぐにいくつかのニュアンスに注目します。

1. 解析段階。 これは RegEx と JSON の段階です。 この段階では、ログからデータを抽出して、いわゆる抽出マップを作成します。 必要なフィールドを抽出されたマップにコピーするだけで JSON から抽出できます。または、正規表現 (RegEx) を使用して、名前付きグループが抽出されたマップに「マッピング」されます。 抽出されたマップはキーと値のストアで、キーはフィールドの名前、値はログからの値です。
2. トランスフォームステージ。 このステージには XNUMX つのオプションがあります。変換ルールを設定する変換と、抽出されたマップから変換するためのデータ ソースであるソースです。 抽出されたマップにそのようなフィールドが存在しない場合は、作成されます。 このようにして、抽出されたマップに基づいていないラベルを作成することができます。 この段階では、かなり強力なメソッドを使用して、抽出されたマップ内のデータを操作できます。 Golang テンプレート。 さらに、抽出されたマップは解析中に完全にロードされるため、たとえば、その中の値「{{if .tag}タグ値が存在する{end}}」を確認できるようになることを覚えておく必要があります。 テンプレートは、条件、ループ、および置換やトリムなどの一部の文字列関数をサポートしています。
3. アクションステージ。 この時点で、抽出されたコンテンツを使用して何かを行うことができます。
   • 抽出されたデータからラベルを作成し、Loki によってインデックスが付けられます。
   • ログからイベント時間を変更または設定します。
   • Loki に送信されるデータ (ログ テキスト) を変更します。
   • メトリクスを作成します。
4. フィルタリングステージ。 一致ステージでは、必要のないエントリを /dev/null に送信するか、さらなる処理のために転送することができます。

通常の nginx ログを処理する例を使用して、Promtail を使用してログを解析する方法を示します。

テストでは、nginx-proxy として、変更された nginx イメージ jwilder/nginx-proxy:alpine と、HTTP 経由で自身に問い合わせることができる小さなデーモンを使用してみましょう。 デーモンには複数のエンドポイントがあり、さまざまなサイズ、さまざまな HTTP ステータス、さまざまな遅延の応答をそれらのエンドポイントに提供できます。

/var/lib/docker/containers/ パスに沿って見つかる Docker コンテナからログを収集します。 / -json.log

docker-compose.yml で Promtail を構成し、構成へのパスを指定します。

promtail:
  image: grafana/promtail:1.4.1
 // ...
 volumes:
   - /var/lib/docker/containers:/var/lib/docker/containers:ro
   - promtail-data:/var/lib/promtail/positions
   - ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
 command:
   - '-config.file=/etc/promtail/promtail.yml'
 // ...

ログへのパスを promtail.yml に追加します (構成には「docker」オプションがあり、同じことを XNUMX 行で実行しますが、それほど明確ではありません)。

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # for linux only

この構成を有効にすると、すべてのコンテナからのログが Loki に送信されます。 これを回避するには、docker-compose.yml でテスト nginx の設定を変更し、ログ タグ フィールドを追加します。

proxy:
 image: nginx.test.v3
//…
 logging:
   driver: "json-file"
   options:
     tag: "{{.ImageName}}|{{.Name}}"

promtail.yml を編集し、パイプラインを設定します。 入力には次のタイプのログが含まれます。

{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /api/index HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.096"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /200 HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.000"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}

パイプラインステージ:

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

受信 JSON からフィールド stream、attrs、attrs.tag (存在する場合) を抽出し、抽出されたマップに配置します。

 - regex:
     expression: ^(?P<image_name>([^|]+))|(?P<container_name>([^|]+))$
     source: "tag"

抽出されたマップにタグ フィールドを配置できた場合は、正規表現を使用してイメージとコンテナの名前を抽出します。

 - labels:
     image_name:
     container_name:

ラベルを割り当てます。 抽出されたデータ内で image_name キーとcontainer_name キーが見つかった場合、それらの値は対応するラベルに割り当てられます。

 - match:
     selector: '{job="docker",container_name="",image_name=""}'
     action: drop

ラベル image_name とcontainer_name がインストールされていないログはすべて破棄されます。

  - match:
     selector: '{image_name="nginx.promtail.test"}'
     stages:
       - json:
           expressions:
             row: log

image_name が nginx.promtail.test であるすべてのログについて、ソース ログからログ フィールドを抽出し、抽出されたマップに行キーを使用して配置します。

  - regex:
         # suppress forego colors
         expression: .+nginx.+|.+[0m(?P<virtual_host>[a-z_.-]+) +(?P<nginxlog>.+)
         source: logrow

正規表現を使用して入力行をクリアし、nginx 仮想ホストと nginx ログ行を抽出します。

     - regex:
         source: nginxlog
         expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?

正規表現を使用して nginx ログを解析します。

    - regex:
           source: request_url
           expression: ^.+.(?P<static_type>jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
     - regex:
           source: request_url
           expression: ^/photo/(?P<photo>[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P<api_request>[^/?.]+).*$

request_url を解析してみましょう。 正規表現を使用して、静的データ、写真、API などのリクエストの目的を判断し、抽出されたマップに対応するキーを設定します。

       - template:
           source: request_type
           template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"

テンプレートの条件演算子を使用して、抽出されたマップにインストールされているフィールドを確認し、request_type フィールドに必要な値 (写真、静的、API) を設定します。 失敗した場合は他のものを割り当てます。 request_type にはリクエスト タイプが含まれるようになりました。

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

抽出したマップに含めることができた内容に基づいて、ラベル api_request、virtual_host、request_type、および status (HTTP ステータス) を設定します。

       - output:
           source: nginx_log_row

出力を変更します。 これで、抽出されたマップからクリーンアップされた nginx ログが Loki に送られます。

上記の構成を実行すると、ログのデータに基づいて各エントリにラベルが割り当てられていることがわかります。

留意すべき点の XNUMX つは、多数の値 (カーディナリティ) を持つラベルを取得すると、Loki の速度が大幅に低下する可能性があることです。 つまり、たとえば user_id をインデックスに含めるべきではありません。 これについては、記事「Loki のラベルを使用してログ クエリを迅速かつ簡単に行う方法」 ただし、これはインデックスなしでは user_id で検索できないという意味ではありません。 検索 (データを「取得」) するときはフィルターを使用する必要があり、ここでのインデックスはストリーム識別子として機能します。

ログの可視化

Loki は、LogQL を使用して Grafana グラフのデータ ソースとして機能できます。 次の機能がサポートされています。

• rate — XNUMX 秒あたりのレコード数。
• 一定期間のカウント — 指定された範囲内のレコードの数。

Sum、Avg などの集計関数もあります。 非常に複雑なグラフ (HTTP エラー数のグラフなど) を作成できます。

標準データ ソース Loki は、Prometheus データ ソースと比較して機能が多少制限されています (凡例を変更できないなど) が、Loki は Prometheus タイプのソースとして接続できます。 これが文書化された動作かどうかはわかりませんが、開発者の応答から判断すると、「Loki を Prometheus データソースとして構成するにはどうすればよいですか? · 問題 #1222 · グラファナ/ロキたとえば、「」は完全に合法であり、Loki は PromQL と完全に互換性があります。

Prometheus タイプのデータ ソースとして Loki を追加し、URL /loki を追加します。

そして、あたかも Prometheus のメトリクスを操作しているかのように、グラフを作成できます。

機能の不一致は一時的なもので、開発者は将来的にこれを修正すると思います。

メトリクス

Loki は、ログから数値メトリックを抽出して Prometheus に送信する機能を提供します。 たとえば、nginx ログには、応答ごとのバイト数と、標準ログ形式を一部変更して、応答にかかった時間 (秒) が含まれます。 このデータは抽出して Prometheus に送信できます。

promtail.yml に別のセクションを追加します。

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "response time ms"
           source: response_time
           config:
             buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
   selector: '{request_type=~"static|photo"}'
   stages:
     - metrics:
         http_nginx_response_bytes_sum:
           type: Counter
           description: "response bytes sum"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "response bytes count"
           source: bytes_out
           config:
             action: inc

このオプションを使用すると、抽出されたマップのデータに基づいてメトリクスを定義および更新できます。 これらのメトリクスは Loki には送信されません。Promtail /metrics エンドポイントに表示されます。 Prometheus は、この段階で受信したデータを受信するように構成する必要があります。 上記の例では、request_type=“api” についてヒストグラム メトリックを収集します。 このタイプのメトリクスでは、パーセンタイルを取得すると便利です。 静的および写真については、バイトの合計とバイトを受信した行数を収集して平均を計算します。

メトリクスについて詳しく読む ここで.

Promtail でポートを開きます。

promtail:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

promtail_custom プレフィックスが付いたメトリックが表示されていることを確認します。

プロメテウスのセットアップ。 求人情報を追加:

- job_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

そしてグラフを描きます。

こうすることで、たとえば最も遅い XNUMX つのクエリを見つけることができます。 これらのメトリクスの監視を設定することもできます。

スケーリング

Loki は、シングル バイナリ モードまたはシャード モード (水平スケーラブル モード) のいずれかになります。 1.5 番目のケースでは、データをクラウドに保存でき、チャンクとインデックスは別々に保存されます。 バージョン XNUMX では、XNUMX か所に保存する機能が導入されていますが、運用環境での使用はまだ推奨されていません。

チャンクは S3 互換ストレージに保存でき、水平スケーラブルなデータベース (Cassandra、BigTable、または DynamoDB) をインデックスの保存に使用できます。 Loki の他の部分、ディストリビューター (書き込み用) とクエリア (クエリー用) はステートレスであり、水平方向にも拡張されます。

DevOpsDays Vancouver 2019 カンファレンスで、参加者の 1 人である Callum Styan 氏は、Loki を使用したプロジェクトには、合計サイズの XNUMX% 未満のインデックスを持つペタバイトのログがあると発表しました。Loki がメトリクスとログを関連付けてコストを節約する方法"。

ロキとELKの比較

インデックスサイズ

結果のインデックス サイズをテストするために、上記のパイプラインが構成されている nginx コンテナーからログを取得しました。 ログ ファイルには 406 行が含まれており、合計容量は 624 MB でした。 ログは 109 時間以内に生成され、100 秒あたり約 XNUMX エントリが生成されました。

ログの XNUMX 行の例:

ELK によってインデックス付けされると、インデックス サイズは 30,3 MB になります。

Loki の場合、これにより、インデックスが約 128 KB、チャンク内のデータが約 3,8 MB になりました。 ログは人工的に生成されたものであり、多種多様なデータが含まれていないことに注意してください。 データを含む元の Docker JSON ログを単純に gzip すると、95,4% の圧縮が得られました。クリーンな nginx ログのみが Loki 自体に送信されたという事実を考慮すると、最大 4 MB の圧縮は理解できます。 Loki ラベルの一意の値の合計数は 35 であり、インデックスのサイズが小さいことがわかります。 ELK の場合、ログもクリアされました。 したがって、Loki は元のデータを 96%、ELK は 70% 圧縮しました。

メモリ消費量

Prometheus と ELK スタック全体を比較すると、Loki の「食べる」量は数分の XNUMX になります。 Go サービスが Java サービスより消費量が少ないことは明らかであり、JVM ヒープ Elasticsearch のサイズと Loki に割り当てられたメモリを比較するのは誤りですが、それでも、Loki が使用するメモリがはるかに少ないことは注目に値します。 CPU の利点はそれほど明白ではありませんが、存在します。

スピード

Loki はログをより速く「貪食」します。 速度は多くの要因 (ログの種類、ログの解析の高度さ、ネットワーク、ディスクなど) によって決まりますが、間違いなく ELK よりも高速です (私のテストでは約 XNUMX 倍)。 これは、Loki がインデックスに入れるデータがはるかに少ないため、インデックス作成に費やす時間が短縮されるという事実によって説明されます。 検索速度に関しては、状況は逆です。Loki は数ギガバイトを超えるデータでは著しく速度が低下しますが、ELK の検索速度はデータのサイズに依存しません。

ログから検索する

Loki は、ログ検索機能の点で ELK に大きく劣ります。 正規表現を使用した grep は強力ですが、成熟したデータベースには劣ります。 範囲クエリの欠如、ラベルによる集約のみ、ラベルなしで検索できないことなど、これらすべてが Loki での関心のある情報の検索を制限します。 これは、Loki を使用して何も見つからないという意味ではありませんが、Prometheus チャートで最初に問題を見つけ、次にこれらのラベルを使用してログ内で何が起こったかを探すときのログの操作フローを定義します。

インターフェース

まず第一に、それは美しいです（ごめんなさい、抵抗できませんでした）。 Grafana のインターフェイスは見栄えがしますが、Kibana の方がはるかに機能が豊富です。

ロキの長所と短所

利点の XNUMX つは、Loki が Prometheus と統合されているため、すぐにメトリクスとアラートを取得できることです。 Prometheus から継承したサービスディスカバリがあり、自動的にラベルが付けられるため、Kubernetes Pod からログを収集して保存するのに便利です。

欠点はドキュメントが弱いことです。 Promtail の特徴や機能など、いくつかのことはコードを研究する過程でのみ発見されましたが、幸いにもそれはオープンソースです。 もう 1.0 つの欠点は、解析機能が弱いことです。 たとえば、Loki は複数行のログを解析できません。 もう 2019 つの欠点は、Loki が比較的新しいテクノロジーであることです (リリース XNUMX は XNUMX 年 XNUMX 月でした)。

まとめ

Loki は、小規模および中規模のプロジェクトに適した 100% 興味深いテクノロジーであり、ログの集約、ログの検索、監視、およびログの分析の多くの問題を解決できます。

私たちには、私たちに合った ELK スタックがあり、長年にわたってさまざまなカスタム ソリューションが増えすぎているため、Badoo では Loki を使用しません。 私たちにとって、障害となるのはログの検索です。 100 日あたり約 XNUMX GB のログがあるため、すべてを見つけて、それ以上の情報を迅速に見つけられることが重要です。 グラフ作成と監視には、ニーズに合わせて相互に統合された他のソリューションを使用します。 Loki スタックには明らかな利点がありますが、既に得ている以上のものは得られず、その利点が移行コストを上回ることは確かにありません。

調査の結果、Loki を使用できないことが明らかになりましたが、この投稿が選択に役立つことを願っています。

記事で使用されているコードが含まれるリポジトリは次のとおりです。 ここで.

出所： habr.com