Недавно я хотел разобраться в лог-проектах и личных мыслях, которые я делал раньше, поэтому у меня есть эта статья.
задний план
Среда развертывания приложений на нашей стороне относительно сложна и в основном включает следующее:
- Прямое развертывание машины
- Развертывание через собственный докер
- Развертывание через кластер kubernates
Среда развертывания неоднородна, что делает неудобным просмотр журналов приложений.
Потребности бизнеса
В соответствии со средой развертывания требования к сбору журналов делятся на следующие категории:
- Текстовые журналы на машине (журналы приложений, работающие непосредственно на физических или виртуальных машинах)
- Журналы приложений, работающие в док-контейнере
- Журналы приложений, запущенные в кластере kubernates
Конкретные потребности бизнеса можно разделить на:
- Извлечение журналов в соответствии с измерениями проекта, приложения и экземпляра и поддержка выделения ключевых слов при поиске (поскольку при извлечении журналов необходимо извлекать журналы проекта, приложения и экземпляра).
- После извлечения нужного журнала вы можете просмотреть контекст (просмотреть контекст журнала файла журнала, в котором находится журнал).
- Загрузка журнала поддержки (в настоящее время поддерживать два сценария: Результаты поиска Скачать, контекстные загрузки; Поддержка двух способов: Скачать онлайн, Загрузить в автономном режиме)
- Поддерживает автоматическое пакетное развертывание и удаление агентов, а также визуализирует процесс развертывания и удаления.
- Один экземпляр поддерживает несколько кластеров elasticsearch
- Поддерживает текстовые журналы, журналы докеров, журналы k8s и может сопоставлять журналы с их бизнес-значениями. (То есть, какой бы ни была форма журнала и источник, он в конечном итоге должен соответствовать проекту, приложению и экземпляру в бизнес-смысле, потому что для пользователя журнала отправная точка запроса журнала должна запросить определенный проект, определенное приложение (необязательно), экземпляр (необязательно), журналы за определенный период времени.)
- Поддержка развертывания в собственном бизнес-кластере
Спрос прояснился, давайте посмотрим на отраслевой план.
Архитектура системы отраслевого журнала
- Роль коллектора:
- Очищайте и объединяйте данные, чтобы снизить нагрузку на серверные кластеры.
- Безопасность.Агенту не разрешено напрямую подключаться к внутренним кластерам, таким как kafka, чтобы обеспечить определенную степень безопасности.Даже если серверная часть настроена, стабильность соединения агента и метода аутентификации может быть гарантирована.
- Роль MQ состоит в том, чтобы срезать пики и заполнять долины, отделять и потреблять несколько раз.
Архитектура, показанная на рисунке выше, является относительно распространенной архитектурой в отрасли и считается универсальной для различных сценариев.
Поскольку архитектура отрасли настолько совершенна, должны ли мы просто принять ее?
Для нас есть следующие вопросы:
- Задействовано много компонентов, связь относительно длинная, а эксплуатация и техническое обслуживание более проблематичны.
- Весь этот набор архитектуры не способствует раздельному развертыванию (например, сеть комнаты развертывания бизнес-приложений изолирована, а проект небольшой, может быть предоставлено только ограниченное количество машин. В настоящее время, если вам нужно для развертывания этой архитектуры в отрасли ресурсы будут ограничены.Он будет более ограничен.Если вы хотите поддерживать подключаемость компонентов отраслевой архитектуры (например, вы можете гибко решать, нужны ли вам Collector и MQ), то вам нужно управлять и поддерживать несколько наборов конфигураций или кодов)
- Самое главное — это функции, предоставляемые компонентами, которые мы сейчас не используем. Например, MQ срезает пики и заполняет впадины и потребляет несколько раз.
Выбор компонентов
При выборе компонентов мы в основном учитываем следующие аспекты:
- Экосистема с открытым исходным кодом, соответствующая компонентам, завершена и активна.
- Соответствующий стек технологий нам знаком, наш языковой стек технологий в основном Java и Go, если языком компонента являются C и Ruby, его следует исключить.
- Стоимость эксплуатации и обслуживания
- Простота развертывания, хорошая производительность
Agent
Когда речь заходит о решениях для сбора журналов, первое, что приходит на ум, это определенно ELK (Elasticsearch, Logstash, Kibana), но Logstash не лучший выбор для агентов сбора журналов, поскольку он зависит от производительности или простоты JVM.
Лично я считаю, что хороший агент должен занимать меньше ресурсов, иметь хорошую производительность, не зависеть от других компонентов и может развертываться независимо. Логсташ явно не соответствует этим требованиям, и, возможно, именно исходя из этих соображений эластичный запустил Filebeat.
Коллектор, МК
При развертывании кластера Elasticsearch такая информация, как емкость, машины и сегменты, обычно оценивается заранее, потому что после запуска кластера Elasticsearch горизонтальное расширение затруднено, и мы не можем правильно оценить емкость из-за ограничений бизнеса и затрат. ., так что это сочетается с реальными требованиями компании: бизнес-сторона, использующая сервис логов, привозит свою машину, то есть у бизнес-стороны будет независимый кластер Elasticsearch.
Каждая бизнес-сторона использует свой собственный кластер Elasticsearch, поэтому давление кластера будет не очень большим, поэтому два компонента Collector и MQ мало на нас влияют.
ETL
Поскольку Elasticsearch Ingest Node может полностью удовлетворить наши потребности в синтаксическом анализе, нет необходимости вводить связанные компоненты, такие как Logstash.
На данный момент мы можем в основном видеть, что наша архитектура выглядит следующим образом:
Несколько принципов архитектурного проектирования:
- Подходит лучше, чем ведущие в отрасли
- Простое лучше сложного
- Эволюция лучше, чем один шаг
Выполнение
Основываясь на наборах потребностей и EFK, расчесывая наши уникальные вещи в нашей сцене:
- Docker Относительно простая сцена журнала сцены, до того, как продукт проходит через развертывание выпуска, который докер более унифицировал правила именования, имя приложения может быть получено путем перехвата Docker.container.name; в то же время, когда развертывание, развертывание Целевая машина может знать IP, так что, применив к имени экземпляра + IP.
- Сценарий k8s также относительно однороден, все выпущено и развернуто с помощью предыдущего продукта B, и его правила именования подов относительно однородны.Вы можете получить имя приложения, перехватив kubernetes.pod.name (но вам нужно связать его с клиентом через пространства имён, а затем передать тенанта в проект. Соответствие один к одному); pod.name в k8s уникально, поэтому его можно использовать как имя инстанса.
- Текстовый журнал: поскольку основным сценарием текстового журнала является приложение, развернутое на «голом железе», в этом сценарии нет автоматической миграции приложения, поэтому имя приложения и имя экземпляра текстового журнала могут быть помечены во время развертывание.
Конкретные правила и анализ показаны на следующем рисунке (обработка примера детали еще не отмечена):
Рекомендуется записывать журнал в текстовый файл, просто используйте стандартный вывод.
Здесь вы можете увидеть, что мы выбираем Filebeat в качестве сборщика журналов и Elasticsearch для хранения журналов и предоставления возможностей поиска.
Итак, где производится очистка журнала?
Как правило, два способа очистить журналы:
- Сначала собирайте журналы в kafka, а затем используйте данные kafka через Logstash для очистки данных.
- Очищайте данные напрямую через [Ingest Node] Elasticsearch, поскольку Ingest Node также поддерживает выражения Grok.
Для нашего сценария требования, которые нам нужны для очистки данных, относительно просты, в основном перехват имени приложения и экземпляра и обработка времени журнала в текстовом журнале (@сброс метки времени, обработка часового пояса), поэтому мы выбрали схему 2. .
В нашем решении интерфейс Kibana не предоставляется пользователям напрямую, а мы самостоятельно разработали его под бизнес компании.
Почему вы не используете Kibana для внешнего интерфейса, а должны разработать его самостоятельно?
- Kibana имеет определенные расходы на обучение для разработчиков бизнеса
- Интерфейс Kibana не очень хорош для связывания содержимого журнала с бизнес-значением (выбор интерфейса лучше, чем ввод, поэтому мы разрешаем проект журнала, приложение, экземпляр и другую бизнес-информацию).
- log-searchПоддерживается Query String, поэтому для разработчиков, знакомых с kibana, эффект поиска во внешнем интерфейсе, разработанном нами, такой же.
log-searchПредоставленные функции можно найти на github:GitHub.com/jiankun король…
Если лог нужно чистить больше, то можно использовать вариант 1, либо не чистить сначала, скинуть данные сначала в Elasticsearch, а потом обрабатывать при запросе. Например, в нашем сценарии журналы можно сначала поместить в Elasticsearch, а затем, когда необходимо получить имя приложения, код можно использовать для обработки и получения имени приложения.
мониторинг, оповещение
На самом деле, на основе лога можно сделать многое, например:
- Мониторинг на основе логов (Google Dapper)
- Оповещения на основе журналов
- Выполнять машинное обучение на основе журналов
Для конкретных идей, пожалуйста, обратитесь к следующему рисунку:
Условие: Пользователи могут быть обязаны распечатывать журналы в соответствии с определенными правилами. Мониторинг развития: Мониторинг в основном заключается в том, чтобы сначала открыть трассировку ссылок, а затем усилить идентификацию бизнес-аспектов в отчетной информации или информации журнала, то есть добавить к мониторингу перспективу бизнес-измерения.
разное
DaemonSet
Развертывание Filebeat в режиме DaemonSet для сбора журналов фактически представляет собой журналы в каталоге /var/lib/docker/containers хоста. Запуск Filebeat в Kubernetes
Sidecar
Контейнер агента журнала, в котором запущена боковая панель в POD, используется для сбора журналов, созданных основным контейнером POD.
Необъяснимо думать об istio.
Filebeat может собирать журналы контейнеров в режиме sidecar, то есть контейнеры filebeat и конкретных служб развертываются в одном и том же модуле, указывают путь или файл для сбора журналов, а затем отправляют журналы в указанное место или в поиск, например в систему Elasticsearch. Преимущество режима развертывания filebeat в каждом модуле состоит в слабой связи с конкретными службами приложений и высокой масштабируемости, но в yaml требуется дополнительная настройка.
Личный публичный аккаунт WeChat:
Персональный гитхаб:
личный блог: