К сожалению, так и не понятно, какой клиент использовать под Android.
Из описанных в статье, все они имеют недостатки, а Cisco AnyConnect у меня не работает из-за бага https://quickview.cloudapps.cisco.com/quickview/bug/CSCvr47450 (у меня прописан свой DNS сервер на Android, получается при использовании Cisco каждый раз приходится эту настройку отключать потом включать). И очень странно, что баг зарегистрирован в 2019 году, но в интернете о проблеме крайне мало информации, обходного решения тоже не нашёл.
Скорее всего да. Я более детально не углублялся в вопрос, т.к. пользуюсь Alertmanager-ом встроенным в Grafana (так что возможно есть варианты), но если верить документации то: "This feature is not supported in <...>, or when Grafana is configured to send alerts to other Alertmanagers such as the Prometheus Alertmanager".
Отвечая на вопрос "зачем": в самом начале статьи писал, что решение можно использовать в том числе без изменения каких-либо настроек docker на хостах, без установки плагинов логирования и какого-либо дополнительного софта на сам хост. По умолчанию docker пишет логи так, фича решения в том, что оно умеет работать с теми логами, которые даёт docker по умолчанию.
Ну тогда решение кажется таким на первый взгляд: настроить docker, чтобы он писал логи в journal, а promtail, чтобы он из journal отправлял логи в loki (это он умеет). То, что можно так настроить — это факт, но в любом случае нужно пробовать и дополнительно исследовать на предмет того, как в таком случае писать в эти логи (а затем парсить оттуда) имена сервисов, проектов и прочие labels.
В конкретно данной концепции, которая описана в статье, всё рассчитано на работу именно с "log-driver": "json-file" : используемая конфигурация promtail парсит json-файлы логов docker, мы не устанавливаем дополнительные драйверы логирования на машины.
Обойтись без изменения конфигурации docker (добавления настроек логирования в daemon.json) можно, но, как и описано в начале статьи, тогда мы лишимся большинства labels в логах (stack_name, service_name, ...).
Ещё одно НО, согласно документации логирования docker, данный log-driver и так используется по умолчанию, и мы только добавляем некоторые labels в этот лог (т.е. если вы ничего не меняете, у вас и так "log-driver": "json-file").
А в каких случаях логи потеряются при добавлении данной настройки, но при этом не потеряются, при использовании настроек по умолчанию? Я не смог воспроизвести такой кейс.
Касательно парсинга логов nginx вопрос действительно интересный, особенно интересен ещё тем, что благодаря pattern parser в версиях LogQL (2.3+) такие текстовые логи можно парсить чуть удобнее (чем, например, regex). Но, тут тоже есть некоторые нюансы, по-хорошему для этого нужна отдельная статья.
То же самое думаю и про Grafana Mimir (и вышеупомянутый в другом комментарии VictoriaMetrics), отлично что эти инструменты упомянуты, но, мне кажется, они находятся чуть повыше чем посыл "быстро и просто" (в заголовке статьи).
Про status code 429, да, когда логов станет много, в любом случае придётся "тюнить" конфигурации под свою ситуацию (есть разные способы - изменить лимиты в секции limits_config со стороны Loki, изменить интенсивность отправки логов со стороны Promtail, даже вплоть до крайних мер - "дропа" лишних). По понятным причинам все эти настройки оставлены по умолчанию, т.к. вряд ли можно подобрать значение, которое будет лучше для всех.
Про ситуацию с дисковым пространством, как мне кажется, что если на сервере заканчивается дисковое пространство, то ожидаемо, что работать нормально не будет (но, что именно произойдёт, упадёт контейнер ли, не пробовал). Но если это "боевой" сервер/VM, то, наверное, правильнее изначально продумать так, чтобы ситуации не возникло (например, замониторить и заалертить то самое дисковое пространство), ну и частично уменьшит вероятность попадания в такую ситуацию правильная настройка retention (для очистки старых логов и освобождения места, о последнем в статье упомянул).
К сожалению, так и не понятно, какой клиент использовать под Android.
Из описанных в статье, все они имеют недостатки, а Cisco AnyConnect у меня не работает из-за бага https://quickview.cloudapps.cisco.com/quickview/bug/CSCvr47450 (у меня прописан свой DNS сервер на Android, получается при использовании Cisco каждый раз приходится эту настройку отключать потом включать). И очень странно, что баг зарегистрирован в 2019 году, но в интернете о проблеме крайне мало информации, обходного решения тоже не нашёл.
Скорее всего да. Я более детально не углублялся в вопрос, т.к. пользуюсь Alertmanager-ом встроенным в Grafana (так что возможно есть варианты), но если верить документации то: "This feature is not supported in <...>, or when Grafana is configured to send alerts to other Alertmanagers such as the Prometheus Alertmanager".
Отвечая на вопрос "зачем": в самом начале статьи писал, что решение можно использовать в том числе без изменения каких-либо настроек docker на хостах, без установки плагинов логирования и какого-либо дополнительного софта на сам хост. По умолчанию docker пишет логи так, фича решения в том, что оно умеет работать с теми логами, которые даёт docker по умолчанию.
Ну тогда решение кажется таким на первый взгляд: настроить docker, чтобы он писал логи в journal, а promtail, чтобы он из journal отправлял логи в loki (это он умеет). То, что можно так настроить — это факт, но в любом случае нужно пробовать и дополнительно исследовать на предмет того, как в таком случае писать в эти логи (а затем парсить оттуда) имена сервисов, проектов и прочие labels.
В конкретно данной концепции, которая описана в статье, всё рассчитано на работу именно с
"log-driver": "json-file": используемая конфигурация promtail парсит json-файлы логов docker, мы не устанавливаем дополнительные драйверы логирования на машины.Обойтись без изменения конфигурации docker (добавления настроек логирования в
daemon.json) можно, но, как и описано в начале статьи, тогда мы лишимся большинства labels в логах (stack_name,service_name, ...).Ещё одно НО, согласно документации логирования docker, данный log-driver и так используется по умолчанию, и мы только добавляем некоторые labels в этот лог (т.е. если вы ничего не меняете, у вас и так
"log-driver": "json-file").А в каких случаях логи потеряются при добавлении данной настройки, но при этом не потеряются, при использовании настроек по умолчанию? Я не смог воспроизвести такой кейс.
Касательно парсинга логов nginx вопрос действительно интересный, особенно интересен ещё тем, что благодаря pattern parser в версиях LogQL (2.3+) такие текстовые логи можно парсить чуть удобнее (чем, например, regex). Но, тут тоже есть некоторые нюансы, по-хорошему для этого нужна отдельная статья.
То же самое думаю и про Grafana Mimir (и вышеупомянутый в другом комментарии VictoriaMetrics), отлично что эти инструменты упомянуты, но, мне кажется, они находятся чуть повыше чем посыл "быстро и просто" (в заголовке статьи).
Про status code 429, да, когда логов станет много, в любом случае придётся "тюнить" конфигурации под свою ситуацию (есть разные способы - изменить лимиты в секции limits_config со стороны Loki, изменить интенсивность отправки логов со стороны Promtail, даже вплоть до крайних мер - "дропа" лишних). По понятным причинам все эти настройки оставлены по умолчанию, т.к. вряд ли можно подобрать значение, которое будет лучше для всех.
Про ситуацию с дисковым пространством, как мне кажется, что если на сервере заканчивается дисковое пространство, то ожидаемо, что работать нормально не будет (но, что именно произойдёт, упадёт контейнер ли, не пробовал). Но если это "боевой" сервер/VM, то, наверное, правильнее изначально продумать так, чтобы ситуации не возникло (например, замониторить и заалертить то самое дисковое пространство), ну и частично уменьшит вероятность попадания в такую ситуацию правильная настройка retention (для очистки старых логов и освобождения места, о последнем в статье упомянул).
Ещё раз спасибо, почему то мои пальцы (а затем и глаза, при проверке) пропускают такие ошибки, буду думать, что с этим делать на будущее.
Касательно alertmanager - в Grafana есть внутренний alertmanager: grafana.com/docs/grafana/latest/alerting/fundamentals/alertmanager/, с ним данный функционал работает.
Спасибо, поправил опечатку.