По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Где и зачем? На сегодняшний день логирование информации в процессе разработки имеет огромное значение. Сохранение информации в лог-файлы это первоочередная задача для выявления неполадок и слабых мест в работе приложения. Однако, если приложение работает на основе многих сложных процессов здесь не обойтись без эффективного инструмента навигации и анализа по логам. В одной из предыдущих статей мы разбирали такое решение, как ELK Elasticsearch, Logstash, Kibana. В таком сочетании эти программы способны оперативно решать задачи по сбору, хранению, выборке и анализу информации даже в крупных проектах. Это и является их основным назначением. Однако, эти программы также можно использовать по отдельности, поскольку они являются самостоятельными программными продуктами. Как же можно использовать эти приложения в разных сочетаниях, и для чего это нужно? Приступим к разбору. Самым востребованным инструментом из этой тройки является Elasticsearch. Оно и понятно поисковая система, действующая на основе горизонтального масштабирования (то есть, с возможностью искать данные по запросу пользователя параллельно на множестве серверов) стала очень популярным решением для осуществления поиска не только в логах, но и во множестве данных. При этом данные не обязательно могут быть структурированы, и пользователь с высокой вероятностью получит четкие результаты по запрашиваемому фрагменту текста. При этом широкую популярность данному приложению обеспечивают также широкие возможности по интегрированию с другими программами, множество вариантов конфигурирования, а также подключаемые плагины, работа над которыми ведется как специалистами компании Elastic, так и "народными умельцами" Альтернативным вариантом использования Elasticsearch является вариант с созданием на основе этого приложения централизованных хранилищ данных, содержащих логи использования с разных устройств. Конечно, в этом случае потребуется визуализация, поэтому наилучшее взаимодействие с Elasticsearch обеспечивает Kibana. Данная связка является наиболее популярной и эффективной, поскольку обе программы разрабатывались специально с прицелом на взаимодействие. Несомненным плюсом ELK является модульная архитектура. Комбинируя различные модули, можно сконфигурировать систему для выполнения разнородных задач. Так, например, модуль Metricbeat, включенный в систему позволяет оптимально сконфигурировать систему для мониторинга инфраструктуры,решение Heartbeat позволяет осуществлять uptime-мониторинг. Направления Elastic SIEM и Elastic API также существенно расширяют функциональность ELK Помимо непосредственно разработчиков, комплекс ELK Stack также могут использовать и тестировщики. Конечно, если приложение занимает небольшой объем, то установка ELK вряд ли будет рациональным решением, но, если это будет серьезная объемная программа, тогда тестер сможет быстро выявить проблему и не тратить время разработчика на поиск и анализ. Такая схема работы достаточно популярна и эффективна в некоторых компаниях, разрабатывающих программное обеспечение. Также доступ к логам программы могут затребовать управленцы - менеджер, курирующий проект, или же представители заказчика. В данном случае анализ логов позволяет выявить, эффективно ли ведется работа над исправлением выявленных ранее неисправностей, и не появилось ли новых багов в процессе исправления старых. В последнее время развивается использование комплекса ELK в бизнес-процессах для обеспечения эффективного сбора информации, оперативного анализа и принятия решений. Как пример, можно привести огромный супермаркет со множеством касс. Как правило, для наличного расчета на начало рабочего дня в кассе должна быть определенная сумма наличных для выдачи сдачи. Так вот, комплекс ELK применяется для сбора данных о проведенных по кассе операциях, выборки из собранных данных информации об остатках наличных в разных кассах, и анализа информации, после которого специалист, работающий с программой, может принять решение, какая сумма наличных нужна для обеспечения нужд кассиров по выдаче сдачи. Непрерывный сбор и анализ информации позволяет оценить пики и спады, сравнить информацию с аналогичными показателями за вчерашний день, прошедшие неделю или месяц. По этой причине решение ELK приобретает все большую популярность как инструмент биржевой аналитики. Хотя на текущий момент есть инструменты и получше, однако динамика развития данного решения позволяет думать, что оно вряд ли перестанет быть актуальным и для подобных задач.
img
Давно прошли те времена, когда «база данных» представляла собой единую СУБД на основе реляционной модели данных, которую обычно устанавливали на самом мощном сервере в центре обработки данных. Такая база данных могла обслуживать все виду запросов – OLTP (On-Line Transaction Processing – обработка транзакций в режиме реального времени), OLAP (On-Line Analytical Processing – аналитическая обработка данных в режиме реального времени) – все, что нужно для бизнеса. В настоящее время базы данных работают на самом обычном оборудовании, они также стали более сложными с точки зрения высокой доступности и более специализированными для обработки определенного типа трафика. Специализация позволяет добиться гораздо большей производительности баз данных – все оптимизировано для работы с определенным типом данных: оптимизатор, механизм хранения, даже язык может быть не SQL, как это бывает обычно. Он может быть основан на SQL с некоторыми расширениями, которые позволяют более эффективно манипулировать данными, или может быть чем-то абсолютно новым, созданным с нуля. На сегодня мы имеем аналитические столбчатые базы данных, такие как ClickHouse или MariaDB AX, платформы обработки и анализа больших данных, такие как Hadoop, решения NoSQL, такие как MongoDB или Cassandra, хранилища данных типа «ключ-значение», такие как Redis. Мы также имеем базы данных временных рядов, такие как Prometheus или TimeScaleDB. Это именно то, на чем мы акцентируем внимание в данной статье. Базы данных временных рядов (Time Series Databases) – что это такое и зачем вам нужно еще одно хранилище данных в своей среде. Для чего нужны базы данных временных рядов? Как видно из названия, базы данных временных рядов предназначены для хранения данных, которые изменяются со временем. Это могут быть абсолютно любые данные, собранные с течением времени. Это могут быть метрические показатели, собранные из некоторых систем – все системы трендов являются примерами данных временных рядов. Каждый раз, когда вы смотрите на информационные панели в ClusterControl, на самом деле вы видите визуальное представление временных рядов, хранящихся в Prometheus – базе данных временных рядов. Временные ряды не ограничиваются метрическими показателями базы данных. Метриками может быть что угодно – изменение потока людей, входящих в торговый центр, с течением времени, изменение трафика в городе, использование общественного транспорта в течение дня, течение воды в реке или ручье, количество энергии, вырабатываемое водной установкой – все это и все остальное, что можно измерить во времени, является примером временных рядов. Такие данные можно запросить, построить, проанализировать, чтобы найти корреляционную зависимость между различными метриками. Структура данных в базе данных временных рядов Как вы понимаете, самая важная составляющая данных в базе данных временных рядов – это время. Существует два основных способа хранения данных. Первый способ чем-то похож на хранилище «ключ-значение» и выглядит так: Метка времени Метрика 1 2019-03-28 00:00:01 2356 2019-03-28 00:00:02 6874 2019-03-28 00:00:03 3245 2019-03-28 00:00:04 2340 Проще говоря, для каждой метки времени имеется некоторое значение метрики. Второй способ подразумевает хранения большего числа показателей. Вместо того, чтобы хранить каждую метрику в отдельной таблице или коллекции, их можно хранить вместе. Метка времени Метрика 1 Метрика 2 Метрика 3 Метрика 4 Метрика 5 2019-03-28 00:00:01 765 873 124 98 0 2019-03-28 00:00:02 5876 765 872 7864 634 2019-03-28 00:00:03 234 7679 98 65 34 2019-03-28 00:00:04 345 3 598 0 7345 Такая структура данных, когда все метрики связаны, позволяет более эффективно запрашивать данные. Вместо того, чтобы читать несколько таблиц и объединять их для получения всех метрик, достаточно прочитать лишь одну единственную таблицу, чтобы подготовить данные к обработке и представлению. У вас может возникнуть вопрос – что же здесь нового? Чем эта база данных отличается от обычной таблицы в MySQL или в любой другой реляционной базе данных? Да, действительно, конструкция таблиц очень похожа. Однако есть существенные различия в рабочей нагрузке, которые могут существенно повысить производительность, если хранилище данных предназначено для использования такого рода таблиц, Временные ряды, как правило, только растут. Маловероятно, что вы будете обновлять старые данные. Чаще всего строки в таблице не удаляются, однако вам может понадобиться какая-то агрегация данных с течением времени. Если принять это при проектировании внутреннего устройства базы данных, то этот факт будет иметь существенное расхождение в сравнении со «стандартными» реляционными (и не реляционными) базами данных, предназначенными для обработки транзакций в режиме реального времени. Что здесь является наиболее важным, так это способность последовательно хранить большие объемы данных, поступающих со временем. Можно, конечно, использовать РСУБД для хранения временных рядов, но она не оптимизирована для этого. Данные и индексы, сгенерированные на ее основе, могут стать слишком большими, и запросы будут проходить очень медленно. Механизмы хранения данных, используемые в СУБД, предназначены для хранения различных типов данных. Обычно они оптимизированы для рабочей нагрузки обработки транзакций в режиме реального времени, которая включает в себя частое изменение и удаление данных. В реляционных базах данных также часто отсутствуют специализированные функции и функции, предназначенные для обработки временных рядов. Мы уже упоминали, что вы вероятно столкнетесь с необходимостью агрегировать данные, полученные ранее какой-то временной метки. Вы также можете иметь возможность легко запускать некоторые статистические функции для ваших временных рядов, чтобы сглаживать их, определять и сравнивать тренды, интерполировать данные и многое другое. Здесь, например, вы можете найти некоторые функции, которые Prometheus предоставляет пользователям. Примеры баз данных временных рядов На рынке существует множество баз данных временных рядов, поэтому, естественно, что рассмотреть все мы не сможем. Но мы все же хотели привести несколько примеров баз данных временных рядов, которые, возможно, вам уже знакомы или которые вы уже, возможно, используете (сознательно или нет). InfluxDB InfluxDB была разработана компанией InfluxData. Это база данных временных рядов с открытым исходным кодом, написанная языке программирования Go. Хранилище данных позволяет вводить запросы данных на языке, подобном SQL, что позволяет разработчикам легко интегрировать эту базу данных в свои приложения. InfluxDB также может работать как часть коммерческого решения, которое охватывает весь стек, предназначенный для обеспечения процесса обработки данных временных рядов, полнофункциональной высоко доступной средой. Prometheus Prometheus – это еще один проект с отрытым исходным кодом, который также написан на языке программирования Go. Он обычно используется в качестве серверной части для различных инструментов и проектов с открытым исходным кодом, например, Percona Monitoring and Management. Prometheus также является наилучшим вариантом для ClusterControl. Prometheus можно развернуть из ClusterControl с целью хранения данных временных рядов, собранных на серверах баз данных, контролируемых и управляемых ClusterControl: Prometheus широко используется в мире Open Source, поэтому его довольно легко интегрировать в уже существующую среду с помощью нескольких экспортеров. RRDtool Это один из примеров базы данных временных рядов, которую многие используют, даже не подозревая об этом. RRDtool – это достаточно популярный проект с открытым исходным кодом для хранения и визуализации временных рядов. Если вы хоть раз использовали Cacti, то и RRDtool вы тоже использовали. Если вы разработали свое собственное решение, вполне вероятно, что и здесь вы тоже использовали RRDtool в качестве серверной части для хранения данных. Сейчас RRDtool, возможно, не так популярен, как это было в 2000-2010 годах. В те годы это был самый распространенный способ хранения временных рядов. Забавный факт – ранние версии ClusterControl использовали именно RRDtool. TimeScale TineScale – это база данных временных рядов, разработанная на основе PostgreSQL. Это расширение для PostgreSQL, которое использует основное хранилище данных для предоставления доступа к ним, что означает, что оно поддерживает все разновидности SQL, доступные для использования. Поскольку это расширение, то оно использует все функции и расширения PostgreSQL. Вы можете совмещать временные ряды с другими типами данных, например, объединять временные ряды с метаданными, пополняя информацией выходные данные. Вы также можете выполнить более сложную фильтрацию, используя JOIN и таблицы без временных рядов. Геоинформационное обеспечение в PostgreSQL TimeScale можно использовать для отслеживания географических местоположений с течением времени, а также использовать все возможности масштабирования, предлагаемые PostgreSQL, включая репликацию. Timestream Amazon Web Services также предлагает базы данных временных рядов. О Timestream было объявлено совсем недавно, в ноябре 2018 года. Она добавляет еще одно хранилище данных в портфель AWS, помогая пользователям обрабатывать временные ряды, поступающие из таких источников, как устройства Интернет вещей или отслеживаемые сервисы. Его также можно использовать для хранения метрических данных, полученных из журналов, созданных несколькими службами. Это позволяет пользователям выполнять аналитические запросы к ним, помогая понять закономерности и условия, в которых работают службы. Tiemstream, как и большинство сервисов AWS, обеспечивает простой способ масштабирования в случае, если с течением времени возрастает потребность в хранении и анализе данных. Как видите, вариантов баз данных временных рядов на рынке множество, и это не удивительно. В последнее время, все более популярным становится анализ временных рядов, поскольку он становится все более важных для различных бизнес-операций. К счастью, есть большое количество проектов как с открытым кодом, так и коммерческих. И с большой долей вероятности вы сможете найти инструмент, который полностью удовлетворит ваши потребности.
img
Windows 10 предлагает встроенный инструмент сетевого анализатора PktMon.exe для мониторинга внутреннего распространения пакетов и отчетов о сбрасывании пакетов. Этот инструмент может помочь вам исследовать сеть и помочь устранить причину задержки в сети, выявить уязвимые приложения и, при использовании с дополнительным набором инструментов, может предоставить представление о главных показателях. В то время как пользователи Linux всегда имели инструмент tcpdump для отслеживания сети, пользователям Windows приходилось устанавливать сторонние программы, такие как Microsoft Network Monitor и Wireshark. Сетевой анализатор пакетов pktmon.exe в Windows 10 PktMon или Packet Monitor - это новый сетевой анализатор (сниффер) или средство диагностики сети и мониторинга пакетов. Он находится в папке System (C:Windowssystem32pktmon.exe.), что означает, что вы можете вызвать его из командной строки, при помощи утилиты Run или PowerShell. Как запустить Packet Monitor в Windows 10? Для запуска Packet Monitor сначала необходимо открыть окно командной строки. Нажмите Ctrl + R, чтобы открыть Run и введите cmd, затем нажмите Enter или нажмите кнопку OK. В командной строке введите pktmon.exe и нажмите Enter. Что может PktMon? Если вы запустите справку PktMon, введя в командной строке pktmon help, вот что вы получите: filter: управление фильтрами пакетов comp: управление зарегистрированными компонентами reset: сброс счетчиков до нуля start: начать мониторинг пакетов stop: остановить мониторинг format: преобразовать файл логов в текст unload: выгрузить драйвер PktMon. И если вам нужна дополнительная помощь по конкретной команде, вы можете запустить справку для этой команды. Вот как это выглядит: pktmon filter help pktmon filter { list | add | remove } [OPTIONS | help] Commands list Display active packet filters. add Add a filter to control which packets are reported. remove Removes all filters. Как использовать PktMon для мониторинга сетевого трафика Рассмотрим как использовать PktMon. В этом примере предполагается, что вы хотите отслеживать порт на компьютере, который часто имеет проблемы. Для этого необходимо: Создать фильтр для мониторинга порта Начать мониторинг Экспортировать логи в читаемый формат Создание фильтра Основная опция, которая позволяет вам отслеживать трафик - это filter. Используя эту опцию, вы можете создать фильтр, чтобы контролировать, какие пакеты будут под наблюдением, на основе кадра Ethernet, заголовка IP, заголовка TCP и инкапсуляции. Если вы запустите нижеупомянутую команду, вы получите полную информацию о том, что вы можете сделать с фильтром. pktmon filter add help Итак, возвращаясь к нашей теме, давайте предположим, что нам нужен порт TCP 1088. Это может быть порт, используемый вашим пользовательским приложением, который начал сбоить. Откройте командную строку или PowerShell с правами администратора и создайте фильтр пакетов с помощью команды: pktmon filter add -p [port] pktmon filter add -p 1088 Чтообы удалить все фильтры, выполните команду pktmon filter remove Начать мониторинг Поскольку это не автоматическая программа, работающая в фоновом режиме, а работающая по требованию, вам нужно запустить мониторинг вручную. Запустите следующую команду, чтобы начать мониторинг пакетов: pktmon start --etw - p 0 Она запустит мониторинг и создаст файл с логами в указанном месте. Вам нужно будет вручную останавливать мониторинг, используя аргумент stop, чтобы остановить ведение лога, или это само закончится, когда компьютер выключится. Если вы запустите команду с -p 0, то она будет захватывать только 128 байтов пакета. После выполнения pktmon записывает все пакеты на ВСЕХ сетевых интерфейсах устройства. Чтобы захватывать весь пакет и только с определенного устройства Ethernet, вы можете использовать аргументы -p 0 (захват всего пакета) и -c 13 (захват только с адаптера с идентификатором 13). Чтобы определить ID вашего адаптера, вы можете запустить команду pktmon comp list Log filename: C:Windowssystem32PktMon.etl Logging mode: Circular Maximum file size: 512 MB Экспорт лога в читаемый формат Файл журнала сохраняется в файле PktMon.ETL, который можно преобразовать в удобочитаемый формат с помощью следующей команды: pktmon format PktMon.etl -o port-monitor-1088.txt Таким образом мы на выходе получаем .txt файл с логами, который можно открыть в блокноте. Однако чтобы извлечь выгоду из полученных данных, стоит скачать и установить Microsoft Network Monitor и использовать его для просмотра файла ETL. Используя Network Monitor, вы можете увидеть полный пакет, который был отправлен, включая любую текстовую информацию. Мониторинг в реальном времени Вы можете включить мониторинг в реальном времени, используя аргумент -l real-time. Это приведет к тому, что захваченные пакеты будут отображаться непосредственно на экране, а также сохраняться в файле ETL. Microsoft также добавила возможность конвертировать файлы ETL в формат PCAPNG, чтобы их можно было использовать в таких программах, как Wireshark. pktmon pcapng help После преобразования файла в формат PCAPNG их можно открыть в Wireshark.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59