ドキュメントを_search APIで取得するか、短いPythonスクリプトにhelpers.scanを使ってページ化させます。パイプラインが元のログ行を保持している場合(通常はmessageやevent.originalに)、そのフィールドだけを抽出して生のログを取得できます。OpenSearch Dashboardsは保存済みの検索結果からレポートを生成できますが、現在LogTotalが読み取る形式では提供されていません。
OpenSearchは、Amazon OpenSearch ServiceやWazuhのインデクサーを含む、多くの自家製SIEMやログプラットフォームを支えています。Prime CoreはOpenSearchに対して23,466の検出ルールを提供しており、これらは671のMITRE ATT&CK技術にマッピングされています。以下は、データをクリーンに抽出し、消毒し、LogTotalで無料で調査する方法です。
始める前に
権限。 セキュリティプラグインが有効になっている場合、インデックスパターンに対する読み取りアクセスが必要です:読み取りアクショングループ、または少なくともindices:data/read/search*およびindices:data/read/scroll*が必要です。Amazon OpenSearch Serviceでは、詳細なアクセス制御ユーザーまたはSigV4署名付きIAM認証情報が必要です。
適切なフィールドを見つける。 インデックスパターンはパイプラインごとに異なります。クエリを書く前に、1つのドキュメントとマッピングを確認してください:
GET logs-*/_search?size=1
GET logs-*/_mapping
時間フィールド(@timestampまたはtimestamp)と、理想的には元の行を保持するフィールド(Wazuhではmessage、event.original、full_log)があるかを確認します。
まずはカウント。 クエリと同じ条件でGET logs-*/_countを実行し、これから引っ張るものを確認します。
以下のコマンドはOpenSearch 2.xドキュメントに従っており、2026年10月に確認済みです。
オプション1: Pythonとopensearch-py(推奨)
helpers.scanはページングを処理し、自分で後処理を行います。opensearch-pyをインストールしてから:
import json, os
from opensearchpy import OpenSearch, helpers
client = OpenSearch(
"https://opensearch.example.com:9200",
http_auth=("reader", os.environ["OS_PASSWORD"]),
verify_certs=True,
)
query = {"query": {"range": {"@timestamp": {
"gte": "2026-10-19T00:00:00Z", "lt": "2026-10-20T00:00:00Z"}}}}
with open("opensearch_1019.jsonl", "w") as out:
for hit in helpers.scan(client, index="logs-*", query=query, size=1000):
out.write(json.dumps(hit["_source"]) + "n")
生の行をドキュメント代わりに取得するには、全体の_sourceの代わりにhit[“_source”].get(“message”, “”)を記述します。ファイルを小さく保つためには、クエリに”_source”: [“@timestamp”, “host.name”, “message”]を追加します。
オプション2: 小規模な出力用のcurl
最大10,000件のドキュメントには、1つのリクエストで十分です:
curl -sS -u reader -H 'Content-Type: application/json'
"https://opensearch.example.com:9200/logs-*/_search" -d '{
"size": 10000,
"query": {"range": {"@timestamp": {"gte": "2026-10-19T00:00:00Z", "lt": "2026-10-20T00:00:00Z"}}},
"sort": [{"@timestamp": "asc"}]
}' | jq -c '.hits.hits[]._source' > opensearch_small.jsonl
10,000はデフォルトのindex.max_result_windowです。それを超えるとリクエストが失敗し、オプション1、またはPITとsearch_afterを使用して自動化したい場合があります。
ステップ3: LogTotalでアップロード、サニタイズ、およびレビュー
- アップロード。 開く logtotal.com で.jsonlファイルをドロップします。
- サニタイズ。 続行する前に見直してください。
- レビュー。
問題が発生した場合
| 症状 | 考えられる原因 | Fix |
|---|---|---|
| security_exception / 403 | ロールに検索またはスクロールの権限が欠如 | インデックスパターンの読み取りを要求する |
| 結果ウィンドウが大きすぎる | 1つのリクエストで10,000以上のヒット | helpers.scanまたはPITとsearch_afterを使用する |
| ヒットがゼロだがデータが存在する | 時間フィールド名の誤り、またはタイムゾーンの間違い | マッピングを確認し、明示的なZタイムスタンプを使用する |
| 検索コンテキストが見つからない | ページ間でスクロールが期限切れ | scroll=”5m”をhelpers.scanに渡し、小さいページを使用する |
| Amazon OpenSearch Serviceでの署名エラー | IAMベースのドメインはSigV4を期待 | opensearch-pyからAWSV4SignerAuthを使用する |
FAQ
Wazuhでこれは機能しますか?
はい。WazuhのインデクサーはOpenSearchベースです。アラートは通常、wazuh-alerts-*にあり、元のログ行はfull_logにあります。
_sourceで全てをエクスポートすべきですか?
必要であればだけです。パイプラインはしばしば数十のエンリッチメントフィールドを追加します。時間、ホスト、元のメッセージに絞ることでファイルサイズを小さく保ち、アップロードを速くします。