Google Stackdriver 收到不成功的 HTTP 请求 404

Question

我在 AWS EC2 上。在运行 stackdriver-agent 检查代理的状态时，我收到了 HTTP 请求 404。

堆栈跟踪 -

sudo 服务 stackdriver-agent 状态 stackdriver-agent.service - LSB： 启动和停止 Stackdriver Agent Loaded: 已加载 （/etc/init.d/stackdriver-agent；坏；供应商预设：启用）
活跃：自 2017 年 3 月 15 日星期三 07:15:24 UTC 以来活跃（运行）； 34 秒前 文档：man:systemd-sysv-generator(8) 进程：3732 ExecStop=/etc/init.d/stackdriver-agent stop (code=exited, 状态=0/成功）进程：3754 ExecStart=/etc/init.d/stackdriver-agent start (code=exited, 状态=0/成功） 任务：12 内存：2.1M CPU：68ms CGroup：/system.slice/stackdriver-agent.service └─3782 /opt/stackdriver/collectd/sbin/stackdriver-collectd -C /opt/stackdriver/collectd/etc/collectd.conf -P /var/run/stackdriver-agent.pid

3 月 15 日 07:15:24 ip-10-0-5-248 collectd[3781]: plugin_load: plugin “match_throttle_metadata_keys”已成功加载。 3月15日07:15:24 ip-10-0-5-248 collectd [3781]：plugin_load：插件“stackdriver_agent” 成功加载。 3 月 15 日 07:15:24 ip-10-0-5-248 收集 [3781]： plugin_load：插件“聚合”成功加载。 3月15日07:15:24 ip-10-0-5-248 stackdriver-agent[3754]: ...完成。 3月15日07:15:24 ip-10-0-5-248 systemd[1]：启动 LSB：启动和停止 Stackdriver 代理人。 3 月 15 日 07:15:24 ip-10-0-5-248 collectd[3782]: write_gcm: json 凭据解析成功。 电子邮件=stackdriver-agent-authorizatio@myproject-1.iam.gserviceaccount.com, 项目=日志 3 月 15 日 07:15:24 ip-10-0-5-248 collectd [3782]：write_gcm： 不成功的 HTTP 请求 404： 404 - 未找到

404 - 未找到

3 月 15 日 07:15:24 ip-10-0-5-248 collectd[3782]: write_gcm: wg_get_from_metadata_server 提取失败 http://169.254.169.254/computeMetadata/v1beta1/instance/hostname 三月 15 07:15:24 ip-10-0-5-248 collectd [3782]：初始化完成， 进入读循环。 3 月 15 日 07:15:24 ip-10-0-5-248 收集 [3782]： tcpconns 插件：从 netlink 读取成功。将使用netlink 从现在开始的方法。

当我尝试记录异常时，消息 JSON 已成功创建，但是引发了网络异常

错误 RawSocketSender:199 - org.fluentd.logger.sender.RawSocketSender java.net.ConnectException：连接被拒绝（连接被拒绝） 在 java.net.PlainSocketImpl.socketConnect（本机方法） 在 java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) 在 java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) 在 java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) 在 java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) 在 java.net.Socket.connect(Socket.java:589) 在 org.fluentd.logger.sender.RawSocketSender.connect(RawSocketSender.java:83) 在 org.fluentd.logger.sender.RawSocketSender.reconnect(RawSocketSender.java:92) 在 org.fluentd.logger.sender.RawSocketSender.flush(RawSocketSender.java:186) 在 org.fluentd.logger.sender.RawSocketSender.send(RawSocketSender.java:177) 在 org.fluentd.logger.sender.RawSocketSender.emit(RawSocketSender.java:147) 在 org.fluentd.logger.sender.RawSocketSender.emit(RawSocketSender.java:129) 在 org.fluentd.logger.sender.RawSocketSender.emit(RawSocketSender.java:124) 在 org.fluentd.logger.FluentLogger.log(FluentLogger.java:101) 在 org.fluentd.logger.FluentLogger.log(FluentLogger.java:86) 在 com.rachna.interceptor.RachnaExceptionMappingInterceptor.publishException（RachnaExceptionMappingInterceptor.java:141） 在 com.opensymphony.xwork2.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:201) 在 com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216) 在 com.opensymphony.xwork2.DefaultActionInvocation.invoke（DefaultActionInvocation.java:244） 在 org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:54) 在 org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:564) 在 org.apache.struts2.dispatcher.ng.ExecuteOperations.executeAction（ExecuteOperations.java:81） 在 org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:99) 在 com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82) 在 com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:119) 在 com.google.inject.servlet.GuiceFilter$1.call(GuiceFilter.java:133) 在 com.google.inject.servlet.GuiceFilter$1.call(GuiceFilter.java:130) 在 com.google.inject.servlet.GuiceFilter$Context.call(GuiceFilter.java:203) 在 com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:130) 在 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) 在 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) 在 org.apache.catalina.core.StandardWrapperValve.invoke（StandardWrapperValve.java:213） 在 org.apache.catalina.core.StandardContextValve.invoke（StandardContextValve.java:106） 在 org.apache.catalina.authenticator.AuthenticatorBase.invoke（AuthenticatorBase.java:502） 在 org.apache.catalina.core.StandardHostValve.invoke（StandardHostValve.java:141） 在 org.apache.catalina.valves.ErrorReportValve.invoke（ErrorReportValve.java:79） 在 org.apache.catalina.valves.AbstractAccessLogValve.invoke（AbstractAccessLogValve.java:616） 在 org.apache.catalina.core.StandardEngineValve.invoke（StandardEngineValve.java:88） 在 org.apache.catalina.connector.CoyoteAdapter.service（CoyoteAdapter.java:522） 在 org.apache.coyote.ajp.AbstractAjpProcessor.process（AbstractAjpProcessor.java:868） 在 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672) 在 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1504) 在 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1460) 在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

Answer 1

您的问题是关于两个不同的问题。第一部分是关于 Stackdriver monitoring 代理（它曾经是唯一的 Stackdriver 代理，因此不幸的遗留了一些命名）。 404 错误实际上是意料之中的——它试图依次联系 GCE 和 AWS 元数据服务器，并从 GCE 中获取 404。

第二个是与 Stackdriver logging 代理通信时出错，您未提供有关此问题的详细信息。服务名称为google-fluentd，运行sudo service google-fluentd status应该可以得到服务状态。了解google-fluentd 和google-fluentd-catch-all-config 的已安装软件包版本也将有所帮助。