Ох, спасибо за nginx-sla и nginx-statsd!
По поводу nginx-sla еще надо покопаться, а statsd у нас уже активно используется, и теперь я имею шансы выкинуть костыли в виде скриптов на sh, которые считают статусы ответов по логам nginx, и отдают их в zabbix. Теперь можно просто все отправлять в statsd, а механизм statsd -> zabbix у нас уже работает.
Ну и красивые графики в graphite, конечно, лишними не будут.
Мы используем немного другую схему, но, в целом, суть та же — TTL на записи 5 минут, в случае падения одного ДЦ запись меняется.
Через пять минут после переключения я на своем haproxy вижу 0, редко-редко когда появится 1-2.
Вывод: подавляющее большинство провайдеров TTL обрабатывают правильно.
У меня обратный опыт, поддержка именно GAfB прекрасна, реагируют быстро, консультируют, решают проблемы, иногда даже перезванивают.
(«Мне звонил гугль!»)
А FibreChannel до сих пор стоит эпических денег, несколько килобаксов за 16-портовый коммутатор.
Я так подозреваю, что там все завязано на патенты и лицензирование, и поэтому вход на этот рынок очень дорог. Уже имеющиеся игроки рынка работают только на enterprise-сегмент.
Я давно в этот рынок не заглядывал, может, уже появились какие-то SMB-решения на FC? Или SMB достаточно iSCSI?
гугл-почта является частью коммерческого google apps for business, который на данный момент должен приносить уже ощутимую сумму денег.
а уговорить бизнес-пользователей отказаться от стандартной концепции почты и перейти на какой-то там бабл — это им вряд ли удастся.
Одно дело — возможность пользоваться с мобильных (в мобильном браузере? неудобно же!), другое — интеграция с внешними сервисами.
Существует немало сервисов, которые используют Google Reader как бекенд. Одни по сути просто являются интерфейсом к гугльридеру (Reeder, например), другие имеют кучу своих источников подписок, и гугльридер — один из кучи (Flipboard, например).
То есть гугльридер был этаким единым стандартом для многих сервисов.
После закрытия google reader они остаются без бекенда. Reeder, судя по всему, сделает свой, Flipboard — просто выключит поддержку гугльридера, и немного потеряет.
Интегрироваться с self-hosted решением или с яндексом они явно не будут.
параллельный вопрос: существует ли кто-то из «опытных пользователей», или айтишников, кто использует тулбары в браузерах, например? добровольно? хоть какие-нибудь?
предполагаю, что команду-то послали одну, но выполнялась она 66 секунд. копирование десятков гигабайт данных с одних дисков на другие занимает ненулевое время, даже если оно происходит внутри массива.
logstash в первую очередь прекрасен grok'ом, во вторую — логикой доставки распарсенных данных.
а в третью — большим количеством вариантов, куда можно полученные данные отправить. хочешь — в statsd, хочешь — в graylog2, а хочешь — в файл пиши.
у нас сложился немного отличающийся от автора подход использования logstash: мы им логи парсим, цифры вытаскиваем, но в какое-то централизованное хранилище пока не складываем.
в основном мы вытаскиваем метрики приложений и демонов с последующим выводом в statsd, который, в свою очередь, отправляет метрики в graphite для построения красивых графиков и в zabbix для алертов в случае выхода метрик за определенные пределы.
по сути получилась удобная замена наколенным скриптикам, которыми до этого парсились логи на предмет вытаскивания в мониторинг нужных цифр.
пока что вся эта конструкция в статусе, так сказать, опытного внедрения.
по архитектуре сделал вывод, что на небольших нагрузках можно вешать logstash с фильтром прямо на ноду с приложением, а там, где логов генерится много и/или и без того нехватка ресурсов — проще фигачить в связку «log -> rsyslog (udp) на logserver -> logstash+grok» или даже «log -> rsyslog (udp) -> logstash-shipper -> redis -> logstash+grok».
elastic для хранения логов пока не используем — хотя, в теории, это должно избавить от необходимости хранения гигабайтов логов на каждой машинке. впрочем, эта задача может прекрасно решаться средствами попроще.
«Я могу выдать борщ прямо сейчас, но буду уверена в нем только на 30 процентов, что не очень то хорошо. Для того чтобы получить борщ, в котором я буду уверена больше, выдайте мне, пожалуйста, информацию о банковской карте, по которой я смогу приобрести все необходимые ингридиенты.»
Использую исключительно как шлюз в скайп-чатики с андроида.
Pros: куда меньше оригинального скайп-клиента кушает батарейку и может не висеть иконкой в верхней панели.
Cons: очень криво работает со скайповскими групчатами и подгрузкой скайповой истории.
We furthermore just allow access to the «s3c-fimc» memory block as this is seemingly the only space which upon access denial actually breaks functionality.
То есть дырка — не просто случайно забытые слишком широкие разрешения на файл, а разрешения, использующиеся родными же приложениями. Это успех, да.
заманчиво.
По поводу nginx-sla еще надо покопаться, а statsd у нас уже активно используется, и теперь я имею шансы выкинуть костыли в виде скриптов на sh, которые считают статусы ответов по логам nginx, и отдают их в zabbix. Теперь можно просто все отправлять в statsd, а механизм statsd -> zabbix у нас уже работает.
Ну и красивые графики в graphite, конечно, лишними не будут.
Через пять минут после переключения я на своем haproxy вижу 0, редко-редко когда появится 1-2.
Вывод: подавляющее большинство провайдеров TTL обрабатывают правильно.
(«Мне звонил гугль!»)
Я так подозреваю, что там все завязано на патенты и лицензирование, и поэтому вход на этот рынок очень дорог. Уже имеющиеся игроки рынка работают только на enterprise-сегмент.
Я давно в этот рынок не заглядывал, может, уже появились какие-то SMB-решения на FC? Или SMB достаточно iSCSI?
а уговорить бизнес-пользователей отказаться от стандартной концепции почты и перейти на какой-то там бабл — это им вряд ли удастся.
Существует немало сервисов, которые используют Google Reader как бекенд. Одни по сути просто являются интерфейсом к гугльридеру (Reeder, например), другие имеют кучу своих источников подписок, и гугльридер — один из кучи (Flipboard, например).
То есть гугльридер был этаким единым стандартом для многих сервисов.
После закрытия google reader они остаются без бекенда. Reeder, судя по всему, сделает свой, Flipboard — просто выключит поддержку гугльридера, и немного потеряет.
Интегрироваться с self-hosted решением или с яндексом они явно не будут.
Грядет суровый передел этой ниши. :)
Интересное решение.
а в третью — большим количеством вариантов, куда можно полученные данные отправить. хочешь — в statsd, хочешь — в graylog2, а хочешь — в файл пиши.
у нас сложился немного отличающийся от автора подход использования logstash: мы им логи парсим, цифры вытаскиваем, но в какое-то централизованное хранилище пока не складываем.
в основном мы вытаскиваем метрики приложений и демонов с последующим выводом в statsd, который, в свою очередь, отправляет метрики в graphite для построения красивых графиков и в zabbix для алертов в случае выхода метрик за определенные пределы.
по сути получилась удобная замена наколенным скриптикам, которыми до этого парсились логи на предмет вытаскивания в мониторинг нужных цифр.
пока что вся эта конструкция в статусе, так сказать, опытного внедрения.
по архитектуре сделал вывод, что на небольших нагрузках можно вешать logstash с фильтром прямо на ноду с приложением, а там, где логов генерится много и/или и без того нехватка ресурсов — проще фигачить в связку «log -> rsyslog (udp) на logserver -> logstash+grok» или даже «log -> rsyslog (udp) -> logstash-shipper -> redis -> logstash+grok».
elastic для хранения логов пока не используем — хотя, в теории, это должно избавить от необходимости хранения гигабайтов логов на каждой машинке. впрочем, эта задача может прекрасно решаться средствами попроще.
Pros: куда меньше оригинального скайп-клиента кушает батарейку и может не висеть иконкой в верхней панели.
Cons: очень криво работает со скайповскими групчатами и подгрузкой скайповой истории.
интересно, удастся ли им в многопользовательском режиме повторить ту экономическую «песочницу», что сейчас есть в EVE Online.
Ну явно ж HP SuperDome на картинке. Железка не новая уже, они его, скорее всего, на утилизацию потащили. :)
То есть дырка — не просто случайно забытые слишком широкие разрешения на файл, а разрешения, использующиеся родными же приложениями. Это успех, да.
там патчик-то должен быть в полторы строки, как мне кажется.