Коллекция журналов с Graylog на AWS

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

Для этого есть много вариантов, примерно разделенных на две группы — сторонние сервисы и программное обеспечение, которое вы устанавливаете.

Сторонние (или «облачные», если хотите) службы сбора журналов включают Splunk , Loggly , Papertrail , Sumologic . Их очень легко настроить, и вы платите за то, что используете. По сути, вы отправляете каждое сообщение (например, с помощью специального приложения обратного входа) в конечную точку поставщика, а затем используете панель мониторинга для анализа данных. Во многих случаях это будет предпочтительным способом.

В других случаях, однако, политика компании может нарушаться при использовании сторонних сервисов для хранения данных, специфичных для компании, или дополнительные расходы могут быть нежелательны. В этих случаях необходимо приложить дополнительные усилия для установки и управления программным обеспечением для сбора внутренних журналов. Они работают аналогичным образом, но детали реализации могут отличаться (например, вместо отправки сообщений с приложением к целевой конечной точке, программное обеспечение, используя какой-либо агент, собирает локальные журналы и объединяет их). Варианты с открытым исходным кодом включают Graylog , FluentD , Flume , Logstash .

После очень быстрого исследования я решил, что Graylog лучше всего соответствует нашим потребностям, поэтому ниже приведено описание процедуры установки на AWS (хотя первая часть применима независимо от инфраструктуры).

Первое, на что нужно обратить внимание — это готовые к использованию изображения, предоставляемые graylog, в том числе докер, openstack, vagrant и AWS. К сожалению, у версии AWS есть два недостатка — она ​​использует Ubuntu, а не Amazon AMI. Это не большая проблема, хотя некоторые общие сценарии, которые вы используете в вашем стеке, возможно, придется переписать. Другой был нарушитель соглашения — когда вы запускаете его, он не запускает веб-интерфейс, хотя утверждает, что должен. Запускаются только mongodb ,asticsearch и graylog-server. Наличие 2 экземпляров — одного веб-сайта и одного для остальных усложнит ситуацию, поэтому я выбрал ручную установку.

Graylog состоит из двух компонентов — сервера, который обрабатывает ввод, индексирование и поиск, и веб-интерфейса, который представляет собой приятный пользовательский интерфейс, взаимодействующий с сервером. Веб-интерфейс использует mongodb для метаданных, а сервер используетasticsearch для хранения входящих журналов. Ниже приведен скрипт bash (CentOS), который выполняет установку. Обратите внимание, что «sudo» отсутствует, поскольку сценарии инициализации выполняются от имени пользователя root в AWS.

Вы также можете установить TTL (автоматический срок действия) для сообщений, чтобы старые журналы не сохранялись вечно. Вот как

Теперь у вас все работает на экземпляре. Затем вы должны сделать некоторые специфичные для AWS вещи (если использовать CloudFormation, это будет включать в себя кучу JSON). Вот список:

• у вас может быть либо группа автоматического масштабирования с одним экземпляром, либо один экземпляр. Я предпочитаю ASG, хотя другой немного проще. ASG дает вам авто-возрождение, если экземпляр умирает.
• установите вышеупомянутый скрипт, который будет вызываться в UserData конфигурации запуска экземпляра / asg (например, сначала получая его из s3)
• разрешить UDP-порт 12201 (порт регистрации по умолчанию). Это должно происходить для группы безопасности instance / asg (входящей), для группы безопасности узлов приложения (исходящей), а также в качестве сетевого ACL вашего VPC. Проверьте соединение UDP, чтобы убедиться, что оно действительно проходит. Держите доступ ограниченным для всех источников, кроме ваших экземпляров.
• вам нужно передать частный IP-адрес вашего экземпляра серого журнала всем узлам приложения. Это сложно на AWS, так как частные IP-адреса меняются. Вот почему вам нужно что-то стабильное. Вы не можете использовать ELB (балансировщик нагрузки), потому что он не поддерживает UDP. Есть два варианта:
  • Свяжите Elastic IP с узлом при запуске. Передайте этот IP на узлы приложения. Но есть одна загвоздка — если они подключаются к эластичному IP, это будет проходить через NAT (если он у вас есть), и вам, возможно, придется открыть свой экземпляр «миру». Таким образом, вы должны превратить эластичный IP в соответствующий публичный DNS. DNS тогда будет преобразован в частный IP. Вы можете сделать это вручную и взломать:

    1	GRAYLOG_ADDRESS="ec2-$GRAYLOG_ADDRESS//./-}.us-west-1.compute.amazonaws.com"

    или вы можете использовать интерфейс командной строки AWS EC2 для получения сведений об экземпляре экземпляра, с которым связан эластичный IP, а затем с другим вызовом получить свой публичный DNS.

  • Вместо использования Elastic IP, который ограничивает вас одним экземпляром, вы можете использовать Route53 (диспетчер DNS AWS). Таким образом, когда запускается экземпляр серого журнала, он может присоединиться к записи route53, что позволяет использовать циклический DNS для нескольких экземпляров Graylog, находящихся в кластере. Управление записями Route53 снова выполняется через интерфейс командной строки AWS. Затем вы просто передаете доменное имя узлам приложений, чтобы они могли отправлять сообщения.
• В качестве альтернативы вы можете установить Graylog-сервер на всех узлах (в качестве агента) и указать их на кластер эластичного поиска. Но это более сложный и, вероятно, не предполагаемый способ сделать это
• настройте свою структуру ведения журнала для отправки сообщений в graylog. Существуют стандартные приложения GELF (формат greylog), например, этот , и единственное, что вам нужно сделать, это использовать переменную среды Public DNS в logback.xml (которая поддерживает разрешение переменных среды).
• Вы должны сделать веб-интерфейс доступным вне сети, чтобы вы могли использовать для этого ELB или циклический DNS, упомянутый выше. Просто убедитесь, что правила безопасности строгие и не допускают внешнего вмешательства в ваши данные журнала.
• Если вы не используете кластер Graylog (о котором я не буду рассказывать), то единственный экземпляр может потерпеть неудачу. Это не большая потеря, поскольку сообщения журналов могут быть получены от экземпляров, и они в любом случае недолговечны. Но важны метаданные веб-интерфейса — информационные панели, оповещения и т. Д. Поэтому рекомендуется регулярно делать резервные копии (например, с помощью mongodump). Использование тома EBS также вариант.
• Даже если вы отправляете свои сообщения журнала в централизованный сборщик журналов, рекомендуется также вести локальные журналы с надлежащей ротацией и очисткой журналов.

Это не тривиальный процесс, но важно иметь сбор журналов, поэтому я надеюсь, что руководство было полезным.