サポート用情報

Zen Firewall について Aikido Support にお問い合わせいただく際は、まず以下の確認を行い、チケットに必要な情報を含めてください。これにより、問題をより迅速に診断でき、不要なやり取りを減らせます。

1. トークンを確認する

Zen が Aikido と通信するには有効なトークンが必要です。アプリが Zen ダッシュボードに表示されない場合、まず確認すべきなのがトークンです。

• 確認 AIKIDO_TOKEN が、アプリが実際に動作している環境で設定されていることを確認してください（シェル上だけではなく）。
• トークンに余分な引用符や空白が含まれていないことを確認してください。
• トークンが正しいアプリに属していることを確認してください。参照: Aikido Zen Firewall トークンの作成.
• 有効化 AIKIDO_DEBUG=true を有効にし、起動ログでトークンが検出されたことを確認してください。

2. Aikido への接続を確認する

Zen には Aikido のクラウドへの HTTPS の外向きアクセスが必要です。トークンが設定されていてもアプリがダッシュボードに表示されない場合、最も考えられる原因はネットワーク制限です。

参照: Zen の外向きネットワーク接続 ドメインの完全な一覧（EU、US、ME）と接続テストコマンドについては、こちらをご覧ください。これらの確認は、アプリが動作している同じホスト（該当する場合は同じコンテナ）から実行し、失敗したものがあればその出力を共有してください。

3. サポート向け情報

チケットを開く際は、以下を共有してください:

アプリ & 環境

• Aikido 上のアプリへのリンク Zen ダッシュボード
• 使用言語とランタイムのバージョン（例: Node.js 20、Python 3.12、PHP 8.3）
• フレームワークとバージョン（例: Express、Django、Spring MVC、Laravel、ASP.NET Core）
• Zen パッケージ / ライブラリのバージョン
• オペレーティングシステム、コンテナのベースイメージ、またはホスティングプラットフォーム（例: Ubuntu 24.04、 php:8.3-fpm、AWS Lambda、Kubernetes）
• アプリがプロキシ、ロードバランサー、CDN、またはサービスメッシュの背後で動作しているかどうか

設定

• モード: ブロッキング（AIKIDO_BLOCK=true）または検出のみ
• その他の AIKIDO_* 環境変数を設定している場合はそれも。参照: 環境変数による設定

問題の再現性

• 問題は一貫して再現しますか？
• 単一のエンドポイントに影響しますか、それとも複数のエンドポイントに影響しますか？
• 問題を引き起こすサンプルリクエスト（秘密情報と PII はマスク済み）
• 期待していた動作と実際に起きたこと

デバッグログ

1. 次を設定します。 AIKIDO_DEBUG=true アプリが動作している環境で。
2. アプリを再起動し、問題を再現してください。
3. ログの関連部分を取得してチケットに添付してください。どの行が Zen のものかわからない場合は、出力内で Aikido または Zen を検索してください。

Zen の出力先はランタイムによって異なります:

• Node.js: Node プロセスの stdout または stderr を確認してください。プロセスマネージャー（PM2、systemd、Docker、Kubernetes、 npm start コンソールなど）が収集している場所を確認してください。
• Python: Python プロセスの stdout または stderr を確認してください。Gunicorn や Uvicorn のような WSGI / ASGI サーバーでは、ワーカー向けに設定されたエラーログの出力先（例: Gunicorn の --error-logfile、またはフォアグラウンド実行時の stdout）を確認してください。
• PHP: 出力先は SAPI によって異なります:

  • Apache（mod_php）: Apache のエラーログ（ ErrorLog ディレクティブで設定されたパス。多くは /var/log/apache2/error.log).
  • PHP-FPM: FPM プールで設定された error_log と、上流の Web サーバーのエラーログ。
  • FrankenPHP: Caddy / FrankenPHP の stdout、または設定していれば Caddy のログファイル。
  • CLI ワーカー（queue、cron、artisan）: コマンドの stderr。
• Java（Spring、Javalin など）: アプリケーションで設定しているログフレームワーク（SLF4J / Logback / Log4j2）を確認してください。Zen のメッセージは、アプリの他のログと同じ出力先（コンソール、ログファイル、コンテナ内では stdout への JSON）に表示されます。
• .NET（ASP.NET Core / Framework）: アプリケーションで設定している ILogger の出力先を確認してください。デフォルトの Console ロガーでは stdout になります（ dotnet run, journalctl、またはコンテナログから確認可能）。IIS でホストされたアプリでは、stdout は stdoutLogEnabled="true" が web.config.
• Ruby on Rails: Rails のロガー（log/development.log, log/production.log、または設定済みの任意の場所）を確認してください。スタンドアロンの Ruby スクリプトは stderr にログを出します。
• Go: Go バイナリの stdout または stderr を確認してください。

コンテナまたはサーバーレスプラットフォーム（Docker、Kubernetes、AWS Lambda / CloudWatch、Cloud Run、App Service、Heroku、Fly.io など）で実行している場合も、プロセスは上記の行を出力しますが、プラットフォームがそれらをログ収集先へ転送します。そこからログを取得してください。

上記をすべて提供いただくことで、フレームワーク、ランタイム、または環境固有の問題をより効率的に特定できます。