コンテナ内のアプリが複数種類のログを出力する場合の収集方法

こんにちは。アキバです。

この記事は、Elastic Stack (Elasticsearch) Advent Calendar 2020 - Qiita の12日目です。
qiita.com

当社ではリモートワークに移行し始めて9～10か月になろうかというこの頃ですが、リモートワークをされている皆さんはどのような工夫をされているでしょうか？

私はiPad Proを日常的に使って、社内のホワイトボードでやっているような手書き体験の共有をしています。
最近、新しいペーパーライクフィルムを使用することになったのですが、これまでのペーパーライクと触感がガラリと変わり、慣れるまでちょっとぎこちない感じです。

今日は、そんな手書き体験の話とは全く関係ない、ログ収集に関する話です。

何の話か？

定期的に起きる質問

今の時代、アプリケーションをDocker／Kubernetesなどのコンテナ上で動作させることが多くなってきましたが、定期的に以下のような質問が出ます。

コンテナに載せたアプリケーションが複数のログを出力するような場合に、どうやってログを収集するのが良いのか？

コンテナを使わない場合は以下のような形でログ収集することができます。

アプリケーションをコンテナに載せて動かそうとしたときに、通常はFilebeatはコンテナの外に置きたいと思います。
特に、Kubernetesの場合はFilebeatはDaemonSetで動かし、AutoDiscoverによってログ収集対象となるPodを（アプリコンテナの外で）選択します。

こうした構成で、以下のようにコンテナ内で複数種類のログを出力していると、単純にはコンテナ外からログが収集できないわけです。
（もっとも、コンテナ内にログを出力すること自体が悪手であり、ログを活用できないため意味のない行為ではありますが...）

単純にログが１種類ならば、コンソール出力にしてcontainer inputで取得するのが定石かなと思いますが、コンソール出力は複数にできないので、何かしら策を講じる必要が出てきます。

理想的には

お作法的なことを言えば、１つのコンテナで動作するプロセスは１つであり、そのプロセスが出力する（収集対象となる）ログも１種類にしたいところです。
しかしながら、一部のアプリケーションには（アプリケーションの動作ログの他に）以下のようなログを出力するものがあります。

1. アクセスログ - 自分のAPIが呼び出された際の記録（エンドポイント、ステータスコード、応答時間など）
2. 監査ログ - システム／アプリケーションの重要な操作(試行)の記録（操作／権限、ユーザ、成功or失敗など）

どのようにログ収集の仕組みを構築し、Elasticsearch＋Kibanaで可視化するか？をパターンに分けて検討してみたいと思います。

※個人的な見解を含みます。もっと良い方法があるかもしれません。

コンテナ内のアプリが複数種類のログファイルを出力する場合の収集方法

方法１：ログファイルをコンテナ外から参照できるように共有する

Dockerであれば、Volume Mountを使ってホストのディレクトリをコンテナ（のログ出力ディレクトリ）にマウントする方法が可能です。
これにより、ホスト側で動作するFilebeatが、コンテナ内のプロセスが出力したログファイルを参照し、ログを収集することが可能になります。

メリット

1. コンテナが異常終了しても出力したログはホスト側に残るので、欠損（出力したログがElasticsearchに送られない現象）が発生しにくい
2. アプリケーションはログ出力の方式（出力するファイルの数やフォーマット）を変更する必要がない
3. ログの種類ごとのタグ付けはFilebeatで行い、投入先のElasticsearchのインデックス指定をLogstashで行う
4. ログ加工が必要な場合は、Ingest PipelineまたはLogstashを使用可能

デメリット

1. コンテナの可搬性は下がる（DockerComposeを使うことで一部吸収可能だが、ホスト側のディレクトリ準備やuidの統一など一部制約が生まれる）
2. ホスト側でコンテナｘ収集対象ログファイル数のFilebeatを起動する必要がある
3. Kubernetesの場合はこの方式は適用できない

方法２：Filebeatをコンテナ内に入れる

コンテナ内でFilebeatを動かせば、任意のログファイルを収集対象にすることができます。
複数のFilebeatを動かせば、複数のログファイルを収集することができますね。

メリット

1. コンテナの可搬性は高い（イメージに含まれているリソースのみでログ収集が完結する）→ Kubernetesでも実現可能
2. アプリケーションはログ出力の方式（出力するファイルの数やフォーマット）を変更する必要がない
3. ログの種類ごとのタグ付けはFilebeatで行い、投入先のElasticsearchのインデックス指定をLogstashで行う
4. ログ加工が必要な場合は、Ingest PipelineまたはLogstashを使用可能

デメリット

