Так оно не для ui и нужно, а чтобы ускорить определение доменного имени. На уровне ui сделать любую схему работы автодополнения, как и отображение — не трудно.
Скажем, на уровне парсинга url и dns было бы удобней разбирать с конца имени хоста — меньше ресурсов тратиться будет.
2ip — некачественный тестировщик скорости.
не показывает он нормальную скорость, даже, если никаких ограничений нет.
speedtest, или если сомневаетесь — iperf.
про другие сервисы тестирования скорости не скажу — крайний раз этим 4 года назад занимался.
ой не надо тут государства.
Пускай государство ратует за концепцию «сетевого нейтралитета».
А цену рынок сам отрегулирует, как и тарифы «только вк, ок, вацапы и прочие телеграммы» и «всё включено».
А вот расскажите о своём опыте — какие скрипты с хаба Вы лично используете?
Пример по установке nginx понятен, но лучше бы что-то более осязаемое — зачем мне нужен этот репозиторий, какие скрипты там есть, которые могут сэкономить полчаса моего времени?
Ребят, а можете не полениться и написать статью — в каких случаях надо смотреть на `метрику` и что она показывает.
Просто статья говорит — существует over 80 утилит мониторинга.
Но когда их надо использовать и на что внутри смотреть — большой вопрос.
данные в графит отправить — graphite_writer или как-то так.
По документации гуглится легко — шлёт все perf данные в графит.
настраивай по api — я лично не пробовал, но возможность такая есть.
У меня небольшая специфика — хосты часто добавляются/удаляются.
Мониторинг _пока_ вне этого процесса — просто раз в несколько часов запрашиваю список хостовз Б по api… Это даёт много боли — icinga может упасть, если на хосте стоял даунтайм, а его внезапно удалили.
В следующей версии этот баг пофиксят, а работа по API решит все проблемы сразу.
По поводу хостов/сервисов из БД — у меня такая специфика — куча хостов в digitaocean и vcale
Я написал 2 скрипта для каждого провайдера, которые берут список хостов и генерируют конфиг в /etc/icinga2/conf.d/${provider}.conf
а потом ребутают мониторинг.
Это не очень правильное решение, но для меня оно работает.
если бы я делал это сейчас с нуля — я бы тоже самое сделал через API icinga.
Про сервисы — кажется там всё просто — на основе переменных у хоста — применяем сервисы.
В общем, опиши в личку специфику — глядишь что и посоветую.
Да кто ж спорит-то? В icinga можно даже настроить, чтобы данные в графит отправлялись на другой хост.
Я хотел сказать, что с одной стороны — icinga — очень быстрый мониторинг — именно за счёт отсутствия лишних функций.
С другой стороны — как только эти самые «лишние» функции вам становятся нужны — вы должны их сами.
В иных решениях некоторые aggerated/manager-специфичные вещи идут из коробки.
Это то, на что я хотел обратить внимание.
icinga2 — совершенно прекраснейшая вещь.
Быстрая, очень гибкая, но…
графики идут, как приблуда сверху. То есть, вы не получите аналитики, не узнаете отклонений от «обычного» поведения. Мне это не нужно(вернее, у меня нет на это ресурсов) — потому ок.
icinga2 активно разрабатывается — есть высокий риск получить падение программы в неожиданной ситуации.
Впрочем, при должном внимании — это легко решаемо, а при расследовании еще и становится понятно — «как не надо делать».
Важный минус — в веб-интерфейсе нет отчёта по SLA.
Через sql, конечно, можно всё, но кому-то будет минусом.
резюмируя: если бы сейчас я выбирал бы мониторинг — я бы несколько раз подумал в сторону более менеджероориентированных решений.
мимоходом посматриваю на influxdb/opentsdb.
С другой стороны, я не уверен, что они удержат 1500к проверок минуту на одном процессорном ядре.
Icinga скрипит, но держит.
Правда, пару недель назад я не успел оптимизировать часть проверок и потому теперь у меня 2 ядра на исингу))
Труд хороший, но бесполезный — кому надо и так знает, а кто не знает — не поможет.
Лучше бы расписали — в каких случаях какая утилита поможет, имхо, ес-но.
Кому интерестен ваш чат?
Есть мнение — сфомирируй его из своего чата и выскажи.
Нахрена мне твой чат с кем-то?
Хочешь упомянуть коллегу по чату? символ @ тебе в помощь.
Спасибо за статью!
А вот можно реквестовать статью по настройке mysql/postgresql для ноды фиксированной памяти?
Давайте возьмём nginx+php-fpm+db_name.
Пускай размер php-fpm будет 20 и 80мб. Ну для «простых» фреймворков и «крутых». Просто два варианта рассмотрим.
Давайте рассмотрим инстансы для «маленьких» — 512, 1024, 2048, 4096.
Давайте примем за истину, что db_запросы занимают 70% времени работы php-скрипта.
Внмание вопрос — как правильно искать узкие места и оптимизировать их?
Это актуально как для mysql, так и для pg.
Апологеты mysql, так и pgsql — сделайте, пожалуйста.
Как читать explain — и куда смотреть на внутренние параметры БД.
Сравнение какое-то однобокое совсем получилось.
Я как-то много командировался и вот мои заметки к вашей задаче:
1. Если вы сидите только в городах и летаете на самолётах — то на покрытие вам наплевать, а трафик в полёте не нужен. Тогда вы верно заметили — билайн интереснее. Вот только часто имеет смысл взять локальную сим-карту для звонков и интернета. Если это Европейская часть страны. В северных и дальневосточных регионах связь надо везти с собой.
2. Если же вы зачем-либо выезжаете из города или едете на машине — вам может быть интересен интернет вне города и тут уже имеет значение покрытие оператора. Как бы это ни было дорого, у мегафона оно лучшее. Остальные в погоне за лидером. Если мы за пределами европейской части страны — в части посёлков в принципе может быть покрытие только одного опсоса.
3. Если трафика нужно не так много — у каждого оператора есть опцию по типу СуперБит (сколько-то там трафика по всей стране) — это может оказаться выгоднее.
4. В этом году МТС очень сильно испортила тариф СуперМТС, фактически вынудив всех, кому надо выезжать за пределы домашнего региона переходить на линейку Смарт, которая гораздо дороже.
По роду деятельности я немного знаком с ривербедами, потому отвечу вам.
1. У них есть режим работы с предустановкой tcp-соединений, что на канале с высоким RTT даёт выигрыш времени на установку соединения. При типичном RTT 700ms на установку обычного TCP-соединения нужно 2.1 секунды. Если мы заранее установим сессию — мы сэкономим это время.
2. Сжатие данных, в случае простого калькулятора — эффекта будет мало, а для работы среднего приложения по API с передачей данных json/xml выгоды будет существенно больше.
Скажем, на уровне парсинга url и dns было бы удобней разбирать с конца имени хоста — меньше ресурсов тратиться будет.
не показывает он нормальную скорость, даже, если никаких ограничений нет.
speedtest, или если сомневаетесь — iperf.
про другие сервисы тестирования скорости не скажу — крайний раз этим 4 года назад занимался.
Пускай государство ратует за концепцию «сетевого нейтралитета».
А цену рынок сам отрегулирует, как и тарифы «только вк, ок, вацапы и прочие телеграммы» и «всё включено».
Только без государства, плиз.
Пример по установке nginx понятен, но лучше бы что-то более осязаемое — зачем мне нужен этот репозиторий, какие скрипты там есть, которые могут сэкономить полчаса моего времени?
Просто статья говорит — существует over 80 утилит мониторинга.
Но когда их надо использовать и на что внутри смотреть — большой вопрос.
По документации гуглится легко — шлёт все perf данные в графит.
настраивай по api — я лично не пробовал, но возможность такая есть.
У меня небольшая специфика — хосты часто добавляются/удаляются.
Мониторинг _пока_ вне этого процесса — просто раз в несколько часов запрашиваю список хостовз Б по api… Это даёт много боли — icinga может упасть, если на хосте стоял даунтайм, а его внезапно удалили.
В следующей версии этот баг пофиксят, а работа по API решит все проблемы сразу.
По поводу хостов/сервисов из БД — у меня такая специфика — куча хостов в digitaocean и vcale
Я написал 2 скрипта для каждого провайдера, которые берут список хостов и генерируют конфиг в /etc/icinga2/conf.d/${provider}.conf
а потом ребутают мониторинг.
Это не очень правильное решение, но для меня оно работает.
если бы я делал это сейчас с нуля — я бы тоже самое сделал через API icinga.
Про сервисы — кажется там всё просто — на основе переменных у хоста — применяем сервисы.
В общем, опиши в личку специфику — глядишь что и посоветую.
Я хотел сказать, что с одной стороны — icinga — очень быстрый мониторинг — именно за счёт отсутствия лишних функций.
С другой стороны — как только эти самые «лишние» функции вам становятся нужны — вы должны их сами.
В иных решениях некоторые aggerated/manager-специфичные вещи идут из коробки.
Это то, на что я хотел обратить внимание.
Быстрая, очень гибкая, но…
графики идут, как приблуда сверху. То есть, вы не получите аналитики, не узнаете отклонений от «обычного» поведения. Мне это не нужно(вернее, у меня нет на это ресурсов) — потому ок.
icinga2 активно разрабатывается — есть высокий риск получить падение программы в неожиданной ситуации.
Впрочем, при должном внимании — это легко решаемо, а при расследовании еще и становится понятно — «как не надо делать».
Важный минус — в веб-интерфейсе нет отчёта по SLA.
Через sql, конечно, можно всё, но кому-то будет минусом.
резюмируя: если бы сейчас я выбирал бы мониторинг — я бы несколько раз подумал в сторону более менеджероориентированных решений.
мимоходом посматриваю на influxdb/opentsdb.
С другой стороны, я не уверен, что они удержат 1500к проверок минуту на одном процессорном ядре.
Icinga скрипит, но держит.
Правда, пару недель назад я не успел оптимизировать часть проверок и потому теперь у меня 2 ядра на исингу))
Лучше бы расписали — в каких случаях какая утилита поможет, имхо, ес-но.
Нужен ли ssd для бекапов.
Хорошей чёрной пятницы, да.
Есть мнение — сфомирируй его из своего чата и выскажи.
Нахрена мне твой чат с кем-то?
Хочешь упомянуть коллегу по чату? символ @ тебе в помощь.
А вот можно реквестовать статью по настройке mysql/postgresql для ноды фиксированной памяти?
Давайте возьмём nginx+php-fpm+db_name.
Пускай размер php-fpm будет 20 и 80мб. Ну для «простых» фреймворков и «крутых». Просто два варианта рассмотрим.
Давайте рассмотрим инстансы для «маленьких» — 512, 1024, 2048, 4096.
Давайте примем за истину, что db_запросы занимают 70% времени работы php-скрипта.
Внмание вопрос — как правильно искать узкие места и оптимизировать их?
Это актуально как для mysql, так и для pg.
Апологеты mysql, так и pgsql — сделайте, пожалуйста.
Как читать explain — и куда смотреть на внутренние параметры БД.
Спасибо!
Раньше было выгоднее брать суперМтс+локальная симка гостевого региона.
Если интересует только интернет в городах — у Билайна лучшее предложение, но надо внимательно считать сколько трафика нужно.
Я как-то много командировался и вот мои заметки к вашей задаче:
1. Если вы сидите только в городах и летаете на самолётах — то на покрытие вам наплевать, а трафик в полёте не нужен. Тогда вы верно заметили — билайн интереснее. Вот только часто имеет смысл взять локальную сим-карту для звонков и интернета. Если это Европейская часть страны. В северных и дальневосточных регионах связь надо везти с собой.
2. Если же вы зачем-либо выезжаете из города или едете на машине — вам может быть интересен интернет вне города и тут уже имеет значение покрытие оператора. Как бы это ни было дорого, у мегафона оно лучшее. Остальные в погоне за лидером. Если мы за пределами европейской части страны — в части посёлков в принципе может быть покрытие только одного опсоса.
3. Если трафика нужно не так много — у каждого оператора есть опцию по типу СуперБит (сколько-то там трафика по всей стране) — это может оказаться выгоднее.
4. В этом году МТС очень сильно испортила тариф СуперМТС, фактически вынудив всех, кому надо выезжать за пределы домашнего региона переходить на линейку Смарт, которая гораздо дороже.
Сноуден настолько крут, что сделает Землю невидимой при помощи шифрования.
P.S> из текста ясно, что это не сноуден… но сама подача материала доставила.
Сильно тормозить будет?
1. У них есть режим работы с предустановкой tcp-соединений, что на канале с высоким RTT даёт выигрыш времени на установку соединения. При типичном RTT 700ms на установку обычного TCP-соединения нужно 2.1 секунды. Если мы заранее установим сессию — мы сэкономим это время.
2. Сжатие данных, в случае простого калькулятора — эффекта будет мало, а для работы среднего приложения по API с передачей данных json/xml выгоды будет существенно больше.