Elastic:Elasticsearchで摂取遅延を計算し、摂取時間を記憶して観察性を向上させる

Elasticsearchを使用してデータを表示および分析する場合、通常、リモート/監視対象システムで生成されたタイムスタンプを使用した可視化効果と監視およびアラートソリューションが表示されます.ただし、リモートで生成されたタイムスタンプを使用するとリスクがある可能性があります.
リモートイベントの発生とElasticsearchに到達するイベントとの間に遅延がある場合、またはリモートシステム上の時間設定が正しくない場合、重要なイベントはレーダーのスキャン外で発見されない可能性があります.したがって、ドキュメントをElasticsearchに取り込む場合、各ドキュメントの取り込み時間を格納し、各イベントがElasticsearchクラスタに到達するのにどれくらいの時間がかかるかを監視することが一般的に役立ちます.通常の摂取ヒステリシスよりも大きい時間は、摂取プロセスに問題があるか、遠隔システム上の時間設定に問題があることを示す可能性がある.
このブログでは、セットプロセッサがドキュメントに到達したときに、受信ノード(ingest node)をset processorとともに使用して、受信タイムスタンプをドキュメントに追加する方法を示します.このタイムスタンプは、視覚化、監視、アラートに使用できます.
さらに,スクリプトプロセッサ(script processor)を用いて摂取遅延を計算する方法を示す.このヒステリシスは、リモート/監視対象システムでイベントが発生したタイムスタンプと、対応するドキュメントがElasticsearchクラスタに到達した時間との差です.これにより、摂取プロセスに時間がかからないことを確保し、遠隔タイムスタンプが正しく設定されていないかどうかを検出することができる.
摂取タイムスタンプを追加し、摂取ヒステリシスを計算
次に、「ingest_time」と呼ばれる摂取タイムスタンプを追加した摂取パイプの例を示す.また、リモートイベントタイムスタンプとイベントがElasticsearchに到達した時間との間の遅延も計算し、「lag_in_seconds」というフィールドに格納します.
「ingest_time」フィールドは、次の2つの目的で使用されます.

は、Kibanaの可視化における時間フィールドとして使用することができ、監視およびアラート

に使用することができる.

は、ヒステリシス計算に使用される.

各ドキュメントには、リモート/監視システム上の各イベントの発生時間に対応する「event_timestamp」というフィールドがあると仮定します.イベントタイムスタンプフィールドの名前は、あなたのデータとは異なる場合があります.それに応じて変更する必要があります.
Elasticsearchに次のようにパイプを作成します.

PUT _ingest/pipeline/calculate_lag 
{ 
  "description": "Add an ingest timestamp and calculate ingest lag", 
  "processors": [ 
    { 
      "set": { 
        "field": "_source.ingest_time", 
        "value": "{{_ingest.timestamp}}" 
      } 
    }, 
    { 
      "script": { 
        "lang": "painless", 
        "source": """ 
            if(ctx.containsKey("ingest_time") && ctx.containsKey("event_timestamp")) { 
              ctx['lag_in_seconds'] = ChronoUnit.MILLIS.between(ZonedDateTime.parse(ctx['event_timestamp']), ZonedDateTime.parse(ctx['ingest_time']))/1000; 
            } 
        """ 
      } 
    } 
  ] 
}

次に、シミュレーションAPIを使用してパイプをテストできます.

POST _ingest/pipeline/calculate_lag/_simulate 
{ 
  "docs": [ 
    { 
      "_source": { 
        "event_timestamp": "2019-11-07T20:39:00.000Z" 
      } 
    } 
  ] 
}

レスポンスは、「lag_in_seconds」フィールドと「ingest_time」フィールドを含む次のようになります.

{
  "docs" : [
    {
      "doc" : {
        "_index" : "_index",
        "_type" : "_doc",
        "_id" : "_id",
        "_source" : {
          "lag_in_seconds" : 19395388,
          "ingest_time" : "2020-06-19T08:15:28.551500Z",
          "event_timestamp" : "2019-11-07T20:39:00.000Z"
        },
        "_ingest" : {
          "timestamp" : "2020-06-19T08:15:28.5515Z"
        }
      }
    }
  ]
}

最後に、パイプラインを使用して実際のドキュメントをElasticsearchに書き込むことができます.

PUT test_index/_doc/1?pipeline=calculate_lag 
{ 
  "event_timestamp": "2019-11-07T20:39:00.000Z", 
  "other_field": "whatever" 
}

ドキュメントを取得できます.

GET test_index/_doc/1