Filebeatをコンテナ内に置くことでいくつかの注意点が発生します。

1. 「どのコンテナから送られてきたログか」を示すには、コンテナ起動時にひと工夫が必要
   （それさえ出来れば、大きなデメリットではない）
   • filebeat.yml に add_docker_metadata の指定を行う
   • dockerがUNIXソケットで通信をしている場合、ホスト側の /var/run/docker.sock をマウント（TCP/IP通信の場合は、hostパラメータにIPアドレスを記載する）
   • 必要に応じて、rootユーザ権限を付与する
2. コンテナの終了タイミングでFilebeatも終了してしまうため、一部のログがElasticsearchに送られず欠損する可能性がある
3. Filebeatを入れて動かす分、わずかにコンテナサイズが肥大化する
4. 設定がコンテナごとに存在するため、Filebeatの設定変更でコンテナの再作成（再起動）が必要になる

方法３：アプリでログの種類がわかるようにタグ付けし、すべてコンソールに出力する

アプリケーションがすべてのログをコンソール出力するように設定すれば、一つのFilebeatを使ってcontainer inputでまとめて収集することが可能です。

メリット

1. コンテナの可搬性は高い（ログ収集に関するリソースをアプリコンテナが持たない）→ Kubernetesでも実現可能
2. コンテナが異常終了しても出力したログはホスト側に残るので、欠損（出力したログがElasticsearchに送られない現象）が発生しにくい
3. コンテナの外でログ収集が可能なので、Filebeat側でコンテナを区別してタグ付けが可能
4. コンテナにFilebeatを含める必要がないため、イメージの肥大化やライフサイクルの依存がない

デメリット

1. アプリケーション側でログ出力先とフォーマット、特に種類がわかるようにするタグ付けが必要（初期の設計または設計変更が必要となる）
2. 1つのFilebeatで処理をするため、設定できるタグや送信先は1つになる
   ログの種類ごとにElasticsearchのインデックスを分けたり、ログ加工が必要になる場合は、Logstashが必須（Ingest Pipelineだけでは実現できない）

共通：Kibanaでの可視化について

いずれの場合も、Elasticsearchに投入するまでの過程でタグ付けやログ加工、インデックスの振り分けを行えますので、Kibana（LogsやVisualize）で可視化する際の要求に対しては柔軟な設定が可能です。
（どの段階で加工・振り分けを行うか？の違いがあるため、システムの変更／構成管理のしやすさで制約が発生する可能性があります）

逆の言い方をすると、どのような可視化をするか？に沿ってこれらの処理を決める必要があります。
タグ付けやログ加工はそれほど頻繁に変わるものではないですが、コンテナのライフサイクルに影響を与えないことを考えると、Filebeatはコンテナの外にいることが望ましいと思います。

まとめ

Docker単独／Kubernetes上で動かすか、アプリケーション側の対応や変更が可能かによって選択肢が変わってくる部分があるかと思いますが、個人的には方法３がベターなのかなと思っています。
アプリケーション側で最初の設計さえ行えれば、それ以外のログ収集に関する要素をアプリケーション側から切り離すことができるのが最大のメリットだと思います。

ログ収集は後からでも始められますが、システム構築の設計段階からこういったことを考慮しておくと運用がしやすくなるのではないかと思いますので、参考にしていただければと思います。

それでは。

Acroquest Technologyでは、キャリア採用を行っています。

• ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発
• Elasticsearch等を使ったデータ収集／分析／可視化
• マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
• 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

世界初のElastic認定エンジニアと一緒に働きたい人Wanted！ - Acroquest Technology株式会社のデータサイエンティストの求人 - Wantedlywww.wantedly.com

ソースからビルドしてElastic Stackの最新バージョンを触ってみる

こんにちは、ノムラです。
この記事はElastic Stack (Elasticsearch) Advent Calendar 2020 の7日目になります。

目次は以下です。

はじめに

Elastic Stackはご存じの通り、OSSの製品であるため、ソースコードがGit上に公開されています。
github.com
github.com

このソースをビルドすることで開発中の最新バージョンもお試しで触ることができます。
そこで今回は、実際にビルドしてみて、Elastic Stack 8.0を触ってみたいと思います。

環境情報

環境：AWS
OS：Amazon Linux 2 AMI (HVM)
インスタンスタイプ：t2.large
Java：14.0.2

Elasticsearchをビルドする

Elasticsearchのビルドにはgradleを利用します。
まずはgradleのインストールから、と思うところですが、gradlewが作成されているため、実際はgit cloneをしてコマンドを実行するだけです。

ソースを github から clone する

