初めてアドベントカレンダーに参加してみました。以下に参加しております。
この記事では、GitHub Actionsを活用してNew RelicのChange Tracking機能を試した体験を紹介します。具体的には、インフラ構成変更と同時にChange Trackingの記録を自動化する方法について説明します。
GitHub Actionsで実施したこと
- GitHub Actionsでnewrelic-infra.yml等の設定ファイルを更新する
- 設定変更したときに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等も管理対象にしてあります。
ChangeTrackingを追加する
Change Trackingの概要と設定方法についてはこちらを参考にしました。
設定はとても簡単でした。
- GitHub シークレットを登録する
- 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は下記のようにわかりやすいように分けました
${{ secrets.NEW_RELIC_API_LICENSE_KEY }}
${{ secrets.NEW_RELIC_API_USER_KEY }}
ymlファイルのカスタマイズ
今回はせっかくGitHub Actionsと連携しているので、必須属性以外にcommitidとcommit時のコメントを追加するようにしました。
commit: ${{github.sha}}
changelog: ${{github.event.head_commit.message}}
guidをnameから特定する
必須な要素としてChangeTrackingを登録する対象を指定する必要があります。Entity guidはNew Relicの画面からMetadataというボタンから表示できるのですが、できればサービス名とかホスト名でとってこれないかなと思い、Ask AIに聞いてみました！Ask AIは見た目英語ですが気にせず日本語できいてみます。
欲しい回答とはちがうのがでました、、、、でもこういうことも質問したら答えてくれるんですね。
追加で質問してみます。
今度はきました！curlコマンドで取得する方法です。すごいですね。
これをGitHub Actionsのymlに追加して実行します。
こんなかんじ
コマンドの引数のYOUR_API_KEYが入っているところがありましたが、GitHubのシークレット${{ secrets.NEW_RELIC_API_USER_KEY }}に置き換えます。
最初の設定がちょっと手間ですが、設定後は毎回自動で記録してくれるようになるので、とても便利ですね。
ダッシュボードにChangesを表示させてみる
特に気にせずダッシュボードにチャートを表示させていたら、ChangeTrackingの表示がされるものとされないものがありました。
表示される場合
表示されない場合
表示させたい場合には、entityGuidを指定する必要があるようです。
関連のあるリソースの変更も表示させる
グラフの下にあるRelated ChangesというスイッチをOnにすると、関連のあるリソースについての変更も表示させることができます。
これに関しても出るときと出ないときがあります。
出ていない場合にはRelated entitiesの設定が自動でされていない可能性があります。
Related手動設定
サービスマップの右上の・・・メニューからAdd/edit related entitiesを開きAdd a relationshipボタンを押したところから追加できます。
Select entitiesから関連付けたい対象のリソースを選択して、対象との関連性を選択します。
Add relationshipボタンを押した後に下記のような関連性を選択するリストが表示されます。
ここの関連性についての詳細はこちらを参考にしました。
追加すると一覧に出てきますが、Added byがYouとなっているものが今回追加したものになります。関連性のプルダウン（画像ではis the same asとなっているところです）がグレーアウトしていて変更できないものは自動で検知されたものです。
これが終わったら下記の設定後の画像のようにRelated Changesの情報が表示されるようになります
Relationship設定前のチャートです
Relationship設定後のチャートです
これによってInfrastructureの変更タイミングをAPM側のチャートに反映したり、またその逆もできるようになります。
まとめ
今回はGitHub ActionsでのChangeTrackingをやってみましたが、自動記録、いいですね。
自動で記録される仕組みを導入することで、手作業による記録の手間を省けるだけでなく、記録漏れを防ぐことができます。また、変更作業と記録のタイムラグがほとんどなくなるため、インフラやシステムの変化を正確に把握できるのも大きなメリットです。さらに、記録対象を増やすことで、例えばインフラ変更とアプリケーション変更の関連性を可視化でき、全体的な運用管理の効率化と精度向上が期待できそうです。
今回試した方法は基本的な内容ですが、ChangeTrackingには専用のDeploymentのダッシュボードがあったり、複数のdeployをまとめて管理できるGroup IDという機能もあるようなので、
今後も、Change Trackingの活用を進めていきたいと思います。