2019年8月

在 Linux 系统上有许多工具可用于查找硬件规格。在这里,我列出了四种最常用的工具,可以获取 Linux 系统的几乎所有硬件(和软件)细节。好在是这些工具在某些 Linux 发行版上默认预装。我在 Ubuntu 18.04 LTS 桌面上测试了这些工具,但是它们也适用于其他 Linux 发行版。

1、LSHW

lshw(硬件列表)是一个简单但功能齐全的实用程序,它提供了 Linux 系统上的硬件规格的详细信息。它可以报告确切的内存规格、固件版本、主板规格、CPU 版本和速度、缓存规格、总线速度等。信息可以以纯文本、XML 或 HTML 格式输出。

它目前支持 DMI(仅限 x86 和 EFI)、Open Firmware 设备树(仅限 PowerPC)、PCI/AGP、ISA PnP(x86)、CPUID(x86)、IDE/ATA/ATAPI、PCMCIA(仅在 x86 上测试过)、USB 和 SCSI。

就像我已经说过的那样,Ubuntu 默认预装了 lshw。如果它未安装在你的 Ubuntu 系统中,请使用以下命令安装它:

$ sudo apt install lshw lshw-gtk

在其他 Linux 发行版上,例如 Arch Linux,运行:

$ sudo pacman -S lshw lshw-gtk

安装后,运行 lshw 以查找系统硬件详细信息:

$ sudo lshw

你将看到输出详细的系统硬件。

示例输出:

使用 lshw 在 Linux 上查找硬件规格

请注意,如果你没有以 sudo 权限运行 lshw 命令,则输出可能不完整或不准确。

lshw 可以将输出显示为 HTML 页面。为此,请使用:

$ sudo lshw -html

同样,我们可以将设备树输出为 XML 和 json 格式,如下所示:

$ sudo lshw -xml
$ sudo lshw -json

要输出显示硬件路径的设备树,请使用 -short 选项:

$ sudo lshw -short

使用 lshw 显示具有硬件路径的设备树

要列出设备的总线信息、详细的 SCSI、USB、IDE 和 PCI 地址,请运行:

$ sudo lshw -businfo

默认情况下,lshw 显示所有硬件详细信息。你还可以使用类选项查看特定硬件详细信息的硬件信息,例如处理器、内存、显示器等。可以使用 lshw -shortlshw -businfo 找到类选项。

要显示特定硬件详细信息,例如处理器,请执行以下操作:

$ sudo lshw -class processor

示例输出:

*-cpu
description: CPU
product: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz
vendor: Intel Corp.
physical id: 4
bus info: [email protected]
version: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz
serial: To Be Filled By O.E.M.
slot: CPU 1
size: 913MHz
capacity: 2300MHz
width: 64 bits
clock: 100MHz
capabilities: x86-64 fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm arat pln pts md_clear flush_l1d cpufreq
configuration: cores=2 enabledcores=1 threads=2

类似的,你可以得到系统细节:

$ sudo lshw -class system

硬盘细节:

$ sudo lshw -class disk

网络细节:

$ sudo lshw -class network

内存细节:

$ sudo lshw -class memory

你也可以像下面这样列出多个设备的细节:

$ sudo lshw -class storage -class power -class volume

如果你想要查看带有硬件路径的细节信息,加上 -short 选项即可:

$ sudo lshw -short -class processor

示例输出:

H/W path Device Class Description
=======================================================
/0/4 processor Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz

有时,你可能希望将某些硬件详细信息共享给别人,例如客户支持人员。如果是这样,你可以从输出中删除潜在的敏感信息,如 IP 地址、序列号等,如下所示。

$ lshw -sanitize

lshw-gtk GUI 工具

如果你对 CLI 不熟悉,可以使用 lshw-gtk,这是 lshw 命令行工具的图形界面。

它可以从终端或 Dash 中打开。

要从终端启动它,只需执行以下操作:

$ sudo lshw-gtk

这是 lshw 工具的默认 GUI 界面。

使用 lshw-gtk 在 Linux 上查找硬件

只需双击“Portable Computer”即可进一步展开细节。

使用 lshw-gtk GUI 在 Linux 上查找硬件

你可以双击后续的硬件选项卡以获取详细视图。

有关更多详细信息,请参阅手册页。

$ man lshw

2、Inxi

Inxi 是我查找 Linux 系统上几乎所有内容的另一个最喜欢的工具。它是一个自由开源的、功能齐全的命令行系统信息工具。它显示了系统硬件、CPU、驱动程序、Xorg、桌面、内核、GCC 版本、进程、RAM 使用情况以及各种其他有用信息。无论是硬盘还是 CPU、主板还是整个系统的完整细节,inxi 都能在几秒钟内更准确地显示它。由于它是 CLI 工具,你可以在桌面或服务器版本中使用它。有关更多详细信息,请参阅以下指南。

3、Hardinfo

Hardinfo 将为你提供 lshw 中没有的系统硬件和软件详细信息。

HardInfo 可以收集有关系统硬件和操作系统的信息,执行基准测试,并以 HTML 或纯文本格式生成可打印的报告。

如果 Ubuntu 中未安装 Hardinfo,请使用以下命令安装:

$ sudo apt install hardinfo

