はじめに Architecture Design Grp で エンジニア をしている大塚です。 New Relic Advance: Tokyoというイベントに参加してきました。 New Relicのこれからについて、さまざまな発表がありましたので、簡単にまとめさせていただきました。 今回はCEOなどの登壇もあり、見応えのあるイベントでした！ TL;DR New Relicが日本リージョン（国内データセンター）を追加予定で、データ保管要件とレイテンシ面でメリット 生成AI（Analyzer + MCPなど）でアラート調査の初動を短縮し、運用定着を加速する事例が紹介された New Relic Lensで外部DBやDWHなどにクエリし、NRQLで既存データと結合して分析できる イベント概要 日程：2026/03/12 16:00 ~ 18:00 会場：八芳園 全体の所感 New RelicのCEOなどが登壇するようなイベントで、今まで参加したイベントとは雰囲気がだいぶ違いました。 生成AI時代なので、AIの活用を加速させる内容が多かったです。 AI for New RelicとしてAIアシスタントやSRE Agentなどの紹介があり、インシデントなどの対応フローの自動化などが大きなトピックでした。 New Relic for AIとしてMCPの紹介や、ほかプラットフォームとの統合についての紹介もありました。 基調講演でもAIとNew Relicのデータを用いてインシデントやアラート対応を効率化させるという話があったので、BASEでも取り込んでいこうと感じました。 セッション / トピック 1) 日本リージョン追加！ newrelic.com 日本にNew RelicのDCを設立するというお話です。 セキュリティやプライバシー要件的にNew Relicに保存できなかった（海外リージョンのため）データも日本国内にデータが保存されるようになることで、より幅広いデータを集約することが可能になります。 レイテンシなどのパフォーマンスにも寄与するような大きなトピックでした。 2) 生成AIで加速させるNew RelicのEnabling speakerdeck.com blog.kinto-technologies.com New Relicを組織に浸透させるための取り組みにAIを組み合わせて、活用を加速させるというお話でした。 勉強会やドキュメントなどのコンテンツをいくら揃えても、それぞれのエンジニアにはそれぞれのタスクがあるので、時間を使って活用してもらうのは難しいという課題が挙げられていました。 New Relicを用いて、計装→検知→調査→解消までのサイクルは回せるようになるが、結局は人の目や手で対応をする必要があるので非効率という課題が残ってしまっていました。 その課題に対してNew Relic Analyzerという仕組み（AIによる分析）を導入することで、初期調査の時間が大幅に短縮され、MCPを用いた対話型にすることで日常業務への定着も進んだとのことでした。 BASEではアラートはSentryで調査はNewRelicという構造になっているので、現状を維持しても良いがNew Relicを活用できていない部分も大きいと感じました。 インシデントやアラートの対応サイクルを改めて見直し、AIを導入した新しい仕組みづくりをしてみても良いかもしれない。。。 3) New Relic Lens docs.newrelic.com New Relic外のデータソースに対してクエリを実行することが可能になりました。 クエリ結果に対してNRQLでNRDBのデータとjoinして分析・可視化できるようです。 現状対応しているのは以下 クラウド データ ウェアハウス : Snowflake 、 Redshift 、 ClickHouse リレーショナルデータベース : PostgreSQL 、 MySQL 、 SQL Server ドキュメントデータベース : MongoDB 、 Elasticsearch スプレッドシート : Google Sheets データレイク : Iceberg メトリクスと監視 : Prometheus 、 AWS CloudWatch BASEでの活用の今後の展望 アラート対応やインシデント対応の実態調査 New Relic Analyzer的な機能の実装が可能かどうか New Relic Lensを利用してNew RelicからMySQLのデータをクエリできるようにする（可能か？の調査から） 最後に 生成AIの活用が進む中で、アプリケーション監視についてもこれらの技術を用いる必要性を感じました。 今回のイベントの内容はBASEでも活用できる内容が多かったので、積極的に取り入れることで社内のAI Observabilityを向上させていきたいと思います。 こうした生成AIを活用した取り組みは各社行っていると思いますが、BASEでも積極的に開発やサービスに取り入れています。 binc.jp

