Сочинение на тему Приложение для ведения журнала
- Опубликовано: 03.08.2020
- Предмет: Информационная наука
- Темы: Программное обеспечение
Журналы являются важной частью любой системы, они дают вам глубокое понимание вашего приложения, что делает ваша система и что вызвало ошибку, когда происходит что-то не так. Практически каждая система генерирует журналы в той или иной форме, эти журналы записываются в файлы на локальных дисках. Когда вы создаете приложение уровня предприятия, ваша система переходит на несколько хостов, управление журналами на нескольких хостах может быть сложным. Отладка ошибки в приложении на сотнях файлов журнала на сотнях серверов может быть очень трудоемкой и сложной.
Распространенным подходом к этой проблеме является создание приложения централизованного ведения журналов, которое может собирать и объединять различные типы журналов в одном централизованном месте. Существует множество инструментов, которые могут решить некоторую часть проблемы, но нам необходимо создать надежную приложение, использующее все эти инструменты. В централизованном приложении ведения журналов всего четыре части – собирать журналы, транспортировать, хранить и анализировать. Мы подробно рассмотрим каждую из этих частей и посмотрим, как мы можем создать приложение.
Поток журналирования ApplicationCollectionВсе приложения создают журналы различными способами, некоторые приложения регистрируют через системные журналы и другие журналы непосредственно в файлах. Когда вы видите типичное веб-приложение, работающее на сервере Linux, в / var / log будет больше десятка файлов журналов, а также несколько журналов для конкретных приложений в домашних каталогах и других местах. По сути, в разных местах будут создаваться журналы, создаваемые разными приложениями. Теперь учтите, что на сервере запущено веб-приложение, и, если что-то пойдет не так, ваши разработчики или эксплуатационная группа должны быстро получить доступ к данным журналов для устранения проблем, связанных с работой. Вам понадобится решение, которое может отслеживать изменения в файлах журнала практически в режиме реального времени. Чтобы решить эту проблему, вы можете использовать подход репликации,
Подход репликации. В подходе репликации файлы реплицируются на центральный сервер по фиксированному расписанию. Вы настроите задание cron, которое будет реплицировать ваши файлы на сервере Linux на ваш центральный сервер. Одно минутное задание cron может оказаться недостаточно быстрым для устранения неполадок, когда ваш сайт не работает, и вы будете ждать репликации соответствующих данных журнала. Подход с использованием репликации будет полезен для аналитики, если вам нужно анализировать данные журнала в автономном режиме для расчета Метрики или другая работа, связанная с пакетами, подход репликации может быть подходящим. Транспорт Если у вас работает несколько хостов, данные журналов могут быстро накапливаться. Должен быть эффективный и надежный способ передачи этих данных в централизованное приложение и обеспечения защиты данных.
Существует множество платформ для передачи данных журнала. Одним из способов является непосредственное подключение источников ввода, и инфраструктура может начать сбор журналов, а другой способ – отправлять данные журналов через API. Код приложения записывается для непосредственного входа в эти источники, что снижает задержку и повышает надежность. Если вы хотите предоставить несколько входных данных источники, которые вы можете использовать: Logstash – сборщик журналов с открытым исходным кодом, написанный на RubyFlume – сборщик журналов с открытым исходным кодом, написанный на Javaand, Fluentd – с открытым исходным кодом, написанный на RubyThese, предоставляют исходные источники, но также поддерживают собственные файлы и надежно их транспортируют. Эти платформы лучше подходят для более общего применения. Для регистрации данных через API, который, как правило, является более предпочтительным способом регистрации данных в центральном приложении, это следующие платформы, которые можно использовать. Описание – Программное обеспечение с открытым исходным кодом от Facebook, написано в C ++ nsq – с открытым исходным кодом, написанный на Goand, Kafka – вы бы слышали о широко используемом программном обеспечении с открытым исходным кодом Kafka от Apache, написанном на Java, так что речь шла о транспорте, а теперь давайте посмотрим, каким будет эффективный способ хранения такое большое количество журналов данных.
Хранилище. Теперь у нас есть транспорт, журналам понадобится место назначения, хранилище, где будут сохранены все данные журнала. Система должна быть хорошо масштабируемой, поскольку данные будут продолжать расти, и она должна справляться с ростом со временем. Данные журналов будут зависеть от того, насколько велики ваши приложения, если ваше приложение работает на нескольких серверах или во многих контейнерах, оно будет генерировать больше журналов. Есть несколько вещей, которые мы должны учитывать при выборе хранилища. Время – Как долго это должно храниться ?: Система хранения зависит от того, как долго вы хотели бы хранить ваши данные. Если журналы рассчитаны на длительный срок и не требуют немедленного анализа, их можно архивировать и сохранять на S3 или AWS Glacier, поскольку они обеспечивают относительно низкую стоимость большого объема данных. Если вам нужны журналы всего за несколько дней или месяцев, вы можете использовать распределенную систему хранения, например, Cassandra, MongoDB, HDFS или ElasticSearch. И, наконец, если вы хотите хранить данные всего за несколько часов, вы также можете использовать Redis. Объем. Насколько большими будут ваши данные? Google и Facebook создают за день гораздо больший объем данных, чем данные за неделю простого приложения NodeJs. Выбранная вами система хранения должна быть легко масштабируемой и масштабироваться по горизонтали по мере увеличения ваших данных.
Доступ – как вы будете получать доступ к журналам? Выбор системы хранения также зависит от того, как вы получаете доступ к журналам. Например, некоторые системы хранения не подходят для анализа в реальном времени – для загрузки файла AWS Glacier могут потребоваться часы. AWS Glacier или Tape Backup не будут работать, если вам потребуется доступ к данным для анализа неисправностей. ElasticSearch или HDFS – хороший выбор для интерактивного анализа данных и более эффективной работы с необработанными данными. Аналитические журналы предназначены для анализа и анализа. Как только ваши журналы хранятся в централизованном месте, вам нужен способ их анализа. Существует множество инструментов для анализа журналов, если вам нужен пользовательский интерфейс для анализа, вы можете проанализировать все данные в ElasticSearch и использовать Kibana или Greylog для запроса и проверки данных. Графана и Кибана могут использоваться для демонстрации аналитики данных в режиме реального времени
Предупреждение. Это последний компонент в приложении централизованного ведения журналов. Приятно иметь систему оповещений, которая будет предупреждать нас о любых изменениях в шаблонах журналов или рассчитанных показателях. Журналы очень полезны для устранения ошибок. Гораздо лучше создать систему предупреждений в системе регистрации событий, которая отправит электронное письмо или уведомит нас, чтобы кто-то продолжал просматривать журналы на предмет любых изменений. Существует множество инструментов для сообщений об ошибках, вы можете использовать Sentry или Honeybadger. Они объединяют повторяющиеся исключения, которые дают вам представление о том, как часто происходит ошибка. Оповещения также полезны для мониторинга сотен серверов, журналы будут отправлять статус различных приложений, и вы можете настроить систему оповещения, чтобы проверить, работает ли ваша система или вниз.
Оповещение действительно полезно при устранении ошибок, мониторинге и пороговых отчетах. Riemann – очень хорошее программное обеспечение для мониторинга и оповещения. Вот и все. Итак, в первой части мы говорили о всех доступных программах и компонентах, которые нам нужны для создания приложения централизованного ведения журналов, мы начнем создавать наше приложение, начиная с Transport, мы увидим как настроить транспортный компонент для простого приложения NodeJS, которое будет отправлять журналы в центральную систему
За последние десятилетия почти во всех компонентах мобильных и вычислительных устройств было много значительных инноваций. Механических разъемов нет. По мере того как устройства уменьшаются в
Hadoop может быть страстно привлекательным, потому что он отлично масштабируется, может быть настроен на переключение широкого ассортимента и очень дорогой по сравнению со старыми. Hadoop
DirectX определяется как интерфейс прикладной программы или API для создания графических изображений и мультимедийных эффектов и управления ими в таких приложениях, как игры или активные