Сегодня продолжил трогать экосистему Prometheus.
Наконец дошли руки до системы сбора логов - Loki. Вообще, при развертывании "по фен-шую" между сервисами, генерирующими логи и Loki должна использоваться прокладка - Promtail. Promtail осуществляет сбор, анализ, агрегацию и ротацию логов, после чего укладывает их в Loki. Визуализация осуществляется, как и в случае с Prometheus с помощью Graphana.
Но я немного схалтурил и настроил прямую запись из приложения в Loki. Заводится все с ходу, на дефолтных официальных докер образах.
Для централизованной системы анализа логов важно построение поисковых индексов по логам, чтобы из безумного потока отбирать только важное. В ELK стеке индексы конфигурируются из UI при рисовании дашбордов.
В Loki в моей конфигурации об индексировании приходится думать на этапе разработки приложения: надо заложить в сообщения логов метки (например текст {errorType42}), и сообщить отправителю, что их надо индексировать.
А затем, в окне просмотра логов в любой момент можно быстро найти все errorType42 за определенный период времени. И с этой выдачей уже работать другими встроенными инструментами.
#prometheus
Наконец дошли руки до системы сбора логов - Loki. Вообще, при развертывании "по фен-шую" между сервисами, генерирующими логи и Loki должна использоваться прокладка - Promtail. Promtail осуществляет сбор, анализ, агрегацию и ротацию логов, после чего укладывает их в Loki. Визуализация осуществляется, как и в случае с Prometheus с помощью Graphana.
Но я немного схалтурил и настроил прямую запись из приложения в Loki. Заводится все с ходу, на дефолтных официальных докер образах.
Для централизованной системы анализа логов важно построение поисковых индексов по логам, чтобы из безумного потока отбирать только важное. В ELK стеке индексы конфигурируются из UI при рисовании дашбордов.
В Loki в моей конфигурации об индексировании приходится думать на этапе разработки приложения: надо заложить в сообщения логов метки (например текст {errorType42}), и сообщить отправителю, что их надо индексировать.
А затем, в окне просмотра логов в любой момент можно быстро найти все errorType42 за определенный период времени. И с этой выдачей уже работать другими встроенными инструментами.
#prometheus
Небольшая заметка на полях о прометеусе. Оставлю тут, чтобы не утратить обретенные знания.
Раньше я многократно пользовался Прометеусом для отображения метрик приложения. Рантайм шарпа по дефолту экспортирует достаточно информативный набор метрик, в т.ч. потребляемая приложением память, в т.ч. с разбивкой по поколениям сборки мусора. Добавлять кастомные метрики, позволяющие мониторить различные аспекты разрабатываемого приложения - более менее стандартная практика. И тут я задался вопросом, а как разделить метрики на группы (смапленные на разные пути: /metrics, /metrics/critical и т.д.), чтобы можно было опрашивать более критичные метрики с большей периодичностью.
Промучавшись некоторое время, я пришёл к следующему решению:
1. Основную группу метрик маппить стандартным способом, дефолтным .MapMetrics() в Program.cs
2. Для своих метрик создать свой CollectorRegistry, дальше методом Metrics.WithCustomRegistry создать экзмепляр фабрики MetricFactory, который заинжектить в приложение.
3. В местах, где требуются нестандартные метрики забирать MetricFactory и с его помощью создавать экземпляры метрик в нужных местах.
4. Отдачу своих метрик в прометеус осуществлять через самописный контроллер, в который инжектится CollectorRegistry. Дальше метрики в качестве text/plain отдаются контроллером.
#prometheus
Раньше я многократно пользовался Прометеусом для отображения метрик приложения. Рантайм шарпа по дефолту экспортирует достаточно информативный набор метрик, в т.ч. потребляемая приложением память, в т.ч. с разбивкой по поколениям сборки мусора. Добавлять кастомные метрики, позволяющие мониторить различные аспекты разрабатываемого приложения - более менее стандартная практика. И тут я задался вопросом, а как разделить метрики на группы (смапленные на разные пути: /metrics, /metrics/critical и т.д.), чтобы можно было опрашивать более критичные метрики с большей периодичностью.
Промучавшись некоторое время, я пришёл к следующему решению:
1. Основную группу метрик маппить стандартным способом, дефолтным .MapMetrics() в Program.cs
2. Для своих метрик создать свой CollectorRegistry, дальше методом Metrics.WithCustomRegistry создать экзмепляр фабрики MetricFactory, который заинжектить в приложение.
3. В местах, где требуются нестандартные метрики забирать MetricFactory и с его помощью создавать экземпляры метрик в нужных местах.
4. Отдачу своих метрик в прометеус осуществлять через самописный контроллер, в который инжектится CollectorRegistry. Дальше метрики в качестве text/plain отдаются контроллером.
#prometheus
👍3❤1