New Relicの開発ツールキットは、開発者の労苦を軽減するために構築された一連のツールを提供しています。「Terraformを使用したNew Relic Alertポリシーの定義」では、New Relic Terraformプロバイダーを使用して、インフラストラクチャおよびアプリケーションコードと一緒にモニタリングおよびアラート構成をコードで管理し、デプロイする方法について説明しました。現在、Kubernetesについても同じことを行うことができます。

この投稿では、Kubernetes Operatorとその有用性について簡単に説明し、New Relic KubernetesOperatorがKubernetesデプロイメントと一緒にNewRelicリソースをシームレスにデプロイする方法をご紹介します。

Kubernetes Operatorとは?

Kubernetes Operatorは、カスタムリソースを利用してアプリケーションとそのコンポーネントを管理する、Kubernetesの拡張機能です。Kubernetes Operatorは、Kubernetesの原則、特にコントロールループに従います。

Kubernetesは、クラウドでコンテナ化されたサービスをデプロイするためのデファクトスタンダードになりつつあります。Kubernetesはバージョン1.7でOperatorパターンを導入し、サードパーティサービスの設定やプロビジョニングなどのドメイン固有の操作を実行できるカスタムKubernetesオブジェクトを定義することでKubernetesを拡張できるようにしました。

New Relic Kubernetes Operatorについて

New Relic Kubernetes Operatorは、Kubernetes設定を管理するのと同じ方法でNewRelicリソースを設定する機能を提供します。

たとえば、クラスターにオペレーターをインストールすると 、NewRelicのカスタムKubernetesオブジェクトを使用してNewRelicアラートポリシーを作成できます。NRQLアラート条件を使用してオブジェクトを構成することもできます。スタンドアロンのNewRelic NRQLアラート条件を構成し、それを既存のアラートポリシーに適用することも可能です。

 この投稿は、New Relic KubernetesOperatorバージョンv0.0.2およびKubernetesバージョン1.18.2で作成されました。

やってみましょう

このウォークスルーは、Kubernetesクラスターが既にデプロイされていることを前提としています。また、kubectlをインストールし、正しいクラスターを操作できるように設定されていることを前提として話を進めます。

New Relic Kubernetes Operatorのインストール

NewRelic Kubernetes Operatorのインストールは2段階のプロセスです。

まず、KubernetesでTLS証明書を自動的にプロビジョニングおよび管理するcert-managerをインストールします。

kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.0/cert-manager.yaml

次に、New Relic Kubernetes Operatorをインストールします。

kubectl apply -k github.com/newrelic/newrelic-kubernetes-operator/config/default

インストールが成功したことを確認するには、いくつかのkubectlコマンドを実行してステータスを確認します。

New Relic Kubernetes Operator用の名前空間newrelic-kubernetes-operator-systemが作成されていることを確認します。

kubectl get namespaces

出力は、newrelic-kubernetes-operator-systemを含む以下の例のようになります。

NAME                                     STATUS   AGE
cert-manager                              Active   4m35s
default                                   Active   20m
kube-node-lease                           Active   20m
kube-public                               Active   20m
kube-system                               Active   20m
newrelic-kubernetes-operator-system       Active   3m48s

New Relic Kubernetes Operatorのコントローラーマネージャーが実行されていることも確認しましょう。

kubectl get pods --namespace newrelic-kubernetes-operator-system

注:正しい名前空間内のリソースを確認するために、実行時オプションを含めることを忘れないでください--namespace (shorthand -n)kubectl get pods

次のような出力が表示されます。

NAME                                                               
READY STATUS RESTARTS AGE 
newrelic-kubernetes-operator-controller-manager-7b9c64f58crwg9j 2/2      
Running 0 157m

上記のような出力が表示されたら、次のステップに進む準備ができています。newrelic-kubernetes-operator-controller-manager-<hash>という名前のPodが表示されない場合は、kubectlやKubernetes構成を再確認して、コンテキストに間違いがなく、kubectlが正しいクラスターを指していることを確認してください。

New Relic Kubernetes Operatorの使用

無事にNew Relic Kubernetes Operatorがクラスターにデプロイされました。これで、アラートポリシーやコンディションなどのNRQLアラート条件の設定を、マニフェストでデプロイ・管理することができます(他のKubernetes設定を作成するのと同じ方法で管理できます)。

ワークフローの概要

通常は、以下の3段階で適用します。

  1. 宣言型のアプローチを使用して、アラートポリシー構成ファイル(マニフェスト)を作成します。
  2. NewRelicパーソナルAPIキーを構成に追加します。
  3. 準備ができたらkubectl applyを実行します。

最初のアラートポリシーを作成する

物事を開始するには、小さく始めます。まず、必要最小限の構成でアラートポリシーを作成してから、NRQLアラート条件をポリシーに追加します。これにより、NewRelicのポリシーにコンディション条件が追加されます。

