в какой папке лежат логи

Log файлы

Материал из Info

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

Содержание

Система сохранения ошибок

При возникновении ошибки, программные продукты Microinvest моментально сохраняют инженерную информацию о событии. Она записывается незаметно для пользователя в специальный дневник (так называемый Log файл). С помощью этого дневника можно установить, что именно нарушило работу продукта и предпринять соответствующее решение о проблеме.

Папка с Log файлами

Файлы с системными сообщениями сохраняются при настройке продукта, в специально созданной для данной цели папке. Для различных версий Windows папки следующие:

Логи по продуктам

Для каждого продукта своя система журналирования ошибок, которая пишет данные в отдельные места вышеуказанной папки:

Лог портмона

Для выявления проблем в коммуникации с оборудованием программных продуктов Microinvest Склад Pro или Microinvest Склад Pro Light используется специальный командный параметр /portmon, после запуска программы с данным параметром начинает писаться в файл вся коммуникация (включая COM и LAN) оборудования с нашими программами. Запустите программу с данным параметром, проведите продажу, сделайте z-отчет или другое действие которое приводит к ошибке или некорректному результату, запакуйте файл в архив и опубликуйте его в Вашей теме на форуме или отправьте техническим специалистам Microinvest с полным описанием проблемы. Данный файл будет находиться в директории:

Противодействие ошибкам

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

Раннее предупреждение

Сделана специальная система для раннего оповещения о возможных проблемах. Обычно одна ошибка занимает определенное количество памяти в Log файле, и можно поставить лимит количества ошибок, которые возникают в системе. Когда индивидуальный Log файл вырастет до 500 KB, программа выдаст сообщение: «Внимание, необходима профилактика системы…». В этом случае рекомендуется следующая последовательность действий:

Обобщение

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

Источник

Логирование в Kubernetes: как собирать, хранить, парсить и обрабатывать логи

Разберём основы логирования в Docker и Kubernetes, а затем рассмотрим два инструмента, которые можно смело использовать на продакшене: Grafana Loki и стек EFK (Elasticsearch + Fluent Bit + Kibana).

Материал статьи — выжимка из открытой лекции школы «Слёрм». Если есть желание и тем более производственная необходимость можно пройти полное обучение — записывайтесь на курс по Мониторингу и логированию инфраструктуры в Kubernetes.

image loader

Логирование в Docker

На уровне Kubernetes приложения запущены в подах, но на уровне ниже они всё-таки работают обычно в Docker. Поэтому нужно настроить логирование таким образом, чтобы собирать логи с контейнеров. Контейнеры запускает Docker — значит надо разобраться, как логирование устроено на уровне Docker.

Надеюсь, каждый читатель знает: логи приложения надо писать в stdout/stderr, а не внутрь контейнера. Логи агрегирует Docker Daemon, и он работает именно с теми логами, которые отправляются на stdout/stderr. К тому же запись логов внутрь контейнера чревата проблемами: контейнер пухнет от растущего лога (так как никакого Logrotate в контейнере скорее всего нет), а Docker Daemon и не в курсе про этот лог.

У Docker есть несколько лог-драйверов или плагинов для сбора логов контейнеров. В бесплатной версии Docker Community Edition (CE) лог-драйверов меньше, чем в коммерческой Docker Enterprise Edition (EE).

image loader

Docker EE я ни разу не использовал на практике: в Southbridge мы стараемся придерживаться Open Source решений, да и клиентам большая часть дополнительных возможностей Docker EE не нужна.

Лог-драйверы в Docker CE:

local — запись логов во внутренние файлы Docker Daemon;
json-file — создание json-log в папке каждого контейнера;
journald — отправка логов в journald.

Настройки логирования в Docker находятся в файле daemon.json.

В поле “log-driver” указывают плагин, а в поле “log-opts” — его настройки. В примере выше указан плагин “json-file”, ограничение по размеру лога — “max-size”: “10m”; ограничение по количеству файлов (настройки ротации) — “max-file”: “3”; а также значения, которые будут прикручены к логам.