$ sudo yum install -y git
$ git clone https://github.com/elastic/elasticsearch.git

Elasticsearchをビルドする

$ cd elasticsearch/
$ ./gradlew :distribution:archives:linux-tar:assemble

ビルドされたファイルは distribution ディレクトリに出力されます。

$ ls distribution/archives/linux-tar/build/install/elasticsearch-8.0.0-SNAPSHOT
bin     data  lib          logs     NOTICE.txt  README.asciidoc
config  jdk   LICENSE.txt  modules  plugins

Elasticsearchを起動する

$ cd distribution/archives/linux-tar/build/install/elasticsearch-8.0.0-SNAPSHOT
$ bin/elasticsearch
$ curl localhost:9200
{
  "name" : "es-sample",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "tQl8J8LZQPOCfqESKImJRQ",
  "version" : {
    "number" : "8.0.0-SNAPSHOT",
    "build_flavor" : "default",
    "build_type" : "tar",
    "build_hash" : "966189fa6a42882c127742c43c52d29f668c3f48",
    "build_date" : "2020-12-05T16:13:39.509805Z",
    "build_snapshot" : true,
    "lucene_version" : "8.7.0",
    "minimum_wire_compatibility_version" : "7.11.0",
    "minimum_index_compatibility_version" : "7.0.0"
  },
  "tagline" : "You Know, for Search"
}

無事起動できました。
次はKibanaを構築したいと思います。

Kibanaを構築する

Kibanaのソースからの起動方法は公式ドキュメントの開発者ガイドに記載されています。
www.elastic.co

ソースを github から clone する

$ git clone https://github.com/elastic/kibana.git

nvm をインストールする

公式ドキュメントに従ってnvmをインストールします。
github.com

$ wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash
$ nvm use
$ nvm install 14.15.1

yarn をインストールする

同様に公式ドキュメントに従ってyarnをインストールします。
classic.yarnpkg.com

$ curl --silent --location https://dl.yarnpkg.com/rpm/yarn.repo | sudo tee /etc/yum.repos.d/yarn.repo
$ curl --silent --location https://rpm.nodesource.com/setup_12.x | sudo bash -
$ sudo yum install -y yarn

bootstrapを実行し必要なパッケージをインストールする

bootstrap実行の前にgccをインストールします。
後述のyarnコマンド実行のために必要です。

$ sudo yum -y install -y gcc*

yarnコマンドを実行し、パッケージをインストールします。

$ yarn kbn bootstrap

Kibanaを起動する

$ yarn start

Kibanaが起動できました。

おまけ

今回は利用しませんでしたが、以下のコマンドを実行することで、Kibanaプロジェクトのみで動作確認をすることもできます。便利ですね。

$ yarn es snapshot --license trial

まとめ

ソースからビルドして、Elastic Stack 8.0を触ってみました。
これで、今後いち早く気になる最新機能を触ることができそうです。

それでは。

Acroquest Technologyでは、キャリア採用を行っています。

• ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発
• Elasticsearch等を使ったデータ収集／分析／可視化
• マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
• 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

世界初のElastic認定エンジニアと一緒に働きたい人Wanted！ - Acroquest Technology株式会社のデータサイエンティストの求人 - Wantedlywww.wantedly.com

Elastic Stack Advent Calendar 2020（2020年のElastic Stackを振り返る）

こんにちは、アクロクエストテクノロジー株式会社でElastic Stackのコンサルティング業務を担当している吉岡です。本記事は、Elastic Stack (Elasticsearch) Advent Calendar 2020 の1日目の内容になります。

目次は以下です。

Elastic Stackリリース概要

• Elastic Stack Version 7.6.0リリース（2020年2月）
• Elastic Stack Version 7.7.0リリース（2020年5月）
• Elastic Stack Version 7.8.0リリース（2020年6月）
• Elastic Stack Version 7.9.0リリース（2020年8月）
• Elastic Stack Version 7.10.0リリース（2020年11月）

2020年1月時点での最新バージョンはVer.7.5.1、2020年12月1日時点での最新版はVer.7.10.0です。メジャーバージョンは変わっていないので、たった5回マイナーバージョンアップしただけのように見えますが、マイナーチェンジとは思えない多くの機能が盛り込まれています。

Elastic Stackのユースケース

Elastic Stackは、Search(検索)、Observe(ログ監視)、Protect(セキュリティ)という3つのユースケースで利用されます。以降は、ユースケース別に特徴的な機能強化／新機能をまとめてみます。

■Search(1)検索機能

検索の高速化

