Что значит мониторить страницу
Значение слова «мониторить»
монито́рить
1. выполнять мониторинг — систематическое наблюдение за какими-либо процессами, данными ◆ Мы мониторим весь берег на глубину сто миль. У нас тут ни рыба не проплывёт, ни птица не пролетит без разрешения по месту жительства! Василий Аксёнов, «Негатив положительного героя», 1996 г. (цитата из НКРЯ)
Делаем Карту слов лучше вместе
Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!
Спасибо! Я стал чуточку лучше понимать мир эмоций.
Вопрос: дотация — это что-то нейтральное, положительное или отрицательное?
Синонимы к слову «мониторить»
Предложения со словом «мониторить»
Понятия, связанные со словом «мониторить»
Отправить комментарий
Дополнительно
Предложения со словом «мониторить»
Организация обязана постоянно мониторить основные факторы окружающей среды и отмечать своевременные и правильные выводы для собственного предприятия, относительно потребностей в данных изменениях.
Поэтому, привлекая для ведения аккаунта маркетинговое агентство, желательно в то же время назначить сотрудника, который будет мониторить вопросы клиентов и оперативно отвечать на них.
Вам следует регулярно мониторить конкурентов, работать над ещё большим уменьшением цены, либо переходить в другую ценовую нишу.
Как мониторить соцсети и оставаться в курсе всех важных событий
Мы уже говорили о том, что сегодня недостаточно быть первым, кто сообщит о новости. Важнее быть первым, кто создаст добавленную стоимость: сопроводит новость фотографиями, видео, свидетельствами и мнениями очевидцев или участников, придаст материалу сюжетность и наглядность.
При оперативной работе с новостями ведущую роль играют инструменты мониторинга новостного поля и социальных сетей. Самые первые сообщения о событии или его развитии поступают именно из социальных сетей. Из Twitter и Facebook вы узнаете на десятки минут раньше то, о чем напишут ведущие информационные агентства.
Илья Яшин был первым, кто сообщил об убийстве Бориса Немцова в социальной сети. Самые ранние сообщения СМИ публиковались со ссылкой на эту запись в Twitter.
Несмотря на то, что информация из соцсетей нуждается в обязательной проверке и может содержать ложную или ошибочную информацию, в подавляющем большинстве случаев она работает в пользу журналиста и ссылается на полезные источники, о существовании которых вы даже не догадывались.
Соцсети позволяют не только узнавать новости раньше других, но и следить за жизнью публичных людей и знаменитостей, освещать информационные поводы с их участием. Зачастую, они сами публикуют контент, который является одновременно и поводом к написанию новости, и комментарием к ней. Необходимость дозваниваться до знаменитости, чтобы получить короткий комментарий, постепенно отпадает. Верифицированные аккаунты в соцсетях решают эту проблему.
По заявкам подписчиков, которых теперь 400 000. Спасибо!
«По заявкам подписчиков, которых теперь 400 000. Спасибо!»
Подписавшись на аккаунты публичных персон, вы будете оперативно получать информацию из первых рук.
Все понятно, что теперь делать?
Для эффективного мониторинга вам необходимо сформировать пул источников, соответствующих профилю вашего издания. Аккаунт в Twitter или Facebook сегодня есть у всех СМИ, подавляющего большинства журналистов, министерств и ведомств, знаменитостей и публичных политиков, различных групп по интересам. Использовать эти возможности — обязанность современного журналиста.
Вы можете использовать свои личные аккаунты или создавать аккаунты для редакционного использования — это вопрос удобства. В первую очередь, рекомендуется сформировать и постоянно расширять пул источников в Twitter, а также следить за тем, как и с кем ваши источники взаимодействуют (кому отвечают, кого ретвитят) — это позволит получать еще больше оперативной информации и всегда оставаться на одной волне с лидерами новостного поля.
Twitter — в некотором смысле надстройка над соцсетями, так как зачастую содержит ссылки на посты в других соцсетях и сервисах (автоматический репостинг), показывает фото и видео, в то же время не отвлекая журналиста на прочтение длинных текстов. Это идеальный сервис для мониторинга, и он предлагает действительно удобный инструмент для выполнения этой задачи — TweetDeck.
Здесь вы можете следить за всей активностью вашей ленты: кто что сообщил, кто кому ответил, кого занес в избранное, кого зафолловил. Инструмент создания коллекции позволяет сохранять необходимые для работы твиты в одном месте. Также вы можете отслеживать развитие трендов, отмеченных хэштегами, или узнать какие тренды сегодня актуальны в разных регионах мира. Разумеется, вы можете разбить вашу ленту на тематические листы и отслеживать каждый в отдельности.
Другой полезный инструмент при работе с Twitter — это twXplorer от Knight Lab. Он позволит вам увидеть связанные с вашим запросом хэштеги и ссылки, тем самым расширяя поисковые возможности.
Мониторинг новостного поля в Facebook — тривиальная задача. Вам достаточно зафолловить людей или поставить like группам, которые поставляют полезную информацию. Теперь вы можете откинуться на спинку кресла и наслаждаться — вы уже в теме. Если вы хотите эффективно пользоваться поиском по Facebook, вам следует собрать широкий пул источников: в поисковой выдаче этой соцсети доступен контент ваших друзей и друзей ваших друзей.
Если вы работаете в сфере, связанной со знаменитостями, вам необходимо также отслеживать Instagram. Публичные персоны с удовольствием сами публикуют кадры, которые становятся информационными поводами. Веб-версия Instagram или многочисленные сервисы, позволяющие просматривать ленту (Websta.me, Iconosquare и т.п.) вполне подойдут для мониторинга на рабочем месте. Средства поиска по Instagram, включая геолокационные возможности, мы уже описывали в материале “Инструкция по поиску мультимедийного контента”.
Наконец, вам совсем не повредит следить за активностью СМИ, которые активно работают с соцсетями (например, TJournal), и сервисами, которые отслеживают тренды в соцсетях (например, Mediametrics). Они помогут следить за повесткой дня и добавят вам в копилку полезных источников.
Результаты мониторинга полезных источников не заставят себя ждать. Взгляните, как работает группа мультимедийного контента Новостей Mail.Ru:
Не забывайте проверять информацию, полученную из соцсетей. Если аккаунт вызывает подозрения, посмотрите когда он был создан. Возможно, всего час назад.
Если фотография с места события вызывает сомнения, воспользуйтесь Google Images — возможно она уже была использована ранее и не имеет отношения к описываемому событию.
Отсматривайте видео придирчиво, обращайте внимание на детали — время года, местность, дорожные указатели, номерные знаки автомобилей — все что угодно может выдать фейк.
Идя на поводу у других СМИ, что-либо опубликовавших, вы не защищаете себя от ошибки.
Больше о медиа, форматах, подаче и распространении контента, инструментах и аналитике — в нашей группе на Facebook.
Мониторинг сайта: просто, но эффективно
На тему мониторинга приложения уже написано немало литературы. Одно время я работал консультантом по программному обеспечению на предприятии, где под нашим бдительным оком находилось буквально все. Недавно я переключился на стартап, не практикующий подобную систему диагностики, за исключением ряда проверок работоспособности после каждого развертывания. При этом число его активных пользователей каждый месяц увеличивается более чем на 100 тысяч, и вот только сейчас они задумались о мониторинге.
Итак, что же предпринять? Следует ли постоянно отслеживать работу инструментов мониторинга или вообще перестать этим заниматься? Что следует мониторить, и как поддерживать интерес и вовлеченность команды?
Понятие мониторинга
Мониторинг — это процесс тестирования и контроля за тем, чтобы взаимодействие конечных пользователей с сайтом или приложением осуществлялось должным образом.
Из этого следует, что в случае отклонения от установленного порядка соответствующие инструменты должны об этом предупреждать. Мониторинг существует в самых разных видах и формах:
Все нацелено на то, чтобы убедиться в доступности сайта для пользователей и минимизировать время простоя, направив силы разработчиков на обнаружение проблемы.
Если вам ранее доводилось настраивать систему мониторинга, то вы знаете, как непросто поддерживать активное внимание и заинтересованность команды в канале Slack, в котором предупреждения об ошибках приходят каждые 30 минут. При этом не всегда есть возможность отфильтровывать только самые важные из них.
Например, возьмем исключения. Иногда требуется, чтобы способ их генерации позволял получать информацию об определенном участке кода. А иногда мы задействуем библиотеки, которые выбрасывают исключения, не подлежащие контролю. Стоит ли использовать инструмент, фильтрующий эти исключения перед отправкой их в Teams или Slack? Может подойдет приложение Azure со сложной логикой, которую понимает лишь один член команды? А если оно даст сбой? Нужен ли дополнительный контроль за работоспособностью мониторинга?
Вас все глубже затягивает “кроличья нора”, и вот вы не успеваете опомниться — как вдруг перед вами 5 разных панелей мониторинга со всевозможными статистиками, которые никто из команды уже не воспринимает всерьез. И как узнать, сказалось ли все это на рабочем состоянии приложения?
Как же решить проблему?
Обозначим ряд наиважнейших аспектов системы мониторинга.
На этих китах должна основываться система мониторинга сайтов/приложений. Приоритетное внимание уделяется пользовательским потокам, и система оповещения сразу же срабатывает при каком-либо воздействии на них. Если в канале Slack будут появляться только самые важные предупреждения, то каждый будет заинтересован в быстром устранении проблемы.
1. Настройка тестов UI, запускаемых согласно графику
Как убедиться в отсутствии воздействия на пользователя? Путем имитации их поведения.
И это осуществимо при условии объединения тестов API и UI. Данные тесты управляются нами или размещаются на онлайн платформе SAAS, которая по умолчанию подключается к инструментам CI и каналами связи.
Написание тестов UI
Здесь есть свои недостатки и достоинства. Суть первых в том, что создание тестов UI требует знаний программирования и определенной инфраструктурной работы. Достоинство же заключается в том, что благодаря их гибкости в нашем распоряжении оказываются преимущества многих библиотек.
У нас есть возможность использовать такие расширения, как Headless Recorder, для записи сеанса браузера и генерации кода, позволяющего быстро создавать новые потоки и не беспокоиться о технических нюансах и издержках, связанных с настройкой пользовательских селекторов.
Хотя библиотек существует немало, мы рассмотрим две из них, поскольку они напрямую поддерживаются Headless Recorder.
Puppeteer — это библиотека Node.js, разработанная командой Chrome DevTools. Она упрощает тестирование, поскольку общается с браузером посредством DevTools protocol. Эта способность позволяет перехватывать сетевые запросы, необходимые для выявления исходной причины происходящих сбоев. Затем, применяя такую библиотеку, как Jest, можно приступать к тестированию конкретных потоков.
Удостоверьтесь, что https://google.com сопровождается заголовком “Google”.
Playwright — библиотека Node.js, разработанная Microsoft. Ее API аналогичен Puppeteer, так что оба отлично подходят для написания тестов UI. Хотите быстро начать программировать пользовательские потоки, воспользуйтесь Jest Playwright.
Убедитесь, что вы работаете в Chrome.
Осмысленно подходите к распределению тестов по группам, чтобы все разработчики понимали, куда добавлять новые и где искать уже существующие тесты.
Инструменты SAAS
Еще одна возможность заключается в применении инструментов SAAS. Мое внимание привлекли три из них, на которых и предлагаю остановиться. На самом деле их гораздо больше, и методом проб можно выбрать наиболее подходящий для вашей ситуации. Все они позволяют планировать запуски тестов и оповещать команду о неполадках.
Настольное приложение Mabl позволяет всей команде создавать тесты, записывая надлежащее поведение и добавляя по ходу “утверждения” (без знания программирования). Оно предоставляет возможность тестирования веб-сайта на нескольких устройствах и включает множество отличных функциональностей, подчеркивающих пользу данного инструмента.
Однако получить полную информацию о ценах вы сможете только через торгового представителя.
Katalon — один из конкурентов Mabl, но в каком-то смысле они очень похожи. Он также работает как настольное приложение и обеспечивает интеграцию со многими инструментами CI и каналами связи.
При этом в нем заявлено о возможности тестировать нативные приложения (Android/iOS) с помощью Appium. Однако у меня эта функция не заработала, к тому же, судя по недостаточной активности сообщества, я не был уверен, что проблему удастся решить легко.
Katalon выгодно отличается от Mabl тем, что предоставляет полный контроль над селекторами на странице. Вы можете перезаписывать их для элементов, на которые кликаете во время записи сеанса, используя так называемый Web Object Spy.
Checkly отличается от обоих ранее рассмотренных инструментов. Это исключительно онлайн-платформа. Для записи потока на сайте применяется расширение Headless Recorder. Оно генерирует скрипт, который затем вставляется в Checkly, что позволяет повторно запустить поток, вызвав его с помощью вебхука или GitHub.
Мне импонирует простота Checkly, и по этой причине для работы я выбрал именно его. Стоит отметить, что наличие у приложения многочисленных потоков может повлиять на увеличение стоимости предоставляемых услуг.
Все представленные ранее инструменты и библиотеки позволяют быстро создать целую библиотеку тестовых потоков, выполняемых по одному клику на кнопку. Кроме того, не обладая знаниями программирования, вы легко можете добавлять новые тесты.
Планирование выполнения
Как только вы написали весь набор тестов, нужно прикинуть, сколько раз в день вы намерены их запускать, например каждые 5 минут или каждые полчаса. Все зависит от стоимости и важности тестов. Вам и вашей команде придется сделать выбор ради достижения оптимальных результатов и подстраховки.
Для планирования запуска наборов тестов можно воспользоваться основными платформами CI, такими как Azure DevOps, GitLab, GitHub или CircleCI. Выбирая один из инструментов SAAS, вы получаете возможность планировать прогоны тестов внутри этих самых инструментов.
2. Настройка оповещений, отображающихся в наиболее часто используемом канале связи
Запустив тесты, убедимся, что мы гарантированно получим своевременное оповещение по факту сбоя. К счастью, другие разработчики уже позаботились о том, чтобы имеющиеся инструменты CI прекрасно интегрировались с каналами связи.
В случае с самописными тестами целесообразно использовать работающий по графику конвейер, который будет запускать их каждые x минут. Azure DevOps, GitHub и GitLab изначально предоставляют услугу оповещения. При обнаружении ошибки в тесте выполняющий его компонент сообщает о ней в канал Slack или Teams.
Работая с инструментами SAAS, вы сможете задействовать один из их коннекторов для полной уверенности в том, что ни одно из предупреждений не ускользнет из вашего внимания.
А самое примечательное состоит в том, что при применении этих тестов UI исключительно для оповещения команды мы будем уверены, что каждое поступающее предупреждение об ошибке чрезвычайно важно и требует к себе особого внимания. Если же добавить к ним другие оповещения, основанные на исключениях, то команда быстро начнет игнорировать канал, поскольку их исправление не требует оперативных действий.
3. Создание для команды обзоров об общем состоянии приложения
Итак, мы тестируем потоки, но следует ли из этого, что мы не должны быть в курсе всех остальных процессов, происходящих в приложении? Конечно же нет.
В настоящее время у нас в командах практикуется так называемый “еженедельный обзор”. Он включает два пункта: функциональные показатели (количество отправленных e-mail и уведомлений, число пользователей вошедших/зарегистрировавшихся в системе) и технические (уровни CPU на прошедшей недели или число сбоев приложения iOS)
Мы полагаемся на информацию, получаемую в Azures’ Application Insight, Firebase, Mandrill и Twilio. Обобщаем данные из этих источников, сравниваем их с показателями предыдущей недели и в итоге завладеваем намного более ценными сведениями, чем информационная панель, сохраняющая какой-то момент во времени.
Заключение
Мониторинг — задача не из простых. Мы должны быть уверены, что пользователи всегда могут получить доступ к сервису без особых проблем. В данной статье мы рассмотрели, как упрощенный мониторинг и имитация поведения пользователя помогают получить наиболее полную информацию о состоянии платформы.
В завершении отметим, что статья не охватывает все сценарии использования. Всегда старайтесь разобраться в работе приложения и следуйте принципу “чем проще, тем лучше”. Всем удачи!
Как просто наблюдать за состоянием сайта
Чтобы дистанционно следить за работоспособностью серверов, профессионалы используют специальные программные комплексы, вроде Zabbix или Icinga. Но, если вы начинающий владелец или администратор одного-двух веб-сайтов с небольшой нагрузкой, то нет нужды в больших системах мониторинга. Главный параметр — быстро ли сайт обслуживает пользователей. Поэтому следить за работой сайта можно с помощью простой программы, с любого компьютера, подключённого к интернету.
Давайте сейчас напишем такой скрипт — простейшего мониторинга доступности и скорости работы сайта. Эту программу можно запустить на домашнем компьютере, смартфоне и так далее. Программа имеет всего две функции:
Опишу скрипт для операционной системы типа «Линукс» и его использование на домашнем компьютере. По тем же принципам, такое можно сделать и на других платформах. А тем, кто лишь присматривается к возможностям Линукса, может быть интересен ещё один пример, каким простым и мощным средством являются его скрипты.
1. Организация прежде всего
Заведём отдельную папку для этой программы и создадим в ней 3 файла. Например, у меня это папка /home/me/Progs/iNet/monitor (здесь me — имя моего пользователя, Progs/iNet — моя папка для программ, связанных с интернетом, и monitor — название этой программы, от слова мониторить, то есть, наблюдать. Поскольку я единственный пользователь этого компьютера, то держу такие файлы среди личных папок (/home), в отдельном разделе диска, что позволяет сохранять их при переустановке системы). В этой папке будут файлы:
2. Настойчиво и расслабленно
Файл mon.sh мы будем запускать с регулярным небольшим интервалом, например, 60 секунд. Я использовал для этого стандартное средство, предоставляемое операционной системой (точнее, средой рабочего стола).
Моя среда Рабочего стола — Xfce. Это один из самых популярных вариантов для Линукса. Xfce нравится мне тем, что позволяет практически полностью настраивать всё окружение — именно так, как тебе удобно. При этом Xfce несколько компактнее и быстрее двух других известных систем — Gnome и KDE. (Интересны и другие варианты — например, среда LXDE ещё быстрее и легче, чем Xfce, но пока не так богата по возможностям).
Нужное нам средство, в случае Xfce — это плагин для рабочей панели «Монитор общего назначения» (Generic Monitor). Обычно он уже установлен, но, если нет, Установщик легко найдёт его: «Genmon» (описание: xfce4-genmon-plugin). Это плагин, который можно добавить на панель и задать ему в настройках: (1) выполняемую команду и (2) периодичность её выполнения в секундах. В моём случае, команда:
(или, что то же самое,
3. Когда программы ещё нет, ошибки уже есть
Вместо «example.ru» подставьте название вашего сайта, за состоянием которого вы будете наблюдать. И, если он работает по http, поставьте http вместо https. Строка #!/bin/bash означает, что это скрипт для запуска программой Баш (bash — наверное, самой распространённой для выполнения скриптов на Линуксе). Для работы посредством другого командного интерпретатора его указывают вместо Баша. Остальные строки с диезом в начале — комментарии. Первая собственно строка кода — info=$() и в этих скобках команда curl с параметрами. Такая конструкция — нечто=$(что-то) — означает «выполнить команду в скобках и присвоить результат переменной слева». В данном случае, я назвал переменную «info». Эта команда в скобках — curl (на жаргоне именуемая некоторыми «Курл») — посылает запрос в сети по заданному адресу и возвращает нам ответ сервера. (Мой знакомый сказал, объясняя: «Как журавлик курлыкает — и получает ответ от какого-то другого журавля в небе»). Рассмотрим параметры:
-I значит, что мы запрашиваем не всю страницу, а только её «заголовки HTTP». Нам не нужен каждый раз текст страницы целиком, чтобы убедиться в работоспособности сайта. Поскольку мы будем проверять сайт часто, важно сделать размер передаваемых данных как можно меньше. Это экономит и трафик, и электричество, и нагрузку на сервер — и на живую природу.
Кстати, обратите внимание, сколько у вас запасного трафика (не используется за месяц) на хостинге. Ниже увидите, какой объём данных передаётся и сможете посчитать, хватит ли вам запасов; если что, период проверки сайта можно увеличить до 5, 10, или даже 30-60 минут. Хотя в этом случае картина будет не такой полной — и мелкие перебои могут остаться незамеченными; но, в целом, при мониторинге сайта важнее обнаруживать длительные проблемы, чем однократные перебои. Также, какой трафик вы можете себе позволить на вызывающем компьютере? В моём случае — настольный ПК с безлимитным трафиком — это не так важно; но для мобильного устройства или тарифа с лимитами стоит посчитать и, возможно, увеличить интервалы проверки.
4. Шаг следует за шагом, кроме первого шага
Поехали дальше: -o /dev/stdout значит «ответ, полученный Курлом от сервера, направить в такой-то файл». И в данном случае это не файл на диске, а /dev/stdout — Стандартное устройство вывода. Обычно «Стандартное устройство вывода» — это наш экран, где мы можем видеть итоги работы программы. Но в скрипте мы часто направляем этот «стандартный вывод» на дальнейшую обработку (сейчас — сохраняем в переменную info). И дальше мы будем, чаще всего, либо направлять итоги команд в переменные, либо передавать их следующим командам по цепочке. Для создания цепочек из команд служит оператор pipe («Труба»), изображаемый как вертикальная черта («|»).
(И по этому параметру можно судить, достаточно ли сервер производительно работает для ваших задач, удобно ли пользователям его типичное время отклика. Не возникает ли проблем — например, мои сайты на многих хостингах с течением времени замедлялись, и приходилось искать другой хостинг).
Это количество секунд, которое заняло обращение к сайту, плюс наша метка. (Кроме этого параметра, в переменной info нас будет интересовать, главным образом, «Status code» — код состояния, или, по-простому, код ответа сервера. Обычно, когда сервер выдаёт запрошенный файл, код «200». Когда страница не найдена, это знаменитое 404. Когда на сервере ошибки, это, чаще всего, 500 с чем-то).
5. Творческий подход — отец самопроверки
Остальные параметры у нашего curl-а таковы:
что значит: запросить такой-то адрес; максимальное время ожидания ответа 9 секунд (можно ставить меньше, потому что редкий пользователь будет ждать ответа от сайта так долго, он быстрее сочтёт сайт не работающим). И «-s» означает silent, то есть, curl не будет сообщать нам лишних подробностей.
Для отладки мы можем запустить этот curl без обрамляющих скобочек и посмотреть, что он выдаст. (Из этого и рассчитать расход трафика). Мы увидим, в основном, набор заголовков HTTP, типа:
Первой строкой здесь мы видим «HTTP/1.1 302 Found» — что значит: используется протокол передачи данных «HTTP/1.1», код ответа сервера — «302 Found». При запросе другой страницы это может быть код «301 Moved Permanently» и т.п. В дальнейшем примере, нормальный ответ моего сервера — «HTTP/2 200». Если же ваш сервер в норме отвечает по-другому, подставьте этот его ответ вместо «HTTP/2 200» в этом скрипте.
Последней строкой, как мы видим, Курл выдаёт, за сколько секунд мы получили ответ сервера, с нашей приписанной меткой.
Интересно: мы можем так настроить сайт, чтобы он сообщал по этим нашим запросам (и только по ним!) дополнительную информацию о своём состоянии — например, в «самодельном» заголовке HTTP. Скажем, какова нагрузка на процессоры сайта, сколько у него свободной памяти и места на диске, быстро ли работает база данных. (Конечно, для этого сайт должен быть динамическим, то есть, запросы должны обрабатываться программой — на PHP, Node.JS или т.п. Ещё вариант — использовать на сервере специальные программное обеспечение). Но, возможно, эти подробности нам пока не очень нужны. Цель этого скрипта — просто регулярно следить за общей работоспособностью сайта. Во случае проблем — мы уже будем разбираться с диагностикой другими средствами. Поэтому сейчас мы пишем самый простой скрипт, который будет работать для любого сайта, даже статического, и без дополнительных настроек на сервере. В дальнейшем, при желании, можно будет расширить возможности скрипта; а пока сделаем основу.
6. Целесообразность
Здесь я хочу сделать небольшое отступление от технических материй, чтобы читать текст было интереснее. (Если не согласны, пропустите три абзаца). Скажу так, что всякая человеческая деятельность по-своему целесообразна. Даже когда человек намеренно бьётся лбом об стену (или об пол… об клавиатуру. ), в этом есть своя целесообразность. Например, он даёт выход эмоциональной энергии — может, не «лучшим» способом, но уж как умеет. (Да и само понятие «лучший» бессмысленно с точки зрения этого мгновения в этом месте — потому что лучшее и худшее возможно лишь по сравнению с чем-то ещё).
Я сейчас пишу этот текст, вместо, казалось бы, более важных для меня дел — почему? Во-первых, чтобы подвести итоги, пересмотреть и внутренне разложить по полочкам то, чему за эти два дня научился в написании скриптов… Вынести из оперативной памяти и уложить на хранение. Во-вторых, я таким способом немножко отдыхаю… В-третьих, надеюсь, что это разжёванное объяснение пригодится кому-то ещё (и мне самому, возможно, когда-нибудь). Как, не важно, лучшая ли, но внятная напоминалка по теме скриптов и запросов на сервер.
Кто-то, может, поправит меня в чём-то, и итог станет ещё лучше. Кто-то получит кусочек полезной информации. Целесообразно ли это? Пожалуй… это то, что я могу сейчас сделать и делаю. Завтра, может быть, я просплюсь и проведу переоценку нынешних действий… но и эта переоценка даст что-то небесполезное для дальнейшей жизни.
Итак, по выполнении запроса, у нас два кусочка данных:
Аналогично, в переменную date мы записываем строку, в которой сервер выдал его текущие дату и время. Это что-то вроде «date: Sun, 11 Feb 2019 08:06:57 GMT» (как правило, в часовом поясе GMT, он же UTC). Нам надо записывать дату (но лишь один раз в сутки!) в наш лог-файл («журнал состояния сервера») — server.log. А заодно выведем это время на экран. Можно было бы записать в лог дату-время и со своего компьютера, но для удобства возьмём эти, раз уж всё равно сервер их прислал.
Похоже и с нашей третьей переменной, dlay (от английского слова дилей — задержка). Выбираем по нашей нежной метке «эяю» строку, в которой сохранили длительность ожиданияния ответа от сервера. Удаляем эту метку, уже не нужную, с помощью команды sed — и сохраняем результат.
Теперь, если мы для проверки напечатаем эти переменные — например, добавив в наш скрипт строки:
должно получиться что-то вроде:
Итого: код ошибки curl-а — ноль (значит, отработал нормально). Код состояния сервера — не записан (так как был нормальным). Дата и время. Длительность ответа. Осталось правильно вывести, что нужно, на экран и, если нужно, записать в файл.
Это самое интересное: что, при каких условиях и как записывать?
7. Хитрые выводы
Чтобы не утомлять вас больше подробностями, расскажу кратко (а хороших справочников по всем этим командам в интернете достаточно). Кстати, краткость — одна из главных целей, которых мы будем добиваться при записи в этот лог. Тогда он будет и удобен для просмотра, и никогда не займёт много места на диске (в отличие от иных логов, что растут мегабайтами в день).
Первое: позаботимся о том, чтобы записывать дату в лог лишь по одному разу, а не в каждой строке. Для этого выделим из нашей переменной date по отдельности текущую дату (curr) и время (time):
А также считаем из лог-файла строки с датами и возьмём последнюю дату (prev):
Если наша текущая дата (curr) не равна предыдущей (из файла, prev) — то наступил новый день (или, скажем, файл логов был пуст); тогда пишем новую дату в файл:
… и заодно записываем текущую информацию: время, задержка получения ответа с сайта, код ответа сайта (если не обычный):
Это поможет ориентироваться: такой-то день начался с такой-то скорости работы сайта. В остальных случаях давайте не загромождать файл лишними записями. Безусловно, запишем, если получили необычный код состояния сервера:
А также пишем, если время ответа сервера больше обычного. У меня сайт отвечал обычно за 0.23-0.25 секунд, поэтому я фиксирую ответы, которые заняли дольше 0.3 секунд:
Наконец, раз в час я просто записываю время, полученное от сервера — как знак, что он жив, и заодно как своеобразную разметку файла:
Получаем такое содержание файла, где разметка ежечасными записями помогает визуально, не вчитываясь, видеть, когда нагрузка выше или ниже (больше число записей в час):
И, наконец, выводим информацию на экран. А также, если curl сработал с ошибкой, выводим и записываем сообщение об этом (и заодно запускаем Пинг и логируем — проверить, жив ли сервер вообще):
Замените адрес IP во строке ping-а на реальный адрес IP вашего сайта.
8. Послесловие
Слева на панельке видно время в UTC и текущая отзывчивость сайта. Справа — лог: видно слёту, даже при беглом прокручивании, в какие часы нагрузка была больше или меньше. Можно заметить и аномально медленные ответы (пики; хотя пока непонятно, откуда они берутся).
Вот и всё. Скрипт получился простой, дубовый, и его можно совершенствовать: работать над оптимизацией, переносимостью, улучшением оповещений и отображений, с учётом прокси и кеша…
Но уже в этом виде программы она, наверное, может дать представление о состоянии вашего сайта. И пусть это будет сайт мудро целесообразный, полезный для людей и всех существ!
PS. По итогам обсуждения (на 12.02.2019):
Как я и надеялся, знатоки написали много интересных комментариев.
Обдумав, могу ответить на вопрос rsashka, в чём преимущество этого скрипта.
Другие средства, вроде NetData (спасибо tchspprt за наводку!), дают большой массив данных, которые не будут долго храниться. NetData хорошее средство, когда ты каждый день работаешь, обслуживаешь сайты профессионально. Хорошо подходит для диагностики текущих проблем.
А скрипт вроде моего — это чтобы присматривать вполглаза, занимаясь другими делами. Скрипт не требует особого изучения и настроек. Это неплохо для непрофессионалов. А его логи занимают так мало места, что их можно вообще не стирать. Они могут накапливаться годами, и лет через N+1 можно будет посмотреть: «Ого, в 2019 году у меня время отклика было в полтора раза ниже. »
То есть, своя ниша у такого решения есть — в основном, для не занимающихся сисадминством постоянно. (Как говорит tchspprt: «Примерно как соседского кота покормить на время отпуска»).
andreymal посоветовал интересный способ учитывать и потом просматривать нагрузку сайта, без дополнительных средств, просто через логи доступа на сайте. И можно по ним строить красивые графики. Я, наверное, попробую этот вариант и выложу на Гитхабе, что получилось.
unnforgiven посоветовал ещё интересное решение — наверное, несложное (prometheus, blackbox и alermanager установить через docker composer). На моём простом, дешёвом VPS не хватит для этого памяти; и Linux со старым ядром — Докер не запустится. Но за вариант спасибо!
Ещё совет tchspprt: Graphite + Prometheus + Grafana. Или снабдить скрипт красивой графикой (gnuplot или rrdtool).
Mcalexvrn советует простое средство: uptimerobot. Спасибо!
Благодарю всех за такой массив информации! Пусть это пригодится людям…