xj0p8 ej2d2z3rbtaklnifom92k

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

Вот как выглядит схема логирования в Docker:

9orb 5gzm8uphisut9q iol6egs

Как схема работает: лог-драйвер, например json-file, создаёт файлы. Сборщики логов (Rsyslog, Fluentd, Logagent и другие) эти файлы собирают и передают на хранение в Elastic, Sematext или другие хранилища.

Особенности логирования в Kubernetes

Упрощённо схема логирования в Kubernetes выглядит так: есть pod, в нём запущен контейнер, контейнер отправляет логи в stdout/stderr. Затем Docker создаёт файл и записывает логи, которые затем может ротировать.

apnnd 2zze0qk g7m ij95zshrq

Рассмотрим особенности логирования в Kubernetes.

Агрегировать логи со всех инстансов. Если микросервисы хостятся в облаках, то за контроль системы отвечает облачный провайдер. Если микросервисы на своём железе, то помимо логов с контейнеров нужно собирать и логи системы.

Раньше не было удобных инструментов для сбора логов и с системы, и с микросервисов. Обычно один инструмент собирал системные логи (например, Rsyslog), второй — логи с Docker (например, journal-bit с настройкой лог-драйвера Docker на journald). Пробовали использовать journal-bit — собирать логи и с контейнеров (в лог-драйвере Docker указывать, что нужно писать логи в journald), и с системы (в CentOS 7 уже есть systemd и journald). Решение рабочее, но не идеальное. Если логов много, journal-bit начинает лагать, сообщения теряются.

Эксперименты продолжались — и нашёлся другой способ. В CentOS 7 основные системные логи (messages, audit, secure) дублируются в var-лог в виде файлов. В Docker тоже можно настроить сохранение логов в файлы json. Соответственно, эти файлы из CentOS 7 и Docker можно собирать вместе.

Со временем стало популярно решение ELK Stack. Это комбинация нескольких инструментов: Elasticsearch, Logstash и Kibana.

Elasticsearch хранит логи с контейнеров, Logstash собирает логи с инстансов, Kibana позволяет обрабатывать полученные логи, строить по ним графики. Некоторое время ELK Stack активно использовали, но, на мой взгляд, его время проходит. Позже расскажу, почему.

Добавлять метаданные. Поды, приложения, контейнеры могут быть запущены, где угодно. Более того, у одного приложения может быть несколько инстансов. Логи записаны в одном формате, а нам надо понять, какая именно это реплика, какой Pod это пишет, в каком namespace он находится. Именно поэтому логам нужно добавлять метаданные.

Парсить логи. Забавно, но расходы на поддержку системы логирования и мониторинга могут превысить затраты на основное приложение. Когда у вас летят десятки и сотни тысяч логов в секунду, это кажется закономерным, но всё же надо знать грань. Один из способов эту грань найти — парсинг логов.

Как правило, не нужно собирать и хранить все логи, надо отправлять на хранение только часть — например, логи со статусом «warning» или «error». Если речь про логи nginx или ingress-контроллеров, то отправлять на хранение можно только те, статус которых отличен от 200. Но это не универсальный совет: если вы строите каким-то образом аналитику по логам Nginx, то их очевидно стоит собирать.

Бездумно фильтровать логи не рекомендуют, потому что отфильтрованных данных может не хватить для нормальной аналитики. С другой стороны, возможно аналитику стоит проводить не на уровне логирования, а на уровне сбора метрик. Тогда не придётся хранить сотни тысяч строк с кодом 200. Один из подходов — получать информацию о трафике и ошибках из метрик ingress-контроллеров.

Читайте также:  в какой спорт можно отдать ребенка в 2 года

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

Пока нет стандартного решения для логирования. В отличие от мониторинга, где есть одно наиболее распространенное решение Prometheus, в логировании стандарта нет.

В рамках этой лекции мы рассмотрим два инструмента: один популярный, а второй — набирающий популярность. Помимо них есть и другие, но в этой статье мы их не коснёмся.

