GitHub ActionsでNew RelicのChangeTrackingやってみた

初めてアドベントカレンダーに参加してみました。以下に参加しております。

https://qiita.com/advent-calendar/2024/newrelic

この記事では、GitHub Actionsを活用してNew RelicのChange Tracking機能を試した体験を紹介します。具体的には、インフラ構成変更と同時にChange Trackingの記録を自動化する方法について説明します。

# GitHub Actionsで実施したこと

1. GitHub Actionsでnewrelic-infra.yml等の設定ファイルを更新する
1. 設定変更したときにChange Trackingを記録する
の2点です。
今回はNew Relicが本題ですのでGitHub Actionsの詳細は省きますが、やっていることは単純です。
GitHubにあるymlファイルをコピーして、newrelic-infrastructure-agentの再起動をしているだけ。

気にしたところはnewrelic-infra.ymlにはAPI Keyが入っているため、そこだけ
`license_key: {{ secrets.NEW_RELIC_API_KEY }}`
こんな感じでGitHub secretを使って後からいれるようにしました。
newrelic-infra配下のlogging.d等も管理対象にしてあります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262558/cd0176d3-14d3-9138-9f1b-7685f5604f89.png)

## ChangeTrackingを追加する

Change Trackingの概要と設定方法についてはこちらを参考にしました。

https://qiita.com/khara-nrkk/items/7eb11759bf0e17a11bdc

https://docs.newrelic.com/jp/docs/change-tracking/ci-cd/change-tracking-github-actions/

設定はとても簡単でした。

1. GitHub シークレットを登録する
1. GitHub Actions用に用意されている`New Relic Application Deployment Marker`の記載をymlファイルに追記する
の2点だけでとりあえず動いてしまいます。

### apiKeyの設定ではまる

はまったポイントとしてはAPIkeyの設定でKeyには2種類あることを意識せず、変数の値を入れ替えてしまったところです。

Keyの利用にはGit Hub Actions secretを使っていたのですが、最初infrastructure agentの設定ファイル用に`NEW_RELIC_API_KEY`という名前でつくっていたのですが、こちらをChange Trackingでも兼用したのが失敗でした。

最初うまくChange Trackingの登録がされず、keyを変更したところ、うまくいったので、よかったよかったと思っていたら、markerが付いた後から突然agentからのデータが取れなくなったので、あー、なんかまずったなと気づきました。markerが付いた直後から変化がでたので、自分の変更作業の影響だと確信でき、いきなりChange Trackingの効果を実感しました。

API Keyには`USER KEY`と`LICENSEKEY`があるのでご注意ください

GitHub Actionsのsecretの内容は変更できますが、既存の値は確認できないため、
最終的にsecretは下記のようにわかりやすいように分けました

```yaml
${{ secrets.NEW_RELIC_API_LICENSE_KEY }}
${{ secrets.NEW_RELIC_API_USER_KEY }}
```

### ymlファイルのカスタマイズ

今回はせっかくGitHub Actionsと連携しているので、必須属性以外にcommitidとcommit時のコメントを追加するようにしました。

```yaml
commit: ${{github.sha}}
changelog: ${{github.event.head_commit.message}}
```

### guidをnameから特定する

必須な要素としてChangeTrackingを登録する対象を指定する必要があります。Entity guidはNew Relicの画面から`Metadata`というボタンから表示できるのですが、できればサービス名とかホスト名でとってこれないかなと思い、`Ask AI`に聞いてみました！Ask AIは見た目英語ですが気にせず日本語できいてみます。

![askai01_image_bocashi.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262558/6067e0d9-1ace-7fc8-8ed4-3b2a38d7edc5.png)

欲しい回答とはちがうのがでました、、、、でもこういうことも質問したら答えてくれるんですね。
追加で質問してみます。
![askai02_image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262558/5f3e1b04-d769-6093-9287-7695f42b6295.png)
今度はきました！curlコマンドで取得する方法です。すごいですね。
これをGitHub Actionsのymlに追加して実行します。

こんなかんじ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262558/ee5964dc-41d7-8e29-c8ba-b35fdeba01a2.png)

コマンドの引数の`YOUR_API_KEY`が入っているところがありましたが、GitHubのシークレット`${{ secrets.NEW_RELIC_API_USER_KEY }}`に置き換えます。

最初の設定がちょっと手間ですが、設定後は毎回自動で記録してくれるようになるので、とても便利ですね。

## ダッシュボードにChangesを表示させてみる

特に気にせずダッシュボードにチャートを表示させていたら、ChangeTrackingの表示がされるものとされないものがありました。

表示される場合
![query01_bocashi.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262558/6c38d454-5428-0f1a-6073-27a1ab529fd5.png)

表示されない場合
![query02.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262558/549ac6de-2878-8e1e-e131-3277ad32f4a7.png)


表示させたい場合には、entityGuidを指定する必要があるようです。

### 関連のあるリソースの変更も表示させる

グラフの下にある`Related Changes`というスイッチをOnにすると、関連のあるリソースについての変更も表示させることができます。

![related_image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262558/fc380102-59e2-a73d-0d03-afb083a59d8e.png)

これに関しても出るときと出ないときがあります。
出ていない場合には`Related entities`の設定が自動でされていない可能性があります。

### Related手動設定

サービスマップの右上の`・・・`メニューから`Add/edit related entities`を開き`Add a relationship`ボタンを押したところから追加できます。

![servicemap_image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262558/e3459892-a0e7-326a-2f07-654ee594d243.png)

Select entitiesから関連付けたい対象のリソースを選択して、対象との関連性を選択します。

![select1_image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262558/8dbd82f1-30e4-dd44-ae24-ca01541a3526.png)

`Add relationship`ボタンを押した後に下記のような関連性を選択するリストが表示されます。

![select2_image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262558/0bcb567d-0a59-7b21-8d3b-1d10e3513c77.png)

ここの関連性についての詳細はこちらを参考にしました。

https://docs.newrelic.com/jp/docs/new-relic-solutions/new-relic-one/core-concepts/what-entity-new-relic/#types

追加すると一覧に出てきますが、`Added by`が`You`となっているものが今回追加したものになります。関連性のプルダウン（画像では`is the same as`となっているところです）がグレーアウトしていて変更できないものは自動で検知されたものです。

![select3_image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262558/c0d0bb73-f28a-3419-f17f-549463da4643.png)

これが終わったら下記の設定後の画像のように`Related Changes`の情報が表示されるようになります

`Relationship`設定前のチャートです
![track1_image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262558/3505513e-2a50-0112-f4f8-5a898e81e44f.png)

`Relationship`設定後のチャートです
![track2_image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/262558/d986cf73-9caa-07c4-eb93-ed876afe4a0a.png)

これによってInfrastructureの変更タイミングをAPM側のチャートに反映したり、またその逆もできるようになります。

## まとめ

今回はGitHub ActionsでのChangeTrackingをやってみましたが、自動記録、いいですね。

自動で記録される仕組みを導入することで、手作業による記録の手間を省けるだけでなく、記録漏れを防ぐことができます。また、変更作業と記録のタイムラグがほとんどなくなるため、インフラやシステムの変化を正確に把握できるのも大きなメリットです。さらに、記録対象を増やすことで、例えばインフラ変更とアプリケーション変更の関連性を可視化でき、全体的な運用管理の効率化と精度向上が期待できそうです。

今回試した方法は基本的な内容ですが、ChangeTrackingには専用のDeploymentのダッシュボードがあったり、複数のdeployをまとめて管理できるGroup IDという機能もあるようなので、
今後も、Change Trackingの活用を進めていきたいと思います。