• Ver.7.0で一部のクエリに導入されたblock-max WANDが、Ver.7.6では日付や数値のソート処理にも適用されました。結果、ソート付きクエリのパフォーマンスが10倍以上になりました。Elasticsearchの根幹である検索が速くなるのは、クエリを利用するKibanaや各種アプリにとっても嬉しいですね。

ヒープメモリ使用量の大幅削減（同時検索性能の向上）

• セグメント内のTerm Indexはすべての検索可能フィールドの情報を含みますが、相対的に「_id」フィールドの占めるサイズが大きくなります。Ver.7.7では「_id」のTerm Indexがヒープからディスクへ移動。ヒープメモリ使用量を大幅に削減しました。その結果、Ver.7.6以前と7.7以降ではクエリの同時検索性能が大きく改善しています。

非同期検索のサポート

• Elasticsearchは高速検索が求められるケースでよく利用されますが、高速検索を必要としないユースケースも存在します。例えば、大量データをフィルタリングなしで集計するような重いバッチ統計処理であったり、安価なストレージ(HDD)を搭載したDataNodeに対する検索などです。Ver.7.7で登場した非同期検索は、これらのユースケースに最適です。
• 非同期検索のタイムアウトはデフォルトで5日間（長い！）。クエリが完了しなくても途中までの結果を部分的に取得することも可能。ちなみに、Kibana Ver.7.7から、DashboardとDiscoverは非同期検索に対応しています。（一定時間内にクエリが完了しないと、処理が完了するまで非同期検索を続けるかどうかの確認ダイアログが表示される）

■Search(2)エンタープライズ検索

エンタープライズ検索ソリューションの整理

• Ver.7.6において、SaaSサービス検索を実現する「Enterprise Search」を「Workplace Search」に名称変更。
• エンタープライズ検索のソリューション名を「Elastic Enterprise Search」とし、これまでバラバラだった3つの製品をElastic Enterprise Searchの下に位置付けるように変更。（ようやくElasticの検索製品群がきれいに整理されました）

- App Search（アプリ検索）
- Site Search（Webサイト検索）
- Workplace Search（SaaSサービス検索）

Enterprise SearchがKibana UIと統合

• Kibana Ver.7.9から、Enterprise SearchがKibana UIから利用可能になりました。（Kibanaのメニューがさらに縦長に・・・）

■Observe(1)ログ監視／可視化

新アラートフレームワークの統合

• これまでElastic StackのAlertingはすべてWatcherが担っていました。が、利用した方は分かると思いますが、シンプルな閾値通知以外は複雑なJsonを実装する必要があり、生産性も保守性も高くありません。そこで、Kibanaに新しいアラートフレームワークが導入されました。このアラートフレームワークは、Kibanaの各種機能と統合され、SIEM、APM、Metrics、Uptimeなどの各機能画面からアラートをUIから簡易に作成することができるため非常に便利です。

ダッシュボード連携機能

• Kibana Ver.7.8でダッシュボード間のドリルダウン機能が実装され、複数ダッシュボードを活用したデータ分析が容易になりました。また、Ver.7.10ではドリルダウン機能にWebアプリへのURL連携機能が追加されました。

■Observe(2)機械学習による異常検知

教師あり機械学習の強化

• これまではモデル構築／評価までしか対応できませんでしたが、Ver.7.6で「Inference Processor」が実装され、推論も可能になりました。例えば、Ver.7.6で標準搭載の109言語に対応した「言語識別モデル」を利用すると、多言語のテキストデータをElasticsearchに登録するタイミングで言語を推論し、言語毎に別のインデックスに登録するなどが非常に簡単に実現できます。

サービスヘルス監視機能

• Ver.7.8から、Elastic APMに機械学習が算出するヘルス指標を各種サービスマップに追加する機能が新規追加。

■Protect(1)セキュリティ分析

プレビルド検知ルール

• Elastic SIEMはVer.7.6から大きく進化します。このバージョンでは機械学機能が統合されたSIEM検知エンジンおよびMITRE ATT&CK™ナレッジベース準拠のプレビルド検知ルールがリリース。クエリ／モデルベースの異常検知によりマルウェア等の自動検知ができるようになりました。以降、バージョンアップの度に様々なルールが追加され、Ver.7.10時点で316個のプレビルドルールが搭載されています。

ケースマネジメント機能

• SIEMのTimeline機能で脅威の調査を行い、必要に応じてKibanaから外部のインシデント管理システムに起票や更新ができます。Ver.7.7では対応ツールはServiceNowITSMだけですが、以降のバージョンでJIRA／IBM Resilientにも対応します。

Elastic Agent

