Мониторинг Kubernetes

Настройка мониторинга: ожидаемый результат

Используйте существующие системы мониторинга и журналов вашей компании. Chart приложения публикует восемь Service endpoint /metrics. В local values доступны observability.metricsDiscovery и необязательный serviceMonitor при наличии CRD.

1. Сначала подтвердите готовность приложения через helm status/test и состояние Pod.
2. Задайте observability.metricsDiscovery.enabled=true в work/app-values.yaml; ServiceMonitor включайте только с установленной customer-managed CRD.
3. Проверьте discovery командой ниже и сетевой доступ Prometheus к восьми endpoint.

kubectl get service \
  --namespace <namespace> \
  --selector massaccess.net/metrics=true \
  --output custom-columns=NAME:.metadata.name,PORTS:.spec.ports[*].port

1. Разрешите Prometheus доступ к endpoint

При chart-managed NetworkPolicy Prometheus из другого namespace требует отдельного разрешения. Выберите в local values управление сетью инфраструктурой компании и подготовьте полный набор правил. Пример ниже открывает только metrics ingress от выбранного collector; подставьте namespace и устойчивую метку Pod.

• Замените <namespace> и <monitoring-namespace> точными именами несистемных namespace
• Замените <collector-label-key> и <collector-label-value> устойчивой меткой только Pod вашего Prometheus; не разрешайте весь monitoring namespace
• Не применяйте пример как единственную политику: инфраструктура должна отдельно сохранить необходимые внутренние, edge, DNS и egress соединения MassAccess
• Перед применением проверьте manifest в инфраструктурном репозитории; после применения подтвердите разрешённый scrape, рабочие внутренние потоки и запрещённое соединение от постороннего Pod

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-massaccess-metrics
  namespace: <namespace>
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: massaccess
      app.kubernetes.io/instance: massaccess
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: <monitoring-namespace>
          podSelector:
            matchLabels:
              <collector-label-key>: <collector-label-value>
      ports:
        - {protocol: TCP, port: 8001}
        - {protocol: TCP, port: 8002}
        - {protocol: TCP, port: 8003}
        - {protocol: TCP, port: 8004}
        - {protocol: TCP, port: 8005}
        - {protocol: TCP, port: 8006}
        - {protocol: TCP, port: 10002}

2. Добавьте job в существующий Prometheus

Добавьте следующий scrape_config в управляемую конфигурацию Prometheus и замените <namespace>. Job выбирает только Service с massaccess.net/metrics=true и только порты health или admin, поэтому frontend и публичный порт gateway не попадут в сбор. ServiceAccount Prometheus должен иметь get/list/watch для Service в целевом namespace. Проверьте конфигурацию штатным валидатором вашей поставки Prometheus и выполните контролируемый reload.

scrape_configs:
  - job_name: massaccess
    metrics_path: /metrics
    kubernetes_sd_configs:
      - role: service
        namespaces:
          names: [<namespace>]
    relabel_configs:
      - action: keep
        source_labels: [__meta_kubernetes_service_label_massaccess_net_metrics]
        regex: "true"
      - action: keep
        source_labels: [__meta_kubernetes_service_port_name]
        regex: "health|admin"
      - source_labels: [__meta_kubernetes_namespace]
        target_label: namespace
      - source_labels: [__meta_kubernetes_service_name]
        target_label: service
      - source_labels:
          [__meta_kubernetes_service_label_app_kubernetes_io_component]
        target_label: component

Endpoint метрик приложения

Эти восемь целей должны появиться в Prometheus. Других endpoint приложение не обещает.

3. Проверьте результат в Prometheus

Выполните три PromQL-запроса по очереди. Ожидаемые значения: 8 обнаруженных целей, минимальный up равен 1 и 8 уникальных component. Любое другое значение означает незавершённую настройку.

1. Откройте страницу Targets: у job massaccess должно быть восемь целей без duplicate targets и scrape errors
2. Проверьте, что метки namespace, service и component заполнены и не содержат идентификаторов компании, лицензии или клиента
3. При DOWN сначала проверьте DNS Service, выбранный порт, NetworkPolicy и ответ /metrics; не увеличивайте scrape_timeout до установления причины

count(up{job="massaccess", namespace="<namespace>"})
min(up{job="massaccess", namespace="<namespace>"})
count(count by (component) (up{job="massaccess", namespace="<namespace>"}))

4. Подключите журналы и Kubernetes Events

Настройте существующий DaemonSet/агент заказчика на stdout/stderr контейнеров с app.kubernetes.io/part-of=massaccess. Отдельный агент в package не поставляется.

• Добавляйте к записи namespace, pod, container и app.kubernetes.io/component; используйте event_id, correlation_id и parent_event_id только там, где сервис их фактически пишет
• Не используйте лицензионные ключи, идентификаторы компании или заказчика, токены, DSN, значения Secret и содержимое webhook как поля или метки
• Для Kubernetes Events сохраняйте type, reason, объект и ограниченную категорию; свободный message может содержать инфраструктурные сведения
• Установите срок хранения, ограничение доступа и лимит объёма по политике заказчика; проверьте поиск записи по component и correlation_id на тестовом запросе
• Собирайте Kubernetes Events как отдельный поток и настройте уведомление о FailedScheduling, FailedMount, ImagePullBackOff и OOMKilled

5. Подключите правила и маршрутизацию оповещений

Подготовьте собственный файл правил и проверьте его promtool перед загрузкой в rule loader. Используйте только доступные источники метрик, настройте получателей, дедупликацию и тестовое оповещение. Готового alerts.yaml в материалах нет.

• MassAccessKubernetesWorkloadUnavailable, RestartLoop и JobFailed требуют метрик kube-state-metrics с Kubernetes labels
• MassAccessKubernetesPersistentVolumePressure требует kubelet_volume_stats; подтвердите, что CSI/kubelet их публикует
• MassAccessExternalDependencyProbeFailed требует отдельной аутентифицированной проверки заказчика с probe_success, massaccess_signal=external-dependency и bounded dependency label
• LicenseHeartbeatLost, LicenseInactive и MeteringFailure используют метрики приложения из настроенного job massaccess

promtool check rules /secure/path/customer-massaccess-alerts.yaml

6. Критерии готовности

• Prometheus показывает восемь целей UP не менее двух интервалов подряд; метки component/namespace/service корректны.
• В разрешённом тестовом окне подтвердите срабатывание оповещения и восстановление; проверьте разрешённый scrape и запрещённый доступ постороннего Pod.
• Журналы доступны по компоненту, имеют согласованную retention и не раскрывают токены, DSN, Secret или содержимое сообщений.
• Helm test и прикладные проверки проходят; диагностические записи перед отправкой просматриваются и редактируются оператором.

helm --kube-context "$MA_CONTEXT" status massaccess -n "$MA_NAMESPACE"
helm --kube-context "$MA_CONTEXT" test massaccess -n "$MA_NAMESPACE" --logs
kubectl --context "$MA_CONTEXT" -n "$MA_NAMESPACE" get deployment,statefulset,pod,service,job,pvc