第143回 雲勉 [New Relic]インフラストラクチャ監視と気をつけたいポイント

下記、勉強会での資料です。
https://www.youtube.com/watch?v=1mWH6EqePMQ

Transcript

1. 第143回 雲勉 [New Relic] インフラストラクチャ監視と 気をつけたいポイント
2. ０．講師自己紹介 1 ◼ 名前 茅根 涼平(ちのね りょうへい) • (所属)クラウドインテグレーション事業部(構築チーム グループリーダー) • (経歴)新卒入社 コンテナ、エンドユーザーコンピューティング、ネットワーキングとコンテンツ配信 • (アイレット歴)7年目 • (担当案件) EKS環境の構築・運用保守 ※ご質問は YouTubeのコメント欄で受け付けております。後日回答させていただきます！ AWS Well-Architected Lead
3. アジェンダ 3 0. 自己紹介 1. New Relicとは 2. データ集約・アラート 3.気をつけたいポイント 4.まとめ
4. 本日のゴール 4 ◼ New Relicを使用したインフラの監視設定とデータ取り込み量を理解する ・◦アラート ・◦インフラ監視 ・× Synthetics Monitoring ・×ダッシュボード ・×アプリケーション パフォーマンス監視 (APM) ・×インタラクティブ アプリケーション セキュリティ テスト ・×脆弱性管理 ・×サービスレベル など 今日話すこと
5. 1. New Relicとは 5
6. New Relicとは 6 引用:https://newrelic.com/jp システムを詳細に可視化できる ・パフォーマンス(アプリ、インフラ) ・トラブルシューティング すべての機能を備えたオブザーバビリティプラットフォーム さまざまなシステムコンポーネントのデータを集約し、運用者が分かりやすく可視化できる
7. 7 インフラストラクチャモニタリング サーバーやインフラストラクチャのパフォーマンスを監視し、リソースの利用状況や問題を把握します。これによ り、システム全体の健全性を保つことができます。 アプリケーションパフォーマンスモニタリング（APM） アプリケーションの動作をリアルタイムで監視し、パフォーマンスの問題やボトルネックを特定します。これに より、開発者はアプリケーションの速度や安定性を向上させるためのデータを得ることができます。 ビジネスオブザーバビリティ ビジネスの観点からアプリケーションのパフォーマンスを理解するためのデータ分析を支援します。 synthetics monitoring、ブラウザモニタリングとモバイルモニタリング、サービスレベル管理などの機能があ り、顧客離れ、収益インパクトなどデータに基づく意思決定を迅速に行うのに役立ちます New Relicとは
8. 2. データ集約・アラート 8
9. Integration 9 New Relic Integrationでは ・パブリッククラウド ・OS、ミドルウェア ・ネットワーク などの情報を収集できます Kubernetes Pixie Kubernetes/Pixieからのデータを監視およびレポート Prometheus Prometheusからのデータを監視およびレポート On-host Integration 多数のサービス （Apache, NGINX. MySQL, Redisなど） からのデータを監視し、レポート Flex 独自インテグレーションからデータを監視、レポート AWS APIポーリングモード/ストリームモード Azure APIポーリングモード Google Cloud APIポーリングモード 引用:https://docs.newrelic.com/jp/docs/infrastructure/infrastructure-monitoring/get- started/get-started-infrastructure-monitoring/
10. 10 Integration設定すると何ができるようになる？ ・モニタリングUIで、メトリクスの絞り込みと分析できる ・SQLベースのクエリで、カスタムチャートやダッシュボードを作成できる ・アラート条件を作成して、システムやパフォーマンスの問題点を監視できる Integration
11. Alert 11 New Relic Alertsと通知動作の条件 New Relic Alerts は「Policy」、「Condition」、「Workflows」で構成されている 1. アラート条件（Alert Condition）に定義した条件違反が検出される 2. Incident状態になると、Issueが作成される 3. IssueがWorkflowをトリガーして、ユーザーへの通知が行われる
12. 12 Policy インシデントが発生したときにどのように通知するかを定義する条件のグループです。 通知の受け取り方は組織やチームそれぞれ異なるため、ニーズに合わせて選択します。 ポリシーごとに 1 つ Conditionごとに1つ ConditionおよびSignalごとに1つ Alert
13. 13 ・ポリシー全体を通じて、一度に 1 つの問題のみ作成されます ・通知数が最も少なくなります ・アラート中は新たなインシデントは生成されません ・ポリシー内の各条件ごとに、一度に 1 つの問題が開かれます ・障害発生中に別のConditionで閾値が越えた場合には、 新たなインシデントが生成されます New Relicのコンソール上で、何に対して対応が必要か特定します 外部ツールで1次対応ツールなどある場合 課題管理ツールに情報を残したい場合 ポリシーごとに 1 つ Conditionごとに1つ Alert
14. 14 ・アラートポリシーの中に含まれる、全てのCondition、全ての エンティティ毎にインシデントが生成されます ・通知数が最も多くなります 外部ツールで1次対応ツールなどある場合 課題管理ツールに情報を残したい場合 ConditionおよびSignalごとに1つ Alert
15. 15 例えば AおよびBがアラート状態でインシデントにする A, Bどちらかがアラート状態である場合インシデント とする 個別Conditionを組み合わせて 1 つのConditionにし、さらに詳細なアラート条件を定義 アラートのノイズを低減 集約したレベルでのみアクションを実行可能になる New Relicではできない 似たような設定をするには、 あらかじめPolicyで分類する Alert
16. 16 Alert condition アラート条件で定義した条件に該当すると、Incidentが作成されます 今回はNRQLを使用したConditionの方法を説明します アラート条件をガイド付きで作成することができます。 (必要なオプションを選択するだけでconditionを作成できます) アラート条件を詳細に指定して作成することができます NRQL クエリを最初から作成する代わりに、チャートを使用すると、 既存の NRQL クエリを使用してプロセスを開始できます Alert
17. 17 NRQLを使用したCondition 句 説明 SELECT メトリクスを選択する。average,sum,max,min,latest,countなどの関数を組み合わせる FROM データタイプを指定する。ストリームならMetric、APIポーリングなら該当するデータ WHERE 検索条件を指定する。標準的な比較演算子、論理積など FACET 結果を属性値で分割してグループ化 Alert
18. 18 ①Window duration ②sliding window ③Streaming method ④Delay ⑤Gap filling strategy ⑥Evaluation delay ⑦Static / ⑩Anomaly ⑧ level ⑨Thresholds 条件設定 ⑪Consider the signal lost after Alert
19. 19 ①評価対象期間(Window duration) 評価対象のデータを集約する期間を定義するものです 1minであれば1min範囲内のデータが集約対象、2minであれば2min範囲内のデータを集約します ※このデータはタイムスタンプに基づきまとめて収集されます Data aggregation NRQL> SELECT （sum()、average()、またはlatest()など） 例えば データの間隔が60秒毎で値が50,60,70,80で到着し、Window Durationが300秒とする場合 集計関数max集計後のデータ値は80となる Alert
20. 20 ②スライディング ウィンドウ(sliding window aggregation) スライディング ウィンドウは、「とがった」チャートを滑らかにする必要がある場合に役立ちます 参考: https://forum.newrelic.com/s/hubtopic/aAX8W0000008caAWAQ/whats-on-deck-for-alerts-sliding-windows-aggregation ・不安定な信号や不安定な信号をより一貫して集約できるようになります ・まれな信号や一貫性のない信号に対する、より正確で信頼性の高いアラートにできます 引用: https://docs.newrelic.com/docs/nrql/using-nrql/create-smoother-charts-sliding-windows/ Alert
21. 21 Event Flow: データが頻繁に、かつ一貫して直線的に届く場合がお勧めです [イベントフローの使用例] ・エージェントからのデータ ・多くの CloudWatch Metric (CloudWatch Metric Streams使用) ③ストリーミング メソッド(Streaming method) 集計方法は、「Event Flow」、「Event Timer」、「Cadence」の3つがあります Event Timer: データが散発的に、矛盾して、不規則に届く場合がお勧めです [イベントタイマーの使用例] ・APIポーリングされているクラウドインテグレーションデータ ・エラーの数など、データが少ない、または頻度の低いデータを配信するクエリ Cadence: 古い設定方法のため省略します Alert
22. 22 ④遅延(Delay) アグリゲーションが行われる前に、すべてのデータポイントがアグリゲーションウィンドウに 到着していることを確認するための時間的な遅延です ※Delayの使用はEvent Flow、Cadenceを選択している場合 指定した遅延（Delay）の時間経過し、後続のウィンドウのデータが到着したタイミングで評価対象 期間（Window duration）のデータを集約します Alert
23. 23 ⑤ギャップを埋める(Gap filling strategy) 到着したデータに欠損が存在する場合に、欠損データをどう扱って評価するかを定義します 欠損のまま（None） すべての集計ウィンドウに5分間の閾値を超える データポイントが必要であり、5つの集計ウィンドウの1つが 空であるという条件が設定されている場合は、 その条件はインシデントにはなりません Alert
24. 24 固定値(Custom static value) ・評価する前に空の集計ウィンドウにカスタム静的値を挿入します ・データの欠損がクリティカルな影響を与える場合に、 アラートを上げるような値または妥当な値を入れます 前出の値(Last known value) ・評価が行われる前に最後に表示された値を挿入します ・最後に表示された値の状態は最低2時間維持されます Alert
25. 25 ⑥評価の遅れ(Evaluation delay) 設定した閾値に対して新しい信号を評価する前に、New Relicが待機する時間が設定できます。 これは、データストリームのレポート開始時の誤検知インシデントを防ぐのに役立ちます。 最初のアラートでは、このオプションがデータに適用されることがわかっている場合を除いて、 トグルを無効のままにしておくことができます。 例えば、オートスケール環境が有効的です。 新しいエンティティが最初にデプロイされると、そのエンティティのリソース使用率が異常に高くなること があり、誤ったアラートが多数作成されやすくなります。 新しいエンティティから発信された信号のアラート検出の開始を遅らせることで、 デプロイメント関連の誤検知の数を大幅に減らすことができます。 Alert
26. 26 条件のしきい値を設定 ⑦Static 静的な閾値の超過有無で判定する ⑧重大度(Severity level) Warning/Critical ⑨閾値(Thresholds) for at least 閾値を超過する状態が続いたら インシデントがオープンする at least once データポイントのいずれかが閾値の 範囲外になるとインシデントがオープンする Alert
27. 27 ⑩Anomaly 過去のデータに基づいて予測された正常範囲からの逸脱有無で判定 閾値の方向 Upper and lower Upper only Lower only 実際の値が予測値からどれだけ離れているかを許容 するアラート条件の感度を制御します。 閾値は、信号値が予測された値から離れている標準 偏差の数です。 過去 7 日間のデータの予測値と実際の値の間の標準 偏差を追跡します。 引用: https://docs.newrelic.com/jp/docs/alerts/create-alert/set-thresholds/anomaly-detection/ Alert
28. 28 ⑪信号損失しきい値(Consider the signal lost after) NRQL型アラートのデータ受信が途絶えたことを検出したい場合、 データ受信の停止時間 (待機時間) を設定することで、シグナル消失として検出することができます。 Close all current open incident 現在開いているすべてのインシデントを閉じる Close all current open incident 信号が失われたと判断されたときに、 新しいインシデントを開く 上記の両方のアクションを有効にする まずすべてのオープンインシデントが閉じられ、 次に信号損失に関する新しいインシデントが開かれます。 Alert
29. 29 Do not open "lost signal" incident on expected termination 信号が終了することが予想される場合は、新しいインシデントを開かないように選択できます。 これは、特定の時間に信号が失われることがわかっていて、その信号喪失に対して新しいインシ デントを開きたくない場合に便利です Alert
30. 3.気をつけたいポイント 30
31. 気をつけたいポイント 31 データの取り込み量 引用: https://docs.newrelic.com/jp/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing/
32. 32 請求対象の取り込みデータとみなされるものは？ ・インフラストラクチャデータやディメンションメトリクスなど ・ゴールデンメトリクス( New Relic Lookout、Workloadsなど) ・Syntheticモニターチェック(ping モニターを除く) ・追跡データの使用量と請求（NrConsumptionなど） ・アカウント管理に関連するデータ（NrIntegrationError、NrAuditEventなど） 参照元 https://docs.newrelic.com/jp/docs/accounts/accounts-billing/new-relic-one-pricing-billing/data-ingest-billing/#usage-calculation 気をつけたいポイント
33. 33 メトリクス APIポーリングモード AWS 設定内の AWS services にて監視対象以外のサービスにチェックを入れていないか 気をつけたいポイント
34. 34 ストリームモード ストリームはデータ量を理解して、サービス単位、メトリクス単位で選択できているか 本当に必要なメトリクスを選択しない場合 ・データの取り込み量が増加 ・AWS利用料が増加 気をつけたいポイント
35. 35 プロセス システム的やビジネス的に重要なホストとプロセスをフィルター適用する すべてのプロセスデータを送信すると、New Relicに送信されるデータの量が増える可能性があります 句 説明 enable_process_metrics プロセスのデータを取得するように設定 disable_zero_mem_process_filter プロセスのメモリ使用率が少ない場合でもデータを取得するように設定 include_matching_metrics 監視するプロセスを指定する process.executable 監視する プロセスの実行ファイル を記載する 気をつけたいポイント
36. 36 ログ システム的やビジネス的に重要なホストとログをフィルター適用する すべてのログデータを送信すると、New Relicに送信されるデータの量が増える可能性があります 句 説明 name New Relic に転送するログの名前を定義をする。 Logs に格納される情報ではないのでファイル内で区別つきやすい任意の名前 disable_zero_mem _process_filter パスを含めた対象ログファイルを記載する。 例）/var/log/message /var/log/httpd/error/*_log ※ファイルパス内にワイルドカードを使用できます。 pattern 対象ログファイル内のレコードをフィルタリングするための正規表現を記載します。 ※指定しない場合、全てのログを転送するので、必要なものだけを転送するようにフィルタリン グをお願いします。 気をつけたいポイント
37. 37 ドロップフィルタールール 引用: https://docs.newrelic.com/jp/docs/logs/ui-data/drop-data-drop-filter-rules/ フィルターに一致するデータがNew Relicデータベース（NRDB）に書き込まれる前に、 取り込みパイプラインから削除されます ・特定の属性を削除してコスト削減する ・重要なログのみ保存できる 気をつけたいポイント
38. 38 使用量の確認 参考 https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-pricing-billing/usage-queries-alerts/ 請求の管理を容易にする、 予期しないデータ取り込み量を把握する アラート設定 ・取り込んだギガバイトがしきい値を超えた ・使用量が推定コストしきい値を超えた Administration -> Data Management -> Data ingestion 気をつけたいポイント
39. 39 データ制限を理解する 参考 https://docs.newrelic.com/jp/docs/licenses/license-information/general-usage-licenses/new-relic-data-usage-limits-policies/ 制限を超えた場合 データ収集の一時停止または中止 制限に達した場合 達した制限の種類、制限を超えた期間、 頻度、量など、いくつかの要因によって 異なります。 多くは比例的に適用されます。つまり、制限をわずかに超えている場合、200% 超え ている場合よりも、より少ない措置が取られます。 気をつけたいポイント
40. 40 インシデント テーブルの色分け 赤: 制限を超えた 黄色: 制限の80～100% 緑: 80%未満 灰色: 指定された期間に使用状況や インシデントが報告されていない制限 Administration -> Data Management -> Limit ダッシュボードを利用 現在のシステムリミットの消費状況や超過しているシステムリミットを確認することができます 気をつけたいポイント
41. 41 参考 https://docs.newrelic.com/jp/docs/data-apis/manage-data/query-limits/ リミットメトリクスを利用した監視 リミットメトリクスを利用することによってシステムリミットの消費状況を閾値監視することが可能です 項目 説明 newrelic.resource Consumption.limitValue システムリミットの制限値 newrelic.resource Consumption.currentValue システムリミットの現在値 newrelic.resource Consumption.impact システムリミットの超過により発生している制限イベント数 属性 説明 limitName リミットメトリクスの種類(例：RPM Metric API)、 newrelic.resourceConsumption.impactには無し dataType メトリクスが指しているデータの区分(例：Metric, Log, APM) Resource 対象のリソース(例：Request) Impact システムリミットの超過により起きているイベントについての情報、 newrelic.resourceConsumption.impactのみ consumingAccountId リソースが消費されているNewRelicアカウント 気をつけたいポイント
42. 4.まとめ 42
43. まとめ 43 1.New Relictとは すべての機能を備えたオブザーバビリティプラットフォームです 2.アラート作成 大量のアラートを一つにグループ化したり、データタイプや さまざまなケースに合わせて監視設定できる 3.データ送信量 オブザーバビリティ観点では、さまざまデータを集約した方が効率的に分析できるが、 コスト意識を持って本当に必要なデータに絞ることも大切です
44. ご清聴有り難うございました