先日のGitHub University Recap Tokyo 2024でも紹介した機能です。GitHub ActionsのWorkflowの実行に関するテレメトリーデータをNew Relicに取り込み、可視化することができます。
セットアップ
テレメトリーデータは、以下のリポジトリで公開されているGitHub Actionsを使ったWorkflowを定義し、計測対象のWorkflowが実行された後に起動することで送信されます。
手順の詳細はこのリポジトリのREADME.mdに記載されています。まず、GitHubからデータを取得し、New Relicにデータを送信するので、GitHubとNew Relicに認証するキーがそれぞれ必要となります。New Relicについては、Ingest License KeyをNEW_RELIC_LICENSE_KEYという名前でGitHub ActionsのSecretsに設定します。GitHubについては、自動トークン認証を利用する場合はGITHUB_TOKENを参照します(Secretsの追加は不要です)。このとき、自動トークン認証がactionsへの読み取り権限を持っていることを確認してください。もしくは個人用アクセストークンを利用することもできます。
workflowは新規に作成し、サンプルの定義を記載します。ほぼそのまま利用できるはずです。サンプルの定義であれば、他のworkflowが実行されるとトリガーされそのテレメトリーデータを送信します。何かしら別のworkflowを実行し、このworkflowが正常に実行されるのを確認したら、実際のデータを見てみます。
実際のデータを確認する
計測されたデータは、OpenTelemetryで計測されたServiceのエンティティとして表示されます。New Relic UIでAll EntitiesのServices - APMもしくはAPM & Servicesの画面で、リポジトリ名を名前にもったエンティティとして表示されているはずです。下の画像だと、newrelickk/NewRelicKKLab.GHU-DemoApp に該当します。
APMというエンティティにはなっていますが、実際には分散トレースのデータのみ記録されているので、Distributed tracingの画面を確認します。1つのWorkflowを1つのTraceとして記録するので、Trace groupsには計測したworkflowごとに表示されているはずです。下の画像では、1つのWofklowのみを計測しています。
なお実行しているWorkflowは次の定義となっています。
name: Build and deploy ASP.Net Core app to Azure Web App - ghu-demo-webapp
on:
push:
branches:
- master
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up .NET Core
uses: actions/setup-dotnet@v4
with:
dotnet-version: '8.x'
- name: Build with dotnet
run: dotnet build --configuration Release
- name: dotnet publish
run: dotnet publish -c Release -o ${{env.DOTNET_ROOT}}/myapp
- name: Upload artifact for deployment job
uses: actions/upload-artifact@v4
with:
name: .net-app
path: ${{env.DOTNET_ROOT}}/myapp
deploy:
runs-on: ubuntu-latest
needs: build
environment:
name: 'Production'
url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
permissions:
id-token: write #This is required for requesting the JWT
steps:
- name: Download artifact from build job
uses: actions/download-artifact@v4
with:
name: .net-app
- name: Login to Azure
uses: azure/login@v2
with:
client-id: ${{ secrets.AZUREAPPSERVICE_CLIENTID_ID }}
tenant-id: ${{ secrets.AZUREAPPSERVICE_TENANTID_ID }}
subscription-id: ${{ secrets.AZUREAPPSERVICE_SUBSCRIPTIONID_ID }}
- name: Deploy to Azure Web App
id: deploy-to-webapp
uses: azure/webapps-deploy@v3
with:
app-name: 'ghu-demo-webapp'
slot-name: 'Production'
package: .
- name: Update Env Vars
id: update-envvar
uses: Azure/cli@v2.1.0
with:
inlineScript: "az webapp config appsettings set -g ghu-demo -n ghu-demo-webapp --settings NEW_RELIC_METADATA_COMMIT=${{ github.sha }}"
newrelic:
runs-on: ubuntu-latest
name: New Relic
steps:
# This step builds a var with the release tag value to use later
- name: Set Release Version from Tag
run: echo "RELEASE_VERSION=${{ github.ref_name }}" >> $GITHUB_ENV
# This step creates a new Change Tracking Marker
- name: New Relic Application Deployment Marker
uses: newrelic/deployment-marker-action@v2.3.0
with:
apiKey: ${{ secrets.NEW_RELIC_API_KEY }}
guid: ${{ secrets.NEW_RELIC_DEPLOYMENT_ENTITY_GUID }}
version: "${{ env.RELEASE_VERSION }}"
changelog: "https://github.com/${{ github.repository }}/blob/master/CHANGELOG.md"
commit: "${{ github.sha }}"
description: "Automated Release via Github Actions"
deploymenttype: "BASIC"
groupId: "Workshop App Release: ${{ github.ref_name }}"
user: "${{ github.actor }}"
# When chaining steps together, the deployment id is placeed into the github environment
- name: View output
run: echo "${{ env.deploymentId }}"
Trace groupsを開くと、workflowの1回の実行結果が1つのtraceとして記録された様子がわかります。下の画像では2回実行されています。Trace durationが1回のworkflowの実行時間です。記録された2回で32秒と1分52秒と大きく差がありますが、これはDeploy Gateによるチェック条件が満たされずデプロイのアクションが実行されなかったためです。
さらにいずれかのTraceを開くと、そのworkflowの中で実行されたアクションおよびその中のstepsがSpanとして記録された分散トレースを確認できます。下の画像では一番時間がかかっているのはdeployというアクションで、その中でどんな処理が行われ、どのくらい時間がかかっているかがわかります。
このworkflowは3つのアクションがあり、その中のdeployアクションはbuildアクションの完了が必要です。そのためnewrelicアクションはdeployアクションの完了を待たずに実行することができ、実際並行に処理されていることがこのトレースからもわかります。
このnewrelicアクションではNew Relic Change Trackingのために、New Relic Application Deployment Markerを使って変更情報をNew Relicに記録しています。実際の運用では実際にデプロイが成功したときだけ変更情報を記録したい時が多いと思いますので、deployアクションが成功したときだけ実行する方が嬉しいかもしれません。
また、Logsタブではこのworkflowが実行中に出力されたログを確認することができます。
こちらの機能を使うとGitHub Actionsのパフォーマンスを可視化できるのでぜひお試しください。
その他
New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！
無料でアカウント作成も可能なのでぜひお試しください！
New Relic株式会社のX(旧Twitter) や Qiita OrganizationOrganizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！