最小限のアラートポリシー構成は、以下のコードで表されます。このウォークスルーのために、このファイルに名前を付けますnew_relic_alert_policy.yaml

new_relic_alert_policy.yaml

apiVersion: nr.k8s.newrelic.com/v1
kind: AlertsPolicy
metadata:
  name: my-policy
spec:
  account_id: <your New Relic account ID> # New RelicアカウントIDを指定します
  api_key: <your New Relic personal API key> # personal API keyを指定します
  name: "Alert Policy Created With k8s" # アラートポリシー名を指定します
  region: "us"

注:personal API keyについては、NewRelicのドキュメントをご覧ください。

キーなどのセンシティブな情報をマニフェストに直接記述するのはリスクが高いので、Secretを利用することもできます。
予めSecretを作成しておきポリシーのマニフェストからSecretを参照することで、アカウントIDやpersonal keyを隠蔽することができます。サンプルはこちらにあります。

次に、kubectl applyコマンドを実行してアラートポリシーを作成します。

kubectl apply -f ./new_relic_alert_policy.yaml

次のような出力が表示されます。

alertpolicy.nr.k8s.newrelic.com/my-policycreated \

 

New Relic上でポリシーを表示し、アラートポリシーが作成されたことを確認します。名前で新しいポリシーを検索できます。この場合、ポリシー名はAlert Policy Created With k8s」で検索します

これで新しいアラートポリシーが作成されました。
次に、同じ構成ファイルを使用して、ポリシーにNRQLアラート条件を追加してみしょう。

 

NRQLアラート条件をアラートポリシーに追加する

アラートポリシーを作成したので、ポリシーにいくつかのアラート条件を追加して、特定のメトリックがラインから外れたときにアラートをトリガーできるようにします。

new_relic_alert_policy.yamlファイルで、NRQLアラート条件をポリシーに追加します。これは、アプリケーションの全体的な平均応答時間が3分間で5秒を超えたときにアラートを出すものです。

new_relic_alert_policy.yaml

# The policy from the previous steps
apiVersion: nr.k8s.newrelic.com/v1
kind: AlertsPolicy
metadata:
  name: my-policy
spec:
  account_id: <your New Relic account ID>
  api_key: <your New Relic personal API key>
  name: "Alert Policy Created With k8s" 
  incidentPreference: "PER_POLICY"
  region: "us"

  # 先ほどのファイルに以下を追加します。
  conditions:
    - spec:
        type: "NRQL"
        name: "NRQL Alert Condition Created With k8s"
        nrql:
          query: "SELECT average(duration) FROM Transaction WHERE appName = 'YOUR APP NAME'"
          evaluationOffset: 3
        enabled: true
        terms:
          - threshold: "5"
            threshold_occurrences: "ALL"
            threshold_duration: 180
            priority: "CRITICAL"
            operator: "ABOVE"
        violationTimeLimit: "ONE_HOUR"
        valueFunction: "SINGLE_VALUE"

注:アラートがトリガーされたときに通知受信するには、アラートポリシーに通知チャネル 追加する必要があります。

この状態で再度 kubectl applyコマンドを実行し、アラートポリシーを更新します。これにより、NRQLアラート条件が作成され、ポリシーに追加されます。

kubectl apply -f ./new_relic_alert_policy.yaml

NRQLアラート条件が正常に作成されたことを確認するには、アラートポリシーを更新します。アラートポリシーに新しいアラート条件が追加されていれば成功です。

最後に 通知チャネルを作成してアラートポリシーに追加します。たとえば、アラート条件がトリガーされたときにチームにメールを送信する場合などです。github上にサンプルがありますので、ぜひチャレンジしてみてください。

まとめ

Kubernetesワークフロー内にシームレスに統合されるコードを使用して、NewRelicアラートポリシーとNRQLアラート条件を管理できるようになりました。これにより、ドメイン固有のパターンでアラートを構成および管理し、一貫性と保守性を提供できます。また、今後の潜在的な変更に対するコードレビューのメリットも得られます。New Relic Kubernetes Operatorは、コードとしての可観測性を促進することを目的としたNew Relic DeveloperToolkitのいくつかのツールの1つとして提供されています。

New Relicオープンソースでは、New Relic KubernetesOperatorだけでなく、ワークフローを自動化するのに役立つ様々なツールを提供しています。ぜひ他のツールも確認してみてください

 

Happy monitoring!!!

 

SIerにてシステム開発プロジェクトのPMやインフラ設計・構築などを歴任。その後、クラウドインテグレーション組織の立ち上げを行い、多くのお客様システムのクラウド移行を支援。近年はDevOpsやクラウドネイティブ化へ向けたコンテナやKubernetes、CI/CDなどの技術要素の導入支援を行い、現職。現在はDevRelを通じた文化醸成に興味を持っている。 View posts by .