Відмовостійкість

OpenTelemetry Collector розроблено з компонентами та конфігураціями, які мінімізують втрату даних під час обробки та експорту телеметрії. Однак, розуміння потенційних сценаріїв, в яких може статися втрата даних, і способів їх мінімізації, має вирішальне значення для забезпечення відмовостійкості конвеєра спостережуваності.

Розуміння відмовостійкості колектора

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

Відмовостійкість колектора в першу чергу залежить від того, як він обробляє дані, коли налаштована точка доступу (місце призначення трейсів, метрик або журналів) стає недоступною або коли сам екземпляр колектора зазнає проблем, таких як збої в роботі.

Черга надсилання (буферизація в памʼяті)

Найпростіша форма відмовостійкості, вбудована в експортери колектора, — це черга надсилання.

• Як вона працює: Коли експортер налаштовано, він зазвичай включає чергу надсилання, яка буферизує дані в памʼяті, перш ніж надсилати їх до точки призначення, що знаходиться далі за ланцюжком потоку даних. Якщо точка призначення доступна, дані проходять через неї швидко.

• Обробка недоступності точки призначення: Якщо точка призначення стає недоступною, наприклад, через проблеми з мережею або перезавантаження серверної частини, експортер не може негайно надіслати дані. Замість того, щоб видалити дані, він додає їх до черги на надсилання в памʼяті.

• Механізм повторної спроби: Колектор використовує механізм повторних спроб з експоненціальною затримкою і відставанням. Він буде повторювати спроби надіслати буферизовані дані після інтервалів очікування. Стандартно, повторні спроби тривають до 5 хвилин.

• Сценарій втрати даних:

  • Переповнення черги: черга в памʼяті має розмір, що налаштовується ( зазвичай це 1000 пакетів/запитів). Якщо точка доступу залишається недоступною, а нові дані продовжують надходити, черга може переповнитися. Після заповнення черги вхідні дані відкидаються, щоб запобігти вичерпанню памʼяті Колектора.
  • Тайм-аут повторів: Якщо точка доступу залишається недоступною довше, ніж налаштована максимальна тривалість повторної спроби (стандартно 5 хвилин), колектор припинить повторні спроби для найстаріших даних у черзі і видалить їх.

• Налаштування: Ви можете налаштувати розмір черги та поведінку повторних спроб у налаштуваннях експортера:

  exporters:
    otlp:
      endpoint: otlp.example.com:4317
      sending_queue:
        storage: file_storage
        queue_size: 5_000 # Збільшити розмір черги (стандартно 1000)
      retry_on_failure:
        initial_interval: 5s
        max_interval: 30s
        max_elapsed_time: 10m # Збільшити максимальний час повторної спроби (стандартно 300 секунд)
  

Постійне сховище (write-ahead log - WAL)

Для захисту від втрати даних у разі збою або перезапуску самого екземпляра колектора, ви можете увімкнути постійне сховище для черги надсилання за допомогою розширення file_storage.

• Як це працює: Замість того, щоб просто буферизуватися в памʼяті, черга надсилання записує дані до журналу попереднього запису (Write-Ahead Log, WAL) на диску перед спробою експорту.

• Обробка збоїв колектора: Якщо колектор аварійно завершує роботу, коли дані перебувають у черзі, вони зберігаються на диску. Після перезапуску колектор зчитує дані з WAL і відновлює спроби надіслати їх до точки призначення.

• Сценарій втрати даних: Втрата даних може статися, якщо диск вийшов з ладу або на ньому закінчилося місце, або якщо точка призначення залишається недоступною за межами ліміту повторних спроб навіть після перезапуску колектора. Гарантії можуть бути не такими надійними, як у випадку з виділеними чергами повідомлень.

• Налаштування:

  1. Визначте розширення file_storage.
  2. Вкажіть ідентифікатор сховища у конфігурації sending_queue експортера.

  extensions:
    file_storage: # Визначте екземпляр розширення
      directory: /var/lib/otelcol/storage # Виберіть постійну теку
  
  exporters:
    otlp:
      endpoint: otlp.example.com:4317
      sending_queue:
        storage: file_storage # Посилання на екземпляр розширення сховища
  
  service:
    extensions: [file_storage] # Увімкніть розширення в конвеєрі обслуговування
    pipelines:
      traces:
        receivers: [otlp]
        exporters: [otlp]
  

Черги повідомлень

Для забезпечення найвищого рівня відмовостійкості, особливо між різними рівнями колекторів (наприклад, від Агента до Gateway) або між вашою інфраструктурою та бекендом постачальника, ви можете запровадити спеціальну чергу повідомлень, як у Kafka.

