Да, память и подозреваю. Сейчас уже нет графиков (у меня эта машина мониторится только за сутки, надо бы свой мониторинг настроить), но память там точно кушалась (как и проц).
Я так понимаю, influx не очень умеет справляться с ситуацией, когда ему кидают одновременно десяток-два запросов, которые заставляют его бежать по данным на сутки назад. К сожалению, та же grafana устроена так, что она закидывает его отдельными запросами для каждого графика, хотя могло бы быть намного оптимальнее.
Использую influxdb в одном проекте, с удовольствием поделимся опытом и обсудим впечатления. Пока что influx радует почти всем, но есть пара моментов:
1. Все-таки весьма куцые возможности по обработке данных, выборкам, агрегатным функциям и т.п. Хотелось бы where в continuous queries, функций типа moving average, и/или какого-нибудь вообще встроенного скриптинга.
2. Он у нас уже несколько раз падал или зависал — при условии постоянной нагрузки на запись (средней интенсивности — порядка 200 записей в секунду, пачками) и пары тяжелых запросов на чтение поверх нее. Причем, без всякий слов в логах. У вас не случалось подобного?
Если сделать этот UUID равным, например, sha256( СНИЛС_пользователя + ID_инициативы_на_РОИ ) — то можно убить двух зайцев: с одной стороны, невозможно будет пересечь данные от разных голосований (защита персданных), с другой — пользователь сможет убедиться, что его голос учтен.
А если еще и сделать «цепочку подписей», чтобы на каждый голос кроме UUID публиковать еще и метку времени current_timestamp и контрольный хэш, равный sha256( UUID + current_timestamp + контрольный_хэш_предыдущего_голоса ) — то получим вообще прекрасную надежную систему.
Вот только добиться от РОИ, чтобы они это реализовали, ни у кого не получится.
Как в Badoo мониторят доступность для посетителей? Не секрет, что даже если на сервере все в порядке, клиенты могут быть недовольны из-за проблем с каналами. Мониторите ли вы время отклика (загрузки) сайта и какими методами?
И более практический вопрос — а как бы вы организовали мониторинг не одного сложного сервиса (Badoo), а множества простых сайтов (скажем, мониторить реальную доступность для постителей клиентских сайтов на хостинге). Если просто «пинговать» сайты из нескольких ДЦ — это не слишком отражает картину для пользователей.
После последнего автоматического обновления родной прошивки (на 14.4.A.0.108) Xperia Z1 Compact начал дико глючить. Постоянно пишет «приложение Контакты остановлено», «Процесс какой-то там core прекратил работу» и т.п. Пользоваться невозможно. Есть идеи, что с этим можно сделать?
Передача секретных значений в GET-параметрах опасна тем, что в живой системе куда больше вероятность «оседания» этих значений во всяких логах, дампах и т.п.
Правильно ли я понял, что клиенский софт обращается напрямую к ардуине с датчиком, на которой установлен веб-сервер?
Предвижу проблемы в такой архитектуре: нехватка производительности самой ардуины, узкий или нестабильный канал до датчика — могут привести к нестабильной работе сервиса.
Чтобы решить эти проблемы, предлагаю перейти на трехзвенную архитектуру:
1. датчик (или датчики) — та самая ардуина или прибитый гвоздем старый android, постит информацию на сервер
2. сервер — размещен в быстром стабильном дата-центре, хранит информацию со всех датчиков и отдает ее клиентам
3. клиенты (iOS, Mac OS и т.п.) — получают данные от сервера (и кстати, push неплохо было бы сделать)
Кроме повышения надежности, такая архитектура позволит развязать стандарт взаимодействия сервера с датчиком и сервера с клиентом. Таким образом, можно будет, не меняя софт на клиенте, подключать новые типы датчиков (например, работающие только по poll-режиму или использующие нестандартный канал типа sms).
У Mail.Ru Group есть более 3000 сотрудников, которых можно использовать в качестве бета-тестеров. Не у каждого стартапа в первые месяцы набирается столько пользователей ;-)
Здравствуйте. Давно это было, но постараюсь кратко ответить по существу.
Первое и самое главное — если вы еще не зарегистрировались на postmaster.mail.ru/ — сделайте это скорее. Там вы увидите очень ценную статистику для отправлений с ваших доменов.
Далее, отвечу на вопросы:
1. Уверен, что ни один почтовый сервис не позволяет (и не позволит) проверить рассылку «на спам» предварительно. Причина в том, что решение «спам/не спам» принимается не только на основе текста письма, но и на основе данных об объемах рассылки, и реакции пользователей на нее (что они делают с письмом, жалуются ли они на спам). Разумеется, поведение пользователей не предскажешь, поэтому предварительно можно проверить только частично.
2. Ошибоно предполагать, что решение по спаму принимается на основе IP-адресов. И тем более, что решение принимается по принципу черного и белого списков. Блокировка отдельного IP бывает, но в крайне злостных случаях (как правило, блокировка временная и продолжается несколько часов). А вообще каждое письмо рассматривается отдельно, и см. ответ на 1 вопрос.
3. Узнать о причине проблем можно несколькими способами. Во первых, как я уже сказал, postmaster.mail.ru/. Во вторых, код ошибки в SMTP-сессии — подробное их объяснение есть тут help.mail.ru/mail-help/postmaster/error. Наконец, в тексте SMTP-ошибки есть http-ссылка, по которой можно отправить обращение в службу поддержки, и они разберутся и ответят.
Простите, это кому он «должен идти первым»? По какому закону гугл должен ставить конкретный сайт на первое место? А если он завтра алгоритм поменяет и другой сайт окажется первым? Насколько я знаю, алгоритмы поиска пока (к счастью!) не регулируются законодательством ЕС или какой-либо другой страны.
Между регулированием и лобби очень тонкая грань. Оправдать или обругать можно любое решение — но в жизни эта грань часто окзывается еще тоньше, чем кажется.
Однако, в романе Риарден не продавал свой металл врагам (хотя это не означает, что кто-то не сделал из этого металла оружие). И в жизни Google не пособничает преступникам (хотя это не значит, что преступники не используют Гугл).
Вы определитесь, пожалуйста, с чем вы спорите: что ситуация не похожа на роман? По моему, очень похожа — ровно про то же самое. Или с тем, что написано в самом романе? Тогда спорить надо явно не со мной (хотя вы, вроде, симпатизируете роману). Или вы считаете, что в романе монополисты «хорошие», а в реальной жизни «плохие»? Ну, извините…
Георгий, вот именно про это Айн Рэнд и пишет в «Атланте». Идея этого романа в том, что есть люди, которые просто хорошо делают свое дело. И от этого миру в целом становится лучше. А есть люди, которые пытаются их «зарегулировать».
Я так понимаю, influx не очень умеет справляться с ситуацией, когда ему кидают одновременно десяток-два запросов, которые заставляют его бежать по данным на сутки назад. К сожалению, та же grafana устроена так, что она закидывает его отдельными запросами для каждого графика, хотя могло бы быть намного оптимальнее.
1. Все-таки весьма куцые возможности по обработке данных, выборкам, агрегатным функциям и т.п. Хотелось бы where в continuous queries, функций типа moving average, и/или какого-нибудь вообще встроенного скриптинга.
2. Он у нас уже несколько раз падал или зависал — при условии постоянной нагрузки на запись (средней интенсивности — порядка 200 записей в секунду, пачками) и пары тяжелых запросов на чтение поверх нее. Причем, без всякий слов в логах. У вас не случалось подобного?
А если еще и сделать «цепочку подписей», чтобы на каждый голос кроме UUID публиковать еще и метку времени current_timestamp и контрольный хэш, равный sha256( UUID + current_timestamp + контрольный_хэш_предыдущего_голоса ) — то получим вообще прекрасную надежную систему.
Вот только добиться от РОИ, чтобы они это реализовали, ни у кого не получится.
И более практический вопрос — а как бы вы организовали мониторинг не одного сложного сервиса (Badoo), а множества простых сайтов (скажем, мониторить реальную доступность для постителей клиентских сайтов на хостинге). Если просто «пинговать» сайты из нескольких ДЦ — это не слишком отражает картину для пользователей.
Предвижу проблемы в такой архитектуре: нехватка производительности самой ардуины, узкий или нестабильный канал до датчика — могут привести к нестабильной работе сервиса.
Чтобы решить эти проблемы, предлагаю перейти на трехзвенную архитектуру:
1. датчик (или датчики) — та самая ардуина или прибитый гвоздем старый android, постит информацию на сервер
2. сервер — размещен в быстром стабильном дата-центре, хранит информацию со всех датчиков и отдает ее клиентам
3. клиенты (iOS, Mac OS и т.п.) — получают данные от сервера (и кстати, push неплохо было бы сделать)
Кроме повышения надежности, такая архитектура позволит развязать стандарт взаимодействия сервера с датчиком и сервера с клиентом. Таким образом, можно будет, не меняя софт на клиенте, подключать новые типы датчиков (например, работающие только по poll-режиму или использующие нестандартный канал типа sms).
Первое и самое главное — если вы еще не зарегистрировались на postmaster.mail.ru/ — сделайте это скорее. Там вы увидите очень ценную статистику для отправлений с ваших доменов.
Далее, отвечу на вопросы:
1. Уверен, что ни один почтовый сервис не позволяет (и не позволит) проверить рассылку «на спам» предварительно. Причина в том, что решение «спам/не спам» принимается не только на основе текста письма, но и на основе данных об объемах рассылки, и реакции пользователей на нее (что они делают с письмом, жалуются ли они на спам). Разумеется, поведение пользователей не предскажешь, поэтому предварительно можно проверить только частично.
2. Ошибоно предполагать, что решение по спаму принимается на основе IP-адресов. И тем более, что решение принимается по принципу черного и белого списков. Блокировка отдельного IP бывает, но в крайне злостных случаях (как правило, блокировка временная и продолжается несколько часов). А вообще каждое письмо рассматривается отдельно, и см. ответ на 1 вопрос.
3. Узнать о причине проблем можно несколькими способами. Во первых, как я уже сказал, postmaster.mail.ru/. Во вторых, код ошибки в SMTP-сессии — подробное их объяснение есть тут help.mail.ru/mail-help/postmaster/error. Наконец, в тексте SMTP-ошибки есть http-ссылка, по которой можно отправить обращение в службу поддержки, и они разберутся и ответят.
Кроме того, рекомендую прочитать три раздела рекомендаций для отправителей: help.mail.ru/mail-help/rules/info
А что там с NFC — есть? На офсайте упомянут, но как-то странно, а в обзорах почему-то никто про него не вспоминает.
Вы определитесь, пожалуйста, с чем вы спорите: что ситуация не похожа на роман? По моему, очень похожа — ровно про то же самое. Или с тем, что написано в самом романе? Тогда спорить надо явно не со мной (хотя вы, вроде, симпатизируете роману). Или вы считаете, что в романе монополисты «хорошие», а в реальной жизни «плохие»? Ну, извините…