Руководство по системному администрированию#

Термины и определения#

Термин/аббревиатура

Определение

Платформа

Платформа оркестрации приложений со средствами автоматизации и управления на основе политик, например Kubernetes

Istio SE

Настраиваемая сервисная сетка с открытым исходным кодом, служащая для взаимодействия, мониторинга и обеспечения безопасности контейнеров в кластере Kubernetes

Проект / namespace

Изолированная область (пространство имен) в кластере Kubernetes, предназначенная для разграничения доступа к ресурсам кластера (deployment, service, и т.д.)

Контрольная панель

Namespace, где запущены управляющие приложения (компонент POLM)

Управление политиками / POLM

Компонент Управление политиками

Граничный прокси / IGEG

Компонент Граничный прокси

Сервисный прокси / SVPX

Компонент Сервисный прокси

istio-proxy

Сервисный прокси — Sidecar-контейнер, предназначенный для маршрутизации трафика

Deployment

Набор инструкций для запуска приложения в Kubernetes

Pod

Набор контейнеров внутри узла кластера Kubernetes

Дамп конфигурации

Снимок информации о состоянии конфигурации

TLS

Transport Layer Security, протокол защиты транспортного уровня

Сценарии администрирования#

Для администрирования программного компонента Сервисный прокси используются:

  • дамп конфигурации Sidecar приложения;

  • журнал Sidecar;

  • просмотр конфигурационных файлов: VirtualService, Gateway, ServiceEntry, DestinationRules и т.д.;

  • просмотр метрик

Сценарий 1. Получение дампа конфигурации сервисного прокси#

В зависимости от наполнения образов компонентов SVPX существуют разные способы получения дампа конфигурации.

Способ 1.#

Если в контейнере istio-proxy клиентского приложения доступна исполняемая оболочка (/bin/bash или /bin/sh) и утилита curl, то зайдите в терминал контейнера и выполните команду:

curl localhost:15000/config_dump

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

curl localhost:15000/config_dump | grep -C 10 "starttls"

Способ 2.#

Если в контейнере istio-proxy нет исполняемой оболочки, но есть утилита curl, то выполните команду удаленно через клиентскую утилиту kubectl:

kubectl exec <SVPX_pod_name> -c istio-proxy -n <namespace_name> -- curl localhost:15000/config_dump

Также можно перенаправить вывод команды в файл:

kubectl exec pg-client-794688bfb5-vmpcg -c istio-proxy -n syn-test -- curl localhost:15000/config_dump > ./sidecar_dump.json

Аналогично воспользуйтесь клиентской утилитой istioctl (поставляется в дистрибутиве) и командой proxy-config (сокращенная форма - pc):

istioctl proxy-config all <SVPX_pod_name> --kubeconfig=<kubeconfig_path> -n <namespace_name> -o <output_format>

где формат вывода результата <output_format> может быть одним из следующих значений: json, yaml, short.

Файл kubeconfig по умолчанию находится по пути ~/.kube/config.

Пример:

istioctl pc all pg-client-794688bfb5-vmpcg --kubeconfig=~/.kube/config -n syn-test -o json > ./sidecar_dump.json

Способ 3.#

Если в контейнере istio-proxy недоступны исполняемая оболочка и curl, воспользуйтесь клиентской утилитой kubectl и выполните команду /usr/local/bin/pilot-agent request:

kubectl exec <SVPX_pod_name> -c istio-proxy -n <namespace_name>  -- /usr/local/bin/pilot-agent request GET /config_dump

Пример:

kubectl exec pg-client-794688bfb5-vmpcg -c istio-proxy -n syn-test -- /usr/local/bin/pilot-agent request GET /config_dump > ./sidecar_dump.json

Способ 4.#

Если в контейнере istio-proxy недоступны исполняемая оболочка и curl, запустите интерфейс администратора для istio-proxy командой istioctl dashboard envoy:

istioctl dashboard envoy <SVPX_pod_name> --kubeconfig=<kubeconfig_path> -n <namespace_name> --port=<port_value> --browser=<open_browser>

где:

  • флаг --port отвечает за то, по какому порту будет выполняться обращение к интерфейсу (значение по умолчанию - 15000);

  • флаг --browser принимает значения true или false, при значении true в браузере пользователя откроется окно с интерфейсом администратора.

Флаги --port и --browser опциональны.

После выполнения команды на рабочей машине пользователя будет создано подключение к удаленному контейнеру. Интерфейс можно будет открыть в браузере по адресу localhost:<port_value>.

Пример:

istioctl dashboard envoy pg-client-794688bfb5-vmpcg --kubeconfig=~/.kube/config -n syn-test

В данном примере в браузере откроется окно с адресом http://localhost:15000, где будет доступен интерфейс администратора istio-proxy.

Model

Чтобы завершить подключение к контейнеру, достаточно выключить процесс (выполнить Ctrl + C в консоли).

Сценарий 2. Просмотр дополнительных сведений о конфигурации Envoy в составе SVPX#

Дополнительная информация о состоянии Envoy в составе SVPX может быть получена обращением к api Envoy, расположенному по адресу localhost:15000/ в контейнере istio-proxy.

Способ 1.#

Если в образе SVPX есть исполняемая оболочка (/bin/bash или /bin/sh) и утилита curl, зайдите в терминал контейнера istio-proxy и выполните команду:

curl localhost:15000/help

Способ 2.#

Если в образе SVPX нет исполняемой оболочки, но есть утилита curl, подключитесь к api Envoy удаленно с помощью клиентской утилиты kubectl:

kubectl exec <SVPX_pod_name> -c istio-proxy -n <namespace_name>  -- curl localhost:15000/help

Пример:

kubectl exec pg-client-794688bfb5-vmpcg -c istio-proxy -n syn-test -- curl localhost:15000/help

Способ 3.#

Если в образе SVPX нет исполняемой оболочки и утилиты curl, подключитесь к api Envoy удаленно с помощью клиентской утилиты kubectl и команды:

kubectl exec <SVPX_pod_name> -c istio-proxy -n <namespace_name>  -- /usr/local/bin/pilot-agent request GET /help

Пример:

kubectl exec pg-client-794688bfb5-vmpcg -c istio-proxy -n syn-test -- /usr/local/bin/pilot-agent request GET /help

В результате будет выведен список доступных команд:

