最近在公司有一個比較大的任務，就是負責處理 Datadog to Prometheus Migration，既然使用了 AWS managed Service for Prometheus (AMP)，就免不了會用 AWS managed Service for Grafana (AMG)，然後 …在 AMG 就被雷到(淚)
先簡述一下問題，這問題其實滿雞助，就是如果是用 AWS Grafana alerting (version 9 之後出的新版 alerting，相較於舊版的就稱為 classic dashboard alerting)，新版好處多多，就不贅述，而這個問題其實在官方文件 Note 和 GitHub issue 都有提到或有人發問，只是有時候沒那麼多時間看文件就直接試了，而後就發了 AWS Support ticket 問一下這問題
順便提一下公司的 AWS Support plan 已經是 Enterprise，所以會有一個 AWS TAM 註點在 Slack Channel，其實很方便，有時候 Daily Meeting 大家在同步 Tasks 時，Line Manager 有時候會提醒我們，遇到 AWS 相關問題就先問 TAM 來節省時間，順便把一些壓力轉嫁到他們身上 (好像是不錯的方式來轉拋壓力？疑)
回來問題，AWS Support 很快的給了回覆，給了 3 種解決方案
- 使用 Prometheus AlertManager
- 退回使用 Grafana classic dashboard alerting
- 使用 SNS FIFO 內建的去除重覆訊息功能
再三考量和 team member 做了溝通後，就決定選 3 了，不行再退回第二個 Grafana classic dashboard alerting，但 classic alerting 實在不方便，建個 alert 一定要先建 Dashboard 後在 panel 設定，至於第一個 Prometheus AlertManager 為什麼不選，照理說網路上滿多人推這個方式，但考量設定 Alert 不能統一在一個地方，alert rule 要在 Prometheus configuration 寫 yaml，然後再到 Grafana 那邊設定 Notification policies，沒那麼方便，再者 Grafana 還可以整合像 AWS CloudWatch，那自然 alert rules 統一在 Grafana 設定是最好的了
所以為了方便忍痛選了第 3 個方案，流程圖大概像這樣
這個方案非常的繞，也不聰明，但做為 workaround 免強接受，未來 AMG 修掉這個問題後 workaround 就可以拔掉了，雖然 AWS TAM 給我們的回覆是說，這個問題目前不在 service team 的 ETA 中(哇咧…)，所以我猜 AMG 的用戶不夠多，不然一人一則去轟炸 Github issue 應該很快就修好了XD
整個核心重點在 SNS (FIFO) + SQS (FIFO)，deduplication 是可選的 feature，另外送 SNS FIFO 的參數中 deduplication ID 是可選的，如果確定 message content 一定都是重覆的，deduplication ID 可以不用，SNS FIFO 會用 message content 來判斷是否需要在 5 分鐘內去除重覆的訊息
另外還有一點在 Grafana (AMG) contact point 中為什麼不能直接設定對 SNS FIFO 呢？還要先透過一個 SNS 搭配 Lambda 來 trigger SNS FIFO？因為…AMG contact point 不支援 SNS FIFO XD (已反應給 TAM，相信之後會改)，其實看 AWS boto SDK 就知道只差在 SNS FIFO 要多送一個參數 MessageGroupId，猜測是這個原因
以上大概簡述完了，這 workaround 也花了快一週釐清問題、討論、實作…，真的很花時間，不過也是能學到東西就是了，希望看到這篇的人未來也不用再踩這個雷了 🙂
