之前在K8s平臺，采用的ELK（Elasticsearch+Logstash+Kibana+Filebeat）的日志采集與展示方案，

K8s方案

方案1

在每個K8s Node主機上設置DemonSet->Filebeat，通過Filebeat收集所有當前Node上pod容器中的stdout日志輸出，需要每個應用配置stdout日志輸出（在springboot log4j2中需要配置console日志輸出），同時Logstash、ES部署在K8s集群外；

log4j2配置：?

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="off" monitorInterval="1800">
? ? <properties>
? ? ? ? <property name="LOG_HOME">/data/logs/project_name/</property>
? ? ? ? <property name="FILE_NAME">project_name</property>
? ? </properties>
? ??
? ? <Appenders>
? ? ? ? <Console name="Console" target="SYSTEM_OUT">
? ? ? ? ? ? <PatternLayout pattern="%date{yyyy-MM-dd HH:mm:ss.SSS} %level [%thread][%file:%line] - %msg%n"/>
? ? ? ? </Console>
? ? ? ? ...
? ? </Appenders>
? ??
? ? <Loggers>
? ? ? ? <Logger name="com.mx" level="trace" additivity="false">
? ? ? ? ? ? <AppenderRef ref="..."/>
? ? ? ? ? ? <AppenderRef ref="Console"/>
? ? ? ? </Logger>
? ? </Loggers>
</Configuration>

方案2

利用K8s中pod內可以存在多個docker容器，即在每個app所對應的pod中再單獨添加一個filebeat容器，并且app容器的日志輸出目錄和filebeat容器日志監控目錄掛載到同一本地文件目錄下，由此伴生的filebeat容器來負責app容器日志的采集；同時Logstash、ES部署在K8s集群外；

方案1采用DemonSet的方式占用資源少（不必每個app都單獨啟動一個Demonset），但是由于開發都比較習慣log輸出目錄下日志的配置與查看方式，并且基于目錄的日志采集配置比較靈活（可指定不同日志輸出目錄）?，故最終使用了方案2的方式；

Isito方案

在Isito中延用了K8s中的方案2，但是在Istio中所有的外部請求（如filebeat->logstash）都要經過sidecar（istio-proxy），

即在Istio中，filebeat要經過istio-proxy后才能將日志上傳到Logstash：filebeat->istio-proxy->logstash

Isito - ELK - 問題

起初使用該方案在華為云上沒有問題，但是到了公司的測試環境后發現日志怎么也上傳不上去，并且發現K8s環境下日志是可以上傳成功的，但是切換到Istio后日志便無法上傳；

查看了Filebeat后，發現如下異常日志：

并且查看了app應用的istio-proxy日志，發現如下error：

lumberjack?protocol error，HPE_INVALID_METHOD均揭示了istio-proxy和Logstash協議版本不匹配的問題，

起初看到lumberjack?protocol error時，調查到了Istio 1.1.x 僅支持IPV4（1.2版本支持K8s IPV6），而Logstash默認監聽IPV6，

可能是IP協議版本不匹配的問題，所以通過修改了Logstash的/usr/local/logstash-6.5.4/config/jvm.options中的JVM啟動參數，添加如下jvm options：

-Djava.net.preferIPv4Stack=true
-Djava.net.preferIPv6Addresses=false

重啟Logstash之后通過netstat進行查看，Logstash已經切換到IPV4:

但是Filebeat還是無法成功上傳日志；

之后看到istio-proxy提示HPE_INVALID_METHOD時，調查到envoy目前不支持自定義的Http method，估計是Logstash支持的協議中使用了自定義的method，導致istio-proxy無法成功上傳日志；

最后想到既然k8s集群支持ELK，而Istio集群（filebeat需要經過istio-proxy）不支持ELK，那么如果可以設置istio-proxy不去攔截filebeat->logstash的請求，而是由filebeat直接去訪問logstash是否就可以成功了呢？

查看Istio官網direct-access-to-external-services，直接修改istio-system.configmap.istio-sidecar-injector中traffic.sidecar.istio.io/includeOutboundIPRanges為K8s集群內的IPRange（SERVICE_CIDR，CLUSTER_CIDR），如此Istio sidecar僅會去攔截K8s集群內的服務（即K8s集群內的Isito Traffic都會生效），而集群外的IPRange（例如單獨部署在集群外的Logstash）都不會去攔截，修改后重啟pod后便會看到istio-init初始化容器啟動參數發生變化（如下圖）：

istio-init啟動參數說明：?

-p: 指定重定向所有 TCP 流量的 Envoy 端口（默認為 $ENVOY_PORT = 15001）
-u: 指定未應用重定向的用戶的 UID。通常，這是代理容器的 UID（默認為 $ENVOY_USER 的 uid，istio_proxy 的 uid 或 1337）
-g: 指定未應用重定向的用戶的 GID。（與 -u param 相同的默認值）
-m: 指定入站連接重定向到 Envoy 的模式，“REDIRECT” 或 “TPROXY”（默認為 $ISTIO_INBOUND_INTERCEPTION_MODE)
-b: 逗號分隔的入站端口列表，其流量將重定向到 Envoy（可選）。使用通配符 “*” 表示重定向所有端口。為空時表示禁用所有入站重定向（默認為 $ISTIO_INBOUND_PORTS）
-d: 指定要從重定向到 Envoy 中排除（可選）的入站端口列表，以逗號格式分隔。使用通配符“*” 表示重定向所有入站流量（默認為 $ISTIO_LOCAL_EXCLUDE_PORTS）
-i: 指定重定向到 Envoy（可選）的 IP 地址范圍，以逗號分隔的 CIDR 格式列表。使用通配符 “*” 表示重定向所有出站流量。空列表將禁用所有出站重定向（默認為 $ISTIO_SERVICE_CIDR）
-x: 指定將從重定向中排除的 IP 地址范圍，以逗號分隔的 CIDR 格式列表。使用通配符 “*” 表示重定向所有出站流量（默認為 $ISTIO_SERVICE_EXCLUDE_CIDR）。
?

參考連接：理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫持

如上操作后，istio-proxy放過了對Logstash請求的攔截，直接通過filebeat去請求Logstash后發現日志成功上傳到了Logstash->ES，之后便可在Kibana中查看到日志；

總結

以上是生活随笔為你收集整理的Istio - 集成ELK - HPE_INVALID_METHOD, lumberjack protocol error的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。