はじめに こんにちは、WEAR開発部バックエンドブロックの小山です。普段は弊社サービスである WEAR のバックエンド開発を担当しています。 WEARではハイブリッド検索などの新たな検索体験の実現を目指しています。その実現に必要な ハイブリッド検索 はOpenSearch 2.11で導入された機能です。Elasticsearch 7.10.2では利用できないため、Amazon OpenSearch Service上のエンジンをOpenSearch 2.11.0以上へ移行する必要がありました。今回はOpenSearch 2系の最新バージョンだった2.19.0を採用しました。本記事では、この移行にあたり対応したSearchkickの導入、ダブルライト戦略によるインデクシング移行、カナリアリリースによる段階的トラフィック切り替えについてご紹介します。 目次 はじめに 目次 抱えていた課題 Elasticsearch 7.10.2の限界 既存のアーキテクチャ 課題を解決したアプローチ 1. Searchkickとopensearch-rubyへの移行 elasticsearch-modelからSearchkickへ elasticsearchからopensearch-rubyへ 既存Searchableとの並存 2. インデクシングのダブルライト戦略 embulk-outputの変更 RakeタスクとDigdagワークフローの追加 3. クエリ種別ごとの動作確認 確認の目的と方針 確認対象の抽出方法 確認したクエリ種別 確認方法 4. 負荷試験 試験条件 試験結果 5. カナリアリリースによる段階的トラフィック移行 リリーススケジュール 各段階での確認項目 確認結果 効果と得られた知見 移行後のアーキテクチャ Searchkickとopensearch-rubyへの移行による保守性向上 並行稼働時のインデクサー移行方法 カナリアリリースの有効性 おわりに 抱えていた課題 Elasticsearch 7.10.2の限界 WEARではコーディネートや動画、メイクの投稿検索にAmazon OpenSearch Service上でElasticsearch 7.10.2を利用していました。しかし、以下の課題がありました。 新機能の利用不可：WEARではハイブリッド検索などの新たな検索体験を計画していたが、Elasticsearch 7.10.2はハイブリッド検索に対応しておらず、実現できない状態 サポートの先行き不透明：Elasticsearch 7.10.2は、Amazon OpenSearch Serviceで提供される最終のオープンソースElasticsearchバージョン。今後の新機能追加やセキュリティパッチの提供が見込めない状態。Elasticsearch 7.1〜7.8の標準サポートは2025年11月に終了しており、7.10.2も同様のサポート終了が予想される状態。AWS側でもOpenSearchエンジンへの移行を推奨 ライブラリのメンテナンス性： elasticsearch gem 7.14.0以降ではAmazon OpenSearch Service上のElasticsearchへ接続不可。gemのバージョンを7.13.3に固定せざるを得ず、アップデートができない状態 既存のアーキテクチャ WEARの検索基盤は、以下のシステム構成で運用していました。 検索機能： elasticsearch-model gemを利用し、検索メソッドを提供。内部では elasticsearch gemが提供する Elasticsearch::Client を通じてOpenSearch Serviceと通信 マッピング定義： elasticsearch-model gemを利用し、モデルにマッピング定義を記述 インデックス操作： elasticsearch gemを利用し、Rakeタスクによるインデックス作成、エイリアス切り替え、旧インデックス削除、ドキュメント削除 インデクシング：トラフィックを考慮し、レコード更新ごとではなくDigdagワークフローと Embulk による定時バッチ（日次の洗い替えと差分更新）でインデクシング 課題を解決したアプローチ 今回の移行では、既存ドメインのインプレースアップグレードではなく、OpenSearch 2.19.0の新規ドメインを作成し、エンドポイントを段階的に切り替える方法を採用しました。その理由は以下の通りです。 インプレースアップグレードでは、Elasticsearch 7.10.2からOpenSearch 2.19.0へ直接移行できず、 OpenSearch 1.xを経由する必要がある elasticsearch-model / elasticsearch から searchkick / opensearch-ruby へのgem移行が必要であり、アプリケーションコードに破壊的変更が生じる 検索基盤は影響範囲が大きいため、カナリアリリースで段階的にリリースしたい これらを踏まえ、Elasticsearchをダウンタイムなく移行させるために以下のアプローチで段階的に進めました。 Searchkickとopensearch-rubyへの移行 インデクシングのダブルライト戦略 クエリ種別ごとの動作確認 負荷試験 カナリアリリースによる段階的トラフィック移行 1. Searchkickとopensearch-rubyへの移行 移行前後のgemの対応関係は以下の通りです。 責務 Elasticsearch利用時 OpenSearch移行後 検索機能 elasticsearch-model （内部で elasticsearch を利用） searchkick （内部で opensearch-ruby を利用） マッピング定義 elasticsearch-model searchkick インデックス操作 elasticsearch 直接利用 opensearch-ruby 直接利用 elasticsearch-modelからSearchkickへ 検索機能とマッピング定義については、既存の elasticsearch-model の代わりに、 searchkick に移行しました。Searchkickを選定した理由は以下の通りです。 OpenSearchを公式にサポートしている リポジトリが継続的にメンテナンスされている nested型への対応など、 elasticsearch-model との互換性がある reindex時のアトミックなエイリアス切り替えが組み込まれているほか、ハイブリッド検索やセマンティック検索にも対応しており、高度な機能を備えている elasticsearchからopensearch-rubyへ インデックス操作のRakeタスクでは、 elasticsearch を使用していました。OpenSearch移行に伴い、これを opensearch-ruby に置き換えました。 - require 'elasticsearch' - client = Elasticsearch::Client.new(client_options) + require 'opensearch-ruby' + client = OpenSearch::Client.new(client_options) client.indices.update_aliases(...) client.indices.delete(...) opensearch-ruby は elasticsearch とAPIの互換性が高いため、クライアントの初期化部分とエラークラスの変更で、既存のインデックス操作ロジックをそのまま利用できました。 唯一の例外がインデックス作成タスクで、ここではSearchkick経由でマッピング定義を取得して作成しています。 task :create_index , [ :index_name ] => :environment do |_, args| index_class = index_class_name(args[ :index_name ]).singularize.capitalize.constantize index = Searchkick :: Index .new(args[ :index_name ]) model_config = index_class.search_index.index_options # Searchkickからマッピング取得 index.create(model_config) # Searchkick経由で作成 end このように、マッピング定義はSearchkickに一元化しつつ、その他のインデックス操作は opensearch-ruby を直接使用する構成としました。 既存Searchableとの並存 WEARでは、モデルごとに *Searchable というconcernを定義し、 elasticsearch-model を利用した検索用のデータ定義とマッピング定義を集約していました。 移行期間中は、Elasticsearchを利用するサーバーとOpenSearchを利用するサーバーを並行稼働させる必要がありました。そこで、モデルごとに *OpensearchSearchable concernを新設し、既存の *Searchable と並存させる構成をとりました。 既存の *Searchable はElasticsearch用のconcernです。 # 既存: Elasticsearch用 module Searchable extend ActiveSupport :: Concern # elasticsearch-model を利用したデータ定義とマッピング定義 end 新設した *OpensearchSearchable はOpenSearch用のconcernです。 # 新規: OpenSearch用 module OpensearchSearchable extend ActiveSupport :: Concern included do searchkick index_name : Rails .configuration.x.application[ :opensearch ][ :index_name ], settings : Rails .configuration.x.application[ :opensearch ][ :settings ], callbacks : false , merge_mappings : true , mappings : search_mappings def search_data # searchkick を利用したデータ定義 end end module ClassMethods def search_mappings # searchkick を利用したマッピング定義 end end end merge_mappings: true を指定することで、独自に定義したマッピングをSearchkickの自動生成マッピングにマージしています。 callbacks: false を指定することで、Searchkickの自動インデクシングを無効化し、既存のEmbulkによるインデクシングとの競合を防いでいます。 2. インデクシングのダブルライト戦略 移行期間中、ElasticsearchとOpenSearchの両方にデータを投入するダブルライトを実施しました。WEARのインデクシングは日次バッチによる洗い替え方式のため、ダブルライトを開始した時点で既存データも含めてOpenSearchに自動で同期されます。そのため、既存データの移行作業を別途行う必要はありませんでした。 embulk-outputの変更 前述の通り、既存の構成ではEmbulkを介して、BigQueryからデータを取得してElasticsearchにインデクシングしていました。インデクシング時のBigQueryのクエリコストが高額なため、OpenSearchにもインデクシングを行う際に単純にジョブを複製してしまうと、費用が2重に掛かってしまうという課題がありました。 そこで、embulk-outputの出力先をElasticsearchとOpenSearchの両方に向けることで、SQLの実行は一度だけで双方にデータを転送できるようにしました。 移行前はElasticsearchのみに出力していました。 # Elasticsearchへのインデクシング時 out : type : elasticsearch mode : insert nodes : - { host : {{ elasticsearch_host }} , port : {{ elasticsearch_port }}} index : {{ elasticsearch_index }} { % Elasticsearchの設定値 % } ダブルライト時は type: multi を使い、ElasticsearchとOpenSearchの両方に出力しました。 # ElasticsearchとOpenSearchにダブルライトするインデクシング時 out : type : multi outputs : - type : elasticsearch mode : insert nodes : - { host : {{ elasticsearch_host }} , port : {{ elasticsearch_port }}} index : {{ elasticsearch_index }} { % Elasticsearchの設定値 % } - type : elasticsearch mode : insert nodes : - { host : {{ opensearch_host }} , port : {{ opensearch_port }}} index : {{ opensearch_index }} { % OpenSearchの設定値 % } ダブルライトのために embulk-output-multi を新たに導入し、複数出力先への分岐を実現しました。OpenSearch側の出力も type: elasticsearch を指定しています。 embulk-output-elasticsearch はOpenSearchとのAPI互換性により、そのままOpenSearchへの出力にも利用できました。 RakeタスクとDigdagワークフローの追加 OpenSearch向けのインデックス操作のRakeタスクとDigdagワークフローを作成し、OpenSearchに対しても実行できるようにしました。 # 既存のElasticsearchのインデックス作成 +create_index_elasticsearch: sh>: ... rails "elasticsearch:create_index[${index_name}]" # 追加したOpenSearchのインデックス作成 +create_index_opensearch: sh>: ... rails "opensearch:create_index[${index_name}]" 3. クエリ種別ごとの動作確認 OpenSearch移行後にすべてのクエリ種別が正常に動作するかをQA環境で確認しました。 確認の目的と方針 Elasticsearchに送信されるクエリの種別ごとに、OpenSearch上でも同等の結果が返ることを確認しました。クエリ種別が重複するエンドポイントは確認対象外とし、効率的に網羅性を担保しました。 確認対象の抽出方法 確認対象の抽出は以下の手順で行いました。 対象エンドポイントの洗い出し：リポジトリ内でElasticsearchのQueryクラスを呼び出している箇所をリストアップ WEAR Webの対象画面の特定：Webマスタ仕様書から対象エンドポイントが使用されている画面を確認 クエリの特定：APIのリクエストパラメーターから生成されるOpenSearchのクエリJSONを特定し、使用されているクエリ種別を分類 確認したクエリ種別 以下のクエリ種別を対象に、WEAR iOS・Android・Webの各プラットフォームで動作確認を実施しました。 分類 クエリ種別 検索クエリ term 、 terms 、 range 、 nested 、 bool （ filter / must_not / must / should ）、 function_score 、 exists ソート sort ページング from 、 size グループ化 collapse 複合検索 msearch 確認方法 WEAR iOS・Android・Webの各プラットフォームで、以下の方法で確認しました。また、対応するRSpecテストを実行し、OpenSearchに対するクエリが正常に動作することはCI上で確認しています。 WEAR iOS・Android：QA環境のAPIに対してcurlコマンドでリクエストを送信し、レスポンスを確認。 WEAR Web：ブラウザ上で対象画面を操作し、APIレスポンスと画面表示を目視確認。 すべてのクエリ種別で正常な動作を確認し、負荷試験に進みました。 4. 負荷試験 本番リリース前に、OpenSearchクラスターがElasticsearch利用時と同等のリクエスト量を処理できるかを確認するため、QA環境で負荷試験を実施しました。 試験条件 QA環境のOpenSearchクラスターを本番環境のElasticsearchと同等のスペックに設定 検索エンドポイントのRedisキャッシュを無効化し、OpenSearchへの直接的な負荷を計測 k6を用いて、各検索エンドポイントに対して本番のピーク帯のMAX rps相当のリクエストを6時間継続 試験結果 レイテンシ ：Datadog APMで各検索エンドポイントのp99レイテンシを直近1か月の平均と比較した結果、OpenSearchがボトルネックとなるレイテンシ劣化は観測されなかった エラー ：Datadog APMで各検索エンドポイントを確認した結果、OpenSearch起因のエラーは発生しなかった クラスターメトリクス ：本番のピーク帯MAX値相当のリクエストを6時間継続した。CPUUtilizationはリクエスト量に対して許容範囲内、JVMMemoryPressureは本番環境と同程度であり、各種メトリクスに大きな影響はなかった この結果をもとに、カナリアリリースによる段階的な本番投入を判断しました。 5. カナリアリリースによる段階的トラフィック移行 本番リリースでは、カナリアリリースによって段階的にトラフィックを移行しました。 リリーススケジュール 日時 内容 2025/9/30 13:00 canary podの作成、APIの正常確認、1％リリース 2025/9/30 17:00 10％リリース 2025/10/1 14:00 50％リリース 2025/10/2 13:30 100％リリース 2025/10/2〜10/6 正常性の継続監視 各段階での確認項目 各段階で以下の項目を確認し、問題がなければ次の段階に進みました。 OpenSearchのレイテンシ比較とエラー確認：Datadog APMでOpenSearchとElasticsearchのレイテンシを比較し、劣化がないことを確認。OpenSearchのエラーがないことを確認。 各検索エンドポイントのレイテンシ比較とエラー確認：Datadog APMで各検索エンドポイントのレイテンシを比較し、劣化がないことを確認。OpenSearch起因のエラーがないことを確認。 クラスターメトリクス：SearchLatency、IndexingLatency、CPUUtilization、JVMMemoryPressureを監視し、劣化がないことを確認。 インデックスの整合性：ElasticsearchとOpenSearchのドキュメント件数に差異がないことを確認。 確認結果 OpenSearchでレイテンシが低い傾向を確認した（平均・最小・最大いずれもOpenSearchの方が高速） OpenSearch起因のエラーが発生しなかった OpenSearchでJVMMemoryPressureがやや高い傾向にあったが、MAXでも60％未満であり問題なかった CPUUtilizationはOpenSearchの方が低い傾向だった 100％リリース後の監視でも劣化が見られず、移行完了を判断した 効果と得られた知見 移行後のアーキテクチャ 移行後の検索基盤は、以下のシステム構成になりました。 検索機能： searchkick gemを利用し、検索メソッドを提供。内部では opensearch-ruby gemが提供する OpenSearch::Client を通じてOpenSearch Serviceと通信 マッピング定義： searchkick gemを利用し、モデルにマッピング定義を記述 インデックス操作： opensearch-ruby gemを利用し、Rakeタスクによるインデックス作成、エイリアス切り替え、旧インデックス削除、ドキュメント削除 インデクシング：既存のDigdagワークフローと Embulk による定時バッチ（日次の洗い替えと差分更新）でのインデクシングを継続 Searchkickとopensearch-rubyへの移行による保守性向上 elasticsearch-model から searchkick 、 elasticsearch から opensearch-ruby に移行し、以下の効果と知見がありました。 OpenSearchの将来的なバージョンアップへの追随が容易になった reindex処理のアトミックなエイリアス切り替えが組み込みで利用可能になった ハイブリッド検索の機能が利用可能になった opensearch-ruby はAPI互換性が高く、Rakeタスクの移行コストが低かった 並行稼働時のインデクサー移行方法 ダブルライト戦略により、以下のメリットがありました。 ElasticsearchとOpenSearchを並行稼働させることで、いつでも切り戻し可能な状態を維持 Embulkを利用した既存のインデクシングパイプラインを最小限の変更で拡張 移行時のクエリコスト増大を防止 Digdagワークフロー層での制御により、アプリケーションコードへの影響を最小化 カナリアリリースの有効性 段階的なトラフィック移行により、以下の知見が得られました。 1％リリースと10％リリースで、JVMMemoryPressureの変動が大きく見られた。これは、リリース後の低トラフィック時にキャッシュヒット率が低いことに起因する可能性が高く、50％リリース以降は安定した。 検索基盤のような影響範囲の大きいミドルウェアの移行にはカナリアリリースが有効であることを実感した。 おわりに 本記事ではWEARにおけるElasticsearch 7.10.2からOpenSearch 2.19.0への移行プロセスを紹介しました。同様の移行を検討している方の参考になれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