安装后,Hardinfo 工具可以从终端或菜单中进行。

以下是 Hardinfo 默认界面的外观。

使用 Hardinfo 在 Linux 上查找硬件

正如你在上面的屏幕截图中看到的,Hardinfo 的 GUI 简单直观。

所有硬件信息分为四个主要组:计算机、设备、网络和基准。每个组都显示特定的硬件详细信息。

例如,要查看处理器详细信息,请单击“设备”组下的“处理器”选项。

使用 hardinfo 显示处理器详细信息

lshw 不同,Hardinfo 可帮助你查找基本软件规范,如操作系统详细信息、内核模块、区域设置信息、文件系统使用情况、用户/组和开发工具等。

使用 hardinfo 显示操作系统详细信息

Hardinfo 的另一个显着特点是它允许我们做简单的基准测试来测试 CPU 和 FPU 功能以及一些图形用户界面功能。

使用 hardinfo 执行基准测试

建议阅读:

我们可以生成整个系统以及各个设备的报告。要生成报告,只需单击菜单栏上的“生成报告”按钮,然后选择要包含在报告中的信息。

使用 hardinfo 生成系统报告

Hardinfo 也有几个命令行选项。

例如,要生成报告并在终端中显示它,请运行:

$ hardinfo -r

列出模块:

$ hardinfo -l

更多信息请参考手册:

$ man hardinfo

4、Sysinfo

Sysinfo 是 HardInfo 和 lshw-gtk 实用程序的另一个替代品,可用于获取下面列出的硬件和软件信息。

  • 系统详细信息,如发行版版本、GNOME 版本、内核、gcc 和 Xorg 以及主机名。
  • CPU 详细信息,如供应商标识、型号名称、频率、L2 缓存、型号和标志。
  • 内存详细信息,如系统全部内存、可用内存、交换空间总量和空闲、缓存、活动/非活动的内存。
  • 存储控制器,如 IDE 接口、所有 IDE 设备、SCSI 设备。
  • 硬件详细信息,如主板、图形卡、声卡和网络设备。

让我们使用以下命令安装 sysinfo:

$ sudo apt install sysinfo

Sysinfo 可以从终端或 Dash 启动。

要从终端启动它,请运行:

$ sysinfo

这是 Sysinfo 实用程序的默认界面。

sysinfo 界面

如你所见,所有硬件(和软件)详细信息都分为五类,即系统、CPU、内存、存储和硬件。单击导航栏上的类别以获取相应的详细信息。

使用 Sysinfo 在 Linux 上查找硬件

更多细节可以在手册页上找到。

$ man sysinfo

就这样。就像我已经提到的那样,可以有很多工具可用于显示硬件/软件规范。但是,这四个工具足以找到你的 Linux 发行版的所有软硬件规格信息。


via: https://www.ostechnix.com/getting-hardwaresoftware-specifications-in-linux-mint-ubuntu/

作者:sk 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

在这个时代,有一些开源替代品可满足你的所有计算需求。甚至还有一个 VR 眼镜之类的开源平台。让我们快速看一下 OpenHMD 这个项目。

什么是 OpenHMD?

OpenHMD 是一个为沉浸式技术创建开源 API 及驱动的项目。这类技术包括带内置头部跟踪的头戴式显示器。

它目前支持很多系统,包括 Android、FreeBSD、Linux、OpenBSD、mac OS 和 Windows。它支持的设备包括 Oculus Rift、HTC Vive、DreamWorld DreamGlass、Playstation Move 等。它还支持各种语言,包括 Go、Java、.NET、Perl、Python 和 Rust。

OpenHMD 项目是在 Boost 许可证下发布的。

新版本中的更多功能和改进功能

最近,OpenHMD 项目发布版本 0.3.0,代号为 Djungelvral(Djungelvral 是来自瑞典的盐渍甘草)。它带来了不少变化。

这次更新添加了对以下设备的支持:

  • 3Glasses D3
  • Oculus Rift CV1
  • HTC Vive 和 HTC Vive Pro
  • NOLO VR
  • Windows Mixed Reality HMD 支持
  • Deepoon E2
  • GearVR Gen1

OpenHMD 增加了一个通用扭曲着色器。这一新增功能“可以方便地在驱动程序中设置一些变量,为着色器提供有关镜头尺寸、色差、位置和 Quirks 的信息。”

他们还宣布计划改变构建系统。OpenHMD 增加了对 Meson 的支持,并将在下一个 (0.4) 版本中将删除对 Autotools 的支持。

OpenHMD 背后的团队还不得不删除一些功能,因为他们希望他们的系统适合所有人。由于 Windows 和 mac OS 对 HID 头的兼容问题,因此禁用了对 PlayStation VR 的支持。NOLO 有一堆固件版本,很多都会有小改动。OpenHMD 无法测试所有固件版本,因此某些版本可能无法正常工作。他们建议升级到最新的固件版本。最后,几个设备仅提供有限的支持,因此不包含在此版本中。

他们预计将加快 OpenHMD 发布周期,以便更快地获得更新的功能并为用户提供更多设备支持。他们优先要做的是“让当前在主干分支中禁用的设备在下次发布补丁时能够试用,同时让支持的头戴式显示器支持位置跟踪。”