既存のBeatsの統合エージェントとして、Ver.7.9からElastic Agentが導入されました。Elastic AgentはElastic Securityの要となる重要機能で、3つの特徴があります。

1. セットアップコストが低い：1種類のエージェントで40種類以上のデータを収集可能であり、1コマンドでセットアップ可能（収集データに合わせて必要ファイルを自動ダウンロード）
2. メンテナンスコストが低い：全てのエージェントをKibanaで一元管理可能であり、Kibanaからエージェントのバージョンアップ／設定変更（例：取得データの追加）が可能
3. データ加工処理を自動実行： データ送信時にElastic Common Schemaへ自動でデータ加工し、多様なデータソースを横断的に検索可能

Endpoint Securityの一部がBASICライセンスで利用可能に

• Ver.7.9から、Endpoint Securityの一部がBASICライセンスで利用可能になりました。

Event Query Language（EQL）の導入

• Ver.7.9でセキュリティイベント検索用言語としてEQLを導入。EQLは時系列の複数ドキュメントに跨った条件を検索することができ、サイバー攻撃をしかけるマルウェア等の特徴的な活動をルール化／検知が可能になります。Ver.7.10では検知ルールの定義にEQLがサポートされ、柔軟に検知ルールをカスタマイズすることができます。

まとめ

2020年のElastic Stackを振り返って、特徴的な機能強化／新機能をピックアップしてみました。Search(検索)、Observe(ログ監視)、Protect(セキュリティ)、３つのユースケースが満遍なく強化されていますが、特にセキュリティに関しては機能追加のスピードが速く、目が離せません。

Elastic Stack

Acroquest Technologyでは、キャリア採用を行っています。

• ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発
• Elasticsearch等を使ったデータ収集／分析／可視化
• マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
• 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

【データ分析】
Kaggle Masterと働きたい尖ったエンジニアWanted！ - Acroquest Technology株式会社のデータサイエンティストの求人 - Wantedlywww.wantedly.com

ElasticON Security Japanに参加してきました！

こんにちは、ノムラです。

Elastic社のイベントである、「ElasticON Security Japan」が11/05に開催されました。
最近は各ソリューション毎のElastic社のイベントが多く開催されており、新しい知識や刺激を得る機会が多く、とても充実しています。

今回のイベントもオンライン上の開催となり、専用のウェブサイト上で配信を観たりコミュニケーションを取れる形式となっています。

増大するセキュリティリスクに対して、どのようにElastic Stackを活用していくかについて、
テクニカルセッションとユーザ事例のセッションの発表がありました。

カンファレンス概要

アジェンダ

1. オープニング
2. 基調講演 Elastic Security その進化とビジョン
3. Elastic Security 包括的な可視性の確立
4. 脅威検知を自動化する
5. Elastic Security Operationalize
6. ユーザ事例
7. クロージング

今回はその中で、

• 基調講演 Elastic Security その進化とビジョン
• Elastic Security 包括的な可視性の確立
• ユーザ事例

についてご紹介します。

セッション内容

1. 基調講演 Elastic Security その進化とビジョン

Elastic Securityの概要や、今後のビジョンについてのセッションでした。

概要

昨今のセキュリティ課題に対して、Elastic Securityがどのように対応していくかについての紹介でした。

今後のビジョン

既存のWindows、Linuxの端末のOSに追加して、より広域なユースケースへの適用を打ち出していくそうです。

DNSやネットワーク機器等の社内に構築されたセキュリティ基盤からクラウドサービス等へも適用可能なため、非常に広いユースケースに対応していると思いました。

2. Elastic Security 包括的な可視性の確立

次は、セキュリティのデータ分析に関する４つの課題に対して、どのようにElastic Securityを活用し対応するかについてのセッションでした。

どんなデータを収集するか／どのようにデータを収集するか

データ収集はElastic Agentを活用することで、よく利用されるプロダクトのログは簡単に収集を開始することができます。
もちろんECS(Elastic Common Schema)に合わせてデータを登録することで、オリジナルフォーマットのログであっても分析することが可能です。

