Crawler統合 - 失敗クロール同期
コマンドシグネチャ
php artisan plg-api:sync-crawl-failed-from-crawler --data-type=SummaryProduct [--limit=100]
php artisan plg-api:sync-crawl-failed-from-crawler --data-type=SummaryProductReview [--limit=100]
php artisan plg-api:sync-crawl-failed-from-crawler --data-type=SummaryCategory [--limit=100]
php artisan plg-api:sync-crawl-failed-from-crawler --data-type=SummarySearchQuery [--limit=100]
目的
これらのコマンドは、Playground APIサービスを通じてCrawlerシステムから失敗したクロール操作の情報を取得し、サマリーウィッシュリストテーブル内の影響を受けたレコードのクロールステータスを更新します。これにより、システムはどのクロール操作が失敗したかを追跡でき、適切な修復アクションや再試行を可能にします。
シーケンス図
sequenceDiagram
participant System
participant Command as plg-api:sync-crawl-failed-from-crawler
participant APIService as PlaygroundApiService
participant Crawler as Crawler System
participant Job as Summary*Job
participant Repository as SummaryWishlist*Repository
participant Logger
participant Slack
Note over System,Slack: Crawler失敗操作同期フロー(30分毎)
rect rgb(200, 255, 200)
Note right of System: 正常ケース - 通常処理
System->>Command: データタイプで実行
Command->>Logger: コマンド開始をログ
Command->>Command: データタイプパラメータを検証
Command->>Command: 日付範囲を計算(日の開始/終了)
rect rgb(200, 230, 255)
loop 結果がなくなるか次のページがなくなるまで
Note right of Command: ページ分割API処理
Command->>APIService: failedList(data_type, date_range, limit, offset)
APIService->>Crawler: HTTP GET /failed-list
Crawler-->>APIService: 失敗したクロールデータのレスポンス
APIService-->>Command: ページ分割されたレスポンスを返す
rect rgb(230, 200, 255)
alt 結果がある場合
Note right of Command: ジョブ処理
Command->>Job: dispatch(failed_crawls_batch)
Job->>Job: 失敗したクロールから識別子を抽出
Job->>Repository: getExisting(identifiers)
Repository-->>Job: 一致するレコードを返す
Job->>Repository: crawl_statusをErrorに更新
Job->>Logger: バッチ処理成功をログ
Job->>Slack: バッチ成功通知を送信
else 結果なし
Note right of Command: データなしシナリオ
Command->>Logger: "失敗リストが見つかりません"をログ
end
end
Command->>Command: 次のページURLを確認
Command->>Command: 次の反復のためにオフセットを更新
end
end
Command->>Logger: コマンド完了をログ
Command->>Slack: 最終サマリー通知を送信
end
rect rgb(255, 200, 200)
Note right of System: エラーハンドリング
rect rgb(255, 230, 230)
alt APIエラーが発生
APIService->>Logger: APIエラー詳細をログ
APIService->>Slack: APIエラー通知を送信
else ジョブ処理エラー
Job->>Logger: ジョブエラー詳細をログ
Job->>Slack: ジョブエラー通知を送信
else 予期しないエラーが発生
Command->>Logger: エラー詳細をログ
Command->>Slack: コンテキスト付きエラー通知を送信
end
end
end
詳細
パラメータ
--data-type:失敗したクロール情報を同期するデータのタイプを指定する必須パラメータSummaryProduct:製品サマリーデータSummaryProductReview:製品レビューデータSummaryCategory:カテゴリサマリーデータSummarySearchQuery:検索クエリサマリーデータ
--limit=N:各API呼び出しで取得する失敗したクロール数を制御するオプションパラメータ(デフォルト:100)
頻度
各データタイプに対して30分毎
依存関係
- Playground APIサービスにアクセス可能である必要がある
- 有効なAPI認証トークン
- CrawlerシステムがAPIを通じて失敗したクロールデータを提供する必要がある
- サマリーウィッシュリストテーブルに一致する識別子を持つレコードが含まれている必要がある
出力
テーブル
summary_wishlist_products:crawl_statusフィールドを更新- crawl_status:失敗したクロール操作に対してErrorに変更
summary_wishlist_product_reviews:crawl_statusフィールドを更新- crawl_status:失敗したクロール操作に対してErrorに変更
summary_wishlist_categories:crawl_statusフィールドを更新- crawl_status:失敗したクロール操作に対してErrorに変更
summary_wishlist_search_queries:crawl_statusフィールドを更新- crawl_status:失敗したクロール操作に対してErrorに変更
サービス
- Playground API:失敗したクロール操作のページ分割されたリストを提供
- Crawlerシステム:失敗したクロール操作データのソース
データベーススキーマ
erDiagram
summary_wishlist_products {
bigint id PK
string input "製品の入力"
string input_type "入力のタイプ: jan, asin, rakuten_id"
bigint mall_id FK "mallsテーブルへの外部キー"
integer crawl_status "クロールのステータス"
}
summary_wishlist_product_reviews {
bigint id PK
bigint summary_wishlist_product_id FK "summary_wishlist_productsへの外部キー(unique)"
integer crawl_status "クロールのステータス"
}
summary_wishlist_categories {
bigint id PK
string category_id "モール内のカテゴリID"
bigint mall_id FK "mallsテーブルへの外部キー"
integer crawl_status "クロールのステータス"
}
summary_wishlist_search_queries {
bigint id PK
bigint mall_id FK "モールのID"
string keyword "検索キーワード"
integer crawl_status "クロールのステータス"
}
%% Relationships
summary_wishlist_products ||--o{ summary_wishlist_product_reviews : "has reviews"
エラーハンドリング
ログ
- データタイプとパラメータを含むコマンド実行の開始/終了
- 各ページのAPIレスポンスステータスと結果数
- デバッグ用のページ分割情報とオフセット追跡
- レコード数を含むバッチ処理の成功/失敗
- 失敗したクロールが見つからない場合の明示的なログ
- デバッグ用のファイルと行情報を含む詳細なエラーメッセージ
Slack
- データタイプ、API詳細、処理統計を含む成功通知
- 更新されたレコード数を含むバッチ処理通知
- 処理されたレコード総数を含む最終サマリー通知
- 詳細なメッセージとソース情報を含むエラー通知
- APIレスポンス詳細と影響を受けたレコード数を含む完全なエラーコンテキスト
トラブルシューティング
データ確認
- コマンド実行後にsummary_wishlist_*テーブルにcrawl_status = Errorのレコードが含まれていることを確認
- レコードに以前の作成操作からの有効なcrawl_config_id値があることを確認
- 失敗したクロール内の識別子がデータベースレコード(input、input_type、mall_idなど)と一致することを確認
- updated_atタイムスタンプが最近のステータス更新を示していることを検証
ログ確認
- 成功した開始と完了のコマンド実行ログを監視
- HTTPステータスコードとページ分割情報のAPIレスポンスログを確認
- 成功/失敗パターンと処理統計のSlack通知を確認
- 処理遅延や失敗のジョブキューログを調査
- 適切なcrawl_statusのErrorへの遷移を示すデータベース更新ログを確認
- APIレスポンス内の失敗したクロール数と更新されたデータベースレコードを比較
- 処理ログでスキップされたまたは一致しなかった失敗したクロールを確認