小编Sam*_*tch的帖子

由于一些非常荒谬的管理原因，我们在 Office365 上有一个带有一个邮箱的拆分域，这需要我们添加include:outlook.com到我们的 SPF 记录中。问题在于，仅该规则就需要9 次DNS 查找，最多 10 次。

说真的，这太可怕了。看看吧：

v=spf1
include:spf-a.outlook.com
include:spf-b.outlook.com
ip4:157.55.9.128/25
include:spfa.bigfish.com
include:spfb.bigfish.com
include:spfc.bigfish.com
include:spf-a.hotmail.com
include:_spf-ssg-b.microsoft.com
include:_spf-ssg-c.microsoft.com
~all

既然我们有我们自己的大十岁上下的邮件系统，我们需要有规则a，mx，include:_spf1.mydomain.com，和include:_spf2.mydomain.com这使我们在13 DNS查找其原因PERMERRORs的严格SPF验证，并与非严格/妥善执行验证完全不可靠/不可预测的验证.

是否有可能以某种方式include:从臃肿的 Outlook.com 记录中消除其中 3 条规则，但仍涵盖 O365 使用的服务器？

编辑：

评论者提到我们应该简单地使用较短的spf.protection.outlook.com记录。虽然这是新闻对我来说，这是更短，这只是一个记录短：

spf.protection.outlook.com
  include:spf-a.outlook.com
  include:spf-b.outlook.com
  include:spf-c.outlook.com
  include:spf.messaging.microsoft.com
    include:spfa.frontbridge.com
    include:spfb.frontbridge.com
    include:spfc.frontbridge.com

编辑²

我想我们可以在技术上将其缩减为：

v=spf1 a mx include:_spf1.mydomain.com include:_spf2.mydomain.com include:spf-a.outlook.com include:spf-b.outlook.com include:spf-c.outlook.com include:spfa.frontbridge.com include:spfb.frontbridge.com include:spfc.frontbridge.com ~all

但我看到的潜在问题是：

1. 我们需要及时了解父项spf.protection.outlook.com和 …

我有一组运行 Carbon 和 Graphite 的机器，我需要扩展以获取更多存储空间，但我不确定是否需要向上扩展或向外扩展。

该集群目前包括：

• 1个中继节点：接收所有指标并转发到相关的存储节点
• 6 个存储节点：容纳所有 Whisper DB 文件

问题是当磁盘使用率接近 80% 时，性能似乎一落千丈。集群写入 IOPS 从近乎恒定的 13k 下降到更混乱的平均 7k 左右，IOwait 时间平均为 54%。

我已经查看了我们的配置存储库，自 4 月初以来没有任何更改，因此这不是配置更改的结果。

问：增加磁盘大小会控制IO性能，还是需要添加更多存储节点？

注意：这里没有 SSD，只有很多主轴。

相关图表：

统计和资料：

e2freefrag：

[root@graphite-storage-01 ~]# e2freefrag /dev/vda3
Device: /dev/vda3
Blocksize: 4096 bytes
Total blocks: 9961176
Free blocks: 4781849 (48.0%)

Min. free extent: 4 KB
Max. free extent: 81308 KB
Avg. free extent: 284 KB
Num. free extent: 19071

HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free …

我有一个脚本可以做一些内务处理，当从交互式 shell 调用时它运行良好，但在被 cron 调用时什么也没做。为了解决这个问题，我使用以下命令启动了一个带有“空白”环境的 shell：

env -i /bin/bash --noprofile --norc

使用这个空白环境，我已经深入到我的脚本中，发现以下内容grep与任何文件都不匹配：

grep -il "^ws_status\s*=\s*[\"']remove[\"']$"

但是，当从交互式 shell 运行时，该命令将返回匹配文件的文件名。

请注意，该表达式匹配如下行： WS_STATUS = "remove"

通过反复试验，我发现将-P选项添加到 [Perl regex] 中，命令开始在“空白”shell 中正常工作。但是，我不知道为什么我的登录 shell 似乎默认为grep -P.

• 只有一个grep二进制，/bin/grep
• 没有为grep=pgrep或定义别名grep="grep -P"
• 没有GREP_OPTIONS定义环境变量。

这里有什么交易？

注：操作系统为 RHEL v5.10，Bash 为 v3.2.25，grep 为 v2.5.1

在 Check_MK 中为仅 SNMP 监控设置一些主机时，我发现一些主机snmpbulkwalk似乎“挂起”，然后在处理某个 OID 时超时。

例如：

OMD[prod]:~$ snmpbulkwalk -v 2c -c public compute01.domain.com .1.3.6.1.4.1.2021
UCD-SNMP-MIB::memIndex.0 = INTEGER: 0
UCD-SNMP-MIB::memErrorName.0 = STRING: swap
UCD-SNMP-MIB::memTotalSwap.0 = INTEGER: 88109052 kB
UCD-SNMP-MIB::memAvailSwap.0 = INTEGER: 88109052 kB
UCD-SNMP-MIB::memTotalReal.0 = INTEGER: 131860964 kB
UCD-SNMP-MIB::memAvailReal.0 = INTEGER: 94429952 kB
UCD-SNMP-MIB::memTotalFree.0 = INTEGER: 182539004 kB
UCD-SNMP-MIB::memMinimumSwap.0 = INTEGER: 16000 kB
UCD-SNMP-MIB::memShared.0 = INTEGER: 0 kB
UCD-SNMP-MIB::memBuffer.0 = INTEGER: 188772 kB
UCD-SNMP-MIB::memCached.0 = INTEGER: 6685180 kB
UCD-SNMP-MIB::memSwapError.0 = INTEGER: noError(0)
UCD-SNMP-MIB::memSwapErrorMsg.0 = STRING:
UCD-SNMP-MIB::laIndex.1 = …