Cloudflare Email Routingのログを転送したメモ
CloudflareのEmail Routingを使用しているのですが、たまにDelivery Failedになります。Email Routingのダッシュボードでは詳細が見れず、何が失敗したのかわかりません。ログも1日？程度で消えてしまうため、失敗した事実にすら気付かないことが多い気がしています。これを解決するために気晴らしを兼ねてログ転送用のCron Trigger Workerを作成したので仕様の意味などの備忘メモを残しておきます。
成果物
簡単な内容
- 毎日日本時間06:55と18:55に起動
- それぞれ前日18:50～06:50の間のログ、06:50～18:50の間のログを転送
- ログはCloudflare Analytics APIから取得
- GraphQLでemailRoutingAdaptiveデータを取得
-
statusがdeliveredでないログのみ取得
- 取得したデータをAxiom.coというロギングサービスに送信
仕様の理由
Email Routing Workerではない理由
Cloudflareのメール受信層で拒否されるSPF/DKIM/DMARC検証の失敗のような場合、Email Routing Workerが起動するかどうか不明なため。また、メールbodyは不要で都度ロギングサービスに送信するほどリアルタイム性も不要なため、その検証に時間をかけたくなかった。加えてメール転送が発生する度にWorkers無料プラン制限回数を消費するのも避けたかった。
起動時間
参考文献によるとemailRoutingAdaptiveデータは1日しか保存されないので、最低でも1日1回実行する必要がある。後述のログ取得期間をずらすために半日に1回、すなわち1日に2回起動することにした。この程度であればWorkers無料プラン制限にもほぼ影響を与えない。
06時・18時に特に理由はない。午前と夜に比較的新しいデータが確認できれば良いと考え、その周辺で時間を設定した。
55分は00分ちょうどに起動すると、00分に送信されるようなメールとタイミング問題が発生する確率が若干上がると判断した。時間をずらすこと自体に何の問題もないため、余計なリスクを排除するためにずらした。
ログ取得期間
メール転送からCloudflare Analytics APIに反映されるまでにどれだけのタイムラグがあるか不明なため、タイミング問題を避けるために意図的にずらした。また、Cron Trigger Workerの起動時間も若干揺らぎがある前提でログ取得条件時刻を正確に得られるように配慮している。
Axiom.co
特にこだわりは無いが以前試しにアカウントを取得して放置していたサービスを使用することにした。無料でも容量が25GB、読み込み量が500GB、30日間データ保存されるため十分だと判断した。必要であれば送信先を別サービスにすれば良いだけになっている。
エラーハンドリング
個人用のためコードのシンプルさを重視し大雑把にしか対応していない。
雑記
GraphQLは初めて触ったので少し勉強になりました。以前から転送先Outlookでよく転送エラーが発生していましたが、その原因が"temporarily rate limited due to IP reputation"であり、状況は変わっていませんでした。これはどうしようもなさそうですね。
しかし宣伝も何もしていないのに、この記事を書いてる時にGitHubのリポジトリを見るとパナマの人にスターを付けられてて二度見してしまいました。どうやって見つけたんだろう...
Discussion