Учитывая все рассмотренные выше особенности, логирование в Kubernetes теперь можно представить на такой схеме:

rkujuimeo5hldarr4sfo9q6fk1e

Остаётся лог контейнера, ротирование, но появляется агент-сборщик, который подбирает логи и отправляет на хранение (на схеме — в Logging Backend). Агент работает на каждой ноде и, как правило, запущен в Kubernetes.

Теперь рассмотрим инструменты для логирования.

Grafana Loki

Grafana Loki появился недавно, но уже стал довольно известным. Его преимущества: лёгко устанавливается, потребляет мало ресурсов, не требует установки Elasticsearch, так как хранит данные в TSDB (time series database). В прошлой статье я писал, что в такой базе хранит данные Prometheus, и это одно из многочисленных сходств двух продуктов. Разработчики даже заявляют, что Loki — это «Prometheus для мира логирования».

Небольшое отступление про TSDB для тех, кто не читал предыдущую статью: TSDB отлично справляется с задачей хранения большого количества данных, временных рядов, но не предназначена для долгого хранения. Если по какой-то причине вам нужно хранить логи дольше двух недель, то лучше настроить их передачу в другую БД.

Ещё одно преимущество Loki — для визуализации данных используется Grafana. Очень удобно: в Grafana мы смотрим данные по мониторингу и там же, подключив Loki, смотрим логи. По логам можно строить графики.

Архитектура Loki выглядит примерно так:

0ba2qeqv2jlas klbjjbq830us8

С помощью DaemonSet на всех серверах кластера разворачивается агент — Promtail или Fluent Bit. Агент собирает логи. Loki их забирает и хранит у себя в TSDB. К логам сразу добавляются метаданные, что удобно: можно фильтровать по Pods, namespaces, именам контейнеров и даже лейблам.

Loki работает в знакомом интерфейсе Grafana. У Loki даже есть собственный язык запросов, он называется LogQL — по названию и по синтаксису напоминает PromQL в Prometheus. В интерфейсе Loki есть подсказки с запросами, поэтому не обязательно их знать наизусть.

image loader
Loki в интерфейсе Grafana

Используя фильтры, в Loki можно найти коды (“400”, “404” и любой другой); посмотреть логи со всей ноды; отфильтровать все логи, где есть слово “error”. Если нажать на лог, раскроется карточка со всей информацией по событию.

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

Elastic + Fluent Bit + Kibana (EFK Stack)

Стек EFK — это более классический, и при этом не менее популярный инструмент логирования.

В начале статьи упоминался ELK (Elasticsearch + Logstash + Kibana), но этот стек устарел из-за не очень производительного и при этом ресурсоёмкого Logstash. Вместо него стали использовать более легковесный и производительный Fluentd, а спустя некоторое время ему в помощь пришёл Fluent Bit — ещё более легковесный и ещё более производительный агент-сборщик.

Если верить разработчикам, то Fluent Bit более, чем в 100 раз лучше по производительности, чем Fluentd: «там, где Fluentd потребляет 20 Мб ОЗУ, Fluent Bit будет потреблять 150 Кб» — прямая цитата из документации. Глядя на это, Fluent Bit стали использовать чаще.

У Fluent Bit меньше возможностей, чем у Fluentd, но основные потребности он закрывает, поэтому мы в основном пользуемся Fluent Bit.

Схема работы стека EFK: агент собирает логи со всех подов (как правило, это DaemonSet, запущенный на всех серверах кластера) и отправляет в хранилище (Elasticsearch, PostgreSQL или Kafka). Kibana подключается к хранилищу и достаёт оттуда всю необходимую информацию.

i8s1gnk owuyo81aghbi09db rm

Kibana представляет информацию в удобном веб-интерфейсе. Есть графики, фильтры и многое другое.

image loader

По логам можно создавать целые дашборды.

image loader

Возможности Fluent Bit

