Я продолжаю свой рассказ о том, как подружить Exchange и ELK (начало тут). Напомню, что эта комбинация способна без колебаний обрабатывать очень большое количество логов. На это раз мы поговорим о том, как наладить работу Exchange с компонентами Logstash и Kibana.

Перевод статьи подготовлен в преддверии старта курса «Нереляционные базы данных».

---

Основные моменты:

• Крайне важно разработать схему несмотря на то, что в MongoDB она необязательна.
• Аналогично, индексы должны соответствовать вашей схеме и шаблонами доступа.
• Избегайте использования больших объектов и больших массивов.
• Будьте осторожны с настройками MongoDB, особенно если речь идет о безопасности и надежности.
• В MongoDB нет оптимизатора запросов, поэтому вы должны быть осторожны при выполнении операций запроса.

Я очень давно работаю с базами данных, но только недавно открыл для себя MongoDB. Есть несколько вещей, которые я хотел бы знать перед началом работы с ней. Когда у человека уже есть опыт в определенной сфере, у него существуют предвзятые представления о том, что такое базы данных и что они делают. В надежде облегчить задачу понимания другим людям, представляю список распространенных ошибок.

Redis (Remote Dictionary Server) - заслужено считается старичком в мире NoSql решений. Этот пост про то, как Spring Data с ним работает. Идея написания данного поста возникла потому, что Redis не совсем похож на привычную базу, он поддерживает типы данных, которые не удобно использовать для хранения объектов(Кеш не в счет) и выполнять поиск по определенным полям. Здесь на примерах я постараюсь описать как с ним работает Spring Data посредством привычного CrudRepository и QueryDSL. Это не пример HowTo, которых множество. Кому интересны внутренности идем дальше.

Начинаю серию статей, где хочу поделиться своим опытом подключения Exchange и ELK. Этот стэк поможет обрабатывать большие объемы логов и не задаваться вопросом, при каком размере привычные инструменты логирования откажутся нам помогать. Давайте знакомиться с новым бойцом с логами.

Часть 1. Начало

1.1 Введение и постановка задачи

В компании МТС мы централизованно занимаемся контролем качества сетей передачи данных или, проще – транспортной сети (не путать с логистической транспортной сетью), далее по тексту – ТС. И, в рамках нашей деятельности, нам постоянно приходиться решать две основные задачи:

1. Обнаружена деградация клиентских (по отношению к ТС) сервисов – нужно определить путь их проключения через ТС, и выяснить, является ли причиной деградации сервисов какой-либо участок ТС. Далее, будем называть это Прямой задачей.
2. Обнаружена деградация качества транспортного канала или последовательности каналов – нужно определить, какие сервисы зависят от данного канала/каналов, чтобы определить влияние. Далее, будем называть это Обратной задачей.

Под сервисами ТС понимается любое проключение клиентского оборудования. Это могут базовые станции (БС), В2В клиенты (использующие ТС МТС для организации доступа в сеть Интернет и/или наложенных сетей VPN), клиенты фиксированного доступа (т.н. ШПД), и т.д. и т.п.

В нашем распоряжении – две централизованные информационные системы:

Любая транспортная сеть по своей сути является ориентированным графом $$, в котором каждое ребро $$ имеет неотрицательную пропускную способность. Потому с самого начала поиск решения указанных задач выполнялся в рамках теории графов.

Сначала вопрос сопоставления показателей качества ТС и сервисов – с топологией ТС решался путем буквального объединения и представления данных топологии и качества в виде сетевого графа.

ELK SIEM Open Distro: Введение. Развертывание инфраструктуры и технологий для SOC как Service (SOCasS)

За последние пару лет количество кибератак зашкаливает. Эти атаки нацелены не только на отдельных людей, но и на фирмы, правительства, критическую инфраструктуру и т. д. Традиционные решения, такие как антивирус, брандмауэр, NIDS и NIPS, больше не являются достаточными из-за сложности атак и их подавляющего количества.

Эта серия статей были задуманы как построение аналога SIEM на полном опенсорсе. Подробности будут представлены в следующих статьях.

В этой статье мы завершим настройку компонентов системы Riak Cloud Storage.

Данная статья это завершение серии вольных переводов официального руководства по системе Riak CS 2.1.1

Часть 1. Настройка Riak KV
Часть 2. Настройка компонента Riak CS

В этой статье мы продолжим настройку отдельных компонентов системы Riak Cloud Storage, а именно компонента Riak CS.


