Комментарии 21
Вместо прометеуса лучше использовать VictoriaMetrics, если предполагается много метрик (и долгое хранение) - выигрыш буде существенным.
Спасибо за идею с grafana-image-renderer - не знал. И вообще хорошая, полезная статья.
Один момент: "reverse", а не "reserve" proxy.
Спасибо, поправил опечатку.
Там ещё осталось "resrve".
А для отправки скриншототов из графаны ещё, ведь, нужен alertmanager, который остался за рамками статьи?
Ещё раз спасибо, почему то мои пальцы (а затем и глаза, при проверке) пропускают такие ошибки, буду думать, что с этим делать на будущее.
Касательно alertmanager - в Grafana есть внутренний alertmanager: grafana.com/docs/grafana/latest/alerting/fundamentals/alertmanager/, с ним данный функционал работает.
Спасибо.
Правильно понимаю, что при помощи grafana-image-renderer скриншоты графиков могут создаваться только для оповещений, создаваемых самой Grafana, а в оповещения, генерируемые Prometheus Alertmanager Grafana не сможет добавить скриншоты?
Скорее всего да. Я более детально не углублялся в вопрос, т.к. пользуюсь Alertmanager-ом встроенным в Grafana (так что возможно есть варианты), но если верить документации то: "This feature is not supported in <...>, or when Grafana is configured to send alerts to other Alertmanagers such as the Prometheus Alertmanager".
Жаль что статья не закрыла вопросы:
1) Подробный парсинг Nginx (не PLUS версии) лога запросов проекта для детального анализа (пример какой запрос упал с ошибкой 500)
2) Ошибка 429 кажется, когда идет большой поток инфы и Loki не успевает принять.
3) Использование Mimir раз уж используем Grafana стек
И вопрос отдельный, не упадет ли контейнер экспортера если на сервере Loki закончилось дисковое пространство?
Касательно парсинга логов nginx вопрос действительно интересный, особенно интересен ещё тем, что благодаря pattern parser в версиях LogQL (2.3+) такие текстовые логи можно парсить чуть удобнее (чем, например, regex). Но, тут тоже есть некоторые нюансы, по-хорошему для этого нужна отдельная статья.
То же самое думаю и про Grafana Mimir (и вышеупомянутый в другом комментарии VictoriaMetrics), отлично что эти инструменты упомянуты, но, мне кажется, они находятся чуть повыше чем посыл "быстро и просто" (в заголовке статьи).
Про status code 429, да, когда логов станет много, в любом случае придётся "тюнить" конфигурации под свою ситуацию (есть разные способы - изменить лимиты в секции limits_config со стороны Loki, изменить интенсивность отправки логов со стороны Promtail, даже вплоть до крайних мер - "дропа" лишних). По понятным причинам все эти настройки оставлены по умолчанию, т.к. вряд ли можно подобрать значение, которое будет лучше для всех.
Про ситуацию с дисковым пространством, как мне кажется, что если на сервере заканчивается дисковое пространство, то ожидаемо, что работать нормально не будет (но, что именно произойдёт, упадёт контейнер ли, не пробовал). Но если это "боевой" сервер/VM, то, наверное, правильнее изначально продумать так, чтобы ситуации не возникло (например, замониторить и заалертить то самое дисковое пространство), ну и частично уменьшит вероятность попадания в такую ситуацию правильная настройка retention (для очистки старых логов и освобождения места, о последнем в статье упомянул).
1) включаем json логи в nginx, пишем алерт, внутри алерта можно вставить любое поле из json
2) расширять канал на прием для Локи в его параметрах
Контейнер не упадёт, в логах будут ошибки о недоступности сервера. Когда проблема решится, данные будут добавлены в Локи (при условии соответствия времени добавления логов параметру, отвечающему за устаревание логов).
А можно ли как-нибудь обойтись без "log-driver": "json-file"?
Эта гадость же трёт логи при каждом пересоздании контейнера.
В конкретно данной концепции, которая описана в статье, всё рассчитано на работу именно с "log-driver": "json-file" : используемая конфигурация promtail парсит json-файлы логов docker, мы не устанавливаем дополнительные драйверы логирования на машины.
Обойтись без изменения конфигурации docker (добавления настроек логирования в daemon.json) можно, но, как и описано в начале статьи, тогда мы лишимся большинства labels в логах (stack_name, service_name, ...).
Ещё одно НО, согласно документации логирования docker, данный log-driver и так используется по умолчанию, и мы только добавляем некоторые labels в этот лог (т.е. если вы ничего не меняете, у вас и так "log-driver": "json-file").
А в каких случаях логи потеряются при добавлении данной настройки, но при этом не потеряются, при использовании настроек по умолчанию? Я не смог воспроизвести такой кейс.
По умолчанию они так же теряются. Чтобы они не терялись, надо ставить "log-driver": "journald". Однако, этот драйвер выглядит несовместимым с вашим решением.
Есть ли что-нибудь, что парсило бы журналы journald?
Ну тогда решение кажется таким на первый взгляд: настроить docker, чтобы он писал логи в journal, а promtail, чтобы он из journal отправлял логи в loki (это он умеет). То, что можно так настроить — это факт, но в любом случае нужно пробовать и дополнительно исследовать на предмет того, как в таком случае писать в эти логи (а затем парсить оттуда) имена сервисов, проектов и прочие labels.
Ничего не понял, если решение агрегирует логи в Loki, то зачем их хранить в json-file или в том же journald?
В предложенном решении логи в Loki попадают не сразу, а сначала пишутся на диск. "Зачем" тут надо спрашивать автора.
Но если уж и писать их на диск, то только в journald. json-file должен быть забыт.
Отвечая на вопрос "зачем": в самом начале статьи писал, что решение можно использовать в том числе без изменения каких-либо настроек docker на хостах, без установки плагинов логирования и какого-либо дополнительного софта на сам хост. По умолчанию docker пишет логи так, фича решения в том, что оно умеет работать с теми логами, которые даёт docker по умолчанию.
Логи из docker compose / docker swarm в Grafana / Loki быстро и просто