Я прошу прощения, но зачем это? Nginx сам создает логи (если может писать в директорию), а chmod 666 (спасибо что не 777) зачем? Это просто 5 бесполезных строк.
И зачем делать touch /etc/nginx/conf.d/grafana.conf, если можно просто сказать vim /etc/nginx/conf.d/grafana.conf и вставить содержание конфига.
Вместо стороннего модуля nginx echo, можно использовать встроенный модуль rewrite с директивой return:
Нас в первую очередь интересовала приватность (безопасность переписки), а потом уже какие-то плюшки и интересности.
В целом достаточно удобно. В плане коммуникаций менее продвинутый чем скайп и ряд других месенджеров — звонки только один на один, нельзя удалять сообщения, редактировать отправленные сообщения можно, но не так удобно (не всем удобно, кому как). В плане интеграций с внешними сервисами всё хорошо, удобный API. Мы настроили уведомления в коммандный чат о новых деплоях и о сбоях сервисов от заббикса и кое что еще. По администрированию вообще вопросов нет, все удобно кроме миграции. Но это думаю больше не понадобится. :)
Основная мысль которую должны понимать современные компаний занимающиеся разроботкой ПО/Web-приложений/и пр. должна быть следующей:
процесс разработки тестирования и эксплуатации ПО неразрывен. Программисты, админы и тестировщики всегда должны быть одной командой. Не нужно никаких модных слов. Нужна хорошая командная работа и грамотный менеджмент без матоков и размахивания пренадлежностями, и тогда и только тогда на выходе будет получаться хороший программный продукт. Без должного отношения друг к другу и нормального отношения к задачам не будет хорошего результата. В общем разработка это сложный процесс который требует слаженности и ответственности и не более.
Т.е. получается что таки каждую минуту может происходить nginx -s reload?
Мне кажется можно делегировать половину действий самому nginx и обойтись без частых reload.
Это именно отмена, а не отключение файла лога. Лог будет писаться в файл off. Что бы действительно отключить запись лога в файл нужно писать access_log /dev/null
access_log off; это директива отключающая лог (в конкретном блоке server или location), про "файл off" в документации нет ни слова (и на практике такой файл не возникает).
Ну вот например, такая конструкция в контексте плейбука или роли:
— roles: {role: foo, tags: [«one», «two»]}
не работает.
Было много обсуждений, но авторы вроде как ссылались, что исправление будет в версии 2.0.
Это все конечно хорошо. Но хотелось бы понимать чем мотивированы ваши цены?
В сравнении с вашим старым облаком цена выше чуть ли не в три раза. Я не пытаюсь сравнивать услуги, в новом частном облаке конечно больше плюшек, но все же.
А зачем согласовывать (или синхронизировать) кеш? Как это влияет на работу кластера и целостность данных?
Возможен ведь вариант при котором с одной ноды будут читаться данные из одной таблицы, а на другой ноде будет чтение из других таблиц или например будет вестись только запись без чтения или чтения будет гораздо меньше.
И все же, зачем query_cache если бд в innodb?
Ну и для примера, допустим размер бд > 50 Гб, при этом активные данные составляют порядка 10%, при этом:
600 r/s — selects,
50 r/s — updates,
20 r/s — inserts,
20 r/s — delete.
Как здесь быть с query_cache и как лучше в этом случае кешировать активные данные?
Я прошу прощения, но зачем это? Nginx сам создает логи (если может писать в директорию), а chmod 666 (спасибо что не 777) зачем? Это просто 5 бесполезных строк.
И зачем делать touch /etc/nginx/conf.d/grafana.conf, если можно просто сказать vim /etc/nginx/conf.d/grafana.conf и вставить содержание конфига.
Вместо стороннего модуля nginx echo, можно использовать встроенный модуль rewrite с директивой return:
Хотя, как по мне, проще файлик подложить в нужное место, чем потом вспонимать откуда этот robots.txt взялся и где его править.
В целом достаточно удобно. В плане коммуникаций менее продвинутый чем скайп и ряд других месенджеров — звонки только один на один, нельзя удалять сообщения, редактировать отправленные сообщения можно, но не так удобно (не всем удобно, кому как). В плане интеграций с внешними сервисами всё хорошо, удобный API. Мы настроили уведомления в коммандный чат о новых деплоях и о сбоях сервисов от заббикса и кое что еще. По администрированию вообще вопросов нет, все удобно кроме миграции. Но это думаю больше не понадобится. :)
процесс разработки тестирования и эксплуатации ПО неразрывен. Программисты, админы и тестировщики всегда должны быть одной командой. Не нужно никаких модных слов. Нужна хорошая командная работа и грамотный менеджмент без матоков и размахивания пренадлежностями, и тогда и только тогда на выходе будет получаться хороший программный продукт. Без должного отношения друг к другу и нормального отношения к задачам не будет хорошего результата. В общем разработка это сложный процесс который требует слаженности и ответственности и не более.
Мне кажется можно делегировать половину действий самому nginx и обойтись без частых reload.
Бред.
The special value off cancels all access_log directives on the current level.
http://nginx.org/en/docs/http/ngx_http_log_module.html
access_log off; это директива отключающая лог (в конкретном блоке server или location), про "файл off" в документации нет ни слова (и на практике такой файл не возникает).
Можно конечно использовать переменные, но мне кажется удобней настраивать логику выполнения тегами (субъективно).
Не работает:
С плейбуками пробовал как в документации указано:
Так тоже не работало.
Ваш пример выше на какой версии работает?
— roles: {role: foo, tags: [«one», «two»]}
не работает.
Было много обсуждений, но авторы вроде как ссылались, что исправление будет в версии 2.0.
Едва ли этого хватит на полноценный мониторинг. Разве что один хост мониторить и хранить не более месяца истории.
В сравнении с вашим старым облаком цена выше чуть ли не в три раза. Я не пытаюсь сравнивать услуги, в новом частном облаке конечно больше плюшек, но все же.
Возможен ведь вариант при котором с одной ноды будут читаться данные из одной таблицы, а на другой ноде будет чтение из других таблиц или например будет вестись только запись без чтения или чтения будет гораздо меньше.
И все же, зачем query_cache если бд в innodb?
Ну и для примера, допустим размер бд > 50 Гб, при этом активные данные составляют порядка 10%, при этом:
600 r/s — selects,
50 r/s — updates,
20 r/s — inserts,
20 r/s — delete.
Как здесь быть с query_cache и как лучше в этом случае кешировать активные данные?
www.opennet.ru/base/dev/intercept_lnx.txt.html
rflinux.blogspot.ru/2008/03/linux-syscalls-linux.html