Так как о Fluent Bit, как правило, слышали меньше, чем о Logstash, рассмотрим его чуть подробнее. Fluent Bit логически можно поделить на 6 модулей, на часть модулей можно навесить плагины, которые расширяют возможности Fluent Bit.

afca2g7bs7pircthqugrmsctdas

Модуль Input собирает логи из файлов, служб systemd и даже из tcp-socket (надо только указать endpoint, и Fluent Bit начнёт туда ходить). Этих возможностей достаточно, чтобы собирать логи и с системы, и с контейнеров.

В продакшене мы чаще всего используем плагины tail (его можно натравить на папку с логами) и systemd (ему можно сказать, из каких служб собирать логи).

Модуль Parser приводит логи к общему виду. По умолчанию логи Nginx представляют собой строку. С помощью плагина эту строку можно преобразовать в JSON: задать поля и их значения. С JSON намного проще работать, чем со строковым логом, потому что есть более гибкие возможности сортировки.

Модуль Filter. На этом уровне отсеиваются ненужные логи. Например, на хранение отправляются логи только со значением “warning” или с определёнными лейблами. Отобранные логи попадают в буфер.

Модуль Buffer. У Fluent Bit есть два вида буфера: буфер памяти и буфер на диске. Буфер — это временное хранилище логов, нужное на случай ошибок или сбоев. Всем хочется сэкономить на ОЗУ, поэтому обычно выбирают дисковый буфер. Но нужно учитывать, что перед уходом на диск логи всё равно выгружаются в память.

Модуль Routing/Output содержит правила и адреса отправки логов. Как уже было сказано, логи можно отправлять в Elasticsearch, PostgreSQL или, например, Kafka.

Интересно, что из Fluent Bit логи можно отправлять во Fluentd. Так как первый более легковесный и менее функциональный, через него можно собирать логи и отправлять во Fluentd, и уже там, с помощью дополнительных плагинов, их дообрабатывать и отправлять в хранилища.

Если планируете использовать Elasticsearch…

Автор: Марсель Ибраев, сертифицированный администратор Kubernetes, практикующий инженер в компании Southbridge, спикер и разработчик курсов Слёрм.

Источник

Лог файлы Linux по порядку

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

image loader

Журналирование является основным источником информации о работе системы и ее ошибках. В этом кратком руководстве рассмотрим основные аспекты журналирования операционной системы, структуру каталогов, программы для чтения и обзора логов.

Основные лог файлы

Все файлы журналов, можно отнести к одной из следующих категорий:

Для каждого дистрибутива будет отдельный журнал менеджера пакетов.

И немного бинарных журналов учета пользовательских сессий.

И другие журналы

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

В домашнем каталоге пользователя могут находится журналы графических приложений, DE.

/.xsession-errors — Вывод stderr графических приложений X11.

/.xfce4-session.verbose-log — Сообщения рабочего стола XFCE4.

Чем просматривать — lnav

Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — lnav, в расшифровке Log File Navigator.

image loader

Установка пакета как обычно одной командой.

Навигатор журналов lnav понимает ряд форматов файлов.

Что в данном случае означает понимание форматов файлов? Фокус в том, что lnav больше чем утилита для просмотра текстовых файлов. Программа умеет кое что еще. Можно открывать несколько файлов сразу и переключаться между ними.

Программа умеет напрямую открывать архивный файл.

Показывает гистограмму информативных сообщений, предупреждений и ошибок, если нажать клавишу . Это с моего syslog-а.

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

Источник

Veeam Log Diving: компоненты и глоссарий

hlxvsi g5k69stzh8

Мы в Veeam любим логи. А поскольку большинство наших решений модульные, то логов они пишут достаточно много. А раз сфера нашей деятельности — это обеспечение сохранности ваших данных (т.е. спокойного сна), то логи должны не только фиксировать каждый чих, но и делать это довольно подробно. Это необходимо чтобы в случае чего было понятно, как это “чего” случилось, кто виноват, и что нужно делать дальше. Тут как в криминалистике: никогда не знаешь, какая мелочь поможет тебе найти убийцу Лоры Палмер.