私自身試しに触ってみた際に、端末へのエージェントのインストールから収集開始までが非常に簡単だったこと(Windows OSへの適用は５分位で可能でした）はとても驚きました。

どのようにデータを管理するのか？

Hot-Warmアーキテクチャを有効に活用することで、効率的にデータを管理することが可能です。
また去年からFreezeインデックスも利用可能となり、より大量のデータを保持／管理することが可能となりました。
詳しくは下記ブログをご参照ください。
www.elastic.co

どのように実行可能にしていくか？

現状で200以上標準で用意されている、検知ルールを活用することで、多様な攻撃を検知することが可能です。
またカスタマイズルールも作成可能なため、標準機能だけでは網羅できない部分もカバーできるようになっています。

3. ユーザ事例の紹介

①Elastic Cloud を利用したセキュリティ監視の事例（横河電機株式会社 塩崎氏）

外部委託していたセキュリティ監視業務を、Elastic Cloud + Elastic Securityを活用することでグローバルで統合した事例の紹介でした。
グローバルの各拠点毎に異なるソリューションを利用しセキュリティ監視を行っていたため、統合的に監視することが可能なElastic Stackを採用したとのことです。

また個人的に気になったのは収集したデータの可視化／分析の部分です。
全てのリージョンを一覧で可視化した、Overviewのダッシュボードから各リージョン、各製品毎のダッシュボードへドリルダウンしていく構成は、
先日のElasticON Globalのブログでも記載したダッシュボード同士を移動できるドリルダウン機能が活用されているのかな、と想像を膨らませていました。
（ElasticON Globalについては下記のブログをご覧ください）
acro-engineer.hatenablog.com
acro-engineer.hatenablog.com

②大規模スレットインテリジェンス基盤の運用事例 Elasticセキュリティ活用ケース紹介（株式会社ラック 山城氏、ザナシル アマル氏）

グローバルに設置したハニーポッドへの攻撃ログの分析基盤として、Elastic Stackを採用した事例についての紹介でした。

この事例紹介では特になぜElastic Stackを採用したのか？という点についての話が勉強になりました。

コスト面だけでなく、様々な切り口からの可視化、データ投入後のデータ加工が可能であるため、Elastic Stackを採用したとのことでした。
私自身も普段Elastic Stackを活用している中で感じるメリットの１つです。

まとめ

今回ご紹介できなかった、他セッションではElastic Securityの検知ルールの詳細や、検知ワークフローについて紹介されているので気になった方は後日ビデオが公開されると思いますので、是非ご覧ください。

簡易にデータ収集／分析を始めることができ、かつ非常に多くの検知ルール、検知用機械学習ジョブが標準で利用可能なElastic Securityは非常に強力なソリューションだと思いました。
現場で実際に活用できるように、引き続き情報を仕入れていきたいと思います。

それでは。

Acroquest Technologyでは、キャリア採用を行っています。

• ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発
• Elasticsearch等を使ったデータ収集／分析／可視化
• マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
• 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

世界初のElastic認定エンジニアと一緒に働きたい人Wanted！ - Acroquest Technology株式会社のデータサイエンティストの求人 - Wantedlywww.wantedly.com

ElasticON Global 2020 最速レポート！2

こんにちは、ノムラです。

以下の最速レポートの続きになります。
acro-engineer.hatenablog.com

私からは「ElasticON Global 2020」のセッションのうち、Keynote以外の各セッションのうち面白かったものをご紹介します。

セッション内容

Security analytics with Elastic at Square Enix

あのSquare Enixのセッションで、データ分析、SIEM関連の内容でした。

このセッションで印象的だったのは当初はデータ分析のために、導入をしたElastic StackがSIEMにおいても価値を発揮した、ということです。
Elastic Stackが多方面の課題を解決できる機能を備えたツールであり、かつ拡張性が高いからこその話だと思いました。

1つのツールで検索、データ分析、機械学習、SIEM等様々な要件に対応でき、複数の軸において、利益を得ることができるのはElatic Stackの大きな強みだと思います。

Securing the Elastic Stack for free

昨年ElasticsearchのSecurity機能の一部がBASICライセンスで利用可能となりました。（詳細については以下のブログをご覧ください）
www.elastic.co

本セッションはそのBASICライセンスで利用可能な機能についての解説でした。
個人的にはRBACとSpaceを用いた権限管理についてデモも交えながらの解説で勉強になりました。

Advanced tips for visualizing and presenting data in Kibana

本セッションは去年末に登場したKibana Lens、7.8で登場したダッシュボード同士を移動できるドリルダウン機能を用いた可視化についての解説でした。
特に今後利用したいと思ったのは、ダッシュボード同士を移動できるドリルダウン機能です。

この機能を利用すると、分析／フィルタ条件を保持しながら移動することができます。
これまでユースケースによっては１つのダッシュボードに大量のビジュアライズを配置した結果分析画面として分かりにくく、かつ画面表示速度が遅くなることがありました。
しかし、複数のダッシュボードに分割してダッシュボード間の移動の仕組みを作ることで、よりシンプルな画面で効率的にかつ高速に分析を実施することができます。

まとめ

以前までは高速さやスケールアウトの容易さを打ち出していましたが、今回はそれは前提として、

　・データ投入後の柔軟なデータ加工、分析
　・他機能、サービスとの連携が容易

等の更なる強み、アピールポイントを打ち出していたように感じました。
これからもどんどん便利になるElastic Stackを使いこなしていきたいですね。

それでは。

Acroquest Technologyでは、キャリア採用を行っています。

• ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発
• Elasticsearch等を使ったデータ収集／分析／可視化
• マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
• 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

世界初のElastic認定エンジニアと一緒に働きたい人Wanted！ - Acroquest Technology株式会社のデータサイエンティストの求人 - Wantedlywww.wantedly.com

ElasticON Global 2020 最速レポート！

こんにちは、@shin0higuchiです😊

Elastic最大のイベントである、「ElasticON Global 2020」が 10/13~10/15で開催されました。
今年はオンラインでの開催となり、専用のウェブサイト上で配信を観たりコミュニケーションを取ったりする形式となっていました。
早速参加レポートをお届けします。

専用ウェブサイト

カンファレンス概要

アジェンダ

全部で、100近いセッションがありました。
今回は３日間の開催でしたが、厳密には２日分のセッションがあり、
後半２日間は、各地域のタイムゾーンに合わせて同一内容を配信する形になっています。

セッションの一覧は下記のURLから確認することができます。
www.elastic.co

ここからは、いくつかのセッションをピックアップして、内容を簡単にまとめます。

セッション内容

Building great search experience

Enterprise Search の検索UIに関する話でした。
簡単にUIを組み立てられる Reference UI と、より細かいカスタマイズをするための Search UI について、デモを交えて紹介されました。
Pagination、Sorting、Facet、AutoCompletion など、検索UIに必要な基本機能は一通り揃っており、非常に短時間で検索UIを構築することが可能です。

www.elastic.co
www.elastic.co

Opening Keynote

例年通り、CEOの Shay Banon 氏によるプレゼンテーションでキーノートが始まりました。

Ingest Managerの話や...

最近のKibana新機能たちの話...

他にも、Searchable Snapshotや、Schema on Read (runtime fields) の話などがありました。

Elastic Stack Keynote

このセッションでは、Opening Keynoteで紹介されたものを、より詳しく説明するような内容でした。
個人的には、耐障害性を担保してコストを削減できる Searchable Snapshotの話が興味深く、是非活用してみたいと思いました。
（Amazon Elasticsearch Serviceの Ultra Warm Nodeに対抗する形になるのでしょうか）

他のセッションについては、別記事で紹介予定です。お楽しみに！

Acroquest Technologyでは、キャリア採用を行っています。

• ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発
• Elasticsearch等を使ったデータ収集／分析／可視化
• マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
• 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

世界初のElastic認定エンジニアと一緒に働きたい人Wanted！ - Acroquest Technology株式会社のデータサイエンティストの求人 - Wantedlywww.wantedly.com

ElasticStack7.9新機能紹介

こんにちはElastic Certified Engineerのノムラです。

昨日、Elastic Stackの7.9がリリースされました。
今回も魅力的な機能が追加されました。

そこで、追加された機能のうち特に面白いと思う機能をご紹介します！

EQL(Event Query Language)

エンタープライズライセンスで利用可能となったSIEM向けの新機能です。
ネットワークログやシステムログのような時系列データに対して、マルウェア等の侵入から感染、不正操作までの一連のイベントを簡単に検索可能とします。
www.elastic.co

検索方法

マルウェアが侵入、インストールされたケースを想定し検索を実行します。
以下のような独自クエリで検索が可能となります。

GET /my-index-000001/_eql/search
{
  "query": """
    sequence
      [ process where process.name == "regsvr32.exe" ]
      [ file where (file.size > 0 and stringContains(file.name, "scrobj.dll")) ]
  """
}

条件として、通常のmatch検索だけでなく、sizeの指定やstringContains等のメソッドが利用可能です。

またsequenceを利用することで、検索時の条件を時系列の順に指定可能です。
上記では、
　１ドキュメント目：process.nameが"regsvr32.exe"であるドキュメントを検索
　２ドキュメント目：fileフィールドのsizeパラメータが0より大きく、かつfile.nameフィールドの値に"scrobj.dll"を含むドキュメントを検索
と各シーケンス毎に条件を指定しています。

検索結果

検索結果は以下です

{
  "is_partial": false,
  "is_running": false,
  "took": 60,
  "timed_out": false,
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "sequences": [
      {
        "events": [
          {
            "_index": "my-index-000001",
            "_id": "OQmfCaduce8zoHT93o4H",
            "_version": 1,
            "_seq_no": 3,
            "_primary_term": 1,
            "_score": null,
            "_source": {
              "@timestamp": "2099-12-07T11:07:09.000Z",
              "event": {
                "category": "process",
                "id": "aR3NWVOs",
                "sequence": 4
              },
              "process": {
                "pid": 2012,
                "name": "regsvr32.exe",
                "command_line": "regsvr32.exe  /s /u /i:https://...RegSvr32.sct scrobj.dll",
                "executable": "C:\\Windows\\System32\\regsvr32.exe"
              }
            }
          },
          {
            "_index": "my-index-000001",
            "_id": "yDwnGIJouOYGBzP0ZE9n",
            "_version": 1,
            "_seq_no": 4,
            "_primary_term": 1,
            "_score": null,
            "_source": {
              "@timestamp": "2099-12-07T11:07:10.000Z",
              "event": {
                "category": "file",
                "id": "tZ1NWVOs",
                "sequence": 5
              },
              "process": {
                "pid": 2012,
                "name": "regsvr32.exe",
                "executable": "C:\\Windows\\System32\\regsvr32.exe"
              },
              "file": {
                  "path": "C:\\Windows\\System32\\scrobj.dll",
                  "name": "scrobj.dll"
              }
            }
          }
        ]
      }
    ]
  }
}

