by shigemk2

当面は技術的なことしか書かない

L4 LB vs L7 LB

web
  • レイヤー4負荷分散
    • トランスポート
    • メッセージの実際の内容を可視化しない
    • アプリケーションポートやプロトコルなどのネットワーク情報に基づいてトラフィックを管理
    • 単純なパケットレベルの負荷分散に有効
    • メッセージの検査や復号を行わないため、迅速かつ効率的で安全な転送が可能
    • デメリット レイヤー4の負荷分散ではコンテンツに基づく判断ができない
      • メディアタイプやローカライズのルールなど、ラウンドロビンルーティングのような単純なアルゴリズム以上の条件でトラフィックをルーティングできない
  • レイヤー7負荷分散
    • アプリケーション
    • HTTPやSMTPなどのプロトコルを使用して、各メッセージの実際のコンテンツに基づいて決定
    • トラフィックの中身をチェックしないまま転送することはしない
    • ネットワークトラフィックを終端し、必要に応じて復号を行い、メッセージを検査し、コンテンツベースのルーティングを決定し、適切な上位サーバーに新しいTCP接続を開始し、リクエストを送信する
    • サーバーの永続性（スティッキーセッション）を提供

www.a10networks.co.jp

cert-manager 1.18 Certificate.Spec.PrivateKey.RotationPolicy

k8s

Why? Because the old default was unintuitive and insecure. For example, if a private key is exposed, users may (reasonably) assume that re-issuing a certificate (e.g. using cmctl renew) will generate a new private key, but it won't unless the user has explicitly set rotationPolicy: Always on the Certificate resource.

とのことなので、Certificate.Spec.PrivateKey.RotationPolicyはデフォルトAlwaysになる

cert-manager.io

new_host_delay renotify_interval メモ

Datadog

new_host_delay

Deprecated（非推奨）: 代わりに new_group_delay を使用してください。

新しいホストが追加された際に、ホストの起動とアプリケーションの完全な起動を待ってからモニター評価を開始するまでの遅延時間（秒）。

項目 内容
型 Number
単位 秒
デフォルト 300（5分）
必須 No（Optional）
非負整数 Yes
  • simple monitor（グループ化なし）では無視される
  • ホストでグループ化された multi-alert monitor でのみ有効
  • 新しいホストが検出されてから指定秒数が経過するまで、そのホストに対するモニター評価がスキップされる

new_group_delay との関係

  • new_group_delay が非ゼロ値で設定されている場合、new_host_delay は上書き（override）される
  • new_host_delay を使う唯一の正当なケースは、デフォルトの300秒を0に上書きしたい場合のみ
  • それ以外はすべて new_group_delay を使うべき
resource "datadog_monitor" "example" {
  name  = "CPU Monitor"
  type  = "metric alert"
  query = "avg(last_5m):avg:system.cpu.user{*} by {host} > 90"

  message = "CPU usage is high on {{host.name}}"

  # 非推奨だが、デフォルト300秒を無効化したい場合のみ使用
  new_host_delay = 0

  # 推奨: こちらを使う
  new_group_delay = 60
}
  • Datadog はクラウドメトリクスに対して15分の遅延を推奨（バックフィルされるため）
  • 除算式（division formula）を使うモニターでは60秒の遅延が推奨
  • コンテナ環境では、新コンテナ作成時の高リソース使用による誤検知を防ぐために設定が有効

renotify_interval

モニターが解決されていない（未リカバリ）状態のまま、最後の通知から何分後に再通知を送るかを指定する。

項目 内容
型 Number
単位 分
デフォルト 0（再通知なし）
必須 No（Optional）
  • モニターが Alert / Warning / No Data 状態のまま解決されない場合に、指定した間隔で再通知を送信する
  • 解決済み（OK）の場合は再通知されない
  • 0 または未設定の場合、再通知は行われない（最初の1回のみ通知）
パラメータ 説明
renotify_interval 再通知の間隔（分）
renotify_occurrences 再通知の最大回数。renotify_interval が設定されている場合のみ有効。null の場合は無制限に再通知
renotify_statuses 再通知を送信するステータスの種類。renotify_interval が設定されている場合のデフォルトは ["alert", "no_data"]
escalation_message 再通知時に含める追加メッセージ。@username 記法をサポート 
resource "datadog_monitor" "example" {
  name  = "High Error Rate"
  type  = "metric alert"
  query = "avg(last_5m):sum:http.errors{*} > 100"

  message            = "Error rate is too high! @slack-alerts"
  escalation_message = "Error rate is STILL high! Escalating. @pagerduty"

  # 60分ごとに再通知
  renotify_interval = 60

  # 最大5回まで再通知
  renotify_occurrences = 5

  # Alert と No Data の状態で再通知
  renotify_statuses = ["alert", "no_data"]
}
  • renotify_interval を設定しないと、アラートが最初の1回しか通知されず、未対応のまま見逃される可能性がある
  • 適切な間隔（例: 60分）を設定し、escalation_message と組み合わせてエスカレーションフローを構築するのが一般的
  • renotify_occurrences を設定しない場合、解決されるまで無制限に再通知が送られるため、通知疲れに注意

まとめ比較表 | パラメータ | 用途 | 単位 | デフォルト | 非推奨 | |---|---|---|---|---| | new_host_delay | 新ホスト追加時の評価遅延 | 秒 | 300 | Yes（new_group_delay を使用） | | new_group_delay | 新グループ追加時の評価遅延 | 秒 | 60 | No | | renotify_interval | 未解決時の再通知間隔 | 分 | 0（再通知なし） | No | | renotify_occurrences | 再通知の最大回数 | 回 | null（無制限） | No | | renotify_statuses | 再通知対象のステータス | - | alert, no_data | No |

公式ドキュメント

Return All Suggested Indexes

MongoDB

curlでPerformance Advisorのサジェストインデックスを返すことができる

Returns the indexes that the Performance Advisor suggests. The Performance Advisor monitors queries that MongoDB considers slow and suggests new indexes to improve query performance. To use this resource, the requesting Service Account or API Key must have the Project Read Only role.

https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-listgroupclusterperformanceadvisorsuggestedindexeswww.mongodb.com

git add -u/-A

Git

-u インデックスにすでにエントリがあるファイル（＝追跡済みファイル）のみを対象に、作業ツリーに合わせてインデックスを更新 -A 作業ツリーにファイルがある場合だけでなく、インデックスにすでにエントリがある場合も含めてインデックスを更新

# 作業ツリーの状態:
#   modified:  existing.txt  （変更）
#   deleted:   old.txt       （削除）
#   new:       newfile.txt   （新規・未追跡）

git add -u
# → existing.txt の変更と old.txt の削除がステージされる
# → newfile.txt は無視される

git add -A
# → existing.txt の変更、old.txt の削除、newfile.txt の追加、すべてステージされる