Cloud Composerのエラー監視にSentryを使う方法

安心感が欲しければエラー監視は必須

昨今ではDatadogやらNew Relicやらといったインフラも含めた監視ツールも充実していて、幾ばくか監視というものはやりやすくなったかと思います。

それだけシステムを動かすということにおいてはただ動けばいいのではなく動き続けていることの監視も含めて重要ということでもあるかと思います。

弊社のデータ基盤は基本的にマネージドな構成で組んでいますので、ソフトウェアのエラー監視に特化する形で概ね問題ないです。

そこで、エラー監視でSentryを導入しようと思いました。

早速AirflowのマネージドサービスであるCloud Composerに導入しようとしたところ、意外とマニュアルがなかったのでまとめてみます。(ちょっとニッチめな記事です)

Airflowへの導入マニュアルは見つかるが…

探してみると、まずAirflow向けのSentry導入マニュアルは簡単に見つかります。

SentryのdocsにもApache Airflowのページがちゃんとありますし、

ちゃんとAirflowのdocsのReference for package extrasのページにも載っています。

どちらも apache-airflow[sentry] を pip で入れろと書いてあります。

あれ？でも こういうとき、マネージドなサービスではどうしたらいいの？ となります。

自前で構築している場合はすぐ出来ることが逆に難しくなる、これはマネージドサービスあるあるだと思います。

実際、Cloud ComposerでPyPIパッケージとして apache-airflow を登録することは出来ません。(そうするとマネージドじゃなくなりますしね) Untitled

どうすればCloud ComposerにSentryが入るか？

一応かつてはプラグインがGitHubで公開されていました: getsentry/sentry_airflow のリポジトリ

しかしここにも書いてある通り、

Note: As of Airflow 1.10.6 you can directly install Sentry in Airflow without the use of this plugin.

とのことで、これが取り込まれたような形になったようで、もうアーカイブされています。ちょっと使うのはこわいですね。

そんなこんなでどうしようかと考えてCloud Composerのrelease notesなどをみていると、2020年9月17日のreleased notesに

A fix for the broken Airflow Sentry integration has been backported to older Composer Airflow versions.

とあることに気付きました。

あれ？ということは実はCloud Composer自体に普通に内包されている？？

そこでとりあえずSentryのプロジェクトを(とりあえず適当にPython等指定して)作り Asahi_Broadcasting_Group_Holdings_Corporation_2024-02-13_15-57-18

DSNが入手されるので、これをコピーし、(このPythonのコード自体は使いません)

Cloud Composerの 「AIRFLOW構成のオーバーライド」 から編集を行うことにしました環境の詳細__Composer__abc-cdp__Google_Cloud_コンソール_2024-02-13_17-51-59

セクションとして「sentry」を環境変数に入れてみると… 環境の詳細__Composer__abc-cdp__Google_Cloud_コンソール_2024-02-13_15-58-28

普通にキーの候補が出ました。

あれ？そういうもんなのか･･と思い、設定を追加し、保存。 Untitled

更新するとタイムアウトのエラーが出てしまい、なぜ？と思うとエラーが出ていました。 Untitled

ModuleNotFoundError: No module named 'sentry_sdk’

とのことなので、 sentry-sdk をPyPIパッケージとして指定します。 Untitled

(この作業は必要なんですね。。)

これでもう一度Airflowの構成を更新してエラーも出なくなり無事仕込み完了です。

動作確認

仕込みが終わったら動作確認です。適当にエラーが出る手動実行のDAGを用意します。

import os

from airflow.models import DAG
from airflow.operators.python import PythonOperator
from airflow.utils.dates import days_ago

PYTHON_FILENAME = os.path.basename(__file__)[:-3]


def raise_error():
    raise Exception("Error")


# エラーを出すだけの手動実行タスク
with DAG(
    dag_id=PYTHON_FILENAME,
    start_date=days_ago(1, hour=0, minute=0, second=0),
    schedule=None,
    catchup=False,
) as dag:
    raise_error_task = PythonOperator(
        task_id="raise_error",
        python_callable=raise_error,
    )
    raise_error_task

実行すると… Untitled

ちゃんとエラーが飛びました！

ちなみに実際はDAG以外でも死んだスケジューラタスクなど様々なエラーが結構な数飛んできます。

飛んできたエラーに応じてフィルタするのかとか、GitHubでIssueにしたりとか、Slackに飛ばしたりとか、それぞれの好みに合わせてSentryでチューニングすることになると思います。

まとめ

今回はCloud ComposerにSentryを導入する方法についてまとめました。

あまりインターネット上に情報がなかったので少し迷走してしまいましたが、答えがわかれば一瞬で解決する類のものですね。

一方で、DAGそのもののエラーは on_failure_callback の設定を行うことでもSlackに飛ばしたりは出来るので、どういったエラーを監視したいかによって使い分けることが好ましいのかなと思います。

なお、Sentry自体はとても便利で気に入っています。サーバレス環境で動かすコードなどにも基本的には仕込むようにしています。

自前で作ったエラー検知の仕組みはそれ自体が正しく動いているかどうかを検知する仕組みがないということにどうしてもなるので、こういった監視サービスに頼るのが一番手っ取り早いですね。トレースもちゃんとしてくれますし、優秀です。