Илья Т., ЭЭ у меня лог около 20 ГБ ниче не встает никуда, встать может только при переполнение массива, но в таком случае вам нужно отказаться от регулярки при старте в таком случае таких проблем не будет ни при каком размере файла.
sphinx прекрасно может решить проблему с индексами, но не совсем понимаю что вы там собрались индексировать и что вы там собираетесь быстро искать.
НУ и да подходы у всех разные, но чем чаще вы пользуетесь возможностями самой ос
тем меньше вам нужно стороннего ПО
В свою очередь я предпочитаю пользоваться именно стоковыми возможностями даже не bash а sh поскольку последнее более распространено и при работе с незнакомым сервером у вас будет возможность так же комфортно работать как и раньше, любой костыль ( замечу даже удобный) требует установки а порой это сделать попросту невозможно, так что проще приучиться работать с потоком ввода вывода, поверьте у вас просто не появится идеи зачем вам нужно такое логирование.
Поскольку просто читать логи как правило не требуется а требуется анализ, подсеты сумировани групирование и тд.
я не совсем понимаю зачем вам sql
Основная задача sql - то чего не может файловое хранение это транзакции, параллельной записи у вас там не намечается следовательно этот плюс пропадает, зачем перетаскивать то что и так прекрасно работает в демона который замечу может отвалиться, крашнуть таблицу и тд не совсем понятно ?
удобная фильтрацияч ?
grep отлично фильтрует и ищет
tail -f - работает с потоком
sed awk тоже вроде никуда не делись
Вот и вопрос а зачем?
Вот пример реально первого попавшегося мне в истории поиска по логу
как вы это собираетесь сделать через GUI ?
боюсь что для действительно комфортной работы а главное эффективной вам нужно знать консольные команды как свои пальцы только в таком случае вы получаете мощнейший инструмент аналитики логов.
Как следствие вам не потребуется GUI.
Именно по этой причине в линукс все плохо с GUI утилитаи, те кто плохо владеют консолью как правило не в состояние написать такую утилиту, а те кто умеют пользоваться консолью не собираются ее писать поскольку она просто не нужна. И это касается не логов а вообще всего линукс.
А красивые графики и тд это здорово но в реальной жизни у вас есть конкретные задачи.
это просто настройки днс сервера
к веб серверу это отношение имеет посредственное.
Вам нужно установтиь веб сервер на вашу вм
самый прсотой вариант это сделать посатвить bitrix vm
Vestscp
braynycp
и тому подобное
Alex Wells,в задаче нет ни обьемов ничего.
Исходя из логики сколь либо значемый проект такоуй хренью не занимается и уж тем более не задают столь простые вопросы.
по этому говорить о какой-то системе кеширования и тд тут смысла нет.
тут очевидно делается костыль я лишь предлагаю его не распространять за пределы пхп
Виктор Таран, блин да не нужно было удалять комент.
опишите как вы добавляли сайт на сервер последовательность
ДНС запись меня пока не интересует.
Имено как создавались папки для сайта на сервере
Lola Gasanova, J о боженьки вы мне сейчас показали кирпич на вопрос о рыбе ;)
давайте по порядку где вы добавляли первое доменное имя покажите это место ?
именно когда создавали его на этом сервере ?
или вы это делали через конфиг ?
Alex Wells, затем что проксировать можно несколькими способами
nginx -proxy_pass
apache -mod_proxy
ну и пхп
так вот на сайте работают в основном разработчики php и естественно с php кодом они легко разберутся, не в момент его создания в в момент когда другй человек или через 3 года нужно будет вспомнить это место.
Если же делать это средствами самого сервера то
1. Вы привязаны к текущему конфигу и нужно всегоад помнить про его существование, что станет проблемой для нового разраба или всмомнить о этом тому-же через пару лет.
2. Вы используеете более обширный стэк технолгий, хоть и простых.
3. при востановление бэкапа на строннем сервере должен быть nginx или апачь соответственно в принудительном порядке, ибо конфиг нуно будет в него вписать или переделать под текущий веб сервер.
4. перенос на новый сервер, см пункт 3
И того для решения этой задачи хватает обычного разраба
против
двух сисадмина и разраба.
Это экономически дешевле обслуживать.
1 да все но, часть из них прокачивается под высоко частотные запросы часть под средни часть по точному вхождению.
Глупо надеиться на одинаковый трафик от запроса "купить трусы"
и "красные трусы с мехом в зеленый горошек. "
эти запросы имеют совершенно разные механизмы раскрутки разный процент конверсии и количество показов.
И да вы же не под каждый запрос делаете страницы, часть запросов будут не иметь страницы куда-то им нужно идти.
2 Да можно сделать их как отдельные страницы но вы можете нарушить структуру сайта , что отразится вам в дальнейшем при его росте.
тут нужно смотреть всю структуру сайта.
3 В примере не услуга разделяется территориально
а одно является вложением в другое, то что там территория в запросе попалась это всего-лишь пример.
Так же не забывайте что я вам указал одну статцнию метро, так же их 1000 штук, так же есть еще и города.
И тут структуризация очень важна, поскольку возможна канализация запроса, проблемы с фильтрациями построениями меню и тд и тп
У вас собрано семантическое ядро запросов ?
покажите вашу " сео карту"
пару урл- запрос куда какие вы собираетесь вести ?
Алексей, из минусов этого вы получите жесткую привязку сайта к nginx
если же вы сделаете как я сказал этой связки не получится, весь сайт се еще будет не привязан так полотно к среде
IvanovIvanIvanych, У вас должна быть страничка которую вы пркоачиваете для СЕО
К примеру у вас список спорт клубов, соответственно страница списка должна быть в поиске на более высоком месте по запросу
"Спортклубы кантемировская" нежели определенный спортклуб скажем Зебра, поскольку запрос не был зебра на кантемировской но спортклуб зебры явно более посещямеая чем какой-то подвал, соответствено яндекс
выбирая между
/sport_zebra
/sport_podval
выберет зебру как основную позицию на запрос "спортклубы кнтемировская"
Посколкьу ее посещяют чаще и дольше читают.
Для этого вы убираете зебру на более низкий уровень вложенности
/sport - эту страничку вы раскручивете ( тут все запросы кроме частных включая просто спортклубы москва)
/sport/zebra - частный случай когда запрос спортклуб зебра
так более понятно ?
А вот если вы раскручиваете моноуслуги к примеру "вскрытие замков" и это у вас основной профиль
то тут услуга может находиться вообще на главной странице, а все остальные услуги типа "востановление двери" уже находятся где-то там внутри. посколкьу они вам коммерчески не интересны и идут довеском.
Так более понятно ?
Но например допускается такая вещь /usluga-1 если вам нужно уменьшить уровень вложенности если это профильная для компании вещь.
Например у вас компания по ремонту телевизоров то да /remont_samsung вполне допустимо
нет как у вс не существует раздела ?
у вас есть более высокочастотный запрос чем частный случай услуги
как вы себ еэто представляете ?
если у вас две три моно услуги то да
если их больше чем 1-2 то нет такой ситуации быть не должно
ashyr96, такие костыли у каждого провайдера свои, однако это точно где-то в регионе поскольку в москве и области такой гадости давно уже ( лет 20 ) нет
давайте конкретный тариф в конккретном городе
дайте хоть почитать что они имеют в виду.
скорее всего это просто промо, ограничивать вас по длине маршрута сознательно никто не будет.
Все что может дать "игровой тариф" это увеличение скорости, качество при этом не должно меняться.
Скорость канала играм особо не нужна.
Качество сознательно понижать никто не будет. Как минимум это не совсем законно.
Если вы дадите ссылку на что именно вы имеете в виду "игровой тариф" то можно обсудить то в нем написано.
MrDimaFIX,
Открою вам секрет что если есть место не важно где но по дороге без шифрования, канал не может считаться защищеным.
В идиале нужно шифровать и бэк и фронт и тунель между ними.
НО последнее это как вы уже заметили возможно маразм для обычного веба.
Однако если у вас в ajax будет ифка с какой протокол то у вас будут проблемы.
если у вас будет АПИША с ожидаемым кодом 200 а у вас будет 301 то тоже проблемы
если у вас будет редирект с http_host = site.ru а он по факту на бэке будет site.ru:82 то тоже будут проблемы, и тд и тп.
я сейчас не говорю о самом шифрование канала я говорю о реальном определение бэком какой сейчас протокол. Посколку идет его подмена на фронте частично это исправляется но бэк работает на незащищеном и это полностью скрыть нельзя, в результате может быть все что угодно.
От зацикливания редиректов, котоырй гоняет по кругу один и тот-же урл вообще не еняя его.
Это не критично и на 95% проектов это вообще не заметно.
Но с точки зрения постороения архитектуру грубейшая ошибка.
Сделайте все правильно, дабы разница в 6 строк конфига.
В чем костыльность проброса сертификатов? никто вам не запрещяет кстати юзать разные.