Читайте также:  в какой период лезут зубы у детей

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

Почему серия статей и почему не описать всё разом?

Просто перечислить, какой лог где лежит и что в нём хранится — затея довольно гиблая. А про поддержание этой информации в актуальном виде даже и думать страшно. Простое перечисление всех возможных видов логов в Veeam Backup & Replication — это таблица на несколько листов мелким шрифтом. Да и актуальна она будет только на момент публикации, т.к. при выходе следующего патча могут появиться новые логи, изменится логика хранимой информации в старых, и т.д. Поэтому гораздо выгоднее будет объяснить их структуру и суть содержащейся в них информации. Это позволит лучше ориентироваться на местах, чем банальная зубрёжка названий.

Поэтому, чтобы не бросаться с головой в омут текстовых простыней, давайте в этой статье проведём некую подготовительную работу. Поэтому сегодня мы не будем залезать в сами логи, а зайдём издалека: составим глоссарий и немного обсудим структуру Veeam с точки зрения генерации логов.

Глоссарий и жаргонизмы

Здесь прежде всего стоит извиниться перед поборникам чистоты русского языка и свидетелями словаря Ожегова. Мы все очень любим свой родной язык, но проклятая IT индустрия работает на английском. Ну вот не мы это придумали, а так исторически сложилось. Не виноватая я, он сам пришёл (с)

В нашем деле проблема англицизмов (и жаргона) имеет свою специфику. Когда под невинными словами вроде «хост» или «гость» весь мир уже давно понимает совершенно конкретные вещи, то на ⅙ части суши продолжается героический разброд и шатание с тыканьем в словари. И строго обязательный аргумент «А вот у нас на работе. ».

Плюс есть чисто наша терминология, которая присуща именно продуктам Veeam, хотя некоторые слова и обороты ушли в народ. Поэтому сейчас мы договоримся, какой термин что значит, и в дальнейшем под словом «гость» я буду иметь в виду именно то, что написано в этой главе, а не то, что вы привыкли у себя на работе. И да, это не лично моя прихоть, это устоявшиеся в индустрии термины. Воевать с ними несколько бессмысленно. Хотя похоливорить в каментах я всегда за.

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

Host (Хост): В мире виртуализации это машина с гипервизором. Физическая, виртуальная, облачная — неважно. Если на чём-то запущен гипервизор (ESXi, Hyper-V, KVM etc), то это «что-то» называется хостом. Будь это кластер на десять стоек или ваш ноутбук с лабой на полторы виртуалки — если запустили гипервизор, то стали хостом. Потому что гипервизор хостит виртуальные машины. Есть даже байка, что VMware в своё время хотела добиться твёрдой ассоциации слова хост именно с ESXi. Но не сдюжила.

В современном мире понятие «хост» практически слилось с понятием «сервер», что вносит определённую смуту в общение, особенно если речь про Windows инфраструктуру. Так что любая машина, на которой находится какой-то интересный нам сервис, может быть смело названа хостом. Например, в логах WinSock словом host помечается всё подряд. Классическое «Host not found» тому примером. Так что исходим из контекста, но помним — в мире виртуализаци хост — это то, что хостит гостей (об этом двумя строчками ниже).

Из локальных жаргонизмов (скорее даже акронимов, в данном случае) тут вспоминается, что VMware — это VI, vSphere — это VC, а Hyper-V — это HV.

Guest (Гость): Виртуальная машина, работающая на хосте. Тут даже и объяснять нечего, настолько всё логично и просто. Однако многие старательно тащат сюда какие-то иные смыслы.

Зачем? Я не знаю.
Guest OS, соответственно, операционка гостевой машины. И так далее.

Backup/Replication Job (джобА): Чисто вимовский жаргонизм, обозначающий какое-то из заданий. Backup job == Бекапная Джоба. Как это красиво перевести на русский — никто не придумал, поэтому все говорят «джобА». С ударением на последний слог.