最后总结

我没有 VR 设备而且从未使用过。我相信它们有很大的潜力,甚至能超越游戏。我很兴奋(但并不惊讶)有一个开源实现会去支持许多设备。我很高兴他们专注于各种各样的设备,而不是专注于一些非品牌的 VR 的努力。

我希望 OpenHMD 团队做得不错,并希望他们创建一个平台,让它们成为 VR项目。

你曾经使用或看到过 OpenHMD 吗?你有没有使用 VR 进行游戏和其他用途?如果是,你是否用过任何开源硬件或软件?请在下面的评论中告诉我们。


via: https://itsfoss.com/openhmd/

作者:John Paul 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

我通常会严格保持此博客的技术性,将观察、意见等内容保持在最低限度。但是,这篇和接下来的几篇文章将介绍刚进入系统管理/SRE/系统工程师/sysops/devops-ops(无论你想称自己是什么)角色的常见的基础知识。

请跟我来!

“我的网站很慢!”

我只是随机选择了本文的问题类型,这也可以应用于任何与系统管理员相关的故障排除。我并不是要炫耀那些可以发现最多的信息的最聪明的“金句”。它也不是一个详尽的、一步步指导的、并在最后一个方框中导向“利润”一词的“流程图”。

我会通过一些例子展示常规的方法。

示例场景仅用于说明本文目的。它们有时会做一些不适用于所有情况的假设,而且肯定会有很多读者在某些时候说“哦,但我觉得你会发现……”。

但那可能会让我们错失重点。

十多年来,我一直在从事于支持工作,或在支持机构工作,有一件事让我一次又一次地感到震惊,这促使我写下了这篇文章。

有许多技术人员在遇到问题时的本能反应,就是不管三七二十一去尝试可能的解决方案。

“我的网站很慢,所以”,

  • 我将尝试增大 MaxClients/MaxRequestWorkers/worker_connections
  • 我将尝试提升 innodb_buffer_pool_size/effective_cache_size
  • 我打算尝试启用 mod_gzip(遗憾的是,这是真实的故事)

“我曾经看过这个问题,它是因为某种原因造成的 —— 所以我估计还是这个原因,它应该能解决这个问题。”

这浪费了很多时间,并会让你在黑暗中盲目乱撞,胡乱鼓捣。

你的 InnoDB 的缓冲池也许达到 100% 的利用率,但这可能只是因为有人运行了一段时间的一次性大型报告导致的。如果没有排除这种情况,那你就是在浪费时间。

开始之前

在这里,我应该说明一下,虽然这些建议同样适用于许多角色,但我是从一般的支持系统管理员的角度来撰写的。在一个成熟的内部组织中,或与规模较大的、规范管理的或“企业级”客户合作时,你通常会对一切都进行检测、测量、绘制、整理(甚至不是文字),并发出警报。那么你的方法也往往会有所不同。让我们在这里先忽略这种情况。

如果你没有这种东西,那就随意了。

澄清问题

首先确定实际上是什么问题。“慢”可以是多种形式的。是收到第一个字节的时间吗?从糟糕的 Javascript 加载和每页加载要拉取 15 MB 的静态内容,这是一个完全不同类型的问题。是慢,还是比通常慢?这是两个非常不同的解决方案!

在你着手做某事之前,确保你知道实际报告和遇到的问题。找到问题的根源通常很困难,但即便找不到也必须找到问题本身。

否则,这相当于系统管理员带着一把刀去参加枪战。

唾手可得

首次登录可疑服务器时,你可以查找一些常见的嫌疑对象。事实上,你应该这样做!每当我登录到服务器时,我都会发出一些命令来快速检查一些事情:我们是否发生了页交换(free / vmstat),磁盘是否繁忙(top / iostat / iotop),是否有丢包(netstat / proc/net/dev),是否处于连接数过多的状态(netstat),有什么东西占用了 CPU(top),谁在这个服务器上(w / who),syslog 和 dmesg 中是否有引人注目的消息?

如果你从 RAID 控制器得到 2000 条抱怨直写式缓存没有生效的消息,那么继续进行是没有意义的。

这用不了半分钟。如果什么都没有引起你的注意 —— 那么继续。

重现问题

如果某处确实存在问题,并且找不到唾手可得的信息。

那么采取所有步骤来尝试重现问题。当你可以重现该问题时,你就可以观察它。当你能观察到时,你就可以解决。如果在第一步中尚未显现出或覆盖了问题所在,询问报告问题的人需要采取哪些确切步骤来重现问题。

对于由太阳耀斑或只能运行在 OS/2 上的客户端引起的问题,重现并不总是可行的。但你的第一个停靠港应该是至少尝试一下!在一开始,你所知道的是“某人认为他们的网站很慢”。对于那些人,他们可能还在用他们的 GPRS 手机,也可能正在安装 Windows 更新。你在这里挖掘得再深也是浪费时间。

尝试重现!

检查日志

我对于有必要包括这一点感到很难过。但是我曾经看到有人在运行 tail /var/log/... 之后几分钟就不看了。大多数 *NIX 工具都特别喜欢记录日志。任何明显的错误都会在大多数应用程序日志中显得非常突出。检查一下。

缩小范围

