refinery
v2.8.4
Подробный список связанных запросов на вытягивание, объединенные в каждом выпуске, см. Changelog.md. Для получения более читаемой информации о недавних изменениях см. В релизе_notes.md.
Некстояние представляет собой прокси-прокси на основе хвоста и работает на уровне целого следа. Некстояние рассматривает целые следы и разумно применяет решения отбора проб к каждому следу. Эти решения определяют, следует ли хранить или отбросить данные трассировки в отбранных данных, направленных в соты.
Модель выборки на основе хвоста позволяет вам одновременно осматривать целый трассировку и принять решение о выборке на основе его содержимого. Например, ваши данные могут иметь корневой промежуток, который содержит код состояния HTTP для обслуживания запроса, и другой промежуток, который содержит информацию о том, были ли данные обслуживались из кэша. Используя нефтеперерабатывающий завод, вы можете сохранить только следы, которые имели код состояния 500 , а также обслуживались из кэша.
Нефтеперерабатывающая поддержка несколько видов отбора проб хвоста:
http.status_code , вы можете включить в свои отобранные данные:2xx4xx5xxНекстояние позволяет вам объединить все вышеперечисленные методы для достижения желаемого поведения отбора проб.
Нефтеперерабатывающий завод предназначен для того, чтобы сидеть в вашей инфраструктуре, где все следы могут достичь ее. Нефтеперерабатывающий завод может работать отдельно или быть развернутым в кластере из двух или более процессов нефтеперерабатывающих заводов, доступных через отдельный балансировщик нагрузки.
Процессы нефтеперерабатывающего завода должны быть в состоянии общаться друг с другом, чтобы сосредоточиться на отдельных серверах.
В рамках вашего приложения (или других источников событий сотовых сообщений) вы настроите API Host как http(s)://load-balancer/ . Все остальное остается тем же, например, ключ API, имя набора данных и так далее, поскольку все, что живет с исходным клиентом.
Каждый экземпляр нефтеперерабатывающего завода должен иметь минимум:
linux/amd64 или linux/arm64Во многих случаях нефтеперерабатывающий завод нуждается только один узел. Если вам может потребоваться масштабировать большой объем трафика, вам может потребоваться масштабировать несколько узлов, и, вероятно, потребуется небольшой экземпляр REDIS для обработки масштабирования.
Мы рекомендуем увеличить количество оперативной памяти и количество ядер после первоначальной настройки. Дополнительная оперативная память и процессор могут использоваться путем увеличения значений конфигурации; В частности, CacheCapacity является важным значением конфигурации. Система Stress Relief нефтеперерабатывающего завода дает хорошее представление о том, как работает трудный нефтеперерабатывающий завод, и при вызове журналы (как reason ) название значения конфигурации нефтеперерабатывающего завода, которое должно быть увеличено, чтобы уменьшить стресс. Используйте нашу документацию по масштабированию и устранению неполадок, чтобы узнать больше.
Некстояние доступно в качестве хлевов в хранилище Honeycomb Helm.
Вы можете установить нефтеперерабатывающий завод со следующей командой, которая использует файл значений по умолчанию:
helm repo add honeycomb https://honeycombio.github.io/helm-charts
helm install refinery honeycomb/refineryВ качестве альтернативы, предоставьте свой собственный файл значений:
helm install refinery honeycomb/refinery --values /path/to/refinery-values.yaml где /path/to/refinery-values.yaml -это путь файла.
Работая в кластере, нефтеперерабатывающий завод рассчитывает собрать все пролеты в следах на один экземпляр, чтобы он мог принять решение следов. Поскольку каждый пролет прибывает независимо, каждый экземпляр нефтеперерабатывающего завода должен иметь возможность общаться со всеми его сверстниками, чтобы распространять трассировки по правильному экземпляру.
Этим сообщением можно управлять двумя способами: через явный список одноранговых одноранговых коллег в файле конфигурации или с использованием саморегистрации через общий кэш Redis. Инсталляции обычно предпочитают использовать Redis. Даже в больших установках нагрузка на сервер Redis довольно легкая, каждый экземпляр делает только несколько запросов в минуту. Обычный экземпляр REDIS с дробным процессором обычно достаточно.
Конфигурация контролируется двумя файлами конфигурации нефтеперерабатывающего завода, которые обычно называют config.yaml для общей конфигурации и rules.yaml . YAML для конфигурации выборки. Эти файлы могут быть загружены из доступной файловой системы или загружены с помощью неаутентированного запроса GET из URL.
Узнайте больше о config.yaml и всех параметрах, которые управляют работой нефтеперерабатывающего завода в нашей документации по конфигурации нефтеперерабатывающего завода.
Узнайте больше о правилах. Конфигурация rules.yaml и Sampler в нашей документации с отбора проб.
Это действительно указать более одного источника конфигурации. Например, можно было бы иметь общий файл конфигурации, а также отдельный файл, содержащий только клавиши. В командной строке укажите несколько файлов, повторяя коммутатор командной строки. В переменных среды разделяйте несколько мест конфигурации с запятыми.
Некстояние является типичным приложением командной строки в стиле Linux и поддерживает несколько коммутаторов командной строки.
refinery -h напечатает расширенный текст справки, в котором указано все параметры командной строки и переменные поддерживаемой среды.
Некстояние поддерживает следующие ключевые переменные среды; Пожалуйста, смотрите помощь командной строки или онлайн -документацию для полного списка. Переключатели командной строки имеют приоритет над конфигурацией файла, а переменные среды имеют приоритет над обоими.
| Переменная среды | Поле конфигурации |
|---|---|
REFINERY_GRPC_LISTEN_ADDRESS | GRPCListenAddr |
REFINERY_REDIS_HOST | PeerManagement.RedisHost |
REFINERY_REDIS_USERNAME | PeerManagement.RedisUsername |
REFINERY_REDIS_PASSWORD | PeerManagement.RedisPassword |
REFINERY_HONEYCOMB_API_KEY | HoneycombLogger.LoggerAPIKey |
REFINERY_HONEYCOMB_METRICS_API_KEY | LegacyMetrics.APIKey |
REFINERY_HONEYCOMB_API_KEY | LegacyMetrics.APIKey |
REFINERY_QUERY_AUTH_TOKEN | QueryAuthToken |
ПРИМЕЧАНИЕ. REFINERY_HONEYCOMB_METRICS_API_KEY имеет приоритет над REFINERY_HONEYCOMB_API_KEY для конфигурации LegacyMetrics.APIKey .
Отправка данных в Honeycomb требует подключения ключа API к телеметрии. Чтобы упростить управление телеметрией, нефтеперерабатывающий завод поддерживает параметры конфигурации ReceiveKeys и SendKey , а также AcceptOnlyListedKeys и SendKeyMode . В различных комбинациях они обладают много выразительной силы. Пожалуйста, смотрите документацию по конфигурации для получения подробной информации о том, как установить эти параметры.
Быстрый старт для конкретных сценариев ниже:
SendKey на действительный ключ сотовой связиSendKeyMode на allSendKey на действительный ключ сотовой связиSendKeyMode в nonblankReceiveKeys в список исключенийSendKey на действительный ключ сотовой связиSendKeyMode в unlistedSendKey на действительный ключ сотовой связиSendKeyMode в missingonlyReceiveKeysAcceptOnlyListedKeys на trueSendKey на действительный ключ сотовой связиSendKeyMode в listedonlyAcceptOnlyListedKeys в falseReceiveKeys в ключи, которые должны быть замененыSendKey на действительный ключ сотовой связиSendKeyMode в listedonly + Примечание + + При использовании пили с классическим ключом API для отправки данных на нефтеперерабатывающий завод убедитесь, что SendKey также является классическим ключом, а не ключом для среды и сервиса (E & S).
При начале работы с нефтеперерабатывающим заводом или при обновлении правил выборки может быть полезно убедиться, что правила работают, как и ожидалось, прежде чем вы начнете сбрасывать трафик. Для этого используйте режим сухого запуска на нефтеперерабатывающем заводе.
Включите режим сухого запуска, добавив DryRun = true в ваш файл конфигурации ( config.yaml ). Затем используйте «Строитель запросов» в пользовательском интерфейсе Honeycomb, чтобы запустить запросы, чтобы проверить ваши результаты и убедиться, что правила работают в соответствии с задумами.
Когда режим сухого запуска включен, Metric trace_send_kept увеличит для каждого трассировки, а метрика для trace_send_dropped останется 0 , отражая, что мы отправляем все следы в соты.
Рекламный завод использует ограниченные очереди и круговые буферы для управления распределением трассировщиков, поэтому даже при использовании памяти с высокой громкостью не должно значительно расширяться. Однако, учитывая, что следы хранятся в круглом буфере, когда пропускная способность трассов превышает размер буфера, все начнет идти не так. Если у вас настроена статистика, счетчик с именем collect_cache_buffer_overrun будет увеличиваться каждый раз, когда это происходит. Симптомы этого будут заключаться в том, что следы перестанут собираться вместе, и вместо этого пролеты, которые должны быть частью одной и той же трассы, будут рассматриваться как два отдельных следа. Все следы будут по -прежнему отправляться (и выборки), но некоторые решения отбора проб будут приняты на неполные данные. Размер круглого буфера - это параметр конфигурации с именем CacheCapacity . Чтобы выбрать хорошее значение, вам следует рассмотреть пропускную способность следов (например, трассировки / второй запуск) и умножить это на максимальную продолжительность трассировки (например, 3 секунды), затем умножьте это на какой -то большой буфер (возможно, 10x) Полем Эта оценка даст хороший запас.
Определение количества машин, необходимых в кластере, не является точной наукой, и лучше всего влияет на наблюдение за перерасходом буфера. Но для грубой эвристики рассчитывайте на одну машину, используя около 2 ГБ памяти для обработки 5000 входящих событий и отслеживания 500 подсекундных трассов в секунду (для каждой полной трассировки длится менее второго и среднего размера 10 пролетов на трассировку) Полем
Нефтеперерабатывающий завод предлагает механизм, называемый Stress Relief , который улучшает стабильность при тяжелой нагрузке. Метрика stress_level представляет собой синтетическую метрику по шкале от 0 до 100, которая построена из нескольких метриков нефтеперерабатывающего завода, связанных с размерами очередей и использованием памяти. При нормальной работе его значение обычно должно быть в однозначных цифрах. Во время всплесков высокого трафика уровни напряжения могут появиться, а затем снова упасть, когда объем падает. Когда он приближается к 100, становится все более и чаще, что нефтеперерабатывающий завод начинает терпеть неудачу и, возможно, разбиться.
Stress Relief - это система, которая может контролировать метрику stress_level и сбросить нагрузку, когда напряжение становится опасной для стабильности. Как только ActivationLevel достигнут, режим Stress Relief станет активным. В этом состоянии. Некстояние детерминированно пробежит каждый размах на основе TraceID без необходимости хранить оставшуюся часть трассировки или оценивать условия правила. Stress Relief останется активным до тех пор, пока стресс не упадет ниже DeactivationLevel указанного в конфигурации.
Настройки снятия стресса:
Mode - настройка, чтобы указать, как используется Stress Relief . never указывает, что Stress Relief не будет активировано. monitor означает Stress Relief активируется при ActivationLevel и деактивации, когда достигнут. always означает, что режим Stress Relief будет постоянно задействовать. Режим always предназначен для использования в чрезвычайных ситуациях.ActivationLevel - Когда уровень напряжения повышается выше этого порога, нефтеперерабатывающий завод будет активировать Stress Relief .DeactivationLevel - Когда уровень стресса падает ниже этого порога, нефтеперерабатывающий завод будет деактивировать Stress Relief .SamplingRate - скорость, с которой активен пробы нефтеперерабатывающего завода при Stress Relief . В настоящее время The stress_level является лучшим прокси для общей нагрузки на нефтеперерабатывающем заводе. Даже если Stress Relief не является активным, если stress_level часто выше 50, это хороший показатель, что нефтеперерабатывающему заводу требуется больше ресурсов - больше процессоров, больше памяти или больше узлов. С другой стороны, если stress_level никогда не входит в двузначные цифры, вероятно, что нефтеперерабатывающий завод чрезмерный.
Некстояние излучает ряд показателей, чтобы дать некоторое представление о здоровье процесса. Эти показатели должны быть отправлены в соты, обычно с открытой телеметрией, а также могут подвергаться воздействию Прометея. Интересные, чтобы посмотреть:
[incoming|peer]_router_* : Сколько событий (без трассировки) против пролетов (следовать информацией) было принято, и сколько отправлено на сверстников?collect_cache_buffer_overrun : это должно оставаться нулевым; Положительное значение указывает на необходимость увеличения размера кругового буфера нефтеперерабатывающего завода (через конфигурацию CacheCapacity ).process_uptime_seconds : записывает время выполнения каждого процесса; Ищите неожиданные перезагрузки как ключ к ограничениям памяти. Уровень ведения warn по умолчанию довольно тихо. Уровень debug излучает слишком много данных, которые будут использоваться в производстве, но содержит отличную информацию в предварительной среде, включая информацию о решении трассировки. info где -то между. Установка уровня журнала для debug во время начальной конфигурации поможет понять, что работает, а что нет, но когда объемы трафика увеличиваются, его следует настроить, чтобы warn или даже error . Журналы могут быть отправлены в Stdout или на сот.
Некрининг проверяет свою конфигурацию при запуске или когда конфигурация перезагружена, и он издает диагностику для любых проблем. При запуске он откажется начать; При перезагрузке это не изменит существующую конфигурацию.
Проверьте загруженную конфигурацию, используя одну из конечных точек /query из командной строки на сервере, который может получить доступ к хосту нефтеперерабатывающего завода.
Конечные точки /query защищены и могут быть включены путем указания QueryAuthToken в файле конфигурации или указания REFINERY_QUERY_AUTH_TOKEN в среде. Все запросы на любую конечную точку /query должны включать заголовок X-Honeycomb-Refinery-Query установленную для значения указанного токена.
Для конфигураций на основе файлов (единственного типа, поддерживаемого в настоящее время), значение hash идентично значению, сгенерированному командой md5sum для данного файла конфигурации.
Для всех этих команд:
$REFINERY_HOST должен быть URL вашего нефтеперерабатывающего завода.$FORMAT может быть одним из yaml , toml или json .$DATASET - это имя набора данных, который вы хотите проверить.Чтобы получить всю конфигурацию правил:
curl --include --get $REFINERY_HOST/query/allrules/$FORMAT --header "x-honeycomb-refinery-query: my-local-token"
Чтобы получить набор правил, который нефтеперерабатывающий завод использует для указанного набора данных, который будет возвращен в качестве карты типа Sampler для его набора правил:
curl --include --get $REFINERY_HOST/query/rules/$FORMAT/$DATASET --header "x-honeycomb-refinery-query: my-local-token"
Для получения информации об используемых в настоящее время конфигурациях, включая временную метку, когда конфигурация была последней загруженной:
curl --include --get $REFINERY_HOST/query/configmetadata --header "x-honeycomb-refinery-query: my-local-token"
Некстояние может отправлять телеметрию, которая включает информацию, которая может помочь отладить решения о выборке, которые принимаются. Чтобы включить, в файле конфигурации установите AddRuleReasonToTrace на true . Это приведет к тому, что следы, которые отправляются в Honeycomb, включают в себя полевую meta.refinery.reason
Нефтеперерабатывающий завод еще не буферирует следы или решения выборки на диск. Когда вы перезагружаете процесс, все следы в полете будут промыть (отправлено вверх по течению в Honeycomb), но вы потеряете запись прошлых решений следов. Когда начнется обратно, он начнется с чистого сланца.
В каждом каталоге интерфейс экспорт зависимости находится в файле с тем же именем, что и каталог, а затем (по большей части) каждый из других файлов является альтернативными реализациями этого интерфейса. Например, в logger , /logger/logger.go logger.go содержит определение интерфейса, а logger/honeycomb.go содержит реализацию интерфейса logger , который будет отправлять журналы в Honeycomb.
main.go устанавливает приложение и делает выбор, которые о том, какие версии реализаций зависимостей использовать (например, какой регистратор, какой пробоотборник и т. Д.) Он запускает все, а затем запускает App .
app/app.go является основной контрольной точкой. Когда его Start функция заканчивается, программа отключается. Он запускает два Router , которые слушают входящие события.
route/route.go слушает в сети для входящего трафика. Есть два маршрутизатора, и они обрабатывают различные типы входящего трафика: события, поступающие из внешнего мира ( incoming маршрутизатор) и события, исходящие от другого члена кафедры кластера ( peer Traffic). Как только он получает событие, оно решает, куда оно должно идти дальше: это входящее запрос событием (или партией событий), и если да, то есть ли у него идентификатор трассировки? Все, что не является событием или событием, у которого нет идентификатора трассировки, немедленно передается transmission , которая будет направлена на Honeycomb. Если это событие с идентификатором трассировки, маршрутизатор извлекает идентификатор трассировки, а затем использует sharder чтобы решить, какой член нефтеперерабатывающего кластера должен обрабатывать эту трассу. Если это сверстник, событие будет направлено на этот сверстник. Если это мы, событие будет преобразовано во внутреннее представление и передано collector чтобы объединить пролеты в следы.
collect/collect.go Коллекционер несет ответственность за то, что объединяет просеивание в следах и принятие решения о том, когда отправить их в соты или если его следует сбросить. В первый раз, когда наблюдается идентификатор трассировки, коллекционер запускает таймер. Если корневой пролет, который является пролетом с идентификатором трассировки и без родителей, прибывает до истечения срока действия таймера, то трассировка считается завершенной. След отправляется, и таймер отменяется. Если таймер истекает до появления корневого промежутка, трассировка будет отправлена независимо от того, будет ли он завершен. Непосредственно перед отправкой коллекционер просит sampler о показателе дискретизации и о том, сохраняет ли след. Коллекционер подчиняется этому решению о отборе отбора проб и записывает его (запись применяется к любым пролетам, которые могут появиться как часть трассировки после принятия решения). После принятия решения о выборке, если след должен быть сохранен, оно передается в transmission для фактической отправки.
transmit/transmit.go - это обертка вокруг HTTP -взаимодействия с Honeycomb API. Он обрабатывает пакетные события вместе и отправляет их вверх по течению.
logger и metrics предназначены для управления журналами и метриками, которые производит сам нефтеперерабатывающий завод.
sampler содержит алгоритмы для вычисления скоростей дискретизации на основе предоставленных трассов.
sharder определяет, какой Peer в кластерной конфигурации нефтеперерабатывающего завода должен обрабатывать отдельный след.
types содержат несколько определений типа, которые используются для вручную данные между пакетами.