既存のQuery DSLでは実現できない、時系列の順（マルウェアの侵入から不正操作までの順）で条件を指定して検索できるのはかなり便利な機能だと思います。

Data Streams

BASICライセンスから利用可能な時系列データの読み書きを簡単に管理することができる機能です。
Data Stream機能を利用することで、1インデックスの作成単位の設定（年月日、サイズ）をILM画面から設定可能となります。
www.elastic.co

特徴

通常、時系列ログを扱うときには複数のインデックスを作る必要があり、管理が複雑化していました。
例えば、「index-a-202008」「index-a-202009」「index-a-202010」... と月毎にインデックスを作成していました。

DataStreamを利用すると、単一のインターフェースを提供し、インデックス名を意識せず単一の名前で扱うことができます。
またインデックスの作成単位や、そのローテート期間等の管理をGUIから一括で行うことが可能です。

利用方法

利用方法は以下です

インデックスの作成単位を設定する

下記の設定では、25GB毎に新しいインデックスを作成するように定義しています

PUT /_ilm/policy/my-data-stream-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "25GB"
          }
        }
      }
    }
  }
}

Index Templateを定義する

SettingsにLife Cycle Policyを定義します。

PUT /_index_template/my-data-stream-template
{
  "index_patterns": [ "my-data-stream*" ],
  "data_stream": { },
  "priority": 200,
  "template": {
    "settings": {
      "index.lifecycle.name": "my-data-stream-policy"
    }
  }
}

