alertmanager:
  enabled: true
  ingress:
    enabled: true
    ingressClassName: nginx
    annotations:
      nginx.ingress.kubernetes.io/rewrite-target: /$2
      nginx.ingress.kubernetes.io/use-regex: "true"
    paths:
    - "/internal/alerts/self-monitoring(/|$)(.*)"
  serviceAccount:
    create: true
  config:
    global:
      resolve_timeout: 5m
    inhibit_rules:
      - source_matchers:
          - 'severity = critical'
        target_matchers:
          - 'severity =~ warning|major|info'
        equal:
          - 'namespace'
          - 'alertname'
      - source_matchers:
          - 'severity = major'
        target_matchers:
          - 'severity = warning|info'
        equal:
          - 'namespace'
          - 'alertname'
      - source_matchers:
          - 'alertname = VMClusterTooHighQueryLoad'
        target_matchers:
          - 'alertname =~ AlertingRulesError|RecordingRulesError'
        # avoids alert Storm from vmalerts when vmcluster is on high load
        equal:
          - 'o11y_k8s_id'
    route:
      group_by: ['...']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 12h
      receiver: 'null'
      routes:
      - receiver: 'null'
        matchers:
          - alertname =~ "InfoInhibitor"
      - receiver: dms
        group_wait: 10s
        group_interval: 30s
        repeat_interval: 1m
        matchers:
          - alertname =~ "Watchdog"
      - receiver: dms
        group_wait: 10s
        group_interval: 30s
        repeat_interval: 1m
        matchers:
        - alertname =~ "AlertmanagerClusterFailedToSendAlerts"
        - integration = "webhook" #jiralert
      - receiver: auto-scaler-api-prod
        continue: true
        matchers:
          - alertname =~ "PrometheusCPUThrottlingHigh|O11yPodMemoryFillingUp|KubePersistentVolumeFillingUp|PodOOMKilled"
      - receiver: default/observability-alertmanager-config/jiralert-prod-warning
        continue: false
        matchers:
          - 'severity =~ warning|info'
      - receiver: default/observability-alertmanager-config/jiralert-prod-major
        continue: false
        matchers:
          - 'severity =~ major'
      - receiver: default/observability-alertmanager-config/jiralert-prod
        continue: false
    receivers:
    - name: 'null'
    - name: 'default/observability-alertmanager-config/jiralert-prod'
      webhook_configs:
      - url: 'https://jiralert-eks-prod.pingcap.net/alert'
        send_resolved: true
    - name: 'default/observability-alertmanager-config/jiralert-prod-warning'
      webhook_configs:
      - url: 'https://jiralert-eks-prod.pingcap.net/alert'
        send_resolved: true
    - name: 'default/observability-alertmanager-config/jiralert-prod-major'
      webhook_configs:
      - url: 'https://jiralert-eks-prod.pingcap.net/alert'
        send_resolved: true
    - name: 'auto-scaler-api-prod'
      webhook_configs:
        - url: 'https://www.gs.us-west-2.aws.observability.tidbcloud.com/api/v1/ops/events/alerts'
          send_resolved: true
    - name: dms
      webhook_configs:
      - url: http://localhost:8088/alert
  alertmanagerSpec:
    nodeSelector:
      node_type: worker
    volumes:
    - name: gke-token
      projected:
        sources:
        - serviceAccountToken:
            audience: observability.pingcap.cloud
            expirationSeconds: 7200
            path: gke-token
    containers:
    - name: deadmanswatch
      image: us-west1-docker.pkg.dev/gcp-autonomous-prod/observability-regional-server/deadmanswatch:sha-891e26c
      imagePullPolicy: IfNotPresent
      args:
        - watch
        - --port=8088
        - --listen-address=0.0.0.0
        - --region=us-west-2
        - --alert-source-label=o11y_k8s_id
        - --metric-dimensions="scope=self-monitoring"
        - --metric-dimensions="environment=prod"
      ports:
        - name: http
          containerPort: 8088
          protocol: TCP
      env:
      - name: AWS_REGION
        value: us-west-2
      - name: AWS_ROLE_ARN
        value: arn:aws:iam::557537366020:role/autonomous-o11y-self-monitoring-gke-prod
      - name: AWS_STS_REGIONAL_ENDPOINTS
        value: regional
      - name: AWS_WEB_IDENTITY_TOKEN_FILE
        value: /var/run/secrets/token/gke-token
      volumeMounts:
      - mountPath: /var/run/secrets/token
        name: gke-token
      livenessProbe:
        httpGet:
          path: /ping
          port: http
      resources:
        requests:
          cpu: 100m
          memory: 50Mi
        limits:
          cpu: 100m
          memory: 50Mi
