Mac版 Chrome のプロファイル切替のショートカットが欲しかったのでメモ。
調べて見ると「デスクトップショートカットを作成」で作成できますという記事が沢山出てきたのですが、Mac版だと存在しないようです。
作成時も作成後の設定メニューにも見当たりません。
Dock から開けます。
Dock の Chrome アイコンを右クリック (または Control + クリック)で表示されるメニューの中に プロファイル が含まれています。
結果的に調べる程の話では無く、灯台下暗しでした。
プロファイル機能
Automator や Launcher 使ってショートカットを作成する記事
一通り実行結果を確認できたのでまとめます。
AWSからの送信を題材にしていますが、他サービスからの連携でも利用できると思います。
内容は充実していますが、情報が散らばっている印象です。
各機能の流れと関係はこのようになると思います。
Developer Mode にした上で利用する形となるため、今回は除外しています。
Developer Platform の "Build App & Integration" 辺りにドキュメントがあります。
Custom Event Transformer Integration のように、
JavaScript による Event Transformer 機能を持っており、
各 Service 配下の Integration 設定で行っていたスクリプトを1箇所で管理するなどができるようです。
今後は後継の Service Orchestration に置き換わっていくと思われるため、今回は除外しています。
各 PagerDuty Service に振り分けされたイベントを操作する際に使用します。 (Service Event Rules)
設定画面上も、 Switch to Service Orchestrations ボタンがあり、今後は Service Orchestration 機能に移行していく事が推奨されているようです。ドキュメントにも記載があります。(Switch to Service Orchestrations
)
どの機能を使用するかの判断はこのようになると思います。
Service 配下の方が小回りが効きます。管理外のシステムから他社に連携してもらう場合など、固有Endpointの方が向いているでしょう。
Global は一箇所でまとめて管理できるメリットがありますが、権限やプランの関係で利用できない可能性があります。
Orchestration か Rulesets かという点は、特に支障が無ければ Orchestration が推奨されると思います。 使ってみた限りでは Rulesets にできて Orchestration にできないことはありませんでした。
Service の場合、提供されているなら Integration が使いやすいと思います。
Custom Event Transfer は自前で Integration を作成するイメージで、JavaScript を書く必要がありますが自由度は高いです。
API 実行で送信を行う場合は Events API v2 インテグレーションを利用します。
Email しか送信手段が無ければ Email Integration になりますが、細かな制御はできません。 抽出・変換は後述 Service Orchestration で行う形になります。
Global の場合、 PD-CEF に対応していれば Integration URL へそのまま送信できます。
Global Orchestration
Global Rulesets
非対応形式の場合は HTTP endpoint か Email となります。 HTTP endpoint へは API を実行して送信します。
Email は、Email Integration 同様、抽出・変換は後述 Service Orchestration で行う形になります。
Service Orchestration にて実施します。 Service にルーティングされたイベントに対して実行できます。 Global Orchestration 経由である必要はありません。 参考例としては、前述の Global Orchestration の記事内 Transformations で使用しています。
各種APIが提供されているのでコード管理も可能です。
Terraformの PagerDutyプロバイダ が提供されているので利用しています。
いずれも PagerDuty API は提供されていますが、検証時点では Terraform (PagerDuty Provider) ではサポートしていませんでした。
resource/pagerduty_service_integration: Add Email Filters to Service Integrations (#468)
これまで Integration を利用することが多かったのですが、 新機能の Orchestration が発表されたことで改めて手法を確認し、様々な連携方法があることを知りました。 各種Webサービスのイベント連携は何かしらで行えそうです。
ノーコードでルール設定できる Orchestration は利用頻度が上がりそうです。特に、受信した内容をそのままルールの条件値として使用できる raw_event が使えるのは良いと思います。
今回の検証した結果の記事一覧は以下になります。
今回試した AWS と PagerDuty の連携例をコード(Terraform)化した物は以下に置いています。
番外編です。
APIを直接実行する事で、任意のイベントを送信できます。
Global Orchestration、Global Ruleset、Service それぞれに対して送信できます。
利用する機能の Integration Key を取得します。
Endpoint は同一の https://events.pagerduty.com/v2/enqueue です。
適宜 Routing Rule と Action Rule を追加します。 例として、送信側で source に TopicArn を設定するようにし、判別できるようにしています。
適宜 Event Rule を追加します。 例として、送信側で source に TopicArn を設定するようにし、判別できるようにしています。
"Events API v2" インテグレーションを使用します。 DEVELOPER PLATFORM の "Events API v2 Overview" に設定方法が記載されています。
指定できるオプションはありません。
API Reference を参考に送信処理を実装します。
Python の場合、標準ライブラリとRequests利用の2パターン例示されています。
import http.client conn = http.client.HTTPSConnection("events.pagerduty.com") payload = "{...}" headers = { 'Content-Type': "application/json" } conn.request("POST", "/v2/enqueue", payload, headers) res = conn.getresponse() data = res.read() print(data.decode("utf-8"))
今回は SNS -> Lambda Function で連携します。
DEVELOPER PLATFORM の "Events API v2 Overview" に記載されています。
Rate Limits の制限値は明記されていません。 制限超過した場合、 StatusCode: 429 (Too Many Requests) を返却するので、必要に応じてリトライを実施しなさいとのことです。
Size Limits は 512 KB です。
API実行時に指定した $payload.summary 、$.payload.custom_details でインシデントが作成されます。
$payload.dedup_key で指定します。
Global Ruleset および Global Orchestration は Email Address を持っています。
SNS Subscription では Email または Email-JSON で送信できるので、2パターン試します。
AWS SNS の Subscription に Global Orchestration の "Email Address" を Protocol "Email" または "Email-JSON" として指定します。
"AWS Notification - Subscription Confirmation" の件名でAlertが作成されるので、confirm を実施することで利用できるようになります。(ルールに合致しない状態ではインシデントは作成されません。)
この際、同一件名で Alert が Triggered (Suppressed) の状態だとAlertも新規発行されず追加となります。
新規発行としたい場合はAlertもResolve(Resolve(Suppressed) の状態)にしておく必要があります。
利用できるfieldは以下になります。
> - event.custom_details.from[0](the from address) >> * The [0] refers to the 1st position in a list of emails. If you would like to generally search through a list of emails (either in the "to" field or the "from" field), please set to event.custom_details.from or event.custom_details.to. > > - event.custom_details.subject (the subject line) > - event.custom_details.plain_body (the email body)
TopicArn の形式などで Email, Email-JSON の判別もできます。
# Email `event.custom_details.subject` matches `AWS Notification Message` and `event.custom_details.plain_body` matches part `?SubscriptionArn=arn:aws:sns:ap-northeast-1:123456789012:example-aws-to-pd-eventbridge:` # Email-JSON `event.custom_details.subject` matches `AWS Notification Message` and `event.custom_details.plain_body` matches part `"TopicArn" : "arn:aws:sns:ap-northeast-1:123456789012:example-aws-to-pd-eventbridge"`
初期状態でのインシデントタイトルはメール件名で作成されます。
AWS Notification Message
詳細欄はメール本文です。 Email は Message の内容のみとなるので、 Email-JSON の方が若干情報量が多いです。
Ruleの "Transformations" から変更します。
Transformationsを参考に出力内容を調整します。
Summary を TopicName と detail-type に変換、
また、都度インシデントを作成するため dedep_key に MessageId を設定します。
Message は JSON 文字列 となっているので正規表現で抜き出します。
| Name | Regex | Source |
|---|---|---|
| topic_name | ^.*SubscriptionArn=(?:[^:]*:){5}([^:]*):.*$ |
event.custom_details.plain_body |
| detail_type | ^.*"detail-type":"([^"]*)".*$ |
event.custom_details.plain_body |
| message_id | ^.*"id":"([^"]*)".*$ |
event.custom_details.plain_body |
| Event Field (CEF) | Value |
|---|---|
| summary | Email [{{variables.topic_name}}] {{variables.detail_type}} |
| dedup_key | {{variables.message_id}} |
| Name | Regex | Source |
|---|---|---|
| topic_name | ^.*"TopicArn" : "(?:[^:]*:){5}([^"]*)".*$ |
event.custom_details.plain_body |
| detail_type | ^.*"Message" : ".*"detail-type\\":\\"([^\\]*)\\".*$ |
event.custom_details.plain_body |
| message_id | ^.*"MessageId" : "([^"]*)".*$ |
event.custom_details.plain_body |
| Event Field (CEF) | Value |
|---|---|
| summary | Email-JSON [{{variables.topic_name}}] {{variables.detail_type}} |
| dedup_key | {{variables.message_id}} |
Summary が変換されたことを確認できます。
dedup_key を指定したことにより、インシデントがTriggeredの状態で残っている状態で再度同一イベントが発生した場合にも、インシデントが作成されます。
Global Ruleset および Global Orchestration は Email Address を持っています。
SNS Subscription では Email または Email-JSON で送信できるので、2パターン試します。
AWS SNS の Subscription に Global Ruleset の "Email Address" を Protocol "Email" または "Email-JSON" として指定します。
"AWS Notification - Subscription Confirmation" の件名でAlertが作成されるので、confirm を実施することで利用できるようになります。(ルールに合致しない状態ではインシデントは作成されません。)
この際、同一件名で Alert が Triggered (Suppressed) の状態だとAlertも新規発行されず追加となります。
新規発行としたい場合はAlertもResolve(Resolve(Suppressed) の状態)にしておく必要があります。
View Message からイベント内の Confirm URL を確認できます。
利用できるfieldは以下になります。
> - headers.from.0.address (the from address) >> * Note: .0.address refers to the 1st position in a list of emails. If you would like to generally search through a list of emails (either in the "to" field or the "from" field), please set to headers.from or headers.to > > - headers.subject (the subject line) > - body (the email body)
TopicArn の形式などで Email, Email-JSON の判別もできます。
# Email When all conditions are met `headers.subject` equals `AWS Notification Message` `body` contains `?SubscriptionArn=arn:aws:sns:ap-northeast-1:123456789012:example-aws-to-pd-eventbridge:` # Email-JSON When all conditions are met `headers.subject` equals `AWS Notification Message` `body` contains `"TopicArn" : "arn:aws:sns:ap-northeast-1:123456789012:example-aws-to-pd-eventbridge"`
初期状態でのインシデントタイトルはメール件名で作成されます。
AWS Notification Message
詳細欄はメール本文です。 Email は Message の内容のみとなるので、 Email-JSON の方が若干情報量が多いです。
Ruleの "Customize Event Fields" から変更します。
Step 1.1: Customize Event Fields (Optional) を参考に出力内容を調整します。
Summary を固定値に変換、
また、都度インシデントを作成するため dedep_key に MessageId を設定します。
Message は JSON 文字列 となっているので正規表現で抜き出します。
| Name | Regex | Source |
|---|---|---|
| message_id | ^.*"id":"([^"]*)".*$ |
body |
| Event Field (CEF) | Value |
|---|---|
| summary | Email: Tag Change on Resource |
| dedup_key | {{message_id}} |
| Name | Regex | Source |
|---|---|---|
| message_id | ^.*"MessageId" : "([^"]*)".*$ |
body |
| Event Field (CEF) | Value |
|---|---|
| summary | Email-JSON: Tag Change on Resource |
| dedup_key | {{message_id}} |
Summary が変換されたことを確認できます。
dedup_key を指定したことにより、インシデントがTriggeredの状態で残っている状態で再度同一イベントが発生した場合にも、インシデントが作成されます。
グローバルオーケストレーションのEndpointへイベントを通知します。
AWS から PagerDuty への通知連携(4) - vague memory
導入部分は上記同様のため割愛します。
変換ルールが無い状態では、インシデントタイトル、詳細欄共にSNSから通知される $.Message が入ります。
Ruleの "Transformations" から変更します。
Transformationsを参考に出力内容を調整します。
Summary を文字通り概要に変換、
また、都度インシデントを作成するため dedep_key に MessageId を設定します。
Message は JSON 文字列 となっているので正規表現で抜き出します。
| Name | Regex | Source |
|---|---|---|
| topic_name | ^.*:(.*) |
raw_event.TopicArn |
| detail_type | ^.*"detail-type":"([^"]*)".*$ |
raw_event.Message |
| message_id | (.*) |
raw_event.MessageId |
| Event Field (CEF) | Value |
|---|---|
| summary | {{variables.topic_name}}: {{variables.detail_type}} |
| dedup_key | {{variables.message_id}} |
Summary が変換されたことを確認できます。
Alert Log でも確認できます。
dedup_key を指定したことにより、インシデントがTriggeredの状態で残っている状態で再度同一イベントが発生した場合にも、インシデント作成されていることが確認できます。
グローバルルールセットのEndpointへイベントを通知します。
AWS から PagerDuty への通知連携(3) - vague memory
導入部分は上記同様のため割愛します。
変換ルールが無い状態では、インシデントタイトル、詳細欄共にSNSから通知される $.Message が入ります。
Ruleの "Customize Event Fields" から変更します。
Step 1.1: Customize Event Fields (Optional) を参考に出力内容を調整します。
Summary を文字通り概要に変換、
また、都度インシデントを作成するため dedep_key に MessageId を設定します。
Message は JSON 文字列 となっているので正規表現で抜き出します。
| Name | Regex | Source |
|---|---|---|
| topic_name | ^.*:(.*) |
TopicArn |
| detail_type | ^.*"detail-type":"([^"]*)".*$ |
Message |
| message_id | (.*) |
MessageId |
| Event Field (CEF) | Value |
|---|---|
| summary | {{topic_name}}: {{detail_type}} |
| dedup_key | {{message_id}} |
更新後、一覧でも反映された事を確認できます。
Summary が変換されたことを確認できます。
Alert Log でも確認できます。
dedup_key を指定したことにより、インシデントがTriggeredの状態で残っている状態で再度同一イベントが発生した場合にも、インシデント作成されていることが確認できます。
