服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

日志传输和聚合的规模

你如何从UNIX / Linux机器上分析日志文件? 我们运行几百台服务器,它们都可以直接或通过系统日志生成自己的日志文件。 我正在寻找一个体面的解决scheme来汇总这些并挑选重要的事件。 这个问题分解成三个部分: 1)消息传输 经典的方法是使用syslog将消息logging到远程主机。 这适用于login到syslog的应用程序,但对写入本地文件的应用程序不太有用。 解决scheme可能包括让应用程序login到连接到程序的FIFO中,使用syslog发送消息,或者写一些grep本地文件并将输出发送到中央系统日志主机。 但是,如果我们去编写工具来把消息写入系统日志的麻烦,我们会更好地用像Scribe这样的东西来代替整个系统,它比syslog提供更多的灵活性和可靠性。 2)消息聚合 日志条目似乎分为两种types:每个主机和每个服务。 每主机消息是在一台机器上发生的消息; 认为磁盘失败或可疑的login。 运行服务的大多数或全部主机上都会出现每个服务的消息。 例如,我们想知道Apache何时发现一个SSI错误,但是我们不希望100台机器发生同样的错误。 在所有情况下,我们只希望看到每种消息types之一:我们不希望10条消息说同一个磁盘失败了,而且每次遇到一个破坏的SSI都不需要消息。 解决这个问题的一个方法是将多个相同types的消息聚合到每个主机上,将这些消息发送到中央服务器,然后将相同types的消息聚合成一个整体事件。 SER可以做到这一点,但使用起来很尴尬。 即使在几天的摆弄之后,我也只有基本的聚合工作,并且不得不经常查找SER用于关联事件的逻辑。 它function强大但棘手:我需要一些我的同事可以在最短的时间内拿起和使用的东西。 SER规则不符合要求。 3)生成警报 当有趣的事情发生时,我们如何告诉我们的pipe理员? 邮件收件箱? 注入Nagios? 那么,你是怎么解决这个问题的? 我不期望在盘子上有答案。 我可以自己搞清楚细节,但是一些高层次的讨论肯定是个普遍的问题。 目前我们正在使用cron作业,系统日志和谁知道还有什么可以find事件。 这不是可扩展的,可维护的或灵活的,因此我们错过了许多我们不应该做的事情。 更新:我们已经在使用Nagios进行监控,这对于检测到主机/testing服务/ etc是非常好的,但是对于抓取日志文件不太有用。 我知道有Nagios的日志插件,但是我对比每个主机警报更具可扩展性和层次感的东西感兴趣。

为networking监控路由/代理SNMP陷阱(或Netflow,通用UDP等)的解决scheme?

我正在为一个非常大的networking(大约5000个networking设备)实施networking监控解决scheme。 我们希望我们networking上的所有设备都将SNMP陷阱发送到一个盒子(技术上这可能是HA盒子对),然后让该盒子将SNMP陷阱传递到真正的处理盒。 这将允许我们有多个后端处理陷阱,并在这些后端盒子之间分配负载。 我们需要的一个关键特性是能够根据陷阱的源地址将陷阱转发到特定的盒子。 任何build议为最好的方式来处理这个? 在我们考虑的事情中有: 使用snmptrapd接受陷阱,并将它们传递给定制的写入perl处理程序脚本,以重写陷阱并将其发送到正确的处理框 使用运行在Linux机器上的某种负载均衡软件来处理这个问题(有一些难以find许多负载均衡程序来处理UDP) 使用负载平衡设备(F5等) 在Linux上使用IPTables将NAT陷阱路由到SNMP陷阱 我们目前已经实施并正在testing最后一个解决scheme,使用配有IPTables的Linux机箱来configuration接收陷阱,然后根据陷阱的源地址,用目标nat(DNAT)重写它,以便将数据包发送到正确的服务器。 例如: # Range: 10.0.0.0/19 Site: abc01 Destination: foo01 iptables -t nat -A PREROUTING -p udp –dport 162 -s 10.0.0.0/19 -j DNAT –to-destination 10.1.2.3 # Range: 10.0.33.0/21 Site: abc01 Destination: foo01 iptables -t nat -A PREROUTING -p udp –dport 162 -s 10.0.33.0/21 -j DNAT –to-destination […]

当Redis加载大数据集时,一些Linux系统变得非常慢

我收到了一个Redis用户的报告,我不知道该怎么回答,因为我不是Linux领域的专家和调度员,但是我们(作为Redis项目)需要特别指出这种问题在未来,与Redis Cluster一样,我们将有许多Redis实例同时在一个盒子中运行。 所以我在这里寻求帮助。 问题: 内核:“Linux redis1 2.6.32-305-ec2#9-Ubuntu SMP Thu Apr 15 08:05:38 UTC 2010 x86_64 GNU / Linux” 大量的可用RAM,没有其他进程执行重要的I / O。 重要的是 ,在EC2大实例上运行,而不是真正的服务器。 我从来没有在非虚拟化的环境中看到类似的东西。 EC2实例是: “高内存超大实例17.1 GB内存,6.5 ECU(2个虚拟核心,每个3.25 EC2计算单元),420 GB本地实例存储,64位平台” 。 基本上,一旦你重新启动一个大的Redis实例,系统会变得很慢,你不能再在shell上input。 当Redis加载实例时,它使用100%的CPU(它尽可能快地加载数据)并顺序读取dump.rdb文件。 加载是CPU限制,而不是I / O限制,I / O不是特别高。 为什么地球上有两个CPU和大量RAM的盒子,没有交换磁盘上的东西,基本上应该停止工作这个工作负载? 我有一个印象,这与它是一个EC2实例有很大关系,所以与我使用的虚拟化技术有关,因为我一直加载Redis 24 GB数据集 ,没有任何问题(即使Redis的其他实例高负荷运转)。 感谢任何提示! 萨尔瓦多 编辑 :添加一些我从twitter收到的反馈: 从@ezmobius:@antirez首先要做的是从/ mnt或本地短暂的驱动器试试看,如果它的EBS flakiness,第二是要确保它不是“第一次写惩罚”(谷歌它),如果是你需要首先在磁盘的dd 0。 从@dvirsky:@antirez我正在这样ec2节点上运行许多redis实例。 我注意到bgsave有一些放缓,但不是这种现象。