а какая версия пчп?)

совершенно без понятия, мне больше интересно как люди пишут правильный код, чем как умеют какое-то говно разбирать

Как думаете валидный код? function foo() { ;;; return 123; }

В попилку вопросов на собес )

Если на собесе такое спрашивают, надо подумать о адекватности

Как думаете валидный код? function foo() { ;;; return 123; }

На каком языке?)

Пхп

Как думаете валидный код? function foo() { ;;; return 123; }

вполне

Как думаете валидный код? function foo() { ;;; return 123; }

должен быть

Всем привет! Может есть какой-то пример правильной настройки monolog в symfony для коннекта с ELK? С максимальной производительностью? Сейчас смотрю в сторону https://docs.graylog.org/docs/gelf с передачей в ELK через UDP.

самый правильный путь - писать в файлы/стдаут, если писать напрямую в логстеш из пхп, любые проблемы с логстешем автоматически ломают приложение. это неоправданно высокая цена за лень (когда можно сделать нормально, но хочется побыстрее и попроще)

но если это всё не смущает, то да, gelf_handler и вперед. могу в целом поискать примеры конфигурации, если сами не найдете

Спасибо! Да я тоже конечно к файлам склонялся, надо делать правильно) Значит будет связка Filebeat + ELK.

да. это правильнее

если будут вопросы - могу попробовать помочь

Спасибо!)

А для чего нужен filebeat в связке с ELK ? Типо что он полегче logstash и можно filebeat на стороне приложухи оставить, а elk на другой сервер ?

Ну допустим у тебя 10 контейнеров

Как ты будешь собирать логи

А для чего нужен filebeat в связке с ELK ? Типо что он полегче logstash и можно filebeat на стороне приложухи оставить, а elk на другой сервер ?

приложение аппендит в файлы, filebeat их tail-ит и шлет в логстеш, обеспечивая некоторой логикой балансировок и ретраев

типа разделение ответственности: приложение просто делает write в дескриптор открытый с O_APPEND, остальное кто-то еще делает

Ну допустим у тебя 10 контейнеров

Я не знаю, знаю что логстеш собирает тоже, вот и спрашиваю)

логстеш не собирает, он для трансформа нужен: принять строку лога, разобрать ее, обогатить и потом записать в хранилище/отбросить

откуда в него пишут строки он не знает

логстеш не собирает, он для трансформа нужен: принять строку лога, разобрать ее, обогатить и потом записать в хранилище/отбросить

Собирает. Я локально поднимал

нет, ну правда не собирает

он ждет поступающие события на 5044 порту по тцп

нет, ну правда не собирает

У меня только ELK стек для пробыб был собран и я считывал с файлов симфы

У логстеша есть input file

о, ну правда. беру слова обратно :)

никогда не задумывался что так можно

Возможно логстеш просто тяжелый, он жрет так нормально.

но это скорее для дебага

в проде не будешь ставить по инстансу логстеша к каждому приложению сайдкаром

он реально жруч

в проде не будешь ставить по инстансу логстеша к каждому приложению сайдкаром

Ну вот мб в этом смысл как раз. Спасибо

вообще попробуйте vector.dev

ему сильно меньше нужно ресурсов чем логстешу (запускать софт на jruby мог придумать конкретный наркоман), там правда не 1в1 ложится логика процессинга

но почти все то же самое можно сделать, только сильно дешевле по цпу

особенно если sink не эластик, а то вектор в балансировку записей в дата-ноды не умеет)

Я юзаю кроны вообще ) и телеграм

Работает месяцами стабильно

Вообще не лажу туда

Какими месяцами. Получается год уже. Правда только ошибки. Без сбора аксес логов и прочей ерунды

Вот такую ерунду накидал себе и юзаю https://github.com/zim32/climonitoring

Но это чисто мой велосипед никого не призываю

Сервера уже десять раз из бекапв поднимались, падали, а эта хрень поднимается сама и пролжает работать я даже удивился ) кроны рулят

логи != мониторинг. оно друг друга дополняет, но это разные плоскости observability

за велосипед плюс, но лично мне надоело такие велосипеды кочегарить. количество скриптов, что ты пишешь, растет экспоненциально. и всё равно не хватает

поэтому теперь только прометеус-стек. за меня всё пишет коммунити, а что не пишет оно, тривиально инструментируется на любом языке

ну типа один node_exporter писать на баше очумеешь, это год работы, наверное

Ну да велосипед чисто для мелких проектов

Для чего-то посерьёзнее конечно надо серьезные инструменты

да скорее гошку подботать)

даже для мелких проще пром поднять

В моем велосипеде просто мне нравится что в принципе нет точки отказа

Любой сервер самодостаточен

но я не настаиваю, велосипеды всегда дело полезное. но бизнес, думаю, вряд ли бы обрадовался, если бы я его я оставил с таким мониторингом 🙂

Не надо еще переживать за сервер мониторинга которого просто нет

Да это больше инструмент личного использования )

вообще, мониторинг, оказывается (реально, я как-то не сразу это осознал) лучше рассматривать не как триггер 0/1, а как таймсирис-базу

появляется тонна дополнительных ручек, о которых ты с zabbix-like инструментами (где алерт - это 0/1) и не мечтал. ну типа "если количество запросов за последние 10 минут упало втрое относительно средне-12-часового, то кинуть алерт"

"если линейная интерполяция утилизация диска через час превысит 80% то кинуть алерт" итд

А это у меня есть

а как это происходит, если нету бд под метрики? каюсь, читал по диагонали

Ну еать процессор average

в рамках одного сервера метрики хранятся? а если он перезагрузится/удалится/добавится новый? если нужна стата, агрегированная по нескольким серверам? ну типа есть десяток бэкендов, на которые запросы балансируются и надо по ним суммарный рпс посчитать и что-то там с ним сделать?

Он внутри высчитывает среднее

И выплёвывает

ага, ну это в памяти агрегация, она не особо персистент

Ну там падает только если упал сервер ) так что там уже не average тогда значит

и среднемесячное какое считать уже довольно накладно (копятся данные в памяти) и ненадежно (процесс-агрегатор может умереть и потерять все накопленное)

Да база надежнек. Но опять таки мне не нужно было все так усложнять

Хранить еще

Диски под это дело выделять. Основная идея была как раз без центрального узла

Чтобы если твое хранения посыпалось, что часто бывает, то все продолжило работать

с промом это удобно: это не агенты пишут в сервер (и встают раком если он сломался), а сервер сам опрашивает агентов. если сервер лёг, то агентам пофигу

Вот это можно как-то в шторме пофиксить? пишет only read but never written

безотносительно сути вопроса: а почему нуллабельное-то?

ваще интересно, у меня так не пишет почему-то

Вот это можно как-то в шторме пофиксить? пишет only read but never written

Сделать setId или добавить флаг игнорирования ошибки