Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SensuとPagerDutyを連携したお話

929 views

Published on

2015/10/02
nifty様セミナールームにて開催された
sensu Deep Talks #2でお話した内容です。

Published in: Internet
  • Be the first to comment

  • Be the first to like this

SensuとPagerDutyを連携したお話

  1. 1. sensu Deep Talks #2 sensuとPagerDutyを連携した話 古渡 晋也(@f_prg) 2015.10.02
  2. 2. AWSを活用しながらビジネスに集中できる コンシェルジュサービス
  3. 3. 24時間365日 定額課金/ 請求書払い PCI DSS、ISMS、Pマーク取得済みの運用体制 監視運用保守 企業 AWS
  4. 4. (1,500日間) ※ 2010年5月cloudpackサービススタート 36,000時間 連続稼働(※)
  5. 5. 4社 社超 プロジェクト超 500 600 5年間 5年間AWSのみで運用保守
  6. 6. アジア地域4社 世界28社最上位パートナー プレミアコンサルティングパートナー
  7. 7. 企業規模別 cloudpack利用比率 36% 27 37% % 中小企業 中堅企業 大企業
  8. 8. Web系 91% うち33%が ソーシャルゲームや メディアサイト cloudpackの主な利用状況
  9. 9. 今日のお話 ☁ sensuの経緯 ☁ cloudpackでのsensu ☁ PagerDuty運用のはじまり ☁ PagerDutyトラブル ☁ PagerDutyへの対策(改造) ☁ まとめ
  10. 10. 自己紹介 ☁ 名前:古渡 晋也(フルワタ シンヤ) ☁ お仕事:cloudpackエンジニア ☁ Twitter: @f_prg ☁ そのほか:JAWSUG さいたま支部コアメ ンバー
  11. 11. sensuの経緯
  12. 12. ☁ http://www.ryuzee.com/contents/blog/ 6843
 で知りました。なんか、かっくいい。 ☁ 前職ではZabbixが嫌いだった。ていうか Zabbixじゃなくその運用がダメすぎたから。 • google spread sheetで行をコピペして記入してた ら反映したと連絡をする。◯◯すぎる。
  13. 13. ☁ アイレット株式会社cloudpackに入る。 2014.06(ほんとは05からお手伝い^ ^) ☁ なんか、sensuで監視してた。
 面白そう ^ ^ /
  14. 14. cloudpackでのsensu運用
  15. 15. ☁ Chef ☁ git(github.comのプライベートリポジトリを活 用) ☁ Berksfile
 
 たまたま、個人でChef触ってたからあまり勉 強するようなことはなかった。
  16. 16. 通常運用監視業務 ☁ Chefでレシピを作成して
 弊社のMSPにメールを飛ばして
 アラートを拾い運用監視をしております。
  17. 17. とあるお客様専用Handlerを
 提供しております。 ☁ 弊社のMSPにアラートメールが届くだけで なく、お客様のメアドも追加したハンド ラーを開発しており、お客様にもアラート が飛ぶようになっております。
  18. 18. つまり、sensuサーバが死ぬと ☁ お客様にも影響がでるようになってしまった。 • confの記述をミスると止まる。 • handlerのjson記述ミスで止まる。
 
 現在、sensuサーバ2台構成なので
 まあなんとかしのいでます。
  19. 19. PagerDuty運用のはじまり
  20. 20. ☁ メールアラート運用がキツくなってきたの で、会社でPagerDutyを導入しはじめてい た。 ☁ ちょっと案件が忙しくて、PagerDutyに出 遅れる。
  21. 21. PagerDutyトラブル
  22. 22. なんかSlackでメッセがきた。 ☁ なんか届いてない。
 (心の声)◯◯◯◯◯◯◯◯◯ ☁ PagerDuty画面をみると確かにおかしい。
 届いてはいるが、別のサービスに届いた。
 
 プロジェクトAのアラートが
 プロジェクトZに届いている。 ☁ 新しい設定すると、プロジェクトQに届く。
  23. 23. PagerDutyへの対策(改造)
  24. 24. 運用を見直してみる。 ☁ サービスごとにAPIキーを発行していた。
 案件単位==プロジェクト単位で
 PagerDutyのサービスを発行していた。 ☁ APIキーはサーバのハンドラを作ってい た。(お客様に渡せないため)
  25. 25. ドキュメントを見直してみる ☁ ドキュメントをググる。
 https://www.pagerduty.com/docs/ guides/sensu-integration-guide/
  26. 26. 運用を見直してみる。 ☁ 監視運用設定手順と
 公式ドキュメント設定はだいたい同じだっ た。 ☁ でも、よーくみてみたら。。。
  27. 27. どうもmultiple設定でなかった。 ☁ つまり、シングル構成の設定では混ざってしまう。
 sensuサーバでは、/etc/sensu/handlers/*.json
 をメモリ上に展開し、
 プロジェクトA のシングル構成の設定を
 "pagerduty": {
 "api_key": "AAAAAAAAAAAAAAAAA"
 }
 のデータ定義を、さらにプロジェクトBの設定で
 "pagerduty": {
 "api_key": "BBBBBBBBBBBBBBBBBBBB"
 }
 にさらに上書きしていた。
  28. 28. じゃ、multiple設定ってどうするの? ☁ pager_teamという値を使って
 階層を深堀りしてねというもので実装する 模様。
  29. 29. sensu_check "check_resource_ram" do command "check-ram.rb -w 20 -c 10" standalone true handlers node.sensu.default_handlers + [“slack"] + [“pagerduty-project-a”] interval node.sensu.default_check_interval additional (occurrences: 3, pager_team: “pd_www”) end sensu_checkに設定いれるのだが、 これだと全ての設定が、手入力ミスしてしま いそうだった。つまり忘れたら、飛ばない。 飛ばない理由を探すのに時間がかかりそう。
  30. 30. 改造ポイント ☁ すべてのsensu_checkアラートは、PagerDutyに飛ば す。 ☁ PagerDutyハンドラは、defaultハンドラーで設定す る。 ☁ pager_teamパラメータは、sensu_checkで指定しな い。
 →自動的にsensuサーバに送るようにする ☁ sensuサーバの設定は、今の形を変えないようにする。
  31. 31. 改造① default.sensu.default_handlers = node.sensu.default_handlers + ["slack"] + [“pagerduty-project-a"] default.sensu.default_check_interval = 300 default.sensu.pager_team = "pagerduty-project-a" ☁ chefのattribute/default.rbで下記のよう にしてます。共通設定で指定をしてます。
  32. 32. 改造①つづき ☁ github.comのcloudpackのprivateリポジトリに あるcookbooks(Berksfileで参照してロード)で 使用しているレシピでは
 アラートの区別のために、
 顧客情報(BacklogのURLなど)を含めており、そ こにpager_teamを追加するようにしました。 ☁ チラ見せ。。。
  33. 33. sensu_client node.sensu.client_name do
 :
  省略
 : customer_name: node.customer_name, customer_description: node.customer_description, project_name: node.project_name, project_description: node.project_description, pager_team: node.sensu.pager_team, ) end
  34. 34. 改造①の結果(chefを実行すると) ☁ 監視対象のサーバで下記となります。
 /etc/sensu/conf.d/clinent.json { "client": { : 省略 :
 "project_name": "", "project_description": "プロジェクト情報n<<割愛>>", "pager_team":“pagerduty-project-a“ } }
  35. 35. 改造② ☁ sensuサーバのハンドラー設定を次のよう にする。
 /etc/sensu/conf.d/handlers/pagerduty- project-a.json

  36. 36. { "pagerduty": { "pagerduty-project-a": { "api_key": "AAAAAAAAAAAAAAA" } }, "handlers": { "pagerduty-project-a": { "type": "pipe", "command": "pagerduty.rb", "severities": [ "critical", "unknown" ] } } }
  37. 37. 改造②の結果 ☁ APIキーの混在がなくなる。
 ^ o ^/
  38. 38. 改造③ ☁ https://raw.github.com/sensu/sensu- community-plugins/master/handlers/ notification/pagerduty.rb
 を改造。
 マニュアル通り導入しますと、このファイ ルを、/etc/sensu/handlers/pagerduty.rbに 設置するようになってます。
  39. 39. if @event['check']['pager_team'] api_key = settings[config[:json_config]][@event['check']['pager_team']]['api_key'] elsif @event['client']['pager_team'] api_key = settings[config[:json_config]][@event['client']['pager_team']]['api_key'] else api_key = settings[config[:json_config]]['api_key'] end
  40. 40. 改造③の結果 ☁ check単位ではなく、clientのパラメータ で振り分けするようにしました。 ☁ ようやくPagerDutyのサービスごと(プロ ジェクトごと)にインシデントが飛ぶよう になりました。
  41. 41. 改造④、というかおまけ ☁ 失敗から得る教訓ってありますよね。 ☁ なんで、エラーしてたかというとほかのサー ビス(プロジェクト)に飛んでいたわけで す。 ☁ つまり原因は、
  42. 42. if @event['check']['pager_team'] api_key = settings[config[:json_config]][@event['check']['pager_team']]['api_key'] elsif @event['client']['pager_team'] api_key = settings[config[:json_config]][@event['client']['pager_team']]['api_key'] else api_key = settings[config[:json_config]]['api_key'] end
  43. 43. 改造④つづき ☁ じゃ、これも使おう!
  44. 44. ☁ シングル構成をあえて残して、sensuの設 定エラーを拾うように応用しています。
  45. 45. { "pagerduty": { "api_key": "EEEEEEEEEEEEEEEEEE" }, "handlers": { "sensu-server-config-error": { "type": "pipe", "command": "pagerduty.rb", "severities": [ "critical", "unknown" ] } } }
  46. 46. まとめ ☁ PagerDutyを始めての
 ちょっと苦労したお話でした。 ☁ 失敗も応用して活用したら、
 シングル+マルチの効果は大きいです。

×