日志服务器有啥作用?

Posted 2023-04-18

日志服务器有什么作用？详细说一下，谢谢

日志服务器是专门供一些服务器，设备在运行过程中产生的使用记录及硬件状态的一个集中反应的数据存储的地方就是日志服务器，用户可以根据需要做数据的查询统计等工作，及时了解各部分设备的运行状态。可以是通用的，也可以是专用的。 参考技术A 帮助我们分析设备是否正常，网络是否健康!
拿一台电脑出来专门做日志服务器,他可以抓服务器（如病毒服务器，防火墙，web等等）上的日志，然后存到这台日志服务器上，这样便于管理和查看本回答被提问者采纳 参考技术B 为了维护自身系统资源的运行状况，计算机系统一般都会有相应的日志记录系统有关日常事件或者误操作警报的日期及时间戳信息。这些日志信息对计算机犯罪调查人员非常有用。
所谓日志（Log）是指系统所指定对象的某些操作和其操作结果按时间有序的集合。每个日志文件由日志记录组成，每条日志记录描述了一次单独的系统事件。通常情况下，系统日志是用户可以直接阅读的文本文件，其中包含了一个时间戳和一个信息或者子系统所特有的其他信息。日志文件为服务器、工作站、防火墙和应用软件等IT资源相关活动记录必要的、有价值的信息，这对系统监控、查询、报表和安全审计是十分重要的。日志文件中的记录可提供以下用途：监控系统资源；审计用户行为；对可疑行为进行告警；确定入侵行为的范围；为恢复系统提供帮助；生成调查报告；为打击计算机犯罪提供证据来源。

Amazon ELB 自动运行状况检查有啥作用，它有啥期望？

【中文标题】Amazon ELB 自动运行状况检查有啥作用，它有啥期望？

【英文标题】：What does the Amazon ELB automatic health check do and what does it expect?Amazon ELB 自动运行状况检查有什么作用，它有什么期望？

【发布时间】：2012-04-25 16:38:15

【问题描述】：

事情是这样的：

我们已经实现了一个 C++ RESTful API 服务器，它具有内置的 HTTP 解析器，并且没有像 apache 或任何类似的标准 HTTP 服务器 它已经在亚马逊结构中使用了几个月，使用普通和 SSL 通信，没有发现与亚马逊基础设施相关的问题 我们正在使用 Amazon ELB 部署我们的第一个后端 Amazon ELB 具有可自定义的健康检查系统，但也可作为自动系统，如 here 所述 我们没有发现健康检查系统发送了哪些数据的文档 后端简单挂在套接字读取指令上，最终关闭连接

我不是在寻找问题的解决方案，因为后端不是基于标准的 Web 服务器，只要有人知道 ELB 健康检查系统正在发送什么样的消息，因为我们发现没有任何地方的相关文档。

非常感谢您的帮助。谢谢。

【参考方案1】：

Amazon ELB 具有可自定义的运行状况检查系统，但也可作为 自动的，如here 所述

customizable 您大概指的是通过 AWS 管理控制台（请参阅Configure Health Check Settings）或通过 API（请参阅ConfigureHealthCheck）配置的运行状况检查。

HealthCheck 数据类型文档的 Target 字段概述了通过这种方式配置的运行状况检查的要求：

指定被检查的实例。协议是 TCP， HTTP、HTTPS 或 SSL。有效端口的范围是一 (1) 到 65535.

注意

TCP 是默认值，指定为 TCP: 端口对，例如 “TCP：5000”。在这种情况下，健康检查只是尝试打开 TCP 连接到指定端口上的实例。 连接失败 在配置的超时时间内被认为是不健康的。

SSL 也被指定为 SSL：端口对，例如 SSL:5000。

对于 HTTP 或 HTTPS 协议，情况不同。你必须 在字符串中包含 ping 路径。 HTTP 被指定为 HTTP:port;/;PathToPing;分组，例如 “HTTP:80/weather/us/wa/seattle”。在这种情况下，HTTP GET 请求是 发给给定端口和路径上的实例。 其他任何答案 在超时时间内超过“200 OK”被认为是不健康的。

HTTP ping 目标的总长度需要为 1024 16 位 Unicode 字符或更少。

[强调我的]

自动你大概是指Why is the health check URL different from the URL displayed in API and Console?中的原因段中描述的健康检查：

除了您为负载均衡器配置的运行状况检查之外， 服务会执行第二次运行状况检查以防止 实例被终止而导致的潜在副作用 被注销。要执行此检查，负载均衡器会打开一个 与运行状况检查配置相同的端口上的 TCP 连接 使用，然后在健康检查完成后关闭连接 完全的。 [强调我的]

Solution 段落阐明了此处的有效负载为零，即它类似于上面为可配置的健康检查描述的非 HTTP/HTTPS 方法：

这项额外的健康检查不会影响您的性能 应用程序，因为它没有向您的后端发送任何数据 实例。您不能禁用或关闭此运行状况检查。

总结/解决方案

假设您的 RESTful API 服务器，内置 HTTP 解析器 应该只服务于 HTTP，您将需要处理两个健康检查：

您将自己配置的第一个为 HTTP:port;/;PathToPing - 您将收到 HTTP GET 请求，并且必须在指定的超时期限内回复 200 OK健康。 第二个由服务自动配置 - 它会在上面配置的 HTTP 端口上打开一个 TCP 连接，不会发送任何数据，然后在健康检查完成后关闭连接。

总而言之，您的服务器可能已经表现得非常好，而您只是对第二次运行状况检查的行为感到恼火 - ELB 是否真的认为您的服务器不健康？

【讨论】：

有谁知道如何配置 nginx 不记录这些事件？每天记录 10,000 多个此类事件确实会“影响应用程序的性能”

不知道以前是否可行，但您现在可以编辑健康检查，在我的情况下，最简单的事情是将协议从 HTTP 切换到 TCP 尽管仍然通过端口 80。不再需要担心您的 Web 服务器和特定路径。这对我有用。

健康检查中要检查的内容

【参考方案2】：

据我所知，这只是一个寻找 200 OK http 响应的 HTTP GET 请求。