Шаблон розгортання — Gateway

Схема розгортання шлюзу-колектора складається з застосунків або інших колекторів, які надсилають телеметричні сигнали до єдиної точки кінцевого доступу OTLP. Ця точка доступу надається одним або кількома екземплярами колектора, що працюють як самостійний сервіс, наприклад, у Kubernetes deployment. Зазвичай точка доступу надається для кожного кластера, центру обробки даних або регіону.

У загальному випадку ви можете використовувати готовий балансувальник навантаження для розподілу навантаження між Колекторами. У цій однорівневій схемі балансувальник навантаження є зовнішнім щодо екземплярів Колектора:

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

На наступній діаграмі показано цю дворівневу конфігурацію. На відміну від зовнішнього балансувальника навантаження на попередній діаграмі, компонент із позначкою Load Balancer тут є Колектором першого рівня, який використовує експортер з балансуванням навантаження:

1. У застосунку SDK налаштовано на надсилання даних OTLP до центрального місця.
2. Колектор першого рівня налаштований на використання експортера з балансуванням навантаження для розподілу сигналів між групою Колекторів другого рівня.
3. Колектори другого рівня надсилають телеметричні дані до одного або кількох бекендів.

Приклади

Наступні приклади показують, як налаштувати шлюз-колектор із загальними компонентами.

NGINX як “готовий” балансувальник навантаження

Припустимо, у вас є три колектори (collector1, collector2 та collector3), налаштовані, і ви хочете балансувати трафік між ними за допомогою NGINX, ви можете використовувати наступну конфігурацію:

server {
    listen 4317 http2;
    server_name _;

    location / {
            grpc_pass      grpc://collector4317;
            grpc_next_upstream     error timeout invalid_header http_500;
            grpc_connect_timeout   2;
            grpc_set_header        Host            $host;
            grpc_set_header        X-Real-IP       $remote_addr;
            grpc_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 4318;
    server_name _;

    location / {
            proxy_pass      http://collector4318;
            proxy_redirect  off;
            proxy_next_upstream     error timeout invalid_header http_500;
            proxy_connect_timeout   2;
            proxy_set_header        Host            $host;
            proxy_set_header        X-Real-IP       $remote_addr;
            proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

upstream collector4317 {
    server collector1:4317;
    server collector2:4317;
    server collector3:4317;
}

upstream collector4318 {
    server collector1:4318;
    server collector2:4318;
    server collector3:4318;
}

Експортер балансування навантаження

Для конкретного прикладу централізованої моделі розгортання Колектора спочатку розглянемо експортер з балансуванням навантаження. Він має два основні поля конфігурації:

• resolver визначає де знайти підлеглі (downstream) Колектори або бекенди. Якщо ви використовуєте субключ static, вам треба вручну вказати всі URL-адреси Колекторів. Інший підтримуваний резолвер — це DNS резолвер, який періодично перевіряє оновлення та виявляє IP-адреси. Для цього типу резолвера підключення hostname вказує імʼя хосту для запиту, щоб отримати список IP-адрес.
• Полем routing_key вказує експортеру маршрутизувати відрізки до конкретних підлеглих Колекторів. Якщо ви встановите це поле на traceID, експортер з балансуванням навантаження експортує відрізки на основі їх traceID. В іншому випадку, якщо ви використовуєте service як значення для routing_key, він експортує відрізки на основі назви їх сервісу, що корисно при використанні конекторів, таких як конектор метрик відрізків, щоб усі відрізки сервісу надсилалися до одного і того ж підлеглого Колектора для збору метрик, гарантуючи точні агрегування.

Колектор першого рівня, що обслуговує точку доступу OTLP, буде налаштований, як показано нижче:

• Static
• DNS
• DNS with service

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters:
  load_balancing:
    protocol:
      otlp:
        tls:
          insecure: true
    resolver:
      static:
        hostnames:
          - collector-1.example.com:4317
          - collector-2.example.com:5317
          - collector-3.example.com

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [load_balancing]

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters:
  load_balancing:
    protocol:
      otlp:
        tls:
          insecure: true
    resolver:
      dns:
        hostname: collectors.example.com

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [load_balancing]

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters:
  load_balancing:
    routing_key: service
    protocol:
      otlp:
        tls:
          insecure: true
    resolver:
      dns:
        hostname: collectors.example.com
        port: 5317

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [load_balancing]

Експортер балансування навантаження генерує метрики, включаючи otelcol_loadbalancer_num_backends та otelcol_loadbalancer_backend_latency, які ви можете використовувати для моніторингу справності та продуктивності Колектора точки доступу OTLP.

Компроміси

Переваги:

• Розділення обовʼязків, таких як централізоване управління обліковими даними
• Централізоване управління політиками (наприклад, фільтрація певних логів або вибірковий відбір)

Недоліки:

• Це ще одна річ, яку потрібно підтримувати і яка може вийти з ладу (складність)
• Додана затримка у випадку каскадних колекторів
• Вищі загальні витрати ресурсів (витрати)

Кілька Колекторів та принцип єдиного записувача

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

Потенційні проблеми

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

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

Error on ingesting out-of-order samples

Ця помилка може вказувати на те, що в двох завданнях існують однакові цілі, а порядок міток часу неправильний. Наприклад:

• Метрика M1 отримана в T1 з міткою часу 13:56:04 зі значенням 100
• Метрика M1 отримана в T2 з міткою часу 13:56:24 зі значенням 120
• Метрика M1 отримана в T3 з міткою часу 13:56:04 зі значенням 110
• Метрика M1 отримана в 13:56:24 зі значенням 120
• Метрика M1 отримана в 13:56:04 зі значенням 110

Поради

• Використовуйте обробник атрибутів Kubernetes для додавання міток до різних ресурсів Kubernetes.
• Використовуйте процесор виявлення ресурсів для виявлення інформації про ресурси на хості та збору метаданих про ресурси.

Наступні кроки

Дізнайтеся, як поєднати шаблони агента та шлюзу для створення надійної та масштабованої архітектури Колектора.