如果没有明显的问题,但你可以重现所报告的问题,那也很棒。所以,你现在知道网站是慢的。现在你已经把范围缩小到:浏览器的渲染/错误、应用程序代码、DNS 基础设施、路由器、防火墙、网卡(所有的)、以太网电缆、负载均衡器、数据库、缓存层、会话存储、Web 服务器软件、应用程序服务器、内存、CPU、RAID 卡、磁盘等等。

根据设置添加一些其他可能的罪魁祸首。它们也可能是 SAN,也不要忘记硬件 WAF!以及…… 你明白我的意思。

如果问题是接收到第一个字节的时间,你当然会开始对 Web 服务器去应用上已知的修复程序,就是它响应缓慢,你也觉得几乎就是它,对吧?但是你错了!

你要回去尝试重现这个问题。只是这一次,你要试图消除尽可能多的潜在问题来源。

你可以非常轻松地消除绝大多数可能的罪魁祸首:你能从服务器本地重现问题吗?恭喜,你刚刚节省了自己必须尝试修复 BGP 路由的时间。

如果不能,请尝试使用同一网络上的其他计算机。如果可以的话,至少你可以将防火墙移到你的嫌疑人名单上,(但是要注意一下那个交换机!)

是所有的连接都很慢吗?虽然服务器是 Web 服务器,但并不意味着你不应该尝试使用其他类型的服务进行重现问题。netcat 在这些场景中非常有用(但是你的 SSH 连接可能会一直有延迟,这可以作为线索)! 如果这也很慢,你至少知道你很可能遇到了网络问题,可以忽略掉整个 Web 软件及其所有组件的问题。用这个知识(我不收 200 美元)再次从顶部开始,按你的方式由内到外地进行!

即使你可以在本地复现 —— 仍然有很多“因素”留下。让我们排除一些变量。你能用普通文件重现它吗? 如果 i_am_a_1kb_file.html 很慢,你就知道它不是数据库、缓存层或 OS 以外的任何东西和 Web 服务器本身的问题。

你能用一个需要解释或执行的 hello_world.(py|php|js|rb..) 文件重现问题吗?如果可以的话,你已经大大缩小了范围,你可以专注于少数事情。如果 hello_world 可以马上工作,你仍然学到了很多东西!你知道了没有任何明显的资源限制、任何满的队列或在任何地方卡住的 IPC 调用,所以这是应用程序正在做的事情或它正在与之通信的事情。

所有页面都慢吗?或者只是从第三方加载“实时分数数据”的页面慢?

这可以归结为:你仍然可以重现这个问题所涉及的最少量的“因素”是什么?

我们的示例是一个缓慢的网站,但这同样适用于几乎所有问题。邮件投递?你能在本地投递吗?能发给自己吗?能发给<常见的服务提供者>吗?使用小的、纯文本的消息进行测试。尝试直到遇到 2MB 拥堵时。使用 STARTTLS 和不使用 STARTTLS 呢?按你的方式由内到外地进行!

这些步骤中的每一步都只需要几秒钟,远远快于实施大多数“可能的”修复方案。

隔离观察

到目前为止,当你去除特定组件时无法重现问题时,你可能已经偶然发现了问题所在。

但如果你还没有,或者你仍然不知道为什么:一旦你找到了一种方法来重现问题,你和问题之间的“东西”(某个技术术语)最少,那么就该开始隔离和观察了。

请记住,许多服务可以在前台运行和/或启用调试。对于某些类别的问题,执行此操作通常非常有帮助。

这也是你的传统武器库发挥作用的地方。stracelsofnetstatGDBiotopvalgrind、语言分析器(cProfile、xdebug、ruby-prof ……)那些类型的工具。

一旦你走到这一步,你就很少能摆脱剖析器或调试器了。

strace 通常是一个非常好的起点。

你可能会注意到应用程序停留在某个连接到端口 3306 的套接字文件描述符上的特定 read() 调用上。你会知道该怎么做。

转到 MySQL 并再次从顶部开始。显而易见:“等待某某锁”、死锁、max_connections ……进而:是所有查询?还是只写请求?只有某些表?还是只有某些存储引擎?等等……

你可能会注意到调用外部 API 资源的 connect() 需要五秒钟才能完成,甚至超时。你会知道该怎么做。

你可能会注意到,在同一对文件中有 1000 个调用 fstat()open() 作为循环依赖的一部分。你会知道该怎么做。

它可能不是那些特别的东西,但我保证,你会发现一些东西。

如果你只是从这一部分学到一点,那也不错;学习使用 strace 吧!真的学习它,阅读整个手册页。甚至不要跳过历史部分。man 每个你还不知道它做了什么的系统调用。98% 的故障排除会话以 strace 而终结。


via: http://northernmost.org/blog/troubleshooting-101/index.html

作者:Erik Ljungstrom 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Logreduce 可以通过从大量日志数据中挑选出异常来节省调试时间。

持续集成(CI)作业会生成大量数据。当一个作业失败时,弄清楚出了什么问题可能是一个繁琐的过程,它涉及到调查日志以发现根本原因 —— 这通常只能在全部的作业输出的一小部分中找到。为了更容易地将最相关的数据与其余数据分开,可以使用先前成功运行的作业结果来训练 Logreduce 机器学习模型,以从失败的运行日志中提取异常。