サイオステクノロジー株式会社 Saman これから5回に分けて、Elastic Securityを使ったセキュリティ監視の基礎を、手を動かしながら学んでいきます。第1回はデータの取り込みと、Discover・Securityの両方で見えるようにするまでの環境構築です。 今後の予定 本シリーズでは、以下の流れでステップアップしていきます。 第2回：KQLでログを読み、最初の検知ルールを作る 第3回：Timelineで攻撃の全体像を追う 第4回：EQL / ES|QLで攻撃を自動検出・集計する 第5回：ノイズを減らし、運用できるルールにする 本ブログでは、ローカル環境に構築した Elastic Stack v9.3 を使用して、実際に手を動かしながら検証・解説を行っています。 Elastic Stack はオープンソースとして利用可能であり、クラウド版（Elastic Cloud）も無料トライアルで試すことができます。 Elastic Stack（ダウンロード） https://www.elastic.co/jp/downloads/ Elastic Cloud（無料トライアル） https://www.elastic.co/jp/cloud/cloud-trial-overview 目次 この記事を読むと何ができるか まず覚えておく5つの用語 演習データについて Step 1：ファイルをアップロードする Step 2：インデックス名を確認する Step 3：マッピングを設定する Step 4：Security画面でもデータを見えるようにする Step 5：時間範囲の調整 取り込みの確認 よくあるつまずきポイント この章のまとめ 第1回チェックリスト この記事を読むと何ができるか サンプルデータ82件をElasticsearchに正しく取り込める Discoverでイベントを確認できる Elastic Securityの画面でも同じデータが見える状態になる まず覚えておく5つの用語 このシリーズ全体で繰り返し登場します。最初に整理しておきます。 イベント ：1件のログです。「ログイン成功」「プロセス起動」「外部への通信」など、「何かが起きた記録」です。このガイドでは 82件のイベントを使います。 ルール ：イベントを条件で監視し、怪しいものを自動で見つけるための設定です。「ログイン失敗が起きたら知らせる」という定義がルールです。 アラート ：ルールの条件に一致した結果です。イベントは「原材料」、アラートは「調査が必要かもしれない、という通知」です。アラートが出たからといって、必ずしもインシデントではありません。 Timeline ：複数のイベントを時系列で並べながら、攻撃の流れを追う調査画面です。第3章で詳しく使います。 Case ：調査メモ、担当者のアサイン、証拠をひとまとめにする入れ物です。チームで調査内容を共有するために使います。 演習データについて 今回使うサンプルデータ security_sample_v2.ndjson の概要です。 項目 値 形式 NDJSON（1行1イベント） 件数 82件 時間範囲 2025-03-18 09:45:00 〜 10:30:00（UTC） 取り込み先インデックス名 training-security-logs このデータはElastic Securityの学習用に設計されたサンプルです。完全な本番用ECSデータではありませんが、Discover・検知ルール・Timelineの練習には十分使えます。 ECS（Elastic Common Schema）とは 異なるログソース間でフィールド名を統一するための共通ルールです。WindowsイベントログでもLinux syslogでも、「ログイン失敗」は event.outcome: "failure" と書く、という約束事です。この共通化によって、複数製品のログを横断して検索・分析できるようになります。 Step 1：ファイルをアップロードする KibanaのIntegrationメニューから「Upload file」を開きます。画面遷移はバージョン差が出ることがあるので、迷ったら Global Search で検索して開いてください。 またはKibanaのホーム画面から「Upload a file」を選んでもかまいません。 security_sample_v2.ndjson を画面にドラッグ&ドロップします。Kibanaがファイルを自動解析します（数秒かかります）。 インデックス名を logs-training-security に指定します。 Step 2：インデックス名を確認する 「Advanced options」を展開し、「Create data view」にチェックが入っていることを確認します。このチェックが入っていると、取り込みと同時にDiscover用のデータビューが自動で作成されます。 training-security-logs ⚠️ このインデックス名は正確に入力してください 第2回以降の手順でこの名前を前提にしています。別の名前で取り込むと、後の手順がすべて動作しません。 Step 3：マッピングを設定する 「Mappings」欄に次のJSONを入力します。マッピングとは「このフィールドを日付として扱う」「これをIPアドレスとして扱う」という型の定義です。省略すると集計や範囲検索が正しく動かなくなります。 { "properties": { "@timestamp": { "type": "date" }, "agent.type": { "type": "keyword" }, "ecs.version": { "type": "keyword" }, "event.kind": { "type": "keyword" }, "event.type": { "type": "keyword" }, "event.category": { "type": "keyword" }, "event.action": { "type": "keyword" }, "event.outcome": { "type": "keyword" }, "source.ip": { "type": "ip" }, "destination.ip": { "type": "ip" }, "destination.port": { "type": "integer" }, "network.bytes": { "type": "long" }, "network.transport": { "type": "keyword" }, "network.protocol": { "type": "keyword" }, "user.name": { "type": "keyword" }, "host.name": { "type": "keyword" }, "process.name": { "type": "keyword" }, "process.pid": { "type": "integer" }, "process.command_line": { "type": "wildcard" }, "process.parent.name": { "type": "keyword" }, "dns.question.name": { "type": "keyword" }, "rule.name": { "type": "keyword" } } } マッピングが重要な理由： @timestamp が date 型でないと、時間範囲で絞り込めない network.bytes が long 型でないと、合計・最大値の集計ができない source.ip が ip 型でないと、CIDRなどのIP範囲検索が使えない 設定を確認したら「Import」をクリックします。「Import complete」と表示されれば成功です。 Step 4：Security画面でもデータを見えるようにする Data Viewを作っただけでは、SecurityアプリはこのインデックスをElastic Securityが使うインデックス一覧に含みません。 securitySolution:defaultIndex という設定にインデックス名を追加する必要があります。 Stack Management → Advanced Settings → securitySolution:defaultIndex 現在の値の末尾に training-security-logs を追加して「Save changes」をクリックし、ページをリロードします。 なぜこの設定が必要か Elastic Securityはデフォルトで logs-* 、 metrics-* などの決まったパターンのインデックスしか見ません。 training-security-logs はそのパターンに含まれないため、明示的に追加する必要があります。本番環境でも、カスタムインデックスを使う場合は同じ手順が必要になります。 ⚠️ バージョンについての注意 securitySolution:defaultIndex の設定箇所はElasticのバージョンによって異なる場合があります。公式ドキュメントも合わせて確認してください。 Step 5：時間範囲の調整 このサンプルデータは 2025-03-18 のタイムスタンプを持っています。Kibanaのデフォルト表示は「直近15分」や「Today」なので、そのままではデータが空に見えることがあります。取り込み失敗ではなく、単に時間範囲が合っていないだけです。 方法 操作 ざっくり確認したい 画面右上の時間範囲ピッカーで「Last 2 years」を選択 正確に指定したい 「Absolute」で開始 2025-03-18 09:45:00 、終了 2025-03-18 10:30:00 を入力 UTC と日本時間（JST）のズレに注意 サンプルデータのタイムスタンプはUTCで記録されています。Kibanaの表示はブラウザのタイムゾーン（日本環境ではJST = UTC+9）で表示されるため、画面上では 18:45〜19:30 のように見えます。このシリーズでは時刻をUTCで記述します。画面上の表示が9時間ずれていても異常ではありません。 取り込みの確認 取り込みが完了したら、次の3つで正しく入ったか確認します。 確認1：件数確認 Dev Tools（Console）で実行します。 GET training-security-logs/_count 期待値： 82 確認2：時間範囲確認 POST _query { "query": """ FROM training-security-logs | STATS total = COUNT(*), earliest = MIN(@timestamp), latest = MAX(@timestamp) """ } 期待値： total = 82 earliest = 2025-03-18T09:45:00.000Z latest = 2025-03-18T10:30:00.000Z 確認3：数値フィールドの型確認 POST _query { "query": """ FROM training-security-logs | WHERE network.bytes IS NOT NULL | STATS max_bytes = MAX(network.bytes), sum_bytes = SUM(network.bytes) """ } 期待値： max_bytes = 120000000 （120MB） この値が返ってくれば、 network.bytes が数値型として正しく取り込まれています。文字列型で取り込まれていると、この集計はエラーになります。 確認4：データ種別確認 POST _query { "query": """ FROM training-security-logs | STATS count = COUNT(*) BY agent.type | SORT count DESC """ } 期待値： winlogbeat = 53 packetbeat = 29 よくあるつまずきポイント 取り込んだはずなのにDiscoverに何も表示されない場合は、次を順番に確認してください。 時間範囲が「Last 15 minutes」になっていないか ：「Last 2 years」に変更する Data Viewが training-security-logs になっているか ：左上のドロップダウンで確認 インデックス名にタイポがないか ： training-security-log （sなし）は別のインデックス Discoverでは見えるのにSecurityでは見えない場合は、Step 4の securitySolution:defaultIndex の設定を再確認してください。 この章のまとめ やったこと なぜ必要か インデックス名を training-security-logs に指定 後の章の全手順がこの名前を前提にしているため マッピングに型を明示 時間検索・数値集計・IP検索を正しく動かすため securitySolution:defaultIndex に追加 Security画面でこのデータを使えるようにするため 時間範囲を調整 2025-03-18の過去データを画面に表示するため 第1回チェックリスト [ ] GET training-security-logs/_count が 82 を返す [ ] Discoverで training-security-logs データビューを開き、イベントが見える [ ] Security → Rules 画面を開いたときにエラーが出ていない 次回は： KQLでログの中身を読みながら、最初の検知ルールを正しい条件で作ります。 event.outcome:"failure" だけでは何が起きるか、第2回で確認します。 The post Elastic Securityで始める検知エンジニアリング — 環境構築とログの取り込み（第1回） first appeared on Elastic Portal .