Данная статья это продолжение вольных переводов официального руководства по системе Riak CS 2.1.1

Часть 1. Настройка Riak KV
Часть 3. Stanchion, Proxy и балансировка нагрузки, клиент S3

С целью обеспечить корректную работу компонента Riak CS важно знать как подключаться к Riak KV. Узел Riak CS обычно запускается на том же сервере, что и соответствующий ему узел Riak KV. Это означает, что изменения будут необходимы только в том случае, если Riak настроен с использованием параметров, отличных от настроек по умолчанию.

Riak CS (Cloud Storage) – лёгкое в использовании программное обеспечение для организации хранилища объектов, работающее поверх Riak KV. Riak (KV) это распределённая NoSQL база данных типа «ключ-значение(key-value)». Riak CS спроектирована так, чтобы обеспечить простоту, доступность, распределённость облачного хранилища любого масштаба, и может использоваться для построения облачных архитектур — как публичных, так и частных — или как инфраструктурного хранилища для высоко нагруженных приложений и сервисов. Riak CS API совместим с Amazon S3 и поддерживает возможность получения отчётов по различным ситуациям.


Данная статья это вольный перевод официального руководства по системе Riak CS версии 2.1.1

В системе хранения Riak CS, три компонента работают совместно друг с другом, что означает обязательную настройку каждого компонента для работы с другими компонентами:

• Riak (KV) – система баз данных, которая действует как конечная система.
• Riak CS — слой облачного хранилища поверх Riak, которая предоставляет хранение и возможности API, хранит файлы и метаданные в Riak, и передаёт их затем конечным пользователям.
• Stanchion — управляет запросами с участием глобально уникальных сущностей, такими как бакеты и пользователями в экземпляре Riak. Например, создание пользователей, создание или удаление бакетов.

Дополнительно вы так же можете настроить S3 клиент для использовании в обмене сообщениями с Riak CS системой.

В предыдущей статье был краткий обзор промышленного интернета вещей I-IoT и описание платформы граничных вычислений. В этой статье я хочу показать простой пример релизации Edge I-IoT платформы, используя популярные открытые технологии.

Redis — достаточно популярный инструмент, который из коробки поддерживает большое количество различных типов данных и методов работы с ними. Во многих проектах он используется в качестве кэшируещего слоя, но его возможности намного шире. Мы в ManyChat очень любим Redis и активно используем его в нашем продукте для решения огромного количества задач. Про некоторые интересные кейсы использования этой in-memory key-value базы данных я расскажу на примерах. Надеюсь, вам они будут полезны, и вы сможете применить что-то в своих проектах.

Рассмотрим следующие кейсы:

• Кэширование данных (да, банально и скучно, но это классный инструмент для кэширования и обойти стороной этот кейс, кажется будет не правильно)
• Работа с очередями на базе redis
• Организация блокировок (mutex)
• Делаем систему rate-limit
• Pubsub — делаем рассылки сообщений на клиенты

Буду работать с сырыми redis командами, чтобы не завязываться на какую-либо конкретную библиотеку, предоставляющую обертку над этими командами. Код буду писать на PHP с использованием ext-redis, но он здесь для наглядности, использовать представленные подходы можно в связке с любым другим языком программирования.

Заключительный перевод разделов Redis Best Practices с официального сайта «Redis Labs». Самое необычное и интересное сегодня под катом!

Elastic Stack — известный инструмент на рынке SIEM-систем (вообще-то, не только их). Может собирать в себя много разнокалиберных данных, как чувствительных, так и не очень. Не совсем правильно, если доступ к самим элементам Elastic Stack не будет защищён. По умолчанию все коробочные элементы Elastic (Elasticsearch, Logstash, Kibana и коллекторы Beats) работают по открытым протоколам. А в самой Kibana отключена аутентификация. Все эти взаимодействия можно обезопасить и в этой статье мы расскажем как это сделать. Для удобства разделили повествование на 3 смысловых блока:

• Ролевая модель доступа к данным
• Безопасность данных внутри кластера Elasticsearch
• Безопасность данных вне кластера Elasticsearch

Подробности под катом.

Осенью 2019 года в iOS команде Облака Mail.ru произошло долгожданное событие. Основной базой данных для персистентного хранения состояния приложения стала весьма экзотическая для мобильного мира Lightning Memory-Mapped Database (LMDB). Под катом вашему вниманию предлагается её подробный обзор в четырех частях. Сначала поговорим о причинах столь нетривиального и трудного выбора. Затем перейдем к рассмотрению трёх китов в основе архитектуры LMDB: отображённые в память файлы, B+-дерево, copy-on-write подход для реализации транзакционности и мультиверсионности. Наконец, на сладкое — практическая часть. В ней рассмотрим, как поверх низкоуровневого key-value API спроектировать и реализовать схему базы с несколькими таблицами, включая индексную.​