grafana:
  enabled: false

prometheusOperator:
  enabled: true
  tls:
    enabled: false
  admissionWebhooks:
    enabled: false
  nodeSelector:
    node_type: worker

kubeControllerManager:
  enabled: false

kubeScheduler:
  enabled: false

coreDns:
  enabled: false

kubeDns:
  enabled: true

kubeProxy:
  enabled: false

kubeApiServer:
  enabled: true

defaultRules:
  rules:
   kubeProxy: false
  disabled:
    KubeAggregatedAPIDown: true
    KubeAggregatedAPIErrors: true
    KubeCPUOvercommit: true #we will overshell so disable this alert
    KubeMemoryOvercommit: true #we have Autoscaler so disable this alert
    CPUThrottlingHigh: true #cfs limits are not accurate
  appNamespacesTarget: "default|cluster-backup|drhouse|external-secrets|ingress-.*|kube-system|monitoring-system|self-montoring|observability|.*devtier.*|.*tidbcloud.*"

prometheus:
  enabled: true
  prometheusSpec:
    nodeSelector:
      node_type: worker
    image:
      tag: v2.55.1
    externalLabels:
      o11y_k8s_id: o11y-prod-regional-asia-southeast1
      cloudProvider: gcp
      component: observability-regional-server
    externalUrl: https://www.ds.asia-southeast1.gcp.observability.tidbcloud.com/prom/self-monitoring/
    retention: 1y
    ## EXPERIMENTAL: Number of shards to distribute targets onto.
    ## Number of replicas multiplied by shards is the total number of Pods created.
    ## Note that scaling down shards will not reshard data onto remaining instances, it must be manually moved.
    ## Increasing shards will not reshard data either but it will continue to be available from the same instances.
    ## To query globally use Thanos sidecar and Thanos querier or remote write data to a central location.
    ## Sharding is done on the content of the `__address__` target meta-label.
    ##
    shards: 1
    resources:
      limits:
        cpu: 1500m
        memory: 8Gi
      requests:
        cpu: 500m
        memory: 4Gi

    ## Prometheus StorageSpec for persistent data
    ## ref: https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/user-guides/storage.md
    ##
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: prometheus.ssd
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 100Gi
    serviceMonitorSelectorNilUsesHelmValues: false
    ## AdditionalScrapeConfigs allows specifying additional Prometheus scrape configurations. Scrape configurations
    ## are appended to the configurations generated by the Prometheus Operator. Job configurations must have the form
    ## as specified in the official Prometheus documentation:
    ## https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config. As scrape configs are
    ## appended, the user is responsible to make sure it is valid. Note that using this feature may expose the possibility
    ## to break upgrades of Prometheus. It is advised to review Prometheus release notes to ensure that no incompatible
    ## scrape configs are going to break Prometheus after the upgrade.
    ## AdditionalScrapeConfigs can be defined as a list or as a templated string.
    ##
    ## The scrape configuration example below will find master nodes, provided they have the name .*mst.*, relabel the
    ## port to 2379 and allow etcd scraping provided it is running on all Kubernetes master nodes
    ##
    additionalScrapeConfigs: []
    # - job_name: kube-etcd
    #   kubernetes_sd_configs:
    #     - role: node
    #   scheme: https
    #   tls_config:
    #     ca_file:   /etc/prometheus/secrets/etcd-client-cert/etcd-ca
    #     cert_file: /etc/prometheus/secrets/etcd-client-cert/etcd-client
    #     key_file:  /etc/prometheus/secrets/etcd-client-cert/etcd-client-key
    #   relabel_configs:
    #   - action: labelmap
    #     regex: __meta_kubernetes_node_label_(.+)
    #   - source_labels: [__address__]
    #     action: replace
    #     targetLabel: __address__
    #     regex: ([^:;]+):(\d+)
    #     replacement: ${1}:2379
    #   - source_labels: [__meta_kubernetes_node_name]
    #     action: keep
    #     regex: .*mst.*
    #   - source_labels: [__meta_kubernetes_node_name]
    #     action: replace
    #     targetLabel: node
    #     regex: (.*)
    #     replacement: ${1}
    #   metric_relabel_configs:
    #   - regex: (kubernetes_io_hostname|failure_domain_beta_kubernetes_io_region|beta_kubernetes_io_os|beta_kubernetes_io_arch|beta_kubernetes_io_instance_type|failure_domain_beta_kubernetes_io_zone)
    #     action: labeldrop
    #
    ## If scrape config contains a repetitive section, you may want to use a template.
    ## In the following example, you can see how to define `gce_sd_configs` for multiple zones
    # additionalScrapeConfigs: |
    #  - job_name: "node-exporter"
    #    gce_sd_configs:
    #    {{range $zone := .Values.gcp_zones}}
    #    - project: "project1"
    #      zone: "{{$zone}}"
    #      port: 9100
    #    {{end}}
    #    relabel_configs:
    #    ...


    ## If additional scrape configurations are already deployed in a single secret file you can use this section.
    ## Expected values are the secret name and key
    ## Cannot be used with additionalScrapeConfigs
    additionalScrapeConfigsSecret: {}
      # enabled: false
      # name:
      # key:


    ## AdditionalAlertManagerConfigs allows for manual configuration of alertmanager jobs in the form as specified
    ## in the official Prometheus documentation https://prometheus.io/docs/prometheus/latest/configuration/configuration/#<alertmanager_config>.
    ## AlertManager configurations specified are appended to the configurations generated by the Prometheus Operator.
    ## As AlertManager configs are appended, the user is responsible to make sure it is valid. Note that using this
    ## feature may expose the possibility to break upgrades of Prometheus. It is advised to review Prometheus release
    ## notes to ensure that no incompatible AlertManager configs are going to break Prometheus after the upgrade.
    ##
    additionalAlertManagerConfigs: []
    # - consul_sd_configs:
    #   - server: consul.dev.test:8500
    #     scheme: http
    #     datacenter: dev
    #     tag_separator: ','
    #     services:
    #       - metrics-prometheus-alertmanager

    ## If additional alertmanager configurations are already deployed in a single secret, or you want to manage
    ## them separately from the helm deployment, you can use this section.
    ## Expected values are the secret name and key
    ## Cannot be used with additionalAlertManagerConfigs
    additionalAlertManagerConfigsSecret: {}
      # name:
      # key:

    ## AdditionalAlertRelabelConfigs allows specifying Prometheus alert relabel configurations. Alert relabel configurations specified are appended
    ## to the configurations generated by the Prometheus Operator. Alert relabel configurations specified must have the form as specified in the
    ## official Prometheus documentation: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#alert_relabel_configs.
    ## As alert relabel configs are appended, the user is responsible to make sure it is valid. Note that using this feature may expose the
    ## possibility to break upgrades of Prometheus. It is advised to review Prometheus release notes to ensure that no incompatible alert relabel
    ## configs are going to break Prometheus after the upgrade.
    ##
    additionalAlertRelabelConfigs: []
    # - separator: ;
    #   regex: prometheus_replica
    #   replacement: $1
    #   action: labeldrop

    ## If additional alert relabel configurations are already deployed in a single secret, or you want to manage
    ## them separately from the helm deployment, you can use this section.
    ## Expected values are the secret name and key
    ## Cannot be used with additionalAlertRelabelConfigs
    additionalAlertRelabelConfigsSecret: {}
      # name:
      # key:

kube-state-metrics:
  metricLabelsAllowlist:
    - nodes=[*]