Да, вот так просто берут и говорят «джоба». И даже в письмах так пишут, и всё хорошо.
Всякие Бекапные работы, Задания Бекапа и т.д., спасибо, но не надо. Просто джоба, и вас поймут. Главное — ударение ставить на последний слог.

Backup (Бэкап, бекап. Для труЪ-олдфагов допускается бакУп): Помимо очевидного (лежащая где-то резервная копия данных), означает ещё и саму джобу (три строчки выше, если уже забыли), в результате которой и появляется тот самый бекапный файл. Вероятно, господа носители английского слишком ленивые, чтобы каждый раз говорить I ran my backup job, поэтому они просто говорят I ran my backup, и все друг дружку отлично понимают. Предлагаю поддержать это замечательное начинание.

Consolidate (Консолидация): Термин, появившийся в ESXi 5.0 Опция в меню работы со снапшотами, запускающая процесс удаления так называемых orphaned снапшотов. То есть снапшотов, которые физически имеются, но выпали из отображаемой логической структуры. Теоретически, данный процесс не должен затронуть отображаемые в менеджере снапшотов файлы, однако бывает всякое. Суть процесса консолидации в том, что данные из снапшота (child disk) записываются в основной (parent) диск. Процесс объединения дисков называется мёржем (merge). Если была отдана команда на консолидацию, то запись о снапшоте может быть удалена из базы раньше, чем снапшот будет смёржен и удалён. И если снапшот не удалось удалить по любой причине, то появляются эти самые orphaned снапшоты. Про работу со снапшотами у VMware есть неплохое KB. И мы тоже как-то про них писали на Хабре.

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

Proxy (Прокси): Важно сразу понять, что Veeam Proxy — это не совсем тоже самое, к чему мы привыкли на полях интернета. В пределах продуктов от Veeam это некая сущность, которая занимается перекладываем данных из одного места в другое. Если не вдаваться в подробности, то VBR — это командный сервер, а прокси — это его рабочие лошадки. То есть прокси — это машина, через которую течёт трафик и на которой установлены компоненты VBR, которые помогают этим трафиком рулить. Например, перекладывать данные из одного канала в другой или просто цеплять к себе диски (HotAdd mode).

Repository (Репозиторий): Технически это просто запись в базе VBR, указывающая на место, где хранятся бекапы, и как к этом месту подключиться. Фактически это может быть как просто CIFS шара, так и отдельный диск, сервер или бакет в облаке. Опять же, находимся в контексте, но понимаем, что репозиторий — это просто место, где лежат ваши бекапы.

В документации и логах ESXi вокруг этого термина творится хаос, и в контексте упоминания снапшотов можно встретить и сами снапшоты, и redo log и даже delta disk. В документации Veeam такого раздрая нет, и снапшот — это снапшот, а редо лог это именно REDO файл, созданный независимым non-persistent диском. REDO файлы удаляются при выключении виртуалки, так что путать их со снапшотами — путь к провалу.

Synthetic (Синтетика): Синтетические бекапы относятся к reverse incremental и forever forward бекапам. Если вы вдруг не сталкивались с этим термином, то это просто один из механизмов, используемых для построения\преобразования бекапной цепочки. Однако в логах также можно встретить понятие Transform, которое используется в рамках создания полных копий из инкрементов (synthetic full).

Task (Таска): Это процесс обработки каждой отдельной машины в рамках джобы. То есть: имеете вы бекапную джобу, куда включено три машины. Значит, каждая машина будет обрабатываться в рамках отдельной таски. Итого, будет четыре лога: основной на джобу и три на таски. Однако тут есть важный нюанс: со временем слово «таска» стало излишне многозначным. Когда мы говорим про общие логи, то подразумеваем, что таска — это именно ВМ. Но свои «таски» есть и на прокси, и на репозитории. Там это может означать и виртуальный диск, и виртуальную машину, и всю джобу. То есть важно не потерять контекст.

Читайте также:  в каком году была война в абхазии и с кем

