Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

iret.kumoben
September 05, 2024

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

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

iret.kumoben

September 05, 2024
Tweet

More Decks by iret.kumoben

Other Decks in Technology

Transcript

  1. 0.講師自己紹介 1 ◼ 名前 茅根 涼平(ちのね りょうへい) • (所属)クラウドインテグレーション事業部(構築チーム グループリーダー)

    • (経歴)新卒入社 コンテナ、エンドユーザーコンピューティング、ネットワーキングとコンテンツ配信 • (アイレット歴)7年目 • (担当案件) EKS環境の構築・運用保守 ※ご質問は YouTubeのコメント欄で受け付けております。後日回答させていただきます! AWS Well-Architected Lead
  2. 本日のゴール 4 ◼ New Relicを使用したインフラの監視設定とデータ取り込み量を理解する ・◦アラート ・◦インフラ監視 ・× Synthetics Monitoring

    ・×ダッシュボード ・×アプリケーション パフォーマンス監視 (APM) ・×インタラクティブ アプリケーション セキュリティ テスト ・×脆弱性管理 ・×サービスレベル など 今日話すこと
  3. 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/
  4. Alert 11 New Relic Alertsと通知動作の条件 New Relic Alerts は「Policy」、「Condition」、「Workflows」で構成されている 1.

    アラート条件(Alert Condition)に定義した条件違反が検出される 2. Incident状態になると、Issueが作成される 3. IssueがWorkflowをトリガーして、ユーザーへの通知が行われる
  5. 13 ・ポリシー全体を通じて、一度に 1 つの問題のみ作成されます ・通知数が最も少なくなります ・アラート中は新たなインシデントは生成されません ・ポリシー内の各条件ごとに、一度に 1 つの問題が開かれます ・障害発生中に別のConditionで閾値が越えた場合には、

    新たなインシデントが生成されます New Relicのコンソール上で、何に対して対応が必要か特定します 外部ツールで1次対応ツールなどある場合 課題管理ツールに情報を残したい場合 ポリシーごとに 1 つ Conditionごとに1つ Alert
  6. 18 ①Window duration ②sliding window ③Streaming method ④Delay ⑤Gap filling

    strategy ⑥Evaluation delay ⑦Static / ⑩Anomaly ⑧ level ⑨Thresholds 条件設定 ⑪Consider the signal lost after Alert
  7. 21 Event Flow: データが頻繁に、かつ一貫して直線的に届く場合がお勧めです [イベントフローの使用例] ・エージェントからのデータ ・多くの CloudWatch Metric (CloudWatch

    Metric Streams使用) ③ストリーミング メソッド(Streaming method) 集計方法は、「Event Flow」、「Event Timer」、「Cadence」の3つがあります Event Timer: データが散発的に、矛盾して、不規則に届く場合がお勧めです [イベントタイマーの使用例] ・APIポーリングされているクラウドインテグレーションデータ ・エラーの数など、データが少ない、または頻度の低いデータを配信するクエリ Cadence: 古い設定方法のため省略します Alert
  8. 26 条件のしきい値を設定 ⑦Static 静的な閾値の超過有無で判定する ⑧重大度(Severity level) Warning/Critical ⑨閾値(Thresholds) for at

    least 閾値を超過する状態が続いたら インシデントがオープンする at least once データポイントのいずれかが閾値の 範囲外になるとインシデントがオープンする Alert
  9. 27 ⑩Anomaly 過去のデータに基づいて予測された正常範囲からの逸脱有無で判定 閾値の方向 Upper and lower Upper only Lower

    only 実際の値が予測値からどれだけ離れているかを許容 するアラート条件の感度を制御します。 閾値は、信号値が予測された値から離れている標準 偏差の数です。 過去 7 日間のデータの予測値と実際の値の間の標準 偏差を追跡します。 引用: https://docs.newrelic.com/jp/docs/alerts/create-alert/set-thresholds/anomaly-detection/ Alert
  10. 28 ⑪信号損失しきい値(Consider the signal lost after) NRQL型アラートのデータ受信が途絶えたことを検出したい場合、 データ受信の停止時間 (待機時間) を設定することで、シグナル消失として検出することができます。

    Close all current open incident 現在開いているすべてのインシデントを閉じる Close all current open incident 信号が失われたと判断されたときに、 新しいインシデントを開く 上記の両方のアクションを有効にする まずすべてのオープンインシデントが閉じられ、 次に信号損失に関する新しいインシデントが開かれます。 Alert
  11. 29 Do not open "lost signal" incident on expected termination

    信号が終了することが予想される場合は、新しいインシデントを開かないように選択できます。 これは、特定の時間に信号が失われることがわかっていて、その信号喪失に対して新しいインシ デントを開きたくない場合に便利です Alert
  12. 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 気をつけたいポイント
  13. 35 プロセス システム的やビジネス的に重要なホストとプロセスをフィルター適用する すべてのプロセスデータを送信すると、New Relicに送信されるデータの量が増える可能性があります 句 説明 enable_process_metrics プロセスのデータを取得するように設定 disable_zero_mem_process_filter

    プロセスのメモリ使用率が少ない場合でもデータを取得するように設定 include_matching_metrics 監視するプロセスを指定する process.executable 監視する プロセスの実行ファイル を記載する 気をつけたいポイント
  14. 36 ログ システム的やビジネス的に重要なホストとログをフィルター適用する すべてのログデータを送信すると、New Relicに送信されるデータの量が増える可能性があります 句 説明 name New Relic

    に転送するログの名前を定義をする。 Logs に格納される情報ではないのでファイル内で区別つきやすい任意の名前 disable_zero_mem _process_filter パスを含めた対象ログファイルを記載する。 例)/var/log/message /var/log/httpd/error/*_log ※ファイルパス内にワイルドカードを使用できます。 pattern 対象ログファイル内のレコードをフィルタリングするための正規表現を記載します。 ※指定しない場合、全てのログを転送するので、必要なものだけを転送するようにフィルタリン グをお願いします。 気をつけたいポイント
  15. 40 インシデント テーブルの色分け 赤: 制限を超えた 黄色: 制限の80~100% 緑: 80%未満 灰色:

    指定された期間に使用状況や インシデントが報告されていない制限 Administration -> Data Management -> Limit ダッシュボードを利用 現在のシステムリミットの消費状況や超過しているシステムリミットを確認することができます 気をつけたいポイント
  16. 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アカウント 気をつけたいポイント