Перейти к основному содержимому

Обслуживание установленных сервисов

Ниже представлены рекомендации по обслуживанию 2ГИС Про внутри установленного комплекса On-Premise.

Резервное копирование инфраструктурных баз данных​

Резервное копирование рекомендовано для баз PostgreSQL сервиса 2ГИС Про, так как они содержат уникальные данные.

Сбор логов​

Ниже представлены рекомендации по сбору и отправке логов сервисов внутри установленного комплекса On-Premise.

Формат логов​

Сервисы комплекса On-Premise в Kubernetes выводят логи в stdout в формате JSON или Plaintext. В некоторых случаях используется комбинация обоих форматов, что позволяет гибко адаптировать вывод логов в зависимости от нужд системы.

Инструменты для сбора логов​

Для сбора и отправки логов рекомендуется установить следующие агенты:

Хранение и анализ логов​

Для централизованного сбора, хранения и анализа логов рекомендуется использовать следующие инструменты:

  • Elasticsearch + Kibana (ELK-стек). Подходит для сложных запросов и долгосрочного хранения логов и предоставляет следующие возможности:

    • полнотекстовый поиск и аналитика логов;
    • гибкие дашборды и визуализации в Kibana.

    Принцип работы: агенты (Fluent Bit, Filebeat) собирают логи с узлов и отправляют их в Elasticsearch. Затем данные индексируются и становятся доступны в Kibana через индекс-паттерны.

  • Grafana Loki. Оптимизирован для работы с логами Kubernetes и предоставляет следующие возможности:

    • экономичное хранение логов (использует объектные хранилища, например MinIO);
    • интеграция с Grafana для совместного анализа логов и метрик.

    Принцип работы: агенты (Fluent Bit) отправляют логи в Loki с метками (labels) для быстрого поиска. Затем логи становятся доступны в Grafana через запросы на языке LogQL.

Мониторинг состояния сервисов​

Сервисы программного комплекса On-Premise предоставляют метрики в формате Prometheus. Этот формат позволяет обеспечить безопасность передачи данных (по HTTPS или защищенным endpoint-ам), а также легко интегрируется с большинством современных систем мониторинга.

Ниже представлены рекомендации по настройке мониторинга сервисов.

Методы мониторинга​

Рекомендуется использовать два основных метода мониторинга:

  • Для API и сервисов в Kubernetes — метод RED:

    • Rate (Частота запросов),
    • Errors (Ошибки),
    • Duration (Время выполнения).

  • Для баз данных и хранилищ на виртуальных машинах — метод USE:

    • Utilization (Использование ресурсов),
    • Saturation (Насыщение),
    • Errors (Ошибки).

Инструменты​

Для полного цикла мониторинга (сбор, хранение, визуализация и отправка уведомлений) рекомендуется использовать следующие инструменты:

  • Сбор и хранение метрик: Prometheus — обеспечивает гибкость запросов (язык PromQL) и надежное хранение данных.
  • Визуализация: Grafana — предоставляет дашборды с возможностью настройки под конкретные запросы.
  • Отправка уведомлений (алертинг): AlertManager — позволяет отправлять уведомления по e-mail, в Slack, Telegram и другие каналы при превышении пороговых значений.

Сбор метрик​

Рекомендуется собирать метрики непосредственно с подов сервиса. Если в вашем кластере Kubernetes используется Prometheus с Kubernetes SD (Service Discovery), добавьте следующие аннотации в параметр podAnnotations в Helm-чарты сервисов:

  • prometheus.io/scrape: "true" — включить сбор метрик с данного пода.
  • prometheus.io/path: "/metrics" — путь, по которому доступны метрики.
  • prometheus.io/port: "80" — порт пода.

Рекомендуется использовать следующие инструменты для сбора метрик:

  • PostgreSQL: postgres_exporter — сбор статистики запросов, репликаций и блокировок.
  • Виртуальные машины: node_exporter — метрики CPU, памяти, дисков и сети.
  • MinIO: см. документацию MinIO — метрики хранилища, объектов.
  • Elasticsearch: elasticsearch_exporter — метрики кластера, индексов и узлов.
  • Apache Kafka: kafka_exporter — метрики кластера, брокеров и топиков.

Метрики API-сервисов в Kubernetes​

При мониторинге API-сервисов в Kubernetes важно учитывать следующие ключевые показатели, которые помогут оценить производительность и стабильность системы и обнаружить потенциальные проблемы:

  • Сетевые показатели:

    • RPS (Requests Per Second) — количество запросов в секунду, проходящих через Ingress или Service. Этот показатель помогает отслеживать нагрузку на сервис. Важно снимать метрики именно с Ingress-controller, так как он показывает полный входящий трафик.

    • Latency — задержки обработки запроса:

      • p50 — медиана.
      • p90 — 90-й перцентиль.
      • p99 — 99-й перцентиль. Важно отслеживать рост p99, так как это показатель наиболее критичных задержек.

    • HTTP-коды ответов:

      • 2xx — успешные запросы.
      • 4xx — ошибки клиента. Важно отслеживать рост ошибок 429 (Too Many Requests).
      • 5xx — ошибки сервера. Количество этих ошибок должно быть минимальным.

  • Ресурсы контейнеров (CPU и RAM):

    • CPU Usage (%) — фактическое потребление ресурсов CPU контейнером.
    • CPU Throttling (троттлинг) — если контейнер превышает лимиты CPU (limits.cpu), Kubernetes ограничивает его выполнение.
    • Memory Usage (RAM, MB/GB) — текущее использование памяти.
    • OOMKills (Out of Memory Kills) — если контейнер превышает лимит памяти (limits.memory), Kubernetes может завершить его выполнение.

  • Ресурсы узлов:

    • Общая загрузка CPU и памяти на узле — если узел перегружен, поды могут испытывать проблемы.
    • Disk utilization — использование дискового пространства и производительности дисков (IOPS, скорость чтения/записи).

  • Сетевые ошибки и ошибки соединений:

    • Connection Errors — ошибки соединений между сервисами (например, Connection reset, Timeout).
    • DNS Latency & Failures — задержки и ошибки в DNS-запросах (CoreDNS).