Veeam %name% Service (Сервис): На благо успешных бекапов трудится сразу несколько сервисов, список которых можно найти в стандартной оснастке. Их имена достаточно прозрачно отражают их суть, однако среди равных есть самый важный — Veeam Backup Service, без которого остальные работать не будут.

VSS: Технически VSS всегда должен обозначать Microsoft Volume Shadow Copy Service. Фактически используется многими как синоним Application-Aware Image Processing. Что, конечно же, категорически неверно, однако это история из разряда «Любой внедорожник можно назвать джипом, и тебя поймут».

Фантастические логи и места, где они обитают

Хочу начать эту главу с раскрытия великой тайны — какое время отображается в логах?

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

Однако визард собирает логи не всех заданий и, например, в случае необходимости изучить логи рестора, фейловера или фейлбека путь ваш лежит в папку %ProgramData%/Veeam/Backup. Это главное логохранилище VBR, а %ProgramData% является скрытой папкой и это нормально. Кстати, место по умолчанию можно переназначить с помощью реестрового ключа типа REG_SZ: LogDirectory в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\.

На линуксовых машинах логи рабочих агентов следует искать в /var/log/VeeamBackup/, если используется рутовый или sudo аккаунт. Если таких привилегий у вас нет, то ищите логи в /tmp/VeeamBackup.

Для Veeam agent for %OS_name% логи надо искать в %ProgramData%/Veeam/Endpoint (или %ProgramData%/Veeam/Backup/Endpoint) и /var/log/veeam соответственно.

Если вы используете Application-Aware Image Processing (а скорее всего вы его используете), то ситуация несколько усложняется. Вам понадобятся логи нашего хелпера, которые хранятся внутри самой виртуалки, и логи VSS. О том, как и где добывать это счастье, подробно написано в этой статье. И, конечно же, есть отдельная статья по сбору необходимых системных логов.

События Windows удобно собирать согласно этой КВ. Если вы используете Hyper-V, дело усложняется, так как вам понадобятся ещё и все его логи из ветки Applications and Service Logs > Microsoft > Windows. Хотя всегда можно пойти более дуболомным путём и просто забрать все объекты из %SystemRoot%\System32\winevt\Logs.

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

Громоздко? Запутано? Страшно? А ведь это даже не половина информации, с которой работает наш саппорт на ежедневной основе. Так что они действительно очень круты.

Компоненты Veeam

И в качестве завершения этой вводной статьи немного поговорим о компонентах Veeam Backup & Replication. Ибо когда ищешь причину болей, неплохо бы было понимать, как устроен пациент.

Итак, как наверняка известно всем, Veeam Backup — это так называемое SQL-based приложение. То есть все настройки, вся информация и вообще всё, что только необходимо для нормального функционирования — всё это находится в его базе. Вернее, в двух базах, если мы говорим про связку VBR и EM: VeeamBackup и VeeamBackupReporting, соответственно. Так и повелось: ставим ещё одно приложение — появляется ещё одна база. Дабы не хранить все яйца в одной корине.

Но чтобы всё это хозяйство работало слаженно, нам понадобится набор сервисов и приложений, которые свяжут все компоненты воедино. Исключительно для примера, вот так это выглядит в одной из моих лабораторий:

image loader

В роли главного дирижёра выступает Veeam Backup Service. Именно он отвечает за обмен информацией с базами. Также он отвечает за запуск всех заданий, занимается оркестрацией выделяемых ресурсов и работает этаким центром коммуникаций для разнообразных консолей, агентов и всего прочего. Словом, без него точно никак, но это совершенно не значит, что он делает всё сам.

В исполнении задуманного ему помогает Veeam Backup Manager. Это не сервис, а сущность, занимающаяся запуском джоб и следящая за процессом их выполнения. Рабочие руки backup service’a, которыми он подсоединяется к хостам, создаёт снапшоты, следит за ретеншеном и так далее.

