Как посмотреть историю серверов в дискорде
Как загрузить и посмотреть историю канала и сообщений в Discord?
Ищите способ загрузки копии всего группового канала Discord, чтобы посмотреть историю сообщений? Узнаем подробно, как это сделать в различных форматах, включая в легко открываемых HTML и текстовых файлах.
Если уже используете Discord, скорее всего, присоединились к нескольким группам и участвовали в бесчисленных разговорах. Большинство из них, возможно, не стоит просматривать и создавать резервные копии. Однако, если также используете Discord для более значимых диалогов, и история не просто усеяна одноразовыми переписками об игровом контенте, есть вероятность, что захотите загрузить и посмотреть эти стенограммы.
Поскольку Discord официально не предлагает способа загрузки / экспорта записи чатов или истории сообщений, нужно использовать сторонние инструменты. Можете скептически относится к тому, как работают эти решения, но есть один исключительный способ, который делает загрузку истории сообщений Discord достаточно простым.
Как получить запись чатов канала и сообщений из Discord?
Чтобы начать загрузку (экспорт) чата из канала и истории сообщений, перейдите на страницу GitHub и скачайте Discord Chat Exporter. Для этого сделайте запрос в интернете по имени этого приложения и после отображения результатов поиска перейдите на сайт, указанный на рисунке.
Перейдите на вкладку Releases и загрузите последнюю версию DiscordChatExporter.
Приложению будет загружено в zip-архиве. Распакуйте его в выбранное место и запустите файл DiscordChatExporter.exe. Теперь следуйте указанной инструкции.
Откройте Discord и войдите в свою учетную запись. Затем нажмите Ctrl + Shift + I, чтобы открыть меню разработчика (Developer Options). Нажмите на вкладку Application в верхней части страницы. Возможно, придется развернуть опцию с помощью стрелки, если она скрыта.
Выберите опцию Local Storage — https://discordapp.com на левой панели. Теперь нажмите Ctrl + R, чтобы обновить страницу. Это позволит отобразить опцию токена, которая не видна при первом доступе к расположению.
Если пытаетесь найти токен и он невидим, обновите страницу и щелкните на кнопку стоп, когда появится код токена. Это заблокирует код, позволяя его скопировать.
Теперь просто скопируйте и вставьте этот код в верхнюю часть DiscordChatExporter без кавычек, нажмите стрелку, и вся информация Discord будет загружена.
Чтобы скачать историю, все, что нужно сделать, это выбрать группу Discord, из которой хотите экспортировать чат или сообщения, затем укажите канал в средней панели.
Как только щелкните на канал, увидите окно с параметрами экспорта. Настройте их в соответствии со своими предпочтениями. Выберите Browse, чтобы указать место для загрузки файла, затем Export для извлечения данных.
Удобным форматом для экспорта истории сообщений является HTML. Поскольку его можно легко посмотреть в текстовом формате, аналогичном исходному макету Discord. Включает в себя значки пользователей, смайлики, эмодзи и ссылки.
Как узнать, на каких серверах Discord кто-то находится
Discord существует уже шесть лет, и с новыми обновлениями он становится все лучше и лучше. Платформа особенно популярна среди геймеров. Учитывая, что к Discord можно получить доступ на вашем мобильном телефоне, ПК и некоторых консолях. Вы даже можете организовывать групповые аудио- и видеозвонки, создавать свои серверы и даже делиться экраном и транслировать прямой эфир со своего компьютера своим друзьям. Есть много серверов и сообществ, к которым вы можете присоединиться в Discord. Теперь, если у вас много друзей, вы можете узнать, на каких серверах они находятся, чтобы вы тоже могли присоединиться к ним. Здесь вы узнаете, как узнать, на каких серверах Discord находится кто-то.
Серверы и сообщества Discord доступны на платформе в большом количестве. Вы можете присоединиться к тем, которые предназначены для геймеров, программного обеспечения, приложений и даже для ваших знаменитостей в социальных сетях. Зачем вам знать, на каких серверах находятся ваши друзья? Хорошо. возможно, они находятся на сервере, который может вас заинтересовать и который в конечном итоге тоже захочет присоединиться к нему. Кроме того, как говорится, вы знакомитесь с новыми людьми в играх онлайн, вы также можете заводить и знакомиться с новыми друзьями на серверах в Discord. Итак, давайте посмотрим, сможете ли вы посмотреть, на каких серверах Discord находятся ваши друзья.
Можете ли вы увидеть, на каких серверах Discord находятся ваши друзья?
Итак, большой вопрос здесь в том, можете ли вы увидеть, к каким серверам присоединились ваши друзья? Что ж, ответ — нет. Единственные серверы, которые вы сможете увидеть, — это общие. Те, на которых находитесь вы и другой человек. Из соображений конфиденциальности Discord не позволяет вам видеть, на каких других серверах находятся ваши друзья или другие люди, кроме общих. Выполните следующие действия, чтобы узнать, на каких общих серверах вы, другие люди или ваши друзья находитесь.
Проверьте Mutual Servers в Discord на ПК
Проверьте совместные серверы в Discord на Android и iOS
Вот как вы можете узнать общие серверы Discord между вами и другими людьми или друзьями. Из соображений конфиденциальности Discord не показывает вам, на каких других серверах, не являющихся взаимными или частными, находится другой человек.
Лучшее, что вы можете сделать для этого, — это, вероятно, спросить их, на каких серверах они находятся, или просто присоединиться к различным серверам в Discord, на которых, по вашему мнению, находится этот человек. Однако это пустая трата времени, и этого не следует делать. Просто спросите их, и если они достаточно удобны, чтобы поделиться, то это хорошо.
Журнал аудита
Журнал аудита (англ. Audit Logs) — журнал действий пользователей на сервере.
Описание
Хм, вы никогда не задумывались, кто создал новый канал на вашем сервере, или кто забанил недоброжелательного участника? Не бойтесь, журнал аудита здесь, чтобы донести вам о всём, что произошло на сервере. С него никак нельзя удалить какую-либо запись
Где он находится?
Итак, журнал аудита вы можете здесь. Для начала зайдите в настройки сервера а уже там есть вкладка с надписью «Журнал аудита».
Примечание. Вы можете просматривать журналы аудита только в том случае, если у вас есть права на просмотр журналов аудита или права администратора После того, как вы нажали вкладку «Журнал аудита», вы увидите что-то похожее на это:
Всякий раз, когда пользователь выполняет действие, оно регистрируется в журнале аудита на срок до 90 дней и запись не может быть удалена или отредактирована. Следующие действия регистрируются в журнале аудита:
Получение деталей
Для многих из этих действий дополнительные сведения можно получить, развернув вкладку действия. И, если вы пытаетесь найти конкретное действие или действие, выполненное конкретным пользователем, не бойтесь! Discord дает возможность фильтровать результаты, полученные обоими этими вариантами! Найти его можно сверху самого журнала
Открытие и очистка журнала аудита в Discord
Пользователи редко когда задумывались о том, кто занимался созданием канала на интересующем сервере в программном обеспечении Discord. Чтобы узнать интересующую информацию, разработчиками было разработано журнал аудита в Дискорде. Что характерно, удалить журнал аудита в Дискорде и записанные данные невозможно.
Что такое журнал аудита
Каждый раз, когда пользователи совершают действия в программном обеспечении, они сохраняются в специально разработанном журнале аудита. Обратите внимание, срок хранения составляет 3 месяца, по истечении которого осуществляется автоматическое стирание. В программном обеспечении автоматически регистрируются сведения относительно:
Обратите внимание, чтобы получить исчерпывающую информацию из журнала аудита, пользователям требуется развернуть специально разработанную вкладку действий. Преимуществом специально разработанной функции считается наличие дополнительной опции фильтрации результатов поиска, интересующих отчетов. Чтобы воспользоваться журналом, достаточно перейти в одноименный раздел программного обеспечения.
Как найти и открыть
Чтобы открыть журнал аудита в Дискорде, пользователям требуется придерживаться определенной последовательности действий:
Обратите внимание: зарегистрированные клиенты в программном обеспечении могут просматривать сформированные журналы аудита исключительно в случае, когда администратор предоставил права доступа. В противном случае функция недоступна по умолчанию. Об этом нужно помнить, чтобы избежать попадания в неприятную ситуацию с вытекающими негативными последствиями.
Как очистить журнал аудита в Дискорде
Изначально пользователям требуется знать, что очистить журнал аудита Дискорд невозможно согласно разработанным правилам программного обеспечения. Однако предусматривается стирание истории переписки с интересующим собеседником. Последовательность действий несложная и подразумевает под собой:
Обратите внимание, последовательность действий не вызывает сложностей и занимает 5 минут свободного времени.
Дискорд – специально разработанное программное обеспечение, которое предназначено для организации непрерывного общения. Зарегистрированные пользователи могут обмениваться текстовыми сообщениями и совершать аудио и видеозвонки.
Многочисленные отзывы пользователей указывают на понятный интерфейс, который исключает вероятность допущения ошибок с вытекающими негативными последствиями. Пользователи, которые приняли решение стать клиентами мессенджеры, должны завести личный кабинет, указав адрес электронной почты, уникальный логин и ключ доступа. При наличии дополнительных вопросов, всегда можно обратиться за помощью к специалистам службы поддержки, которые оказывают посильную помощь в круглосуточном режиме. Заявки обрабатываются в круглосуточном режиме, без выходных и праздничных дней.
Как Discord хранит миллиарды сообщений
Discord продолжает расти быстрее, чем мы ожидали, как и пользовательский контент. Чем больше пользователей — тем больше сообщений в чате. В июле мы объявили о 40 млн сообщений в день, в декабре объявили о 100 млн, а в середине января преодолели 120 млн. Мы сразу решили хранить историю чатов вечно, так что пользователи могут вернуться в любой момент и получить доступ к своим данным с любого устройства. Это много данных, поток и объём которых нарастает, и все они должны быть доступными. Как мы это делаем? Cassandra!
Что мы делали
Изначальную версию Discord написали быстрее чем за два месяца в начале 2015 года. Возможно, одной из лучших СУБД для быстрого выполнения итераций является MongoDB. Всё в Discord специально хранилось в едином реплисете (replica set) MongoDB, но мы также готовили всё для простой миграции в новую СУБД (мы знали, что не собираемся использовать шардинг MongoDB из-за его сложности и неизвестной стабильности). На самом деле это часть нашей корпоративной культуры: разрабатывай быстро, чтобы испытать новую функцию продукта, но всегда с курсом на более надёжное решение.
Выбор правильной СУБД
Перед выбором новой СУБД нам требовалось понять имеющиеся шаблоны чтения/записи и почему возникли проблемы с текущим решением.
Сделав выбор, нужно было доказать, что он действительно оправдан.
Моделирование данных
Лучший способ описать новичку Cassandra — это аббревиатура KKV. Две буквы “K” содержат в себе первичный ключ. Первая “K” — это ключ раздела. Он помогает определить, в какой ноде живут данные и где их найти на диске. Внутри раздела множество строк, и конкретную строку внутри раздела определяет вторая “K” — ключ кластеризации. Он работает как первичный ключ внутри раздела и определяет способ сортировки строк. Можете представить раздел как упорядоченный словарь. Все эти качества вместе взятые позволяют очень мощное моделирование данных.
Вот упрощённая схема для нашей таблицы сообщений (она пропускает примерно 10 колонок).
Хотя схемы у Cassandra и похожи на схемы реляционных БД, их легко изменять, что не оказывает какого-либо временного влияния на производительность. Мы взяли лучшее от хранилища блобов и реляционного хранилища.
Как только начался импорт существующих сообщений в Cassandra, мы сразу увидели в логах предупреждения, что найдены разделы размером более 100 МБ. Да ну?! Ведь Cassandra заявляет о поддержке разделов 2 ГБ! По всей видимости, сама возможность не означает, что так нужно делать. Большие разделы накладывают сильную нагрузку на сборщик мусора в Cassandra при уплотнении, расширении кластера и т.д. Наличие большого раздела также означает, что данные в нём нельзя распределить по кластеру. Стало ясно, что нам придётся как-то ограничить размеры разделов, потому что некоторые каналы Discord могут существовать годами и постоянно увеличиваться в размере.
Мы решили распределить наши сообщения блоками (buckets) по времени. Мы посмотрели на самые большие каналы в Discord и определили, что если хранить сообщения блоками примерно по 10 дней, то комфортно вложимся в лимит 100 МБ. Блоки нужно получать из message_id или метки времени.
Для запроса недавних сообщений в канале мы сгенерировали диапазон блоков от текущего времени до channel_id (он тоже хронологически сортируется как Snowflake и должен быть старше, чем первое сообщение). Затем мы последовательно опрашиваем разделы до тех пор, пока не соберём достаточно сообщений. Обратная сторона такого метода в том, что изредка активным инстансам Discord придётся опрашивать много разных блоков, чтобы собрать достаточно сообщений со временем. На практике оказалось, что всё в порядке, потому что для активного инстанса Discord обычно находится достаточно сообщений в первом разделе, и таких большинство.
Импорт сообщений в Cassandra прошёл без помех, и мы были готовы опробовать её в производстве.
Тяжёлый запуск
Выводить новую систему в производство всегда страшно, так что хорошей идеей будет проверить её, не затрагивая пользователей. Мы настроили систему на дублирование операций чтения/записи в MongoDB и Cassandra.
Немедленно после запуска в баг-трекере появились ошибки, что author_id равен нулю. Как он может быть нулевым? Это обязательное поле!
Согласованность в конечном счёте
Cassandra — система типа AP, то есть гарантированная целостность здесь приносится в жертву доступности, что мы и хотели, в общем. В Cassandra противопоказано чтение перед записью (операции чтения более дорогие) и поэтому всё, что делает Cassandra, — это обновление и вставку (upsert), даже если предоставить только определённые колонки. Вы также можете писать в любую ноду, и она автоматически разрешит конфликты, используя семантику «последняя запись выигрывает» по каждой колонке. Так как это нас коснулось?
Пример состояния гонки редактирование/удаление
В случае, если пользователь редактировал сообщение, в то время как другой пользователь удалял то же самое сообщение, у нас появлялась строка с полностью отсутствующими данными, за исключением первичного ключа и текста, потому что Cassandra записывает только обновления и вставки. Для этой проблемы есть два возможных решения:
Решая эту проблему, мы заметили, что были весьма неэффективны с операциями записи. Поскольку Cassandra согласована в конечном счёте, то она не может вот так взять и немедленно удалить данные. Ей нужно реплицировать удаления на другие ноды, и это следует сделать даже если ноды временно недоступны. Cassandra справляется с этим, приравнивая удаление к своеобразной форме записи под названием “tombstone” («надгробие»). Во время операции чтения она просто проскакивает через «надгробия», которые встречаются по пути. Время жизни «надгробий» настраивается (по умолчанию, 10 дней), и они навсегда удаляются во время уплотнения базы, если срок вышел.
Удаление колонки и запись нуля в колонку — это абсолютно одно и то же. В обоих случаях создаётся «надгробие». Поскольку все записи в Cassandra являются обновлениями и вставками, то вы создаёте «надгробие» даже если изначально записываете нуль. На практике, наша полная схема сообщения состояла из 16 колонок, но среднее сообщение имело только 4 установленных значения. Мы записывали 12 «надгробий» в Cassandra, обычно без всякой причины. Решение проблемы было простым: записывать в базу только ненулевые значения.
Производительность
Известно, что Cassandra быстрее выполняет операции записи, чем чтения, и мы наблюдали в точности это. Операции записи происходили в интервале менее миллисекунды, а операции чтения — менее 5 миллисекунд. Такие показатели наблюдались независимо от типа данных, к которым осуществлялся доступ. Производительность сохранялась неизменной в течение недели тестирования. Ничего удивительного, мы получили в точности то, чего ожидали.
Задержка чтения/записи, по данным из лога
В соответствии с быстрой, надёжной производительностью чтения, вот пример перехода к сообщению годичной давности в канале с миллионами сообщений:
Большой сюрприз
Всё прошло гладко, так что мы выкатили Cassandra как нашу основную базу данных и вывели из строя MongoDB в течение недели. Она продолжала безукоризненно работать… примерно 6 месяцев, пока однажды не перестала реагировать.
Мы заметили, что Cassandra непрерывно останавливается на 10 секунд во время сборки мусора, но совершенно не могли понять, почему. Начали копать — и нашли канал Discord, который требовал 20 секунд для загрузки. Виновником был публичный Discord-сервер подреддита Puzzles & Dragons. Поскольку он публичный, мы присоединились посмотреть. К нашему удивлению, на канале было только одно сообщение. В тот момент стало очевидно, что они удалили миллионы сообщений через наши API, оставив только одно сообщение на канале.
Если вы внимательно читали, то помните, как Cassandra обрабатывает удаления при помощи «надгробий» (упомянуто в главе «Согласованность в конечном счёте»). Когда пользователь загружает этот канал, хоть там одно сообщение, Cassandra приходится эффективно сканировать миллионы «надгробий» сообщений. Тогда она генерирует мусор быстрее, чем JVM может собрать его.
Мы решили эту проблему следующим образом:
Будущее
В данный момент у нас работает кластер из 12 нодов с коэффициентом репликации 3, и мы продолжим добавлять новые ноды Cassandra по мере надобности. Мы верим, что этот подход работоспособен в долговременной перспективе, но по мере роста Discord просматривается отдалённое будущее, когда придётся сохранять миллиарды сообщений в день. У Netflix и Apple работают кластеры с сотнями нодов, поэтому пока что нам не о чем волноваться. Однако хочется иметь пару идей про запас.
Ближайшее будущее
Отдалённое будущее
Заключение
Прошло уже больше года с момента перехода на Cassandra, и несмотря на «большой сюрприз», это было спокойное плавание. Мы вышли с более 100 миллионов общего количества сообщений на более чем 120 миллионов сообщений в день, сохранив производительность и стабильность.
Благодаря успеху этого проекта, с тех пор мы перенесли все остальные наши данные в производстве на Cassandra, и тоже успешно.
В продолжении этой статьи мы исследуем, как мы осуществляем полнотекстовый поиск по миллиардам сообщений.
У нас до сих пор нет специализированных инженеров DevOps (только четыре инженера бэкенда), так что очень классно иметь систему, о которой не приходится волноваться. Мы набираем сотрудников, так что обращайтесь, если подобные задачки щекочут ваше воображение.