• Як це працює: Один екземпляр колектора (агент) експортує дані до топіку Kafka за допомогою експортера Kafka. Інший екземпляр Колектора (Gateway) бере дані з топіка Kafka за допомогою приймача Kafka.
• Обробка недоступності точки доступу/колектора:
  • Якщо колектор-споживач (Gateway) не працює, повідомлення просто накопичуються в топіку Kafka (в межах лімітів зберігання Kafka). Поки Kafka працює, це не впливає на колектор (Агента), що надсилає повідомлення, поки Kafka працює.
  • Якщо ж колектор (Агент) не працює, нові дані не потрапляють до черги, але споживач може продовжувати обробляти наявні повідомлення.
  • Якщо Kafka сам не працює, Колектор-виробник потребує власного механізму відмовостійкості (наприклад, черги надсилання, можливо, з WAL) для буферизації даних, призначених для Kafka.
• Сценарій втрати даних: Втрата даних передусім повʼязана з самим Kafka (збій кластера, неправильна конфігурація топіків, закінчення терміну дії даних) або з нездатністю виробника надсилати дані до Kafka без належної локальної буферизації.
• Конфігурація:

  • Конфігурація Колектора Агента (Producer):

    exporters:
      kafka:
        brokers: ['kafka-broker1:9092', 'kafka-broker2:9092']
        topic: otlp_traces
    
    receivers:
      otlp:
        protocols:
          grpc:
    
    service:
      pipelines:
        traces:
          receivers: [otlp]
          exporters: [kafka]
    

  • Конфігурація Колектора Gateway (Consumer):

    receivers:
      kafka:
        brokers: ['kafka-broker1:9092', 'kafka-broker2:9092']
        topic: otlp_traces
        initial_offset: earliest # Обрбка беклогу
    
    exporters:
      otlp:
        endpoint: otlp.example.com:4317
        # Розглянемо чергу/повторну спробу для експорту *з* Gateway до Backend
    
    service:
      pipelines:
        traces:
          receivers: [kafka]
          exporters: [otlp]
    

Обставини втрати даних

Втрата даних може статися за таких обставин:

1. Відсутність мережі + тайм-аут: Низхідна (downstream) точка доступу недоступна довше, ніж заданий час max_elapsed_time у налаштуваннях retry_on_failure.
2. Відсутність мережі + переповнення черги: Низхідна точка доступу недоступна, а черга надсилання (в памʼяті або постійна) переповнюється до того, як точка доступу відновлюється. Нові дані втрачаються.
3. Збій колектора (без постійного збереження): Екземпляр колектора аварійно завершує свою роботу, а він використовував лише чергу надсилання в памʼяті. Дані в памʼяті втрачено.
4. Збій постійного сховища: Диск, який використовується розширенням file_storage, вийшов з ладу або на ньому закінчилося місце.
5. Збій у черзі повідомлень: Зовнішня черга повідомлень (наприклад, Kafka) зазнає збою або втрати даних, а колектор, що створює повідомлення, не має достатньої локальної буферизації.
6. Неправильна конфігурація: Експортери або приймачі налаштовані неправильно, що перешкоджає потоку даних.
7. Відключена відмовостійкість: У конфігурації явно вимкнено черги надсилання або механізми повторних спроб.

Рекомендації щодо запобігання втраті даних

Дотримуйтесь цих рекомендацій, щоб мінімізувати втрату даних і забезпечити надійний збір телеметричних даних:

1. Завжди використовуйте черги надсилання: Увімкніть sending_queue для експортерів, які надсилають дані мережею.
2. Відстежуйте метрики колекторів: Активно відстежуйте otelcol_exporter_queue_size, otelcol_exporter_queue_capacity, otelcol_exporter_send_failed_spans (та еквіваленти для метрик/логів) для раннього виявлення потенційних проблем.
3. Налаштуйте розмір черги та повторні спроби: Налаштуйте параметри queue_size і retry_on_failure відповідно до очікуваного навантаження, ресурсів памʼяті/диска та допустимого часу простою точок доступу.
4. Використовувати постійне сховище (WAL): для агентів або шлюзів, де втрата даних під час перезапуску колектора неприпустима, налаштуйте розширення file_storage для черги надсилання.
5. Подумайте про черги повідомлень: Для забезпечення максимальної довговічності в різних сегментах мережі або для розділення рівнів колектора використовуйте керовану чергу повідомлень, наприклад, Kafka, якщо операційні накладні витрати є прийнятними.
6. Використовуйте відповідні шаблони розгортання:
   • Використовуйте архітектуру агент + шлюз. Агенти відповідають за локальний збір, а шлюзи — за обробку, пакетну передачу та відмовостійкий експорт.
   • Зосередьте зусилля щодо відмовостійкості (черги, WAL, Kafka) на мережевих переходах: Агент -> Шлюз і Шлюз -> Бекенд.
   • Стійкість між застосунком (SDK) і локальним агентом (Sidecar/DaemonSet) часто менш критична через надійну локальну мережу; додавання черг тут іноді може негативно вплинути на роботу застосунку, якщо агент недоступний.

Розуміючи ці механізми і застосовуючи відповідні конфігурації, ви можете значно підвищити відмовостійкість вашого розгортання OpenTelemetry Collector і звести до мінімуму втрату даних.