SQL, что может быть проще? Каждый из нас может написать простенький запрос — набираем select, перечисляем необходимые колонки, затем from, имя таблицы, немного условий в where и все — полезные данные у нас в кармане, причем (почти) независимо от того какая СУБД в это время находится под капотом (а может и не СУБД вовсе). В результате работу практически с любым источником данных (реляционным и не очень) можно рассматривать с точки зрения обычного кода (со всеми вытекающими — version control, code review, статический анализ, автотесты и вот это все). И это касается не только самих данных, схем и миграций, а вообще всей жизнедеятельности хранилища. В этой статье поговорим о повседневных задачах и проблемах работы с различными БД под прицелом "database as code".

И начнем прямо с ORM. Первые батлы вида "SQL vs ORM" были замечены еще в допетровской Руси.

Введение

«Нужно бежать со всех ног, чтобы только оставаться на месте,
а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!»
(с) Алиса в стране чудес

Некоторое время назад меня попросили прочитать лекцию аналитикам нашей компании на тему проектирования моделей данных, ведь сидя долгое время на проектах (порою по нескольку лет) мы упускаем из виду происходящее вокруг в мире ИТ-технологий. В нашей компании (уж так получилось) на многих проектах не используются NoSQL-базы данных (по крайней мере пока), поэтому в своей лекции я отдельно уделил им некоторое внимание на примере HBase и постарался ориентировать изложение материала на тех, кто с ними никогда не работал. В частности, я иллюстрировал некоторые особенности проектирования модели данных на примере, который несколько лет назад прочитал в статье «Introduction to HB ase Schema Design» by Amandeep Khurana. Разбирая примеры, я сравнивал между собой несколько вариантов решения одной и той же задачи, чтобы лучше донести до слушателей основные идеи.

Недавно, «от нечего делать», я задался вопросом (длинные майские выходные в режиме карантина к этому особенно располагают), насколько теоретические выкладки будут соответствовать практике? Собственно, так и родилась идея этой статьи. Разработчик, который не первый день работает с NoSQL, возможно и не почерпнет из нее что-то новое (и поэтому может сразу промотать полстатьи). Но для аналитиков, которые еще не работали плотно с NoSQL, полагаю, она будет полезна для получения базовых представлений об особенностях проектирования моделей данных для HBase.

Фреймворк Spring Integration умеет отдавать текущее состояние всех EIP-компонентов и их связей в виде JSON-графа. Это кажется очень удобным для изучения и отладки, но увы, ни один из нагугливаемых инструментов (коих всего-то раз /два) не даёт достаточной гибкости для визуализации и анализа такого графа. В этой статье я покажу, как решить эту проблему путем импорта графа в графовую СУБД Neo4j, где такая гибкость стоит на первом месте.

Я продолжаю цикл статей о языке программирования MSH. В одной из предыдущих статей я уже описывал спецификацию этого языка. Но спецификация не раскрывает всех особенностей языка. Тот пробел я и хочу устранить этой статьей. Не все конечно удалось описать, но в основном главные особенности вроде описал. Остальное отложим до лучших времен.

Когда только складывается образ языка, кажется что все логично и непротиворечиво. Но входе реализации языка возникают проблемы, которые приходится решать выбирая ту или иную стратегию. Сейчас когда интерпретатор языка готов, можно увидеть каким образом решал те или иные проблемы реализации.

Продолжаю публикацию решений отправленных на дорешивание машин с площадки HackTheBox.

В данной статье эксплуатируем NoSQL инъекцию в форме авторизации, а также повышаем привилегии через JJS.

Подключение к лаборатории осуществляется через VPN. Рекомендуется не подключаться с рабочего компьютера или с хоста, где имеются важные для вас данные, так как Вы попадаете в частную сеть с людьми, которые что-то да умеют в области ИБ :)

SnappyDB — NoSQL key-value база данных для Android. Она довольно проста в использовании и является неплохим вариантом, если вы хотите использовать NoSQL вариант базы данных в своём проекте (подробнее тут).
По заявлениям разработчиков, в операциях записи и чтения Snappy превосходит по скорости SQLite: