画像がないと全然わかりづらいかもですが。備忘録を。
大体既存コネクタでRedmineISSUE自動登録
１．LogicAppを適当な名前でつくりHTTPrecevedのコネクタを適当に配置、
AzureMonitorから飛んでくるHookのjsonスキーマを定義しておく（こうすると採れた動的なVariablesをあとでIssue登録時のSubjectとかDescriptionで使いまわせる）、Hook受け付けるエンドポイントを控える
２．AzureMonitorのアラートのアクションで、メール飛ばすほかにさっきつくったRedmine登録用のエンドポイントに向けたWebhookを設定する。
複数アクション登録してもそれぞれ動くようだった。
（テストなので適当にCPU1%以上で発報とかにしてアクションルールの有効・無効を切り替えてテストする）
３．LogicApp側でHookを受け取ったコネクタの後にアクションを追加、variablesコネクタという変数を定義するコネクタを用いてProjectNameという名前の変数を初期化しておく。
４．コントロールコネクタCaseで、hookでとれたSubscriptionIdを用いて、特定のサブスクリプションIDに一致するものを特定のProjectNameとして変数に値をセットする。
５．分岐してるCase内で、テスト用と本番用のサブスクリプションIDを定義して気軽にテストできるようにしておく
６．分岐してるCase内で、テスト用、本番用のそれぞれProjectIDを指定してissue登録するRedmineコネクタを用いてURLとAPIキーとプロジェクトIDとトラッカーと設定し、SubjectやDescriptionに適宜Webhookで取れた動的なパラメータを定義して保存（foreachループがalOfとかdimensionなどのAzureMonitorからHookとんでくるjsonスキーマ的に囲われてる関係で自動で生じる）
気になること
・地域とかで分散してつくられてるLogicをコントロールコネクタConditionでまとめたりしたいっぽい
・ARMなら手動ぽちぽちではなく自動的にいけるらしいが冪等に管理とかは同じリソースに対する変更までで削除はできないらしい。（そうか。）
Terraformはガワだけつくることしかできない、というあたりがちょっと管理がめんどうくさい。
・重複登録を防ぐのに特定の期間に同じタイトルか何かで作成ではなく更新にするとかができるといいかもと思われる
・トラッカーがデフォの３つ以外指定してもなんか反映されない。マルチバイトなせいかなと思いきやそうでもなかった。（たぶん既存コネクタじゃなくて作ればいい話のようで残念）
自動クローズもやってみた件
自動で登録はともかく自動でクローズをするには登録された値から更新対象を確認するためのカスタムフィールドをとってきてステータスなどから分岐処理する、という必要がありました。
基本的に、Redmineの既存コネクタは約にたたないのでPostmanとかでAPIの挙動をテストしながら自作する感じにして、以下のようなフローに。（ペアプロっぽい作業でおしえてもらいました。おもしろかった。）
AzureMonitor
AlertルールでアクションをLogicAppsのRequest(トリガ)コネクタのwebhookを指定
↓
LogicApps
Request(トリガ)でhookを受けてダイナミック変数に届いたアラート関連の値が自動で入る
↓
InitializeVariableで"RedmineAPIKey"にRedmineのAPIキーを登録
↓
InitializeVariableで"RedmineProjectId"にRedmineのプロジェクトIDを初期化
↓
InitializeVariableで"ProjectName"を初期化（会社名案件名にあたる
↓
InitializeVariableで"AzureResourceId"を初期化（アラートの一意のIDにあたる
↓
SwitchCaseでサブスクリプションID毎にケース分岐してProjectNameに（案件名）を登録
↓
ForEachで受けたhookが入ってるのをループ
↓
"AzureResourceId"にURIでコードしたリソースidを登録
↓
Conditionでアラートのstatusが"Activated"かどうかで処理を分岐
↓
trueの場合、HTTPでCreateIssue、
HeaderにRedmineAPIKeyを、Bodyのcustom_fieldsに"AzureResourceId"、
subjectにProjectNameとmetricNameとresouceNameを、
project_idに"RedmineProjectId"を指定、
Descriptionにそのほかのメトリックの状況を示す内容を指定
（metricValueを忘れないように）
↓
falseの場合、HTTPでオープンしているIssue情報をGet、
戻り値をParseJSONでパースしてダイナミック変数登録
"AzureResourceId"にあたる値が一致するチケットのissue_idを特定
↓
ForEachでissueを処理
↓
HTTPで既存のRedmineIssueを更新
"AzureResourceId"にあたる値が一致するチケットのissue_idを指定して更新
StatusをResolvedに更新
noteにAlertIsClosedと登録
RedmineのAPIリファレンス
https://www.redmine.org/projects/redmine/wiki/Rest_api
https://www.redmine.org/projects/redmine/wiki/Rest_Issues
事前の用意が要るもの
→Redmineのプロジェクトとトラッカーとカスタムフィールドの定義と必要なIDの特定、APIキー
→アラート飛ばす元のルールとアクションの定義
デバッグに用いたもの
＞Postman
https://www.getpostman.com/downloads/
RestAPIの実行と結果確認と履歴が保存されるのでその活用がしやすくて便利なツール
Curlを打つよりもオプションとかmanみる必要もない
LoggicAppでやりたい内容をまず単体でAPI通信し処理が可能かどうかを確認する
（正直横で見ていただけだが超つかいやすそうでテスト毎にフォルダわけて保存できたり）
＞LogicAppsのヒストリとそこからの再実行
OverviewからRunsHistoryを選択でき、詳細画面に遷移して各個々の実行時のパラメータなどを詳細に見ることができる
その詳細画面（またはRunhistoryの一覧の右クリック選択）でResubmitボタンを押すとその履歴と同じ条件で再実行することができる。
適当にアラートを出して飛ばすためのテスト用アラートルール
CPU1%超えたら等で生殺与奪が自由になる適当なホストにアラートルールとアクションを定義
ハマったところなど
URLデコードが必要
→デコードしてもらった
ループの入れ子の変数が効かない
→codeからなおす
コードみたら壊れた
→保存せずに更新を破棄するのと別窓であけて履歴から確認するなど
環境の取り違え
→アラートのアクションの飛ばしてるさきのLoggicAppが認識してるのと違っていてHTTPが効かないなと思っていた
ペア作業での指摘で発覚した
テストがしづらい
→RestAPIの結果はPostmanでみるのがいい
→履歴から再実行できるのでそうするのがいい
jsonスキーマ貼る場所
→実データを貼るとスキーマを勝手に登録してくれたりする
まあ実際のアラートの管理は人が対応要らない場合の閾値調整だとか調査方法を特定してRedmine追記するやりかたをwikiるとか色々ほかにも。
そのた、Loganalitics検索コネクタでアラート出た直近のログもベタっと自動でできないかなとは思ったのですが、マルチテナントの権限がアレだったというか、AzureのリソースのAPIはサービスプリンシパルじゃないとだめそうな気がしました。
以上