Но вернёмся к списку сервисов. Veeam Broker Service. Появился в v9.5 (и это не майнер крипты, как тогда подумали некоторые). Занимается сбором информации о VMware хостах и поддержанием её актуальности. Но не бегите сразу писать гневные комментарии, что мы за вами шпионим и сливаем все логины/пароли тащмайору. Всё несколько проще. Когда вы запускаете бекап, то первым делом надо подключиться к хосту и обновить все данные о его структуре. Это довольно медленная и громоздкая история. Просто вспомните, сколько у вас длится операция логина через веб интерфейс, и помните, что там считается только верхний слой. А потом ещё надо всю иерархию раскрыть до нужного места, кстати. Словом, ужас. Если вы запускаете десяток бекапов, значит, каждой джобе надо проделать эту процедуру. Если речь о больших инфраструктурах, то этот процесс может занять минут десять и больше. Поэтому было принято решение выделить под это отдельный сервис, через который можно будет получать всегда актуальную информацию. Он при старте проверяет и сканирует всю добавленную инфраструктуру, а потом старается работать только на уровне инкрементальных изменений. Так что даже если у вас будет запускаться одновременно сто бекапов, они все запросят информацию у нашего брокера, а не будут мучить хосты своими запросами. Если переживаете за ресурсы, то по нашим подсчётам на 5000 виртуалок надо всего около 100 Mb памяти.

Далее у нас идёт Veeam Console. Он же Veeam Remote Console, он же Veeam.Backup.Shell. Это тот самый GUI, который мы видим на скриншотах. Всё просто и очевидно — консоль можно запускать откуда угодно, лишь бы это был Windows и была связь до VBR сервера. Единственное, что можно сказать: FLR процесс будет монтировать точки локально (т.е. на машину, где запущена консоль). Ну и разномастные Veeam Explorers тоже будут запускаться локально, ибо они — часть консоли. Но это меня в дебри уже понесло…

Следующий интересный сервис — Veeam Backup Catalog Data Service. В списке сервисов известен как Veeam Guest Catalog Service. Занимается индексированием файловых систем на гостевых машинах и наполняет этими знаниями папку VBRCatalog. Используется только там, где включена галочка индексации. А включать её есть смысл, только если у вас есть Enterprise Manager. Поэтому совет от всей души: не включайте индексацию просто так, если у вас нет ЕМ. Поберегите свои нервы и время саппорта.

Veeam Data Mover — с помощью запускаемых на проксях (и не только) вспомогательных агентов занимается перекладыванием данных. Например, при бекапе один агент будет читать файлы с датасторы хоста, а второй — их тщательно записывать в бекап.

Отдельно хочется отметить важную вещь, на которую часто реагирую клиенты — это разность версий сервисов и информации в оснастке Programs and Features. Да, список будет одинаковый, а вот в версиях может быть полный раздрай. Это не очень здорово с визуальной точки зрения, однако полностью нормально, если всё работает стабильно. Например, у Installer сервиса номер версии сильно отстаёт от соседних. Ужас и кошмар? Нет, ибо он не переустанавливается целиком, а просто обновляется его DLL. В патче v9.5 U4 произошёл страшный сон техподдержки: при обновлении все сервисы получили новые версии, кроме самого главного. В патче U4b транспортный сервис обогнал все остальные аж на две версии (если судить по цифрам). И это тоже нормально — в нём была найдена серьёзная бага, поэтому он получил бонусное обновление относительно остальных. Поэтому, подводя итог: разница версий МОЖЕТ быть проблемой, но если разница присутствует, а все работает исправно, то скорее всего так и надо. Но никто вам не запрещает уточнить это в техподдержке.

Это были так называемые обязательные или Mandatory services. А есть ещё целая пачка вспомогательных, таких, как Tape Service, Mount Service, vPowerNFS Service и так далее.

Для Hyper-V в целом всё тоже самое, только есть специфичный Veeam Backup Hyper-V Integration Service и свой драйвер для работы с CBT.

В случае Linux машин всё намного проще из-за наличия большого количества встроенных библиотек и возможностей самой системы. Например, индексинг делается через mlocate.

Источник

Поделиться с друзьями
admin
Adblock
detector