соотвествующей переменной окружения выводит в лог кучу дополнительной информации (для старого доброго дебага print'ами, когда нет возможности подцепить дебаггер (да и есть ли такая вообще у go даже если не считать что туда, где работает программа удалённый дебагер всё равно не подцепить?)). И используется в коде очень много где. ОЧЕНЬ.
Вот и хотел бы избавить программу от миллионов проверок переменной при каждом чихе.
ну и рядом там есть такая же для вывода бектрейсов (с другой переменной, сотвественно)
Есть такая штука как severity у логгера) Но это все лирика конечно Мой поинт был к тому, чтобы вы задумались, а надо ли оно вам (потому что в 90% случаев не надо). Если надо и вы в этом уверены (а если есть пруфы, то вообще шик), тогда давайте разбираться на конкретном кейсе)
я, наверное, смотрю куда-то не туда, но в "изкоробочном" log, что-то не видел ни слова про severity. А подключать дополнительную внешнюю зависимость - не хотелось бы...
severity это название уровня логирования, насколько я понимаю
Да, в пакете log стандартной библиотеке такого на сколько мне известно нет, но этого одна из его проблем. Ни в одном production-ready приложении я не видел чтобы он использовался. Поэтому этот вброс был про любой сторонний логгер. А чем вы таким занимаетесь, если не секрет?)
тем, что по многим параметрам "ненужно" :) костыляю самодельную реализацию docker-volume-plugin'а для Swarm. Который бы работал как (мне) надо. Так-то, две реализации уже есть, но одна не умеет в "глобальность" (в кластер), а вторая в хранение информации у вольюмах. Вот, скрещиваю ужа с ежом (в смысле, писал свою вариацию "по мотивам" поглядывая и в ту и в другую реализации). Точнее, уже скрестил, теперь переписываю чтобы меньше ног отстреливало :)
Хм, интересное вы себе развлечение нашли) Так а вопрос действительно про логирование? Если да, то очень советую воспрользопаться сторонним логгером. Хороших вариантов множество
ну, вопрос изначально про производительность. У меня там какая история: Сначала я пилил через монтирование "корневой" ФС при старте драйвера. Потом столкнулся что в таком режиме эта скотина отказывается останавлиаться (в т.ч. для переконфигурации и обновления) т.к. у докеровольюмов такая вот особенность: пока есть хоть один исходящий референс из драйвера - он не перезапустится. Ну, я не долго думая переписал на "монтирование корня -> выполнение служебных действий -> отмонтирование". Потом ещё трахался с тем, чтобы сделать так, чтобы параллельные монтирования корня не мешали друг другу. А в итоге оказалось что такой поход хреноват в том, что на одно монтирование вольюма происходит по ~6 монтирований-отмонтирований корня с выполнением служебных операций. И всё это не бесплатно, ни по ресурсам ни по времени. Так что переписал, вот, сейчас, обратно на монтирование корня при старте. Так, хоть, "производительнее" (да и крышу не сносит бекенду ФС, а то уже был прецедент). И вот раз я тут переписываю с упором на производительность - я задумался, что у меня по коду миллиард DBG(), каждый вызов которой происходит if var {}. Потому и задумался о том, чтобы этого тоже избежать
А го - не про производительность :)
Обсуждают сегодня