此方法也可以应用于其他用例,例如,从 Journald 或其他系统级的常规日志文件中提取异常。

使用机器学习来降低噪音

典型的日志文件包含许多标称事件(“基线”)以及与开发人员相关的一些例外事件。基线可能包含随机元素,例如难以检测和删除的时间戳或唯一标识符。要删除基线事件,我们可以使用 k-最近邻模式识别算法(k-NN)。

日志事件必须转换为可用于 k-NN 回归的数值。使用通用特征提取工具 HashingVectorizer 可以将该过程应用于任何类型的日志。它散列每个单词并在稀疏矩阵中对每个事件进行编码。为了进一步减少搜索空间,这个标记化过程删除了已知的随机单词,例如日期或 IP 地址。

训练模型后,k-NN 搜索可以告诉我们每个新事件与基线的距离。

这个 Jupyter 笔记本 演示了该稀疏矩阵向量的处理和图形。

Logreduce 介绍

Logreduce Python 软件透明地实现了这个过程。Logreduce 的最初目标是使用构建数据库来协助分析 Zuul CI 作业的失败问题,现在它已集成到 Software Factory 开发车间的作业日志处理中。

最简单的是,Logreduce 会比较文件或目录并删除相似的行。Logreduce 为每个源文件构建模型,并使用以下语法输出距离高于定义阈值的任何目标行:distance | filename:line-number: line-content