{
  "_index" : "test_index",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 1,
  "_seq_no" : 0,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "lag_in_seconds" : 19395747,
    "ingest_time" : "2020-06-19T08:21:27.383917Z",
    "event_timestamp" : "2019-11-07T20:39:00.000Z",
    "other_field" : "whatever"
  }
}

インデックス設定でパイプを指定するには
生産配置で取込みパイプを使用する場合は、PUT URLでパイプを指定するのではなく、インデックス設定にパイプを適用することが望ましい.これはindex.default_をpipelineをインデックス設定に追加して、次のようにします.

PUT test_index/_settings 
{ 
  "index.default_pipeline": "calculate_lag" 
}

これでtest_に送信indexのすべてのドキュメントはcalculate_を通過します.URLに追加せずにlagパイプ?pipeline = calculate_lag. 次のPUTコマンドを使用して、正常に動作しているかどうかを確認できます.

PUT test_index/_doc/2 
{ 
  "event_timestamp": "2019-11-07T20:39:00.000Z", 
  "other_field": "This is a new doc" 
}

私たちが摂取したドキュメントを表示するには、次のコマンドを実行します.

GET test_index/_doc/2

次のドキュメントを返す必要があります.

{
  "_index" : "test_index",
  "_type" : "_doc",
  "_id" : "2",
  "_version" : 1,
  "_seq_no" : 1,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "lag_in_seconds" : 19396161,
    "ingest_time" : "2020-06-19T08:28:21.767628Z",
    "event_timestamp" : "2019-11-07T20:39:00.000Z",
    "other_field" : "This is a new doc"
  }
}

ingest lagの使用方法
予想以上の摂取遅延は、摂取プロセスに問題があることを示す可能性がある.したがって、ヒステリシスがしきい値を超える場合は、アラートをトリガーするために使用できます.あるいは、機器学習作業に遅延を入力して、撮像処理時間における予期せぬばらつきを検出するようにしてもよい.
あるいは、分析を実行して、他のホストよりも大きな遅延があるかどうかを検出することができ、クロック設定に問題がある可能性があることを示します.さらに、Kibanaダッシュボードを作成して、履歴と現在のヒステリシス値のグラフィック表示を表示できます.
遅延が予想より大きい場合は、遅延の原因を調査する必要があります.リモートシステム上のクロック設定が正しくないため、リモートクロックを正しく設定する必要があります.遅延が遅い摂取過程に起因する場合は、所望の効果を達成するために摂取過程を調査し、調整しなければならない.ヒステリシスの使用方法は、お客様のニーズによってのみ制限されます.
摂取タイムスタンプの使用
Kibanaでの可視化効果を確認したり、異常を観察したりする際には、最終日または最終日に発生するイベントをよく考慮します.しかし、摂取タイムスタンプではなく、リモートで生成されたイベントタイムスタンプに依存している場合、摂取プロセスの遅延は、一部のドキュメントがいつまでも表示または監視されない可能性があります.たとえば、あるイベントが昨日発生したが、今日クラスタに到着したばかりの場合、リモートで生成されたタイムスタンプが昨日から始まったため、このイベントは今日のイベントのダッシュボードに表示されません.また、昨日ダッシュボードを表示すると、Elasticsearchに保存されていないため、使用できません(今日到着しただけなので).
一方、摂取タイムスタンプを使用してデータを可視化し、アラートを設定すると、イベントがいつ発生しても、最新のイベントをElasticsearchに到達することを考慮することができます.これにより、摂取プロセスを一時的にバックアップしても、イベントを逃さないようにします.
摂取タイムスタンプを使用するもう1つの利点は、イベントタイムスタンプが悪意的に設定されているか、正しく設定されていないかに関係する.たとえば、ハッカーが1980年代の日付にクロックを設定するリモートシステムを監視しているとします.リモートで生成されたイベントタイムスタンプに依存すると、1980年代に保存されたイベントを特定しない限り、悪意のあるユーザーがシステム上で実行するすべてのアクティビティを逃す可能性があります.一方、受信タイムスタンプに依存する場合、リモート・システムが各イベントに提供するタイムスタンプにかかわらず、Elasticsearchクラスタに最近到着したすべてのイベントを考慮することが保証されます.
 
結論
本ブログでは,撮像プロセッサを用いて撮像時間を格納し,撮像過程のヒステリシスを計算する方法と,なぜそうするのかを紹介した.さらに,撮像時間を用いた監視と可視化の利点,およびリモートイベントタイムスタンプを用いたリスクについて概説した.