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

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

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

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

• дамп конфигурации 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.

Чтобы завершить подключение к контейнеру, достаточно выключить процесс (выполнить 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 контейнера:

Пример настройки параметров логирования контейнера 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 имеет следующие параметры:

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

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

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.

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

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

Сценарий 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 завершается ошибкой.

Сценарий 9. «Ленивая загрузка» конфигурации Envoy#

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

Основная функциональность

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

В прокси через gRPC поступают четыре вида конфигураций:

1. Кластеры (Cluster).

2. Listener.

3. Данные балансировки кластеров (LoadAssignment).

4. Данные маршрутов (RouteConfiguration).

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

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

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

Активация функциональности

По умолчанию функциональность работы отложенной загрузки отключена. Включить функциональность можно выставив переменную окружения ENVOY_DEFER_ENABLED со значением TRUE.

Режимы работы

Функциональность работает в двух режимах: sidecar и egress. В режиме sidecar производится фильтрация как кластеров, так и listener. Listener, не требуемые в данном поде, не загружаются в прокси. При необходимости определенного listener его конфигурационные данные запрашиваются из контрольной панели и загружаются в прокси. В режиме egress все listener изначально загружены в прокси.

Режим работы прокси определяется автоматически. Однако в режиме sidecar возможна ситуация, когда перед первым запросом потребуется наличие загруженного listener (как в режиме egress). В таком случае можно принудительно переключить работу в режим egress, выставив переменную окружения ENVOY_DEFER_PASS_ALL_LISTENERS со значением TRUE.

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

По умолчанию сервисный прокси сохраняет свои логи в стандартный вывод 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.

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

Сбор статистики осуществляется при обращении:

• в формате Prometheus: к порту 15020 по пути /stats/prometheus;

• в формате Envoy: к порту 15000 по пути /stats.

Данный запрос возвращает статистику в формате Prometheus. Система мониторинга, например, такая как компоненты продукта Platform V Monitor, может использовать данные события для построения графиков использования граничного прокси.

Примеры отображения метрик:

envoy_cluster_upstream_rq{response_code=»XXX», cluster_name=»YYY»} — количество запросов к вышестоящему сервису, где:

• XXX - код ответа: 2xx, 3xx и так далее (классификация и описание кодов ошибок приведено в разделе «Метрики компонента «Граничный прокси» (IGEG)»);

• YYY - имя кластера.

Метрики компонента «Сервисный прокси» (SVPX)#

Название и описание типов и тегов, применимых ко всем таблицам.

Таблица описания типов

Таблица описания кодов ответов

Метрики в таблицах следуют общему формату наименования, состоящему из префикса и суффикса. Префикс — это начальная часть метрики, которая описывает общий контекст или область применения. Суффикс — это завершающая часть метрики, которая уточняет конкретное измерение или характеристику.

Метрики взаимодействия с xDS-сервером#

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

1. При подозрении на ошибки синхронизации конфигураций.

2. Для анализа причин недоступности xDS-сервера.

3. В случае возникновения таймаутов при получении конфигураций.

Метрики сервисного прокси#

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

1. При отладке задержек между сервисами.

2. При мониторинге отказов соединений.

3. При анализе производительности сервисов.

Метрики состояния кластеров#

Метрики показывают состояние кластеров, управляемых Envoy. Полезны для диагностики проблем с балансировкой нагрузки и доступности сервисов. Данные метрики необходимо отслеживать при следующих событиях:

1. При сбоях в работе балансировки нагрузки.

2. Когда наблюдаются частые ошибки подключения к сервисам.

3. Для мониторинга частоты успешных и неуспешных обновлений кластеров.

Метрики состояния CDS#

Метрики состояния CDS отражают процесс обнаружения и обновления кластеров. Помогают убедиться, что Envoy своевременно обнаруживает изменения в топологии сети. Данные метрики необходимо отслеживать при следующих событиях:

1. При изменении структуры кластеров.

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

3. Чтобы избежать увеличения количества ошибок при обновлении кластеров.

Метрики состояния LDS#

Метрики состояния LDS связаны с процессом обнаружения и обновления слушателей. Помогают понять, насколько эффективно Envoy управляет слушателями и реагирует на изменения в сетевой инфраструктуре. Данные метрики необходимо отслеживать при следующих событиях:

1. При изменениях в настройках слушателей.

2. Для проверки успешности обновлений конфигурации слушателей.

3. При увеличении числа ошибок при обновлении конфигурации слушателей.

Метрики Istio Agent#

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

1. При запуске новых сервисов или обновлений — чтобы оценить их влияние на производительность.

2. Во время пиковых нагрузок — для контроля стабильности системы.

3. После изменений в конфигурации — чтобы проверить корректность настроек.

4. При возникновении ошибок или замедлений — для быстрого обнаружения и устранения проблем.

5. Регулярно — для профилактики и долгосрочного анализа тенденций.

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

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