$ logreduce diff /var/log/audit/audit.log.1 /var/log/audit/audit.log
INFO  logreduce.Classifier - Training took 21.982s at 0.364MB/s (1.314kl/s) (8.000 MB - 28.884 kilo-lines)
0.244 | audit.log:19963:        type=USER_AUTH acct="root" exe="/usr/bin/su" hostname=managesf.sftests.com
INFO  logreduce.Classifier - Testing took 18.297s at 0.306MB/s (1.094kl/s) (5.607 MB - 20.015 kilo-lines)
99.99% reduction (from 20015 lines to 1

更高级的 Logreduce 用法可以离线训练模型以便重复使用。可以使用基线的许多变体来拟合 k-NN 搜索树。

$ logreduce dir-train audit.clf /var/log/audit/audit.log.*
INFO  logreduce.Classifier - Training took 80.883s at 0.396MB/s (1.397kl/s) (32.001 MB - 112.977 kilo-lines)
DEBUG logreduce.Classifier - audit.clf: written
$ logreduce dir-run audit.clf /var/log/audit/audit.log

Logreduce 还实现了接口,以发现 Journald 时间范围(天/周/月)和 Zuul CI 作业构建历史的基线。它还可以生成 HTML 报告,该报告在一个简单的界面中将在多个文件中发现的异常进行分组。

管理基线

使用 k-NN 回归进行异常检测的关键是拥有一个已知良好基线的数据库,该模型使用数据库来检测偏离太远的日志行。此方法依赖于包含所有标称事件的基线,因为基线中未找到的任何内容都将报告为异常。

CI 作业是 k-NN 回归的重要目标,因为作业的输出通常是确定性的,之前的运行结果可以自动用作基线。 Logreduce 具有 Zuul 作业角色,可以将其用作失败的作业发布任务的一部分,以便发布简明报告(而不是完整作业的日志)。只要可以提前构建基线,该原则就可以应用于其他情况。例如,标称系统的 SoS 报告 可用于查找缺陷部署中的问题。

异常分类服务

下一版本的 Logreduce 引入了一种服务器模式,可以将日志处理卸载到外部服务,在外部服务中可以进一步分析该报告。它还支持导入现有报告和请求以分析 Zuul 构建。这些服务以异步方式运行分析,并具有 Web 界面以调整分数并消除误报。

已审核的报告可以作为独立数据集存档,其中包含目标日志文件和记录在一个普通的 JSON 文件中的异常行的分数。

项目路线图

Logreduce 已经能有效使用,但是有很多机会来改进该工具。未来的计划包括:

  • 策划在日志文件中发现的许多带注释的异常,并生成一个公共域数据集以进行进一步研究。日志文件中的异常检测是一个具有挑战性的主题,并且有一个用于测试新模型的通用数据集将有助于识别新的解决方案。
  • 重复使用带注释的异常模型来优化所报告的距离。例如,当用户通过将距离设置为零来将日志行标记为误报时,模型可能会降低未来报告中这些日志行的得分。
  • 对存档异常取指纹特征以检测新报告何时包含已知的异常。因此,该服务可以通知用户该作业遇到已知问题,而不是报告异常的内容。解决问题后,该服务可以自动重新启动该作业。
  • 支持更多基准发现接口,用于 SOS 报告、Jenkins 构建、Travis CI 等目标。

如果你有兴趣参与此项目,请通过 #log-classify Freenode IRC 频道与我们联系。欢迎反馈!


via: https://opensource.com/article/18/9/quiet-log-noise-python-and-machine-learning

作者:Tristan de Cacqueray 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

从炎热的夏日中走入到钱塘江畔清凉的网易云会客室,我见到了陈谔,开始这次“轻舟”之行。

说实话,初次近距离见到陈谔时,心中有点愕然,作为网易杭研的元老之一、网易云基础服务的领头人,我竟然从他身上感到一点点腼腆和技术人员的质朴。联想到之前网易云这边作为背景信息给出的个人介绍,这样的一位领军人物,居然自谦自己“对分布式系统设计开发、云计算平台系统架构有一定的经验和理解”,我不禁有些恍然。

我接触和采访过很多开源和互联网公司的技术领袖,陈谔应该是我见过的最温和而又不失自信的人之一,他的脸上总是浮现着内敛的笑容,让我们在谈话的一开始,就有了一个良好的氛围。

受访者(左):网易云陈谔,采访者(右):老王

网易云:千锤百炼终成型

和很多互联网公司推出的云服务一样,网易云也是一个脱胎于内部实践的云服务。网易杭州研究院作为整个网易公司的技术攻坚力量和创新业务孵化团队,随着网易业务和规模的不断的变化,杭州研究院面临着非常大的压力去做好基础设施的相关工作。

随着移动互联网的到来,原本可以很好应对博客、游戏等业务的 IT 基础设施逐渐变得捉襟见肘,原本的资源调度能力无法处理好随着新业务和新模式的快速增长和迭代而产生的需求和复杂度。IT 基础设施成为了当时网易发展业务的新瓶颈。

为了能够更好的服务网易内部的业务, 2012 年,网易杭州研究院组建了专门的云平台产品部,来建设网易内部使用的云计算平台,以应对移动互联网到来而产生的更加复杂应用带来的基础设施需求。

随着网易云产品对内提供服务,规模上的问题被逐渐解决,但是,产品的研发模式也在不断的迭代,网易内部开始不断地实践微服务架构。在这个过程中,陈谔感觉到,现有的 IaaS 产品和 PaaS 产品已经渐渐无法支撑来自微服务架构的复杂度,但在那时,云原生理念和技术尚未成熟的时代,对于微服务的探索只能独立践行。网易云针对性的提供了 CI/CD、分布式架构链路跟踪、服务治理的工具,帮助用户更好的去实践微服务。

到了 2015 年 7 月,随着 CNCF 的成立,这时陈谔发现,网易云的很多产品和服务,和 CNCF 的理念是一致的或相似的,于是,网易云决定将自己的探索和成果更好地结合社区的发展,向社区贡献自己的努力,也吸纳来自社区的营养,将网易云的发展和开源社区的路线结合起来。

也正因为拥抱社区,网易云很早就走上了 Kubernetes + Docker 的发展路线。谈起对于 Docker 和 Kubernetes 的选择,陈谔表示,网易云选择 Docker 和 Kubernetes 并不是偶然之下的决定。

实际上,早在 Docker 出现之前,网易云已经开始使用 LXC 技术来进行更细粒度的资源分配,实现了类似的容器技术栈,在此过程中,陈谔及其团队亲历了 LXC 技术在实施的过程中各种问题和技术缺陷带来的困扰。而 Docker 的横空出世使得整个云计算领域眼前一亮。虽然网易云自建的技术栈已经可以满足当时及近期业务的需求,但作为具有技术远瞻力的技术负责人,陈谔知道,相比于得到业界普遍看好的 Docker,自研的专属技术栈的生态环境狭窄,技术人员的培养成本也居高不下。而另外一方面,Docker 的镜像机制、分层文件系统机制,也使得之前在 LXC 技术栈里面斩荆披棘的网易云似乎看到容器技术发展的堂皇大道,使用 Docker 也就变得顺理成章。因此,网易云十分自然的就完成了从 LXC 向 Docker 的转移。

我问及 Kubernetes 的选择,陈谔笑了笑,他提到,网易云对于 Kubernetes 的支持是非常早的,在早期 Kubernetes、Swarm、Mesos 尚三足鼎立的时候,网易云就坚定的投入了 Kubernetes 生态。这一点和网易云过去在微服务、容器编排方面的实践是密不可分的。Kubernetes 解决了网易云在过去运维过程中遇到的诸多问题:如何进行弹性伸缩、如何进行服务调度、如何使用配置来进行控制。Kubernetes 所提供的配置能力,特别适合于需要解决微服务架构编排问题的网易云。

对于网易云来说,他们并不是一个刻意追求新奇的团队,相比于新兴的技术,网易云更在乎什么能够解决问题。显然,对于微服务架构支持最好的 Kubernetes 成为最终之选。

企业云:只为解决客户问题

网易云和很多云计算公司不同,没有将目光全部投放在公有云上,而是专注于为企业提供业务云化的解决方案。网易云也和容器云厂商的定位不同,容器是网易云的产品,更是网易云的工具,因此网易云虽然很早就应用了 Docker、Kubernetes 等技术,但是并没有突出这些看起来非常时髦的技术名词,而是根据企业需求,更多的将这些作为服务于上层的微服务产品的基础。通过结合容器的网络方案、存储方案等云原生技术积累,网易云希望更好的服务自己的客户。

陈谔说,网易云之所以选择了企业云的路线,更多是因为网易云发现自身更适合于在云原生领域深耕细作。与其在公有云的红海中去竞争,不如在云原生领域去深入挖掘,提升技术和竞争力。这样,就将竞争从 IaaS 层面,提升到了基于云原生体系的 PaaS 层面,避开了红海的竞争。同时,这种基于 Kubernetes 标准化的 PaaS 服务,其生命力也远超普通的 IaaS 产品,Kubernetes 的设计使得它能够消除厂商锁定,基于其实现的 PaaS 服务可以运行在任何一家 Kubernetes 服务商的云产品上。

陈谔还提到,作为一个面向企业提供解决方案的服务商,网易云和其他的容器云不同的是,更多是希望去靠近企业的 IT 的技术的认知,不会给企业造成过多的认知负担和业务侵入性。在业务落地时,能够根据企业的需要来不断的完成落地,而不是从一开始就要求企业去实践容器等,造成更大的负担。如果不是企业的需求要做容器化的话,不会第一时间要求用户完成容器化的迁移。但陈谔也发现,当用户真正去实施微服务框架的时候,往往会考虑实施和部署容器化,这时,网易云早已准备好的容器平台就可以很好的完成这部分的工作。

对于不希望进行容器化的企业,陈谔提到,网易云针对于这些异构的环境,也提供了不同的解决方案,诸如支持裸金属集群和虚拟机环境的 服务网格 Service Mesh 等能力,可以帮助那些不打算做容器化的企业完成自己的工作。

网易云希望自己的产品能够基于客户的 IT 策略来考虑,而不是将网易内部的实践生搬硬套到客户的业务中去。

DevOps 认知:陈谔的 DevOps 观

在谈到网易云内部的 DevOps 实践时,陈谔提到,在网易云内部其实很早就开始进行了 DevOps 实践。从 2014 年开始,网易云内部就开始推行服务化的组织架构和协作方式。在网易云内部,所有的工作都是接口先行,在网易云看到的每一个界面,都是先有接口,后有界面的。每一个接口背后都对应着网易云的一个服务以及对应的研发团队。这样从一开始,网易云就不设立专门的应用运维团队来负责业务的发布和上线,而是由各服务团队自行完成业务的发布和上线。除了 IaaS 层面基础设施的运维有专门的 SRE 团队来负责以外,各服务的运维都由各自团队自行来负责,这使得对应的团队必须自行解决运维需求。而且,为了更好的协作,网易云内部的所有的 API ,都会放在一个统一的 API 网关中,所有的用户都可以借助 API 来完成自己想要的操作,而无需进行 Web 界面的操作。

我们还谈到了 DevOps 和容器化的关系,在过去的一段时间里,宣传上总是将二者联系起来。在陈谔看来,容器化和 DevOps 的关系实际上是相辅相成的。

在他看来,之所以 DevOps 会出现,核心是随着企业业务的不断服务化拆分、微服务架构的实施,中心化的运维成为瓶颈,这使得企业不得不去提升运维的能力,去招募更多的运维。但是基于企业成本的考虑,运维人员的数量终归是有限的,因此有一些开发人员不得不兼任运维工作。但是,开发人员在运维方面的思路、关注点、风险意识上和传统运维人员存在一定差异,基于这样的考虑,需要一批工具来辅助开发人员进行运维工作,规范开发人员可以做的事情。在这样的一个大背景下,容器技术应运而生了。他相信,即使没有 Docker 公司搞出了容器化,也会有其他的公司来做出类似的产品,不同的只不过是各家的方案的优劣罢了。

轻舟微服务:帮助企业更好落地微服务

此次会见陈谔是在网易云创峰会上,而此次大会浓墨重彩介绍的产品之一就是网易轻舟微服务。

轻舟微服务是网易云在完成了基础设施的 Docker、Kubernetes 等改造完成后,基于对业界的分析和研究后提出来的。出于标准化技术栈的考虑,网易云最终启动了轻舟微服务的项目,将现有的技术栈,打造成一个个独立的标准化技术产品。到了 2018 年,在完成了对所有技术栈的标准化以后,将轻舟微服务发布了出来。

陈谔认为,异构系统整合,包括兼容、通信和系统间事务一致性,和多供应商建设,包括多团队协作、软件资产沉淀,是目前企业在建设在线业务中台过程中遇到的最大障碍,而网易轻舟微服务新品的发布,正是要通过服务网格、分布式事务框架 GTXS、全新 API 网关与原有轻舟产品的整合,完成全栈化在线中台技术体系升级,帮助企业完成业务架构的进化,支撑业务快速创新。

网易云陈谔和老王

陈谔介绍,轻舟服务网格是基于 Istio 和 CNCF 的 Envoy 等主流开源技术构建,可以实现 Java、Python、NodeJS、Golang 和 PHP 等不同技术栈的兼容和通信,能够与网易已有微服务框架 NSF 统一管控、互相发现、互相调用,并且支持容器、虚拟机和裸机部署,将异构系统的支持实现到了业界领先的程度。

在陈谔看来,轻舟微服务的推出,是网易云内部的微服务能力的对外输出,是网易云内部技术能力的输出体系,针对企业客户,提供了一整套的技术方案,以及对应的咨询服务和最佳实践的指导,帮助先前没有足够能力独力完成微服务化的企业,完成企业产品和服务的微服务化。

很多企业的 独石应用 Monolithic applications 随着企业的发展和产品的变迁,都面临新的挑战,而微服务化改造是企业所寄予众望的一条发展路径。但或因为微服务的技术储备不足,或因为既有业务的历史包袱过重,企业自行开发微服务体系不但耗时周期过长,而且可能因经验不足而走了弯路,因此,网易云在推出了轻舟微服务以后,赢得了不少企业用户的关注。

在实际的使用过程中,轻舟的部署也帮助企业大幅度提升了新业务接入的效率和版本发布的效率。举个例子来说,如果同时有数十个微服务的不同版本在开发,在传统的模式下,就需要提供数十个测试环境来完成测试,但在轻舟下,就可以基于无侵入的流量染色功能重用一套测试环境,仅将测试流量路由至特定版本微服务,降低了环境的成本。

后记

由于我离开了中国电信好几年了,近些年我对企业级产品和服务接触并不太多。而这次的采访,使得我对于一直以来缺少了解的网易云和其产品有了更深刻的认识。显然,网易云在这场云计算大潮中,找到了企业界真正的痛点,关注到了众多企业的真实需求,这种深耕的思路,一方面让网易云支撑起来网易云音乐、网易考拉等明星产品,另外一方面也使得网易云在企业上云和 IT 现代化方面不断攻城略地,取得不菲的成果,这值得云计算领域的细分厂商学习。

“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访,将为大家介绍中国开源领域中一些积极推动开源,谙熟开源思想的技术人,并辨析其思考、挖掘其动因,揭示其背后所发生的事情,为关注开源、有志于开源的企业和技术人标出一条路径。

取名为“穿山甲”寓意有二:取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用;穿山甲是珍稀保护动物,宣传公益。

不要错过最近两周最大的开源新闻。

在本期开源新闻综述中,我们分享了 Facebook 开源了两种算法来查找有害内容,Apple 在数据传输项目中的新角色以及你应该知道的更多新闻。

Facebook 开源算法用于查找有害内容

Facebook 宣布它开源两种算法用于在该平台上发现儿童剥削、恐怖主义威胁和写实暴力。在 8 月 1 日的博客文章中,Facebook 分享了 PDQ 和 TMK + PDQF 这两种将文件存储为数字哈希的技术,然后将它们与已知的有害内容示例进行比较 - 现在已放在 GitHub 上

该代码是在 Facebook 要尽快将有害内容从平台上移除的压力之下发布的。三月份在新西兰的大规模谋杀案被曝光在 Facebook Live 上,澳大利亚政府威胁如果视频没有及时删除 Facebook 高管将被处以罚款和入狱。通过发布这些算法的源代码,Facebook 表示希望非营利组织、科技公司和独立开发人员都能帮助他们更快地找到并删除有害内容。

阿里巴巴发布了最快的开源 CPU

上个月,阿里巴巴的子公司平头哥半导体公司发布了其玄铁 91 处理器。它可以用于人工智能、物联网、5G 和自动驾驶汽车等基础设施。它拥有 7.1 Coremark/MHz 的基准,使其成为市场上最快的开源 CPU。

平头哥宣布计划在今年 9 月在 GitHub 上提供其优质代码。分析师认为此次发布旨在帮助中国实现其目标,即到 2021 年使用本地供应商满足 40% 的处理器需求。近期美国的关税调整威胁要破坏这一目标,从而造成了对开源计算机组件的需求。

Mattermost 为开源协作应用提供了理由

所有开源社区都受益于可以从一个或多个地方彼此进行通信。团队聊天应用程序的世界似乎由 Slack 和 Microsoft Teams 等极少数的强大工具主导。大多数选择都是基于云的和专有产品的;而 Mattermost 采用了不同的方法,销售开源协作应用程序的价值。

“人们想要一个开源替代品,因为他们需要信任、灵活性和只有开源才能提供的创新,”Mattermost 的联合创始人兼首席执行官 Ian Tien 说。

随着从优步到国防部的客户,Mattermost 走上了一个关键市场:需要开源软件的团队,他们可以信任这些软件并安装在他们自己的服务器上。对于需要协作应用程序在其内部基础架构上运行的企业,Mattermost 填补了 Atlassian 离开后 的空白。在 Computerworld 的一篇文章中,Matthew Finnegan 探讨了为什么在本地部署的开源聊天工具尚未死亡。

Apple 加入了开源数据传输项目

Google、Facebook、Twitter 和微软去年联合创建了 数据传输项目 Data Transfer Project (DTP)。DTP 被誉为通过自己的数据提升数据安全性和用户代理的一种方式,是一种罕见的技术上的团结展示。本周,Apple 宣布他们也将加入

DTP 的目标是帮助用户通过开源平台将数据从一个在线服务转移到另一个在线服务。DTP 旨在通过使用 API 和授权工具来取消中间人,以便用户将数据从一个服务转移到另一个服务。这将消除用户下载数据然后将其上传到另一个服务的需要。Apple 加入 DTP 的选择将允许用户将数据传入和传出 iCloud,这可能是隐私权拥护者的一大胜利。

其它新闻

谢谢 Opensource.com 的工作人员和主持人本周的帮助。


via: https://opensource.com/article/19/8/news-august-3

作者:Lauren Maffeo 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出