☰

如何检测 Apache 是否（即将）被请求淹没？

tag-icon • tag-icon apache-2.4 high-load
如何检测 Apache 是否（即将）被请求淹没？

我正在维护和规划一个在 Ubuntu 上运行 Apache2 的 EC2 服务器实例，该实例目前每小时最多接收约 10000 个（非常简单）请求。这只是通过 POST 传入的一些数据，并使用虚拟纯文本连字符进行响应。

请求量将随着时间的推移逐渐上升，最高可达每小时一百万个左右。

我如何（可靠地）检测到服务器已经瘫痪并且不再能够处理传入的请求？

我目前正在做的只是检查内存和 CPU 负载htop- 如果它们没有达到满负荷，那么我认为一切正常。

答案1

我认为你观察系统资源是正确的。平均负载、IO 负载、内存、交换、CPU 等...

您可能会受益于有关 Apache 内部状态的一些详细信息，例如它的进程实际上正在做什么。

http://www.tecmint.com/monitor-apache-web-server-load-and-page-statistics/

mod_status 可以显示的内容示例，来自 www.apache.org

http://www.apache.org/server-status

这可能有助于随着时间的推移收集信息，以便以后整体查看

https://httpd.apache.org/docs/2.4/programs/log_server_status.html

根据您的设置，您需要独立监视 Apache 正在使用的后端服务（如数据库服务器等）的性能。

答案2

关于量化 Apache 对最终用户的性能，响应时间很有用，它会随着服务器负载的增加而增加。我通常将此值的记录与一些 Web 分析软件（如 awstats 或 webalizer）结合起来。

不幸的是，默认日志格式没有显示这一点，因此我在我的 apache 中使用自定义日志格式，这是一个示例；

# Define logfile format used for response time analysis
LogFormat "\"%{%Y-%m-%d %H:%M:%S}t\" %V %m \"%U\" \"%q\" %{Content-Type}o %s %B %O %D" responsetime
CustomLog "/var/log/apache2/responsetime.log" responsetime

自定义日志格式指令%D给出请求时间；

%D 处理请求所需的时间（以微秒为单位）。

Apache 文档：
http://httpd.apache.org/docs/current/mod/mod_log_config.html

例子来自这里；
http://www.moeding.net/archives/33-Logging-Apache-response-times.html

答案3

免责声明：我在 www.mosoplot.com 工作，该网站可自动完成此处所需的大部分容量规划。我使用了 MOSOplot 中的一些图表来演示如何执行此操作。

这就是我对网络服务器进行容量规划的方式。

首先要考虑的是，使用 Htop/top 并不适合进行这种分析。它们只显示最极端的短期视图，这对于性能分析非常有用，但对于容量规划却很糟糕。您确实需要查看更长的时间范围才能准确判断这一点。这就像抽样几个人来确定一个国家的宗教构成。您怎么知道您观察的短时间代表了服务器在其余时间的情况？当您睡觉时怎么办？您甚至知道现在是否是高峰时间吗？

Htop 默认也只使用 2 秒间隔。因此峰值时有时无，它们可能重要也可能不重要。实际上，容量规划的最小间隔是 5 分钟，但我更喜欢 1 小时。这将平滑峰值以显示潜在趋势。这就是您需要制定计划的原因。但是，如果您有理由相信存在短期趋势（例如，如果所有传输都发生在每小时开始时的 10 分钟内），那么请务必查看。

步骤1：收集数据并存储。

MOSOplot 使用 collectd 代理，它能够收集 apache 指标以及系统指标。

要获取 apache 统计数据（响应时间和数量），您可以使用 collectd tail 插件，它将读取 apache 日志文件并提取所需的数据。有一个专用的 apache 插件，但它不会获取响应时间。

类似这样的事情应该是一个开始，与 Tom H 概述的配置变化一起包括 %D。

LoadPlugin tail
<Plugin "tail">
 <File "/var/log/apache2/access.log"> <-- PUT IN CORRECT FILENAME
  Instance "apache"
  <Match>
   Regex "GET.*?\\s([0-9\\.]+)\\s[0-9\\.]+$"
   ExcludeRegex "\\s/(favicon|wp-)"
   DSType "GaugeAverage"
   Type "response_time"
   Instance "last_byte"
  </Match>
 </File>
</Plugin>

第 2 步：查看关键资源指标

  • 响应时间
  • 交易次数
  • CPU 利用率
  • 内存利用率

要查看的首要指标是响应时间 - 除非您的应用程序是批处理系统，在这种情况下您可以忽略它。

尝试将 CPU 和内存利用率与响应时间关联起来。这样您就可以了解系统何时会崩溃。响应时间可能会增长到正常情况下的 5 倍，但之后可能会迅速恶化。但有些应用程序甚至可能无法处理这种情况，所以这取决于具体情况。

以下是一个图表的链接，其中显示了 CPU 与网络服务器每分钟点击次数的比较示例。在本例中，点击量较低，看起来我们可以轻松达到每分钟 15 次点击。 CPU V 命中数/分钟

步骤 3：何时升级

如果您无法收集响应时间，则需要使用固定阈值。绝对不要等到 CPU 和/或内存接近满负荷时才开始。首先，它可能会在 60% 左右（每小时平均值）开始下降。其次，Amazon 在其某些系统上在 60% 标记处使用突发模式，这很好地表明他们认为这是一个好的阈值。如果您经常超过突发级别，那么您应该考虑升级。

内存在 90% 左右时应该没问题，但考虑到 apache 有时会出现 OOM 问题（nginx 在这方面表现更好），因此我更愿意接受 70% 的峰值使用率。

Apache 的内存使用情况往往非常不稳定。在我们监控的一台 Web 服务器上，我们最终改用了 nginx，因为它是一个只有 1GB RAM 的小型实例，而 Apache 遇到了 OOM 错误。以下图表显示了 Apache 和 nginx 下 RAM 使用率的波动情况。 apache v nginx 的内存变量

这里要考虑的另一件事是你能多快获得赞同升级。虽然在 AWS 上实际升级可能很快，但假设您的应用程序是可扩展的，在与我合作的大多数客户那里获得升级批准非常缓慢！如果您需要的话，请给自己几周/几个月的余地。

相关内容