Мониторинг Kubernetes

Метрики, журналы, события, оповещения и граница ответственности инфраструктуры заказчика.

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

После настройки Prometheus должен видеть ровно восемь целей MassAccess со статусом UP, журналы Pod должны попадать в хранилище заказчика, а правила должны загружаться только при наличии всех исходных метрик.

1. Убедитесь, что установка завершена без FAIL, а healthcheck возвращает код 0
2. Сверьте текущий kube-context и namespace, затем выполните команду ниже: она должна вернуть archiver, auditor, bot-max, bot-telegram, core, gateway, webhook и worker
3. Проверьте configuration/installation-config.yaml: текущий генератор пакета фиксирует metricsDiscovery.enabled=true и serviceMonitor.enabled=false
4. Выберите сетевой сценарий до скачивания пакета: для Prometheus в другом namespace используйте в панели режим NetworkPolicy «управляет инфраструктура» и подготовьте точное разрешение ingress

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 вход разрешён только Pod MassAccess того же namespace; Prometheus из отдельного monitoring namespace не сможет собирать метрики. Для такого размещения выберите в панели владельца NetworkPolicy «инфраструктура», скачайте пакет заново и добавьте это разрешение поверх полного набора customer-owned политик после подстановки трёх placeholder.

• Замените <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. Подключите правила и маршрутизацию оповещений

Извлеките alerts.yaml из chart скачанного пакета, проверьте его promtool и загрузите в ваш rule loader. Не загружайте правило, пока отсутствует его источник данных. Настройте получателя, дедупликацию, окно повторов и ссылку на внутренний runbook в системе заказчика.

• 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

tar -xOf release/charts/massaccess-<chart-version>.tgz \
  massaccess/files/observability/alerts.yaml \
  > /secure/path/massaccess-alerts.yaml

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

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

• Prometheus показывает 8/8 целей UP не менее двух интервалов сбора подряд
• Контрольная остановка одного тестового Pod отражается в метриках, журнале и разрешённом тестовом оповещении; после восстановления цель снова UP
• Посторонний Pod не может читать /metrics, а Prometheus может
• В журнале и метках нет Secret, токенов, DSN, license/company/customer identifiers и содержимого сообщений
• healthcheck и status успешны; локальный support-bundle создан с правами 0600, проверен оператором и никуда не отправлен автоматически

./bin/healthcheck.sh --namespace <namespace>
./bin/massaccess-k8s status --namespace <namespace>
./bin/massaccess-k8s support-bundle --namespace <namespace>