Свободный поиск эластичных материалов с помощью kubernetes-ingress - PullRequest
Новая
       40

Свободный поиск эластичных материалов с помощью kubernetes-ingress

0 голосов
/ 06 ноября 2019

Я настроил ElasticSearch в кластере Kubernetes. В кластере Kubernetes для приложения я настроил fluentd, используя схему управления THIS , со следующими параметрами: 

    spec:
      containers:
      - env:
        - name: FLUENTD_ARGS
          value: --no-supervisor -q
        - name: OUTPUT_HOST
          value: x.x.x.x
        - name: OUTPUT_PORT
          value: "80"
        - name: OUTPUT_PATH
          value: /elastic
        - name: LOGSTASH_PREFIX
          value: logstash
        - name: OUTPUT_SCHEME
          value: http
        - name: OUTPUT_SSL_VERIFY
          value: "false"
        - name: OUTPUT_SSL_VERSION
          value: TLSv1_2
        - name: OUTPUT_TYPE_NAME
          value: _doc
        - name: OUTPUT_BUFFER_CHUNK_LIMIT
          value: 2M
        - name: OUTPUT_BUFFER_QUEUE_LIMIT
          value: "8"
        - name: OUTPUT_LOG_LEVEL
          value: info

В кластере ElasticSearch у меня настроен контроллер ввода-вывода nginx, и я хочу, чтобы fluentdотправлять логи в Elasticsearch через этот вход nginx. В "OUTPUT_HOST" я использую публичный IP-адрес nginx. В «OUTPUT_PORT» я использовал «80», поскольку nginx прослушивает 80.

Я получаю следующую ошибку в fluentd: 

2019-11-06 07:16:46 +0000 [warn]: [elasticsearch] failed to flush the buffer. retry_time=40 next_retry_seconds=2019-11-06 07:17:18 +0000 chunk="596a7f6afffad60f2b28a5e13f" error_class=Fluent::Plugin::ElasticsearchOutput::RecoverableRequestFailure error="could not push logs to Elasticsearch cluster ({:host=>\"x.x.x.x\", :port=>80, :scheme=>\"http\", :path=>\"/elastic\"}): [405] {\"error\":\"Incorrect HTTP method for uri [/] and method [POST], allowed: [HEAD, GET, DELETE]\",\"status\":405}"

Я могу догадаться, посмотрев журнал, эторассматривает "/astic" в качестве индекса.

В упомянутом ЗДЕСЬ используется аннотация "nginx.ingress.kubernetes.io/rewrite-target: /", но проблема сохраняется.

После этого я изменил nginx-ingress, чтобы прослушивать вызовы по "/" вместо "/astic". изменил "OUTPUT_PATH" в конфигурации fluentD.

Я мог видеть, что ошибка, которую я получал ранее, исчезла, но я все еще хотел бы использовать "/astic" вместо "/". Я не уверен, какой конфиг nginx мне нужно изменить, чтобы добиться этого. Пожалуйста, помогите мне здесь.

После этого я получил ошибку «слишком большая сущность запроса», которая была устранена путем добавления - «nginx.ingress.kubernetes.io/proxy-body-size: 100m» в аннотациях. По умолчанию его 1M, а для fluentD по умолчанию 2M. Это должно было произойти сбой.

Теперь я получаю ошибки, такие как:

2019-11-06 10:01:08 +0000 [warn]: сбросить событие ошибки: error_class= Fluent :: Plugin :: ConcatFilter :: TimeoutError error = "Сброс таймаута: kernel: default" location = nil tag = "kernel" time = 2019-11-06 10: 01: 08.267224927 +0000 record = {"transport" => "kernel", "syslog_facility" => "0", "syslog_identifier" => "kernel", "boot_id" => "6e4ca7b1c1a11b74151a12979", "machine_id" => "89436ac666fa120304f2077f3bf2>," priority "=," ="hostname" => "gke-dev - node-pool", "message" => "cbr0: порт 9 (vethe75a241b) вошел в отключенное состояние устройства vethe75a241b оставил беспорядочный режимcbr0: порт 9 (vethe75a241b) вошел в отключенное состояние IPv6: ADDRCONF (NETDEV_UP): veth630f6cb0: ссылка не готова IPv6: ADDRCONF (NETDEV_CHANGE): veth630f6cb0: ссылка становится готовойcbr0: порт 9 (veth630f6cb0) вошел в состояние блокировкиcbr0: порт 9 (veth630f6cb0) вошел в состояние отключенного состоянияпорт 9 (ветеринарh630f6cb0) вошел в состояние пересылки "," source_monotonic_timestamp "=>" 61153348174 "}

Может кто-нибудь помочь мне с этим?

1 Ответ

0 голосов
/ 07 ноября 2019

  1. Что касается конфигурации nginx: здесь является официальной документацией, касающейся перезаписи. Вы можете настроить его в соответствии со своими потребностями вместе с OUTPUT_PATH в конфигурации FluentD, как вы уже упоминали.

  2. Относительно события ошибки: сброс тайм-аута просто указывает на то, что сброс произошел. Используйте timeout_label для обработки записей, где произошла очистка. Обычно лучше отправлять сообщение, а не выдавать сообщение об ошибке.

Пожалуйста, дайте мне знать, если это помогло.

...