В данной реализации отсутствуют какие-либо метрики связанные с работой сервера ( latency, errors, requests count ), поэтому остаётся только снимать метрики с самого пода, для этого можно использовать cAdvisor, так как имеется helthchek, альтернативный вариант - использовать blackbox exporter для проверки доступности этого эндпоинта.
Для реализации вышеперечисленного, самым простым вариантом является установка prometheus-stack или victoria-metrics-stack helm-чарта
В случае с prometheus, в namespace приложения необходимо будет создать CRD serviceMonitor, который будет "смотреть" на Service связанный с деплойментом приложения. Если использовать VictoriaMetrics, вместо serviceMonitor надо будет создать CRD vmServiceScrape, который будет отсылать собранные метрики на vmAgent.
В обоих случаях метрики будут хранится в TSDB ( базы разные ), в которую будет обращаться Grafana, используем её для визуализации метрик.
Для алертинга будем использовать alertmanager, который на основе данных из TSDB будет формировать алерты ( для VictoriaMetrics ещё нужен будет vmAlert ). Откажемся от Grafana Alerts, так как с ними сложнее работать при as code подходе, да и алерты alertmanager можно отразить в Grafana.
Ради удобства будем оставаться в рамках одной платформы, поэтому для хранения и работы c логами будем использовать Loki. Самый простой вариант - использовать loki-stack helm-чарт, предварительн отключив компоненты, которые уже были установлены для мониторинга.
В таком случае мы получаем Promtail в качестве сборщика логов ( альтернативы: Fluent Bit, Logstash и другие)
Сами логи хранятся в Loki ( для старых логов можно подключить S3 хранилище )
Визуализация и поиск идёт в Grafana.
Алертинг на основе сырых логов настраивать не будем, дабы избежать лишнего шума, лучше в будущем поднимем и настроим Sentry.
В качестве альтернативы для Loki можно использовать ElastickSearch и Kibana
Как единую платформу для всего можно использовать SigNoz
Для улучшения Observability, реализовать cбор трэйсов yf на базе OpenTelemetry