admin commands are:
  /: Admin home page
  /certs: print certs on machine
  /clusters: upstream cluster status
  /config_dump: dump current Envoy configs (experimental)
      resource: The resource to dump
      mask: The mask to apply. When both resource and mask are specified, the mask is applied to every element in the desired repeated field so that only a subset of fields are returned. The mask is parsed as a ProtobufWkt::FieldMask
      name_regex: Dump only the currently loaded configurations whose names match the specified regex. Can be used with both resource and mask query parameters.
      include_eds: Dump currently loaded configuration including EDS. See the response definition for more information
  /contention: dump current Envoy mutex contention stats (if enabled)
  /cpuprofiler (POST): enable/disable the CPU profiler
      enable: enables the CPU profiler; One of (y, n)
  /drain_listeners (POST): drain listeners
      graceful: When draining listeners, enter a graceful drain period prior to closing listeners. This behaviour and duration is configurable via server options or CLI
      inboundonly: Drains all inbound listeners. traffic_direction field in envoy_v3_api_msg_config.listener.v3.Listener is used to determine whether a listener is inbound or outbound.
  /healthcheck/fail (POST): cause the server to fail health checks
  /healthcheck/ok (POST): cause the server to pass health checks
  /heap_dump: dump current Envoy heap (if supported)
  /heapprofiler (POST): enable/disable the heap profiler
      enable: enable/disable the heap profiler; One of (y, n)
  /help: print out list of admin commands
  /hot_restart_version: print the hot restart compatibility version
  /init_dump: dump current Envoy init manager information (experimental)
      mask: The desired component to dump unready targets. The mask is parsed as a ProtobufWkt::FieldMask. For example, get the unready targets of all listeners with /init_dump?mask=listener`
  /listeners: print listener info
      format: File format to use; One of (text, json)
  /logging (POST): query/change logging levels
      paths: Change multiple logging levels by setting to <logger_name1>:<desired_level1>,<logger_name2>:<desired_level2>.
      level: desired logging level; One of (, trace, debug, info, warning, error, critical, off)
  /memory: print current allocation/heap usage
  /quitquitquit (POST): exit the server
  /ready: print server state, return 200 if LIVE, otherwise return 503
  /reopen_logs (POST): reopen access logs
  /reset_counters (POST): reset all counters to zero
  /runtime: print runtime values
  /runtime_modify (POST): Adds or modifies runtime values as passed in query parameters. To delete a previously added key, use an empty string as the value. Note that deletion only applies to overrides added via this endpoint; values loaded from disk can be modified via override but not deleted. E.g. ?key1=value1&key2=value2...
  /server_info: print server version/status information
  /stats: print server stats
      usedonly: Only include stats that have been written by system since restart
      filter: Regular expression (Google re2) for filtering stats
      format: Format to use; One of (html, text, json)
      type: Stat types to include.; One of (All, Counters, Histograms, Gauges, TextReadouts)
      histogram_buckets: Histogram bucket display mode; One of (cumulative, disjoint, none)
  /stats/prometheus: print server stats in prometheus format
      usedonly: Only include stats that have been written by system since restart
      text_readouts: Render text_readouts as new gaugues with value 0 (increases Prometheus data size)
      filter: Regular expression (Google re2) for filtering stats
  /stats/recentlookups: Show recent stat-name lookups
  /stats/recentlookups/clear (POST): clear list of stat-name lookups and counter
  /stats/recentlookups/disable (POST): disable recording of reset stat-name lookup names
  /stats/recentlookups/enable (POST): enable recording of reset stat-name lookup names

С помощью этих команд можно посмотреть все сертификаты Envoy:

curl localhost:15000/certs

или количество текущих и закрытых соединений к конкретному адресу:

curl localhost:15000/clusters | grep postgres-db-svc | grep "cx_active\|cx_total\|rq_active\|rq_total"

Сценарий 3. Просмотр дополнительных сведений о конфигурации Service Mesh#

Дополнительная информация о состоянии Service Mesh может быть получена с помощью клиентской утилиты istioctl.

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

istioctl help

Результат выполнения:

Istio configuration command line utility for service operators to
debug and diagnose their Istio mesh.

Usage:
  istioctl [command]

Available Commands:
  admin                Manage control plane (istiod) configuration
  analyze              Analyze Istio configuration and print validation messages
  authz                (authz is experimental. Use `istioctl experimental authz`)
  bug-report           Cluster information and log capture support tool.
  completion           Generate the autocompletion script for the specified shell
  create-remote-secret Create a secret with credentials to allow Istio to access remote Kubernetes apiservers
  dashboard            Access to Istio web UIs
  experimental         Experimental commands that may be modified or deprecated
  help                 Help about any command
  install              Applies an Istio manifest, installing or reconfiguring Istio on a cluster.
  kube-inject          Inject Istio sidecar into Kubernetes pod resources
  manifest             Commands related to Istio manifests
  operator             Commands related to Istio operator controller.
  profile              Commands related to Istio configuration profiles
  proxy-config         Retrieve information about proxy configuration from Envoy [kube only]
  proxy-status         Retrieves the synchronization status of each Envoy in the mesh [kube only]
  remote-clusters      Lists the remote clusters each istiod instance is connected to.
  tag                  Command group used to interact with revision tags
  uninstall            Uninstall Istio from a cluster
  upgrade              Upgrade Istio control plane in-place
  validate             Validate Istio policy and rules files
  verify-install       Verifies Istio Installation Status
  version              Prints out build version information

Flags:
      --context string          The name of the kubeconfig context to use
  -h, --help                    help for istioctl
  -i, --istioNamespace string   Istio system namespace (default "istio-system")
  -c, --kubeconfig string       Kubernetes configuration file
  -n, --namespace string        Config namespace
      --vklog Level             number for the log level verbosity. Like -v flag. ex: --vklog=9

Additional help topics:
  istioctl options                           Displays istioctl global options

Use "istioctl [command] --help" for more information about a command.

Можно запросить информацию о доступных опциях каждой конкретной команды в составе istioctl. Для просмотра состояния IGEG и SVPX используйте команду istioctl proxy-config:

$ istioctl proxy-config help
A group of commands used to retrieve information about proxy configuration from the Envoy config dump

Usage:
  istioctl proxy-config [command]

Aliases:
  proxy-config, pc

Examples:
  # Retrieve information about proxy configuration from an Envoy instance.
  istioctl proxy-config <clusters|listeners|routes|endpoints|bootstrap|log|secret> <pod-name[.namespace]>

Available Commands:
  all            Retrieves all configuration for the Envoy in the specified pod
  bootstrap      Retrieves bootstrap configuration for the Envoy in the specified pod
  cluster        Retrieves cluster configuration for the Envoy in the specified pod
  ecds           Retrieves typed extension configuration for the Envoy in the specified pod
  endpoint       Retrieves endpoint configuration for the Envoy in the specified pod
  listener       Retrieves listener configuration for the Envoy in the specified pod
  log            (experimental) Retrieves logging levels of the Envoy in the specified pod
  rootca-compare Compare ROOTCA values for the two given pods
  route          Retrieves route configuration for the Envoy in the specified pod
  secret         Retrieves secret configuration for the Envoy in the specified pod

Flags:
  -h, --help                   help for proxy-config
  -o, --output string          Output format: one of json|yaml|short (default "short")
      --proxy-admin-port int   Envoy proxy admin port (default 15000)

Global Flags:
      --context string          The name of the kubeconfig context to use
  -i, --istioNamespace string   Istio system namespace (default "istio-system")
  -c, --kubeconfig string       Kubernetes configuration file
  -n, --namespace string        Config namespace
      --vklog Level             number for the log level verbosity. Like -v flag. ex: --vklog=9

Use "istioctl proxy-config [command] --help" for more information about a command.

С ее помощью можно просмотреть статус endpoints, доступных на выбранном istio-proxy:

istioctl proxy-config endpoint pg-client-794688bfb5-vmpcg -n syn-test

или просмотреть кластеры, объявленные в конфигурации Envoy:

istioctl pc cluster pg-client-794688bfb5-vmpcg -n syn-test

Сценарий 4. Настройка логирования на SVPX#

В каждом контейнере istio-proxy компонента SVPX можно направить вывод всех 3 типов логов в файлы и настроить их ротацию.

Есть 2 способа настройки:

  • с помощью создания сущности EnvoyFilter в прикладном namespace и настройки deployments;

  • с помощью внесения изменений в IstioOperator, создания сущности Telemetry в прикладном namespace и настройки deployments.

Способ 1. EnvoyFilter#

Для настройки вывода access-логов Envoy в файл необходимо создать ресурс типа EnvoyFilter, который может быть применен ко всем приложениям namespace или к одному из них.

Пример:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: envoy-access-logs
spec:
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: ANY
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.http_connection_manager
    patch:
      operation: MERGE
      value:
        name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          access_log:
          - name: envoy.access_loggers.file
            typedConfig:
              '@type': type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
              path: /etc/istio/proxy/access.log
              # jsonFormat:
              #   businessID: '%REQ(ufs-business-id)%'
              #   clientID: '%REQ(ufs-client-id)%'
              #   message: '%BYTES_RECEIVED%'
              #   requestDepth: '%REQ(x-mt-request-chain-depth)%'
              #   requestUid: '%REQ(x-request-chain-id)%'
              #   sessionLogin: '%REQ(ufs-user-login)%'
              #   sessionUid: '%REQ(ufs-forward-sid)%'
              #   timestamp: '%START_TIME(%Y-%m-%dT%H:%M:%S.%3f)%'
              logFormat:
                textFormatSource:
                  inlineString: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS% \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n"
  - applyTo: NETWORK_FILTER
    match:
      context: ANY
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.tcp_proxy
    patch:
      operation: MERGE
      value:
        name: envoy.filters.network.tcp_proxy
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy
          access_log:
          - name: envoy.access_loggers.file
            typedConfig:
              '@type': type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
              path: /etc/istio/proxy/access.log
              # jsonFormat:
              #   businessID: '%REQ(ufs-business-id)%'
              #   clientID: '%REQ(ufs-client-id)%'
              #   message: '%BYTES_RECEIVED%'
              #   requestDepth: '%REQ(x-mt-request-chain-depth)%'
              #   requestUid: '%REQ(x-request-chain-id)%'
              #   sessionLogin: '%REQ(ufs-user-login)%'
              #   sessionUid: '%REQ(ufs-forward-sid)%'
              #   timestamp: '%START_TIME(%Y-%m-%dT%H:%M:%S.%3f)%'
              logFormat:
                textFormatSource:
                  inlineString: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS% \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n"
  - applyTo: LISTENER
    match:
      context: ANY
    patch:
      operation: MERGE
      value:
        access_log:
        - name: envoy.access_loggers.file
          typedConfig:
            '@type': type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
            path: /etc/istio/proxy/access.log
            # jsonFormat:
            #   businessID: '%REQ(ufs-business-id)%'
            #   clientID: '%REQ(ufs-client-id)%'
            #   message: '%BYTES_RECEIVED%'
            #   requestDepth: '%REQ(x-mt-request-chain-depth)%'
            #   requestUid: '%REQ(x-request-chain-id)%'
            #   sessionLogin: '%REQ(ufs-user-login)%'
            #   sessionUid: '%REQ(ufs-forward-sid)%'
            #   timestamp: '%START_TIME(%Y-%m-%dT%H:%M:%S.%3f)%'
            logFormat:
              textFormatSource:
                inlineString: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS% \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n"

Можно использовать стандартный формат записи (не закомментирован в примере) или формат json (закомментирован в примере), который подходит для обработки файлов логов компонентом LOGA.

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

Пример лога HTTP-запроса в формате по умолчанию:

[2023-09-22T13:08:27.531Z] "GET /test HTTP/1.1" 200 - 0 22 2 2 "-" "Go-http-client/1.1" "1cf460fb-b3f6-45e1-ad4a-d4ef1f11c7ee" "server-v1.test-http.svc.cluster.local:8080" "XX.XXX.X.XX:9999"

Пример лога HTTP-запроса в формате inlineString, совпадающем с тем, как логи пишутся в stdout контейнера:

[2023-09-22T13:08:32.533Z] "GET /test HTTP/1.1" 200 - via_upstream - "-" 0 22 3 3 "-" "Go-http-client/1.1" "a98c0241-78bc-4b16-85a1-1a7a92e20fa3" "server-v1.test-http.svc.cluster.local:8080" "XX.XXX.X.XX:9999" outbound|9999||egress-gw-svc.test-http.svc.cluster.local XX.XXX.X.XX:33792 XX.XXX.X.XX:8080 XX.XXX.X.XX:60822 - -

Пример лога HTTP-запроса в формате json:

{"timestamp":"2023-09-22T13:09:29.555","sessionLogin":"-","requestDepth":"-","requestUid":"-","sessionUid":"-","clientID":"-","message":"0","businessID":"-"}

Способ 2. IstioOperator и Telemetry#

Для настройки вывода access-логов Envoy в файл в namespace должен быть создан ресурс типа Telemetry, а в настройках контрольной панели в параметре meshConfig IstioOperator — ресурс extensionProviders со значением пути, равным необходимому пути для записи access-логов Envoy.

Подробнее о настройке meshConfig в IstioOperator указано в документе «Руководство по установке» компонента POLM.

Пример IstioOperator:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-demo
  namespace: istio-system
spec:
  meshConfig:
    extensionProviders:
    - name: envoy_default
      envoyFileAccessLog:
        path: /dev/stdout
    - name: envoy_file
      envoyFileAccessLog:
        path: /etc/istio/proxy/access.log

Пример ресурса Telemetry, применяемого ко всем приложениям namespace:

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: default
  namespace: syn-test
spec:
  accessLogging:
  - providers:
    - name: envoy_default
    - name: envoy_file

Пример ресурса Telemetry, применяемого к выбранному приложению namespace:

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: default
  namespace: syn-test
spec:
  accessLogging:
  - providers:
    - name: envoy_default
    - name: envoy_file
  selector:
    matchLabels:
      app: pg-client

Настройка deployments#

Для настройки логирования и ротации в каждом контейнере istio-proxy компонента SVPX задайте следующие переменные в args или env контейнера:

Параметр env

Параметр args

Описание

Возможные значения

PILOT_LOG_PATH

--log_rotate

Путь к ротируемому файлу логов pilot-agent

Путь к файлу, папка которого создана как volumeMount в контейнере istio-proxy

PILOT_LOG_LEVEL

--log_output_level

Уровень детализации логов pilot-agent.
Строка значений вида scope:level, объединенных запятой

Возможные значения scope: default, validation, processing, analysis,installer, translator, adsc, klog, kube
Возможные значения level: debug, info, warn, error, fatal, none

PROXY_LOG_PATH

--proxyLogPath

Путь к ротируемому файлу логов Envoy

Путь к файлу, папка которого создана как volumeMount в контейнере istio-proxy

PROXY_LOG_LEVEL

--proxyLogLevel

Уровень детализации логов Envoy

Возможные значения: trace, debug, info, warning, error, critical, off

ACCESS_LOG_PATH

--accessLogPath

Путь к ротируемому файлу access-логов Envoy

Путь к файлу, папка которого создана как volumeMount в контейнере istio-proxy

LOG_ROTATE_MAX_SIZE

--log_rotate_max_size

Раз в минуту pilot-agent проверяет размеры указанных ротируемых файлов и копирует их содержимое в новый файл с именем в формате -., очищая исходный файл

Целое число в МБ,
значение по умолчанию - 100

LOG_ROTATE_MAX_BACKUPS

--log_rotate_max_backups

Число бэкап-файлов, сохраняющихся при ротации. 0 - не удалять файлы

Целое число,
значение по умолчанию - 0

LOG_ROTATE_MAX_AGE

--log_rotate_max_age

Число дней, которое хранятся файлы бэкапов

Целое число,
значение по умолчанию - 30

Пример настройки параметров логирования контейнера istio-proxy в deployment с использованием аннотаций, в которых заданы переменные env контейнера:

kind: Deployment
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: 'true'
        proxy.istio.io/config: |
          proxyMetadata:
            PILOT_LOG_PATH: '/etc/istio/proxy/pilotagent.log'
            PILOT_LOG_LEVEL: 'default:debug'
            PROXY_LOG_PATH: '/etc/istio/proxy/envoy.log'
            PROXY_LOG_LEVEL: 'trace'
            ACCESS_LOG_PATH: '/etc/istio/proxy/access.log'
            LOG_ROTATE_MAX_SIZE: '1'
            LOG_ROTATE_MAX_BACKUPS: '2'
            LOG_ROTATE_MAX_AGE: '5'

Сценарий 5. Изменение уровня логирования Envoy в составе SVPX в рантайме#

Изменить уровень логирования Envoy в контейнере istio-proxy, не прерывая его работу, можно двумя способами.

Способ 1.#

Если в образе SVPX есть исполняемая оболочка (/bin/bash или /bin/sh) и утилита curl, зайдите в терминал контейнера istio-proxy и выполните команду:

curl -X POST localhost:15000/logging?level=<level>

Способ 2.#

Если в образе SVPX нет исполняемой оболочки и/или утилиты curl, измените уровень логирования Envoy с помощью клиентской утилиты istioctl:

istioctl proxy-config log --level <logger1:level,logger2:level...> <SVPX_pod_name> --kubeconfig=<kubeconfig_path> -n <namespace_name>

Чтобы получить текущие loggers и уровни их логирования, необходимо выполнить следующую команду:

istioctl proxy-config log <SVPX_pod_name> --kubeconfig=<kubeconfig_path> -n <namespace_name>

Значение параметра level задается как перечисление loggers и их уровней логирования через запятую в формате logger1:level,logger2:level.

В качестве logger можно указывать значения: admin, aws, assert, backtrace, client, config, connection, conn_handler, dubbo, file, filter, forward_proxy, grpc, hc, health_checker, http, http2, hystrix, init, io, jwt, kafka, lua, main, misc, mongo, quic, pool, rbac, redis, router, runtime, stats, secret, tap, testing, thrift, tracing, upstream, udp, wasm.

В качестве значений уровня логирования укажите одно из следующих значений: trace, debug, info, warning, error, critical, off

Если не выставить значение для logger, то уровень логирования применится ко всем loggers.

Пример:

istioctl proxy-config log --level http:trace,wasm:debug pg-client-794688bfb5-vmpcg --kubeconfig=~/.kube/config -n syn-test

Чтобы вернуть уровни логирования всех loggers к значениям по умолчанию, выполните следующую команду.

istioctl proxy-config log <SVPX_pod_name> --kubeconfig=<kubeconfig_path> -n <namespace_name> -r

Пример:

istioctl proxy-config log pg-client-794688bfb5-vmpcg --kubeconfig=~/.kube/config -n syn-test -r

Сценарий 6. Маскирование данных Envoy#

Начиная с версии SSM 4.2, в образе proxyv2 (образ контейнеров istio-proxy приложений IGEG и sidecars istio-proxy SVPX) задана переменная окружения:

# Environment variable to mask authorization headers & ott-tokens by default
ENV SYNAPSE_MASKING_CONFIG='{"exact":[{"name":"authorization","pattern":"^.{4}(.+).{4}$"},{"name":"ott-token","pattern":"^.{4}(.+).{4}$"}]}'

Она устанавливает маскирование заголовков authorization и ott-token в логах контейнеров istio-proxy включенным по умолчанию.

Существуют следующие пути переопределения маскирования по умолчанию:

  1. Задание переменной окружения SYNAPSE_MASKING_CONFIG в sidecar SVPX с указанием полного пути до файла конфигурации.

  2. Задание переменной окружения SYNAPSE_MASKING_CONFIG в sidecar SVPX с указанием конфигурации маскирования.

Конфигурация переменной окружения SYNAPSE_MASKING_CONFIG имеет следующие параметры:

Параметр

Значение

exact

Поиск точного совпадения в имени заголовка

regex

Поиск совпадения регулярного выражения с именем заголовка

name

Имя заголовка для поиска

pattern

Паттерн регулярного выражения для маскирования значения заголовка

Задание переменной окружения с указанием полного пути до файла конфигурации#

Необходимо выполнить два условия:

  1. Задайте переменную окружения SYNAPSE_MASKING_CONFIG для istio-proxy контейнера, с указанием полного пути до файла с конфигурацией маскирования, и примонтируйте конфигурационный файл. Пример:

    kind: Deployment
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: 'true'
        proxy.istio.io/config: |
          proxyMetadata:
            SYNAPSE_MASKING_CONFIG: "/etc/app/masking-config.yaml"
    spec:
      volumes:
        - name: envoy-configmap
          configMap:
            name: envoy-configmap
            defaultMode: 256

  2. Опишите файл конфигурации маскирования. Пример конфигурации:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: envoy-configmap
data:
  masking-config.yaml: |-
      exact:
        - name: authorization
          pattern: "^.{4}(.+).{4}$"
        - name: path
          pattern: "secret_value"
      regex:
        - name: "x-request.+"
          pattern: "^.{4}(.+).{4}$"

Задание переменной окружения с указанием конфигурации маскирования#

Укажите конфигурацию маскирования, передав значение в переменную окружения:

kind: Deployment
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: 'true'
        proxy.istio.io/config: |
          proxyMetadata:
            SYNAPSE_MASKING_CONFIG: '{"exact":{"name":"authorization","pattern":"^.{4}(.+).{4}$"},"regex":{"name":"x-request.+","pattern":"^.{4}(.+).{4}$"}}'

Приоритет поиска/применения конфига маскирования#

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

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: PHPSESSID=r2t5uvjq435r4q7ib3vtdjq120
Pragma: no-cache
Cache-Control: no-cache

В заголовке данного вида первым обработается имя заголовка «GET» — оно сравнивается с первым параметром конфигурации маскирования «authorization». Далее проверяется равенство «GET» и «path». Следующая проверка сравнивает регулярное выражение «x-request.+» с «GET». И так далее, ниже по списку конфигурации.

Условия для включения маскирования в вашем проекте#

  1. Специфичные параметры для access-логов, где явно указан вывод параметров чувствительно важной информации.

  2. Уровень логирования ниже чем warning. В этом случае есть вероятность, что чувствительно важная информация может попасть, например, из query запроса.

Внимание! В качестве параметров для маскирования не должны быть указаны чувствительно важные данные.

Как составить регулярное выражение#

Следует учитывать следующие правила маскирования при составлении регулярного выражения:

  1. При наличии групп — маскируется только первая группа.

  2. При отсутствии групп и наличия совпадения — маскируется только первое совпадение.

Выражение типа: «^.{4}(.+).{4}$», из примера, маскирует середину, оставляя первые и последние 4 символа без изменений. Такие приемы не всегда очевидны, поэтому для удобства можно воспользоваться информацией с сайта regex101.com.

Picture

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

Picture

Таким образом, найдено одно совпадение и три группы. По условиям маскирования только первая группа будет заменена, что соответствует цифре 8. Самое простое решение — обернуть выражение в круглые скобки, для выделения основной группы. Сложнее составить регулярное выражение, в котором только Match или одна группа.

Picture

Сценарий 7. Избирательное ограничение у Pod возможности открытия новых исходящих соединений#

Иногда может потребоваться ограничить Pod в возможности обращаться к Pods внутри namespace или за его пределами.

В качестве механизма используйте конфигурацию Sidecar:

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: <имя_приложения_для_которого_задается_механизм>
  namespace: <имя_namespace>
spec:
  egress:
    - hosts:
      - ./<имя_приложения_к_которому_доступ_есть>
      - ~/<имя_приложения_к_которому_доступа_нет>
      - <имя_контрольной_панели>/
  workloadSelector:
    labels:
      app: <метка_приложения_для_которого_задается_механизм>

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

Для исправной работы механизма добавьте в существующую конфигурацию:

spec:
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY

Значение REGISTRY_ONLY настройки outboundTrafficPolicy.mode настраивает все прокси таким образом, что они пропускают трафик только на сервисы внутри кластера. На любой внешний host/сервис необходимо создавать конфигурацию ServiceEntry (см. раздел «Конфигурационные файлы»), которая зарегистрирует внешний host в сервисах кластера.

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

Для разрешения всего исходящего трафика используйте ./*.

Сценарий 8. Запуск контейнера SVPX первым с postStart hook#

(!) Важным стоит отметить, что данный механизм holdApplicationUntilProxyStarts опирается в своей работе на недокументированную особенность K8S, которая со временем может перестать поддерживаться. Данная особенность гарантирована В DropApp/DropApp+ c K8S 1.25.

По умолчанию контейнер istio-proxy (SVPX) в прикладном pod запускается не первым, что может привести к нештатным ситуациям, в виду того, что весь cетевой трафик проходит через SVPX. К примеру, сетевое взаимодействие прикладного контейнера может произойти до того, как SVPX перейдет в статус Ready, что в свою очередь вызовет ошибки сетевого взаимодействия.

Если такое поведение является нежелательным, то можно установить флаг holdApplicationUntilProxyStarts в значение true.

Сделать это можно как на уровне POLM (описание - в документе «Руководство по системному администрированию» компонента POLM), так и на уровне SVPX.

Пример на уровне SVPX:

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: 'true'
        proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
    ...

Настройка holdApplicationUntilProxyStarts на уровне SVPX имеет больший приоритет, чем настройка на уровне POLM.

Как работает настройка holdApplicationUntilProxyStarts#

Контейнеры в pod запускаются не всегда параллельно. Если у какого-либо контейнера есть настройка lifecycle.postStart, то пока инструкция/команда, описанная в блоке lifecycle.postStart не завершит свое исполнение, контейнер, следующий после этого контейнера, не будет запущен.

Данная настройка меняет порядок контейнеров в pod таким образом, чтобы SVPX был первым контейнером, и добавляет lifecycle.postStart.

lifecycle:
  postStart:
    exec:
      command:
      - pilot-agent
      - wait

То есть, так как SVPX - первый контейнер, все остальные контейнеры не будут запущены, пока lifecycle.postStart не завершится успехом или ошибкой. При завершении ошибкой данный контейнер перезапускается. При этом неважно, завершился ли lifecycle.postStart успехом или ошибкой, запуск следующих контейнеров произойдет в любом случае.

Команда pilot-agent wait, запускаемая в lifecycle.postStart, раз в 500 миллисекунд проверяет статус Envoy через readinessProbe. При успешной проверке команда pilot-agent wait завершается успехом. Максимальное значение времени, в течение которого идут данные проверки - 60 секунд. По истечении этого периода времени команда pilot-agent wait завершается ошибкой.

События системного журнала#

По умолчанию сервисный прокси сохраняет свои логи в стандартный вывод linux (stdout).

Есть возможность настроить отправку событий в долговременное хранилище. Для этого необходимо настроить вывод логов в файловую систему Pod, откуда их может считать компонент Platform V LOGA и передать дальше в систему журналирования. Подробнее описано в Сценарии администрирования № 4 текущего документа.

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

Включение уровней логирования trace и debug не рекомендуется в промышленных инсталляциях.

В контейнере istio-proxy компонента SVPX в стандартный вывод (/dev/stdout) пишутся 3 вида логов:

1. Логи pilot-agent

При старте контейнера запускается исполняемый файл /usr/local/bin/pilot-agent, который анализирует конфигурацию текущего deployment, создает соединение с deployment istiod в namespace с контрольной панелью, получает и обновляет конфигурацию Envoy, а также запускает его.

Логи pilot-agent содержат информацию о параметрах и переменных окружения, настроенных в deployment, о взаимодействии с XDS-сервером контрольной панели, о запуске Envoy.

Пример логов pilot-agent

2023-09-14T11:34:05.617888Z     info    FLAG: --concurrency="2"
2023-09-14T11:34:05.618002Z     info    FLAG: --domain="test-pg-multi.svc.cluster.local"
2023-09-14T11:34:05.618013Z     info    FLAG: --help="false"
2023-09-14T11:34:05.618016Z     info    FLAG: --log_as_json="false"
2023-09-14T11:34:05.618020Z     info    FLAG: --log_caller=""
2023-09-14T11:34:05.618023Z     info    FLAG: --log_output_level="default:info"
2023-09-14T11:34:05.618035Z     info    FLAG: --log_rotate="/etc/istio/proxy/pilotagent.log"
2023-09-14T11:34:05.618038Z     info    FLAG: --log_rotate_max_age="5"
2023-09-14T11:34:05.618041Z     info    FLAG: --log_rotate_max_backups="2"
2023-09-14T11:34:05.618044Z     info    FLAG: --log_rotate_max_size="1"
2023-09-14T11:34:05.618046Z     info    FLAG: --log_stacktrace_level="default:none"
2023-09-14T11:34:05.618054Z     info    FLAG: --log_target="[stdout]"
2023-09-14T11:34:05.618058Z     info    FLAG: --meshConfig="./etc/istio/config/mesh"
2023-09-14T11:34:05.618061Z     info    FLAG: --outlierLogPath=""
2023-09-14T11:34:05.618064Z     info    FLAG: --proxyComponentLogLevel="misc:error"
2023-09-14T11:34:05.618066Z     info    FLAG: --proxyLogFormat=""
2023-09-14T11:34:05.618069Z     info    FLAG: --proxyLogLevel="warning"
2023-09-14T11:34:05.618072Z     info    FLAG: --proxyLogPath=""
2023-09-14T11:34:05.618075Z     info    FLAG: --serviceCluster="istio-proxy"
2023-09-14T11:34:05.618078Z     info    FLAG: --stsPort="0"
2023-09-14T11:34:05.618080Z     info    FLAG: --templateFile=""
2023-09-14T11:34:05.618084Z     info    FLAG: --tokenManagerPlugin="GoogleTokenExchange"
2023-09-14T11:34:05.618088Z     info    FLAG: --vklog="0"
2023-09-14T11:34:05.618092Z     info    Version 1.17-dev-24c9c092f1dbe2b0184f1127e11bc894b9b5e8ee-dirty-Clean
2023-09-14T11:34:05.671933Z     info    Maximum file descriptors (ulimit -n): 1048576
2023-09-14T11:34:05.672149Z     info    Proxy role      ips=[XX.XXX.X.XXX] type=sidecar id=pg-client-postgres-5b497bd5f7-s7785.test-pg-multi domain=test-pg-multi.svc.cluster.local
2023-09-14T11:34:05.672295Z     info    Apply proxy config from env {"proxyMetadata":{"ACCESS_LOG_PATH":"/etc/istio/proxy/access.log","LOG_ROTATE_MAX_AGE":"5","LOG_ROTATE_MAX_BACKUPS":"2","LOG_ROTATE_MAX_SIZE":"1","PILOT_LOG_LEVEL":"default:debug","PILOT_LOG_PATH":"/etc/istio/proxy/pilotagent.log","PROXY_LOG_LEVEL":"trace","PROXY_LOG_PATH":"/etc/istio/proxy/envoy.log"}}

2023-09-14T11:34:05.677951Z     info    Apply proxy config from annotation proxyMetadata:
  PILOT_LOG_LEVEL: 'default:debug'
  PILOT_LOG_PATH: '/etc/istio/proxy/pilotagent.log'
  PROXY_LOG_LEVEL: 'trace'
  PROXY_LOG_PATH: '/etc/istio/proxy/envoy.log'
  ACCESS_LOG_PATH: '/etc/istio/proxy/access.log'
  LOG_ROTATE_MAX_SIZE: '1'
  LOG_ROTATE_MAX_BACKUPS: '2'
  LOG_ROTATE_MAX_AGE: '5'

2023-09-14T11:34:05.678720Z     info    Effective config: binaryPath: /usr/local/bin/envoy
concurrency: 2
configPath: ./etc/istio/proxy
controlPlaneAuthPolicy: MUTUAL_TLS
discoveryAddress: istiod.istio-system.svc:15012
drainDuration: 45s
proxyAdminPort: 15000
proxyMetadata:
  ACCESS_LOG_PATH: /etc/istio/proxy/access.log
  LOG_ROTATE_MAX_AGE: "5"
  LOG_ROTATE_MAX_BACKUPS: "2"
  LOG_ROTATE_MAX_SIZE: "1"
  PILOT_LOG_LEVEL: default:debug
  PILOT_LOG_PATH: /etc/istio/proxy/pilotagent.log
  PROXY_LOG_LEVEL: trace
  PROXY_LOG_PATH: /etc/istio/proxy/envoy.log
serviceCluster: istio-proxy
statNameLength: 189
statusPort: 15020
terminationDrainDuration: 5s
tracing:
  zipkin:
    address: zipkin.istio-system:9411

2023-09-14T11:34:05.678839Z     info    JWT policy is third-party-jwt
2023-09-14T11:34:05.678912Z     info    using credential fetcher of JWT type in cluster.local trust domain
2023-09-14T11:34:05.690371Z     info    Workload SDS socket not found. Starting Istio SDS Server
2023-09-14T11:34:05.690469Z     info    CA Endpoint istiod.istio-system.svc:15012, provider Citadel
2023-09-14T11:34:05.690503Z     info    Using CA istiod.istio-system.svc:15012 cert with certs: var/run/secrets/istio/root-cert.pem
2023-09-14T11:34:05.691761Z     info    Opening status port 15020
2023-09-14T11:34:05.716896Z     info    ads     All caches have been synced up in 110.036131ms, marking server ready
2023-09-14T11:34:05.717274Z     info    xdsproxy        Initializing with upstream address "istiod.istio-system.svc:15012" and cluster "Kubernetes"
2023-09-14T11:34:05.717619Z     info    sds     Starting SDS grpc server
2023-09-14T11:34:05.717886Z     info    starting Http service at 127.0.0.1:15004
2023-09-14T11:34:05.719222Z     info    Pilot SAN: [istiod.istio-system.svc]
2023-09-14T11:34:05.721175Z     info    Starting proxy agent
2023-09-14T11:34:05.770190Z     info    starting
2023-09-14T11:34:05.770401Z     info    Envoy command: [-c etc/istio/proxy/envoy-rev.json --drain-time-s 45 --drain-strategy immediate --local-address-ip-version v4 --file-flush-interval-msec 1000 --disable-hot-restart --allow-unknown-static-fields --log-path /etc/istio/proxy/envoy.log --log-format [%Y-%m-%d %T.%e][%t][%l][%n] %v -l trace --component-log-level misc:error --concurrency 2]
2023-09-14T11:34:06.071682Z     info    cache   generated new workload certificate      latency=354.43117ms ttl=23h59m59.92833167s
2023-09-14T11:34:06.071767Z     info    cache   Root cert has changed, start rotating root cert
2023-09-14T11:34:06.071785Z     info    ads     XDS: Incremental Pushing:0 ConnectedEndpoints:0 Version:
2023-09-14T11:34:06.072291Z     info    cache   returned workload trust anchor from cache       ttl=23h59m59.927713303s
2023-09-14T11:34:06.174117Z     info    xdsproxy        connected to upstream XDS server: istiod.istio-system.svc:15012
2023-09-14T11:34:06.208038Z     info    ads     ADS: new connection for node:pg-client-postgres-5b497bd5f7-s7785.test-pg-multi-1
2023-09-14T11:34:06.208127Z     info    cache   returned workload certificate from cache        ttl=23h59m59.791877412s
2023-09-14T11:34:06.208367Z     info    ads     SDS: PUSH request for node:pg-client-postgres-5b497bd5f7-s7785.test-pg-multi resources:1 size:4.0kB resource:default
2023-09-14T11:34:06.208065Z     info    ads     ADS: new connection for node:pg-client-postgres-5b497bd5f7-s7785.test-pg-multi-2
2023-09-14T11:34:06.208529Z     info    cache   returned workload trust anchor from cache       ttl=23h59m59.79147353s
2023-09-14T11:34:06.208601Z     info    ads     SDS: PUSH request for node:pg-client-postgres-5b497bd5f7-s7785.test-pg-multi resources:1 size:1.1kB resource:ROOTCA
2023-09-14T11:34:06.579568Z     info    Readiness succeeded in 983.077533ms
2023-09-14T11:34:06.579912Z     info    Envoy proxy is ready

2. Логи Envoy

Содержат информацию о работе Envoy в составе istio-proxy, например, логи уровня trace.

Пример логов Envoy

[2023-09-15 10:04:10.968][27][trace][connection] [C229760] socket event: 3
[2023-09-15 10:04:10.968][27][trace][connection] [C229760] write ready
[2023-09-15 10:04:10.968][27][trace][connection] [C229760] read ready. dispatch_buffered_data=0
[2023-09-15 10:04:10.968][27][trace][connection] [C229760] ssl read returns: 0
[2023-09-15 10:04:10.968][27][trace][connection] [C229760] ssl error occurred while read: ZERO_RETURN
[2023-09-15 10:04:10.968][27][trace][connection] [C229760] ssl read 0 bytes
[2023-09-15 10:04:10.968][27][trace][filter] [C229759] upstream connection received 0 bytes, end_stream=true
[2023-09-15 10:04:10.968][27][trace][connection] [C229759] writing 0 bytes, end_stream true
[2023-09-15 10:04:10.968][27][debug][connection] [C229760] remote close
[2023-09-15 10:04:10.968][27][debug][connection] [C229760] closing socket: 0

3. Access-логи Envoy

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

  • время начала запроса;

  • метод запроса;

  • URI path, если применимо;

  • протокол запроса;

  • HTTP-код ответа, если применимо;

  • флаги ответа;

  • число байт запроса;

  • число байт ответа;

  • длительность транзакции в миллисекундах;

  • некоторые заголовки запроса и ответа;

  • ip-адрес и порт вызова;

  • кластер Envoy, соответствующий вызванному адресу.

Пример access-логов Envoy

[2023-09-15T09:46:11.053Z] "POST /receive HTTP/1.1" 200 - via_upstream - "-" 235 0 0 0 "-" "vmagent" "6b0ed2e5-87ae-43e1-bb51-a2dce59408a0" "synapse-metrics-adapter:8080" "XX.XXX.X.XXX:8080" inbound|8080|| 127.0.0.6:43916 XX.XXX.X.XXX:8080 XX.XXX.X.XXX:46814 outbound_.8080_._.synapse-metrics-adapter.ntpub-tribe-sy-polm-lt-dp.svc.cluster.local default
[2023-09-15T10:07:56.052Z] "POST /receive HTTP/1.1" 200 - via_upstream - "-" 987 0 1 0 "-" "vmagent" "afaecef0-666d-4701-98c7-87429aa6805c" "synapse-metrics-adapter:8080" "XX.XXX.X.XXX:8080" inbound|8080|| 127.0.0.6:40234 XX.XXX.X.XXX:8080 XX.XXX.X.XXX:46814 outbound_.8080_._.synapse-metrics-adapter.ntpub-tribe-sy-polm-lt-dp.svc.cluster.local default

[2023-09-14T07:53:40.169Z] "- - -" 0 UF,URX - - "delayed_connect_error:_111" 0 0 1 - "-" "-" "-" "-" "XX.XXX.X.XXX:5432" outbound|5432||ignite.test.com - XX.XXX.X.XXX:54320 XX.XXX.X.XXX:53420 - -
[2023-09-14T08:14:45.382Z] "- - -" 0 UF,URX - - "delayed_connect_error:_111" 0 0 1 - "-" "-" "-" "-" "XX.XXX.X.XXX:5432" outbound|5432||ignite.test.com - XX.XXX.X.XXX:54320 XX.XXX.X.XXX:37144 - -

[2023-07-24T06:35:35.427Z] "POST /one-window/start-payment-search/pay-doc-info HTTP/1.1" 503 UF,URX,SLR "-" "TLS error: peer ip XX.XXX.X.XXX:443 : session_id  : SSL routines : OPENSSL_internal : TLSV1_ALERT_UNKNOWN_CA : certificate unknown : internal error code 46 : hostname ott.rec-cloud.psi-30-31-apps.ХХХ.ХХХ.ХХХ.ru: Peer CA info - issuer info CN=SberCA Test Int,O=Bank,C=RU : subject info CN=mtls.rec-cloud.apps.psi-terra000030-ips.ХХХ.ХХХ.ХХХ.ru,OU=00CA,O=Bank,C=RU : serial number 51795be915de0f140ab112a15f421b18109a4aa7 : expiration 2026-02-19" 39 91 102 - "XX.XXX.X.XXX" "Apache-HttpAsyncClient/4.1.5 (Java/11.0.12)" "8d47fffc-a0df-9cf2-8077-1710eaa3e116" "ott.rec-cloud.psi-30-31-apps.ХХХ.ХХХ.ХХХ.ru" "XX.XXX.X.XXX:443" outbound|443||ott.rec-cloud.psi-30-31-apps.ХХХ.ХХХ.ХХХ.ru - XX.XXX.X.XXX:21139 XX.XXX.X.XXX:45096 outbound_.21139_._.schd-svc-egress-tenant-rec-cloud-4.ci03132776-batch-scheduler.svc.cluster.local -

[2023-07-24T01:50:00.343Z] "GET /scheduled/retry HTTP/1.1" 503 UF,URX,SLR "-" "TLS error: peer ip XX.XXX.X.XXX:443 : session_id  : SSL routines : OPENSSL_internal : CERTIFICATE_VERIFY_FAILED : unsupported certificate : internal error code 43 : hostname notify-lb.psi-7-8-apps.ХХХ.ХХХ.ХХХ.ru: Peer CA info - issuer info CN=CA Test Int,O=Bank,C=RU : subject info CN=00CA0001PPRBNotifyNOTIFICATION,OU=00CA,O=Bank,C=RU : serial number 66bb6c35dcb4210ca2c1e63e9637f6806b58bc29 : expiration 2025-05-29" 0 91 314 - "XX.XXX.X.XXX" "Apache-HttpAsyncClient/4.1.5 (Java/11.0.12)" "fa74fb56-b798-9624-8b65-02289408d21b" "notify-lb.psi-7-8-apps.ХХХ.ХХХ.ХХХ.ru" "XX.XXX.X.XXX:443" outbound|443||notify-lb.psi-7-8-apps.ХХХ.ХХХ.ХХХ.ru - XX.XXX.X.XXX:21106 XX.XXX.X.XXX:33182 outbound_.21106_._.schd-svc-egress-tenant-pprb4-digital-notify-4.ci03132776-batch-scheduler.svc.cluster.local -

[2023-07-24T00:35:16.670Z] "POST /v1/events HTTP/1.1" 200 - "-" "-" 3226 21 14 12 "XX.XXX.X.XXX" "Fluent-Bit" "c536b004-0b09-93f8-a626-14d1bea7fbc1" "logger-psi-ott.geo.igw.psi-18-19-apps.ХХХ.ХХХ.ХХХ.ru" "XX.XXX.X.XXX:443" outbound|443||logger-psi-ott.geo.igw.psi-18-19-apps.ХХХ.ХХХ.ХХХ.ru XX.XXX.X.XXX:44946 XX.XXX.X.XXX:8888 XX.XXX.X.XXX:49848 outbound_.8888_._.schd-svc-egress-4.ci03132776-batch-scheduler.svc.cluster.local -

[2023-07-24T00:35:17.118Z] "GET /v1/CI02710143_CI03976456/A/CI03132776/P/PPRB_BATCH_PSI/KV/SCHD/journal-certs HTTP/1.1" 200 - "-" "-" 0 9378 153 151 "XX.XXX.X.XXX" "Apache-HttpClient/4.5.14 (Java/11.0.12)" "969cf77a-a5cc-9df2-aefa-7bf4b371a54b" "ift.secrets.ХХХ.ХХХ.ru" "XX.XXX.X.XXX:443" outbound|443||ift.secrets.ХХХ.ХХХ.ru XX.XXX.X.XXX:54268 XX.XXX.X.XXX:8888 XX.XXX.X.XXX:55624 outbound_.8888_._.schd-svc-egress-4.ci03132776-batch-scheduler.svc.cluster.local -

Примеры других сообщений и ошибок обработки трафика приведены в разделе «Часто встречающиеся проблемы и пути их устранения».

Проверка системного журнала#

Общий журнал событий граничного прокси доступен в интерфейсе Pod Kubernetes на вкладке «Logs». Можно скачать его, нажав на соответствующую кнопку.

  1. Авторизуйтесь в веб-консоли платформы. Пользователь должен иметь полномочия не ниже view на ресурсы pods/logs.

  2. Выберите прикладной namespace, подключенный к контрольной панели.

  3. Слева в меню Workloads выберите раздел Deployments.

  4. В списке выберите нужный deployment приложения с подключенным сервисным прокси.

  5. Перейдите на вкладку Pods.

  6. Перейдите на вкладку Logs.

События мониторинга#

Сбор статистики осуществляется при обращении к порту 15020 SVPX по пути /stats/prometheus.

Данный endpoint отдает статистику в формате prometheus, система мониторинга (например, компоненты продукта Platform V Monitor) может использовать данные события для построения графиков использования сервисного прокси.

Примеры метрик#

  • envoy_cluster_upstream_rq_200 — число успешных HTTP-запросов, прошедших через прокси;

  • envoy_cluster_upstream_rq_400 — число неуспешных HTTP-запросов, прошедших через прокси;

  • envoy_cluster_upstream_rq_500 — число ошибочных запросов.

Часто встречающиеся проблемы и пути их устранения#

Проблема

Пути решения

Сервисный прокси не может подключиться к компоненту POLM, в системном журнале видно сообщение Envoy proxy is NOT ready

Проверьте корректность подключения к контрольной панели.
Обратитесь к системным администраторам контрольной панели

До прикладного приложения не доходят запросы

Проверьте access-логи сервисного прокси. Возможные варианты сообщений описаны ниже.

В access-логе сервисного прокси видно сообщение:
NR (No route configured):
В конфигурации сервисного прокси отсутствует требуемый маршрут

Авторизуйтесь в прикладном namespace. Если вызов направлен на внутренний сервис, проверьте наличие сервиса с таким именем, проверьте корректность параметров host/порт в конфигурационных файлах прикладного namespace — Gateway, DestinationRule и VirtualService. Если вызов направлен на внешний host, проверьте наличие конфигурационного файла ServiceEntry для данного сочетания host/порт

В access-логе сервисного прокси видно сообщение:
UO (Upstream overflow with circuit breaking):
Поставщик перегружен запросами

Авторизуйтесь в прикладном namespace. Проверьте корректность конфигурации раздела connectionPoolSettings в DestinationRule

В access-логе сервисного прокси видно сообщение:
UF (Failed to connect to upstream):
Поставщик сбросил соединение

Авторизуйтесь в прикладном namespace. Если используется автоматическая аутентификация ISTIO_MUTUAL — проверьте наличие конфликта в разделе trafficPolicy конфигурационного файла DestinationRule, относящегося к проблемному сервису, и разделе Spec/mTLS конфигурационного файла peerAuthentication. В случае указания разных режимов работы в поле tls — возможны указанные ошибки

В access-логе сервисного прокси видно сообщение:
UH (No healthy upstream):
Поставщик неработоспособен

Авторизуйтесь в прикладном namespace. Проверьте наличие вызываемого сервиса — в веб-интерфейсе Home/Networking/Services/Search_by_name найдите сервис. Проверьте наличие запущенного Pod, на который ссылается сервис — в веб-интерфейсе кликните правой кнопкой мыши на найденный сервис, выберите вкладку Pods на открывшейся странице, убедитесь, что статус Pods на данной странице имеет значение running

Если указанные пути решения не помогли, обратитесь к системным администраторам контрольной панели.