Data Streamを作成する

「my-data-stream-alt」が読み書きの指定対象となります。

PUT /_data_stream/my-data-stream-alt

運用がかなり楽になりそうな機能だと思っており、是非実際に導入してみたい機能です。

Wildcard Datatypeの追加

最後は、Wildcard Datatypeです。
7.9から追加された新しいデータ型でWildcard検索の高速化に利用可能なデータ型です。

特にカーディナリティが高いフィールドに対して、Wildcard Query、Regexp Queryを利用する際、このWildcard Datatypeを利用することで従来のText、Keyword型よりもかなり高速に検索できるそうです。

利用方法

以下のようにIndex Mappingのデータ型にWildcard Datatypeを指定することで、利用可能です

PUT my-index-000001
{
  "mappings": {
    "properties": {
      "my_wildcard": {
        "type": "wildcard"
      }
    }
  }
}

PUT my-index-000001/_doc/1
{
  "my_wildcard" : "This string can be quite lengthy"
}

POST my-index-000001/_doc/_search
{
  "query": {
      "wildcard" : {
          "value": "*quite*lengthy"
        }
  }
}

より詳細が知りたい方は、昨日投稿されたElastic社のブログも参考になると思います。
www.elastic.co

最後に

今回も内容が濃いリリースでした。

特に、最近のリリースからは
　・SIEM
　・データ加工を簡単にする
という部分に力を注いでいるように感じます。

ますます便利になるElasticStackを引き続き使い倒していきたいです！

Acroquest Technologyでは、キャリア採用を行っています。

• ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発
• Elasticsearch等を使ったデータ収集／分析／可視化
• マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
• 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

世界初のElastic認定エンジニアと一緒に働きたい人Wanted！ - Acroquest Technology株式会社のデータサイエンティストの求人 - Wantedlywww.wantedly.com