mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-21 02:10:11 +08:00
Merge branch 'master' of https://github.com/LCTT/TranslateProject into translating
This commit is contained in:
geekpi
commit
dd6e7441b9
@ -0,0 +1,176 @@
|
||||
[#]: subject: "7 key components of observability in Python"
|
||||
[#]: via: "https://opensource.com/article/21/11/observability-python"
|
||||
[#]: author: "Moshe Zadka https://opensource.com/users/moshez"
|
||||
[#]: collector: "lujun9972"
|
||||
[#]: translator: "Yufei-Yan"
|
||||
[#]: reviewer: "wxy"
|
||||
[#]: publisher: "wxy"
|
||||
[#]: url: "https://linux.cn/article-14889-1.html"
|
||||
|
||||
Python 中可观测性的 7 个关键部分
|
||||
======
|
||||
|
||||
> 学习为什么 Python 中的可观测性很重要，以及如何在你的软件开发生命周期中实现它。
|
||||
|
||||
|
||||
|
||||
你写的应用会执行很多代码，而且是以一种基本上看不到的方式执行。所以你是怎么知道：
|
||||
|
||||
* 代码是否在运行？
|
||||
* 是不是在正常工作？
|
||||
* 谁在使用它，如何使用？
|
||||
|
||||
可观测性是一种能力，可以通过查看数据来告诉你，你的代码在做什么。在这篇文章中，主要关注的问题是分布式系统中的服务器代码。并不是说客户端应用代码的可观测性不重要，只是说客户端往往不是用 Python 写的。也不是说可观测性对数据科学不重要，而是在数据科学领域的可观测性工具（大多是 Juptyter 和快速反馈）是不同的。
|
||||
|
||||
### 为什么可观测性很重要
|
||||
|
||||
所以，为什么可观测性重要呢？在软件开发生命周期（SDLC）中，可观测性是一个关键的部分。
|
||||
|
||||
交付一个应用不是结束，这只是一个新周期的开始。在这个周期中，第一个阶段是确认这个新版本运行正常。否则的话，很有可能需要回滚。哪些功能正常运行？哪些功能有细微的错误？你需要知道发生了什么，才能知道接下来要怎么做。这些东西有时候会以奇怪的方式不能正常运行。不管是天灾，还是底层基础设施的问题，或者应用进入了一种奇怪的状态，这些东西可能在任何时间以任何理由停止工作。
|
||||
|
||||
在标准 SDLC 之外，你需要知道一切都在运行中。如果没有，有办法知道是怎么不能运行的，这是非常关键的。
|
||||
|
||||
### 反馈
|
||||
|
||||
可观测性的第一部分是获得反馈。当代码给出它正在做什么的信息时，反馈可以在很多方面提供帮助。在模拟环境或测试环境中，反馈有助于发现问题，更重要的是，以更快的方式对它们进行分类。这可以改善在验证步骤中的工具和交流。
|
||||
|
||||
当进行<ruby>金丝雀部署<rt>canary deployment</rt></ruby>或更改特性标志时，你需要知道是否要继续，还是等更长时间，或者回滚，反馈就显得很重要了。
|
||||
|
||||
### 监控
|
||||
|
||||
有时候你怀疑有些东西不太对。也许是一个依赖服务有问题，或者是社交网站爆出了大量你的网站的问题。也许在相关的系统中有复杂的操作，然后你想确保你的系统能完美处理。在这些情况下，你就想把可观测性系统的数据整合到控制面板上。
|
||||
|
||||
当写一个应用的时候，这些控制面板需要是设计标准的一部分。只有当你的应用能把数据共享给这些控制面板，它们才会把这些数据显示出来。
|
||||
|
||||
### 警报
|
||||
|
||||
看控制面板超过 15 分钟就像看着油漆变干一样。任何人都不应该遭受这种折磨。对于这种任务，我们要有报警系统。报警系统将可观测性数据与预期数据进行对比，当它们不匹配的时候就发出通知。完全深入研究时间管理超出了本文的范围。然而，从两方面来说，可观测应用是<ruby>报警友好的<rt>alert-friendly</rt></ruby>：
|
||||
|
||||
* 它们有足够多，足够好的数据，发出的警报才是高质量的。
|
||||
* 警报有足够的数据，或者接收者可以很容易的得到数据，这样有助于找到源头。
|
||||
|
||||
高质量警报有三个特点：
|
||||
|
||||
* 较少的错报：如果有警报，那一定是有问题了。
|
||||
* 较少的漏报：如果有问题，那一定有警报触发。
|
||||
* 及时性：警报会迅速发出以减少恢复时间。
|
||||
|
||||
这三个特点是互相有冲突的。你可以通过提高监测的标准来减少错误警报，代价是增加了漏报。你也可以通过降低监测的门槛来减少漏报，代价是增加错报。通过收集更多数据，你也可以同时减少错报和漏报，而代价是降低了及时性。
|
||||
|
||||
同时改善这三个参数就更难了。这就要求高质量的可观测性数据。更高质量的数据可以同时改善这三个特点。
|
||||
|
||||
### 日志
|
||||
|
||||
有的人喜欢嘲笑用打印来调试的方法。但是，在一个大多数软件都不在你本机运行的世界里，你所能做的只有打印调试。日志记录就是打印调试的一种形式。尽管它有很多缺点，但 Python 日志库提供了标准化的日志记录。更重要的是，它意味着你可以通过这些库去记录日志。
|
||||
|
||||
应用程序要负责配置日志的记录方式。讽刺地是，在应用程序对配置日志负责了多年以后，现在越来越不是这样了。在现代容器<ruby>编排<rt>orchestration</rt><ruby>环境中，现代应用程序记录标准错误和标准输出，并且信任<ruby>编排<rt>orchestration</rt><ruby>系统可以合理的处理日志。
|
||||
|
||||
然而，你不应该依赖库，或者说，其他任何地方。如果你想让操作的人知道发生了什么，_使用日志，而不是打印_。
|
||||
|
||||
#### 日志级别
|
||||
|
||||
日志记录的一个最重要功能就是 _日志级别_。不同的日志级别可以让你合理的过滤并分流日志。但是这只有在日志级别保持一致的情况下才能做到。最后，你应该在整个应用程序中保持日志级别的一致性。
|
||||
|
||||
选择不兼容语义的库可以通过在应用层面的适当配置来追溯修复，这只需要通过使用 Python 中最重要的通用风格做到：`getLogger(__name-_)`。
|
||||
|
||||
大多数合理的库都会遵循这个约定。<ruby>过滤器<rt>Filters</rt></ruby>可以在日志对象发出之前就地修改它们。你可以给处理程序附加一个过滤器，这个处理程序会根据名称修改消息，使其具有合适的级别。
|
||||
|
||||
```
|
||||
import logging
|
||||
LOGGER=logging.getLogger(__name__)
|
||||
```
|
||||
|
||||
考虑到这一点，你现在必须明确日志级别的语义。这其中有很多选项，但是下面这些是我的最爱：
|
||||
|
||||
* `Error`：发送一个即时警告。应用程序处于一个需要操作人员引起注意的状态。（这意味着包含 `Critical` 和 `Error`）
|
||||
* `Warning`：我喜欢把这些称作“工作时间警报”。这种情况下，应该有人在一个工作日内关注一下。
|
||||
* `Info`：这是在正常工作流程中发出的。如果怀疑有问题的时候，这个是用来帮助人们了解应用程序在做什么的。
|
||||
* `Debug`：默认情况下，这个不应该在生产环境中出现。在模拟环境或开发环境下，可以发出来，也可以不发。如果需要更多的信息，在生产环境也可以特地被打开。
|
||||
|
||||
任何情况下都不要在日志中包含<ruby>个人身份信息<rt>Personal Identifiable Information</rt></ruby>（PII）或密码。无论日志级别是什么，都是如此，比如级别更改，激活调试级别等等。日志聚合系统很少是 <ruby>PII 安全<rt>PII-safe</rt></ruby>的，特别是随着 PII 法规的不断发展（HIPAA、GDPR 等等）。
|
||||
|
||||
#### 日志聚合
|
||||
|
||||
现代系统几乎都是分布式的。<ruby>冗余<rt>redundancy</rt><ruby>、<ruby>扩展性<rt>scaling</rt></ruby>，有时是<ruby>管辖权<rt>jurisdictional</rt></ruby>需要更多的水平分布。微服务意味着垂直分布。登录到每个机器去查看日志已经是不现实的了。出于合理的控制原因，允许开发人员登录到机器中会给予他们更多的权限，这不是个好主意。
|
||||
|
||||
所有的日志都应该被发到一个聚合器。有一些商业的方案，你可以配置一个 ELK 栈，或者也可以使用其他的数据库（SQL 或则 no-SQL）。作为一个真正的低技术解决方案，你可以将日志写入文件，然后将它们发送到对象存储中。有很多解决方案，但是最重要的事情是选择一个，并且将所有东西聚合到一起。
|
||||
|
||||
#### 记录查询
|
||||
|
||||
在将所有东西记录到一个地方后，会有很多日志。具体的聚合器可以定义如何写查询，但是无论是通过从存储中搜索还是写 NoSQL 查询，记录查询以匹配源和细节都是很有用的。
|
||||
|
||||
### 指标抓取
|
||||
|
||||
<ruby>指标抓取<rt>Metric Scraping</rt><ruby>是一个<ruby>服务器拉取<rt>server pull</rt><ruby>模型。指标服务器定时和应用程序连接，并且拉取指标。
|
||||
|
||||
最后，这意味着服务器需要连接和找到所有相关的应用服务器。
|
||||
|
||||
#### 以 Prometheus 为标准
|
||||
|
||||
如果你的指标聚合器是 Prometheus，那么 [Prometheus][2] 格式做为一个<ruby>端点<rt>endpoint</rt></ruby>是很有用的。但是，即使聚合器不是 Prometheus，也是很有用的。几乎所有的系统都包含与 Prometheus 端点兼容的<ruby>垫片<rt>shim</rt></ruby>
|
||||
|
||||
使用客户端 Python 库给你的应用程序加一个 Prometheus 垫片，这将使它能够被大多数的指标聚合器所抓取。当 Prometheus 发现一个服务器，它就期望找到一个指标端点。这经常是应用程序路由的一部分，通常在 `/metrics` 路径下。不管 Web 应用的平台是什么，如果你能在一个端点下运行一个定制类型的定制字节流，Prometheus 就可以将它抓取。
|
||||
|
||||
对于大多数流行的框架，总有一个中间件插件或者类似的东西收集指标，如延迟和错误率。通常这还不够。你需要收集定制的应用数据：比如，每个端点的缓存<ruby>命中/缺失<rt>hit/miss</rt></ruby>率，数据库延迟，等等。
|
||||
|
||||
#### 使用计数器
|
||||
|
||||
Prometheus 支持多个数据类型。一个重要且巧妙的类型就是计数器。计数器总是在前进 —— 但有一点需要注意。
|
||||
|
||||
当应用重置，计数器会归零。计数器中的这些“<ruby>历时<rt>epochs</rt></ruby>”通过将计数器“创建时间”作为元数据发送来管理。Prometheus 知道不去比较两个不同<ruby>历时<rt>epochs</rt></ruby>的计数器。
|
||||
|
||||
#### 使用仪表值
|
||||
|
||||
仪表值会简单很多：它们测量瞬时值。用它们来测量会上下起伏的数据：比如，分配的总内存大小，缓存大小，等等。
|
||||
|
||||
#### 使用枚举值
|
||||
|
||||
枚举值对于整个应用程序的状态是很有用的，尽管它们可以以更精细的方式被收集。比如，你正使用一个<ruby>功能门控<rt>feature-gating</rt></ruby>框架，一个有多个状态（比如，使用中、关闭、<ruby>屏蔽<rt>shadowing</rt></ruby> 等）的功能，也许使用枚举会更有用。
|
||||
|
||||
### 分析
|
||||
|
||||
分析不同于指标，因为它们要对应连续的事件。比如，在网络服务器中，事件是一个外部请求及其产生的工作。特别是，在事件完成之前事件分析是不能被发送的。
|
||||
|
||||
事件包含特定的指标：延迟，数量，以及可能产生的对其他服务请求的细节，等等。
|
||||
|
||||
#### 结构化日志
|
||||
|
||||
现在一个可能的选择是将日志结构化。发送事件只发送带有正确格式的有效<ruby>载荷<rt>payload</rt></ruby>的日志。这个数据可以从日志聚合器请求，然后解析，并且放入一个合适的系统，这样可以对它的可见性。
|
||||
|
||||
### 错误追踪
|
||||
|
||||
你可以使用日志来追踪错误，也可以用分析来追踪错误。但是一个专门的错误系统还是值得的。一个为错误而优化的系统可以发送更多的错误，因为错误毕竟还是罕见的。这样它就可以发送正确的数据，并且用这些数据，它能做更多智能的事情。Python 中的错误追踪系统通常和一般的异常处理关联，然后收集数据，并且把它发到一个专门的错误聚合器。
|
||||
|
||||
#### 使用 Sentry
|
||||
|
||||
很多情况下，自己运行 Sentry 是正确的做法。当错误发生时，就说明有些东西就出问题了。可靠地删除敏感数据是不可能的，因为一定有会出现敏感数据被发送到不应该的地方。
|
||||
|
||||
通常，这种工作量并不会很大：异常并不常出现。最后，这个系统并不需要很高的质量，也不需要高可靠性的备份。昨天的错误应该已经修复了，希望如此，如果没有，你还会发现的！
|
||||
|
||||
### 快速、安全、可重复：三者都要
|
||||
|
||||
可观测的系统开发起来更快，因为它们可以给你提供反馈。它们运行起来也更安全，因为当出问题的时候，它们也会更早的让你知道。最后，因为有反馈回路，可观测性也有助于围绕它构建可重复的过程。可观测性可以让你了解你的应用程序。而更了解它们，就胜利了一半。
|
||||
|
||||
#### 磨刀不误砍柴功
|
||||
|
||||
构建所有的可观测层是一件困难的事情。总会让人感觉是在浪费的工作，或者更像是“可以有，但是不急”。
|
||||
|
||||
之后再做这个可以吗？也许吧，但是不应该。正确的构建可观测性可以加速后面所有阶段的开发：测试、监控，甚至是培训新人。在一个和科技行业一样动荡的行业，减少培训新人的工作量绝对是值得的。
|
||||
|
||||
事实上，可观测性很重要，所以尽早把它写出来，然后就可以在整个过程中进行维护。反过来，它也会帮你维护你的软件。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/21/11/observability-python
|
||||
|
||||
作者：[Moshe Zadka][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[MCGA](https://github.com/Yufei-Yan)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/moshez
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/search_find_code_python_programming.png?itok=ynSL8XRV (Searching for code)
|
||||
[2]: https://opensource.com/article/21/7/run-prometheus-home-container
|
||||
@ -3,83 +3,86 @@
|
||||
[#]: author: "Sagar Sharma https://itsfoss.com/author/sagar/"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: "geekpi"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
[#]: reviewer: "wxy"
|
||||
[#]: publisher: "wxy"
|
||||
[#]: url: "https://linux.cn/article-14888-1.html"
|
||||
|
||||
AppFlowy：Notion 的开源替代品
|
||||
======
|
||||
简介：AppFlowy 旨在成为 Notion 的开源替代品，为你提供更好的隐私。让我们更多地探索它。
|
||||
|
||||
虽然 Notion（项目管理/笔记工具）的功能非常出色，但它并不是一个开源解决方案。此外，它没有 Linux 桌面客户端。
|
||||
|
||||
|
||||
那么，对于 Linux 来说，更透明、更私密和可用的替代方案是什么？
|
||||
> AppFlowy 旨在成为 Notion 的开源替代品，为你提供更好的隐私保护。让我们了解一下它。
|
||||
|
||||
虽然项目管理/笔记工具 Notion 功能非常出色，但它并不是一个开源解决方案。此外，它没有 Linux 桌面客户端。
|
||||
|
||||
那么，对于 Linux 用户来说，更透明、更私密和可用的替代方案是什么？
|
||||
|
||||
这就是 AppFlowy 大放异彩的地方！
|
||||
|
||||
AppFlowy 使用 Rust 和 Flutter 构建，遵循一种最小的方式来简化事情，但有足够的空间进行调整。
|
||||
AppFlowy 使用 Rust 和 Flutter 构建，遵循极简原则，但提供了足够的调整空间。
|
||||
|
||||
### AppFlowy 是隐私和用户体验的完美结合
|
||||
|
||||
![appflowy][1]
|
||||
|
||||
AppFlowy 是相当新的。我们在去年首次推出后[报告][2]了它的发展状况。
|
||||
AppFlowy 是相当新的。在它去年首次推出后，我们曾 [报告][2] 了它的发展状况。
|
||||
|
||||
这是一个开源项目，旨在克服 [Notion][3] 在安全和隐私方面的一些限制。它可以帮助你管理任务、添加待办事项列表、添加截止日期、跟踪事件、添加页面以及为你的笔记/任务设置文本格式。
|
||||
这是一个开源项目，旨在克服 [Notion][3] 在安全和隐私方面的一些限制。它可以帮助你管理任务、添加待办事项列表、截止日期、跟踪事件、添加页面，以及为你的笔记/任务设置文本格式。
|
||||
|
||||
但不仅仅是安全性。用户体验也很重要。而且，AppFlowy 在这方面做得很好，甚至比 Notion 更好。
|
||||
不仅仅是安全性。用户体验也很重要。而 AppFlowy 在这方面做得很好，甚至比 Notion 更好。
|
||||
|
||||
请注意，该项目仍处于**测试阶段**。
|
||||
请注意，该项目仍处于 **测试阶段**。
|
||||
|
||||
目前，该项目的目标不是更好的设计和功能，而是数据隐私、原生体验和社区驱动的机会。
|
||||
目前，该项目的目标不是提供更好的设计和功能，而是数据隐私、原生体验和社区驱动。
|
||||
|
||||
#### Notion 与 AppFlowy：你的优先事项是什么？
|
||||
### Notion 与 AppFlowy，如何选择？
|
||||
|
||||
虽然它旨在取代 Notion 作为开源解决方案，但它可能并不适合所有人。
|
||||
虽然它旨在作为取代 Notion 的开源解决方案，但它可能并不适合所有人。
|
||||
|
||||
因此，如果你要选择 AppFlowy 而不是 Notion，你将获得以下好处：
|
||||
|
||||
##### 透明度
|
||||
#### 透明度
|
||||
|
||||
AppFlowy 是一个开源项目，因此随时欢迎你查看和修改代码。
|
||||
AppFlowy 是一个开源项目，因此你可以随时查看和修改代码。
|
||||
|
||||
##### 隐私
|
||||
#### 隐私
|
||||
|
||||
Notion 可以作为闭源软件直接访问你在云中的私有数据。与此相比，你可以根据自己的喜好托管 AppFlowy。
|
||||
作为闭源软件，Notion 可以直接访问你在云中的私有数据。与之相比，你可以根据自己的喜好自行托管 AppFlowy。
|
||||
|
||||
你的所有个人数据都将保留在你身边，你可以完全控制它。开发人员还提到他们正在使用离线模式来为本地安装带来更好的支持。
|
||||
你的所有个人数据都将保留在你身边，你可以完全控制它。开发人员还提到他们正在使用离线模式来更好的支持本地安装。
|
||||
|
||||
##### 性能和原生体验
|
||||
#### 性能和原生体验
|
||||
|
||||
AppFlowy 使用 Rust 和 Flutter 构建，在提供现代用户体验的同时牢记性能。
|
||||
AppFlowy 使用 Rust 和 Flutter 构建，在提供现代用户体验的同时将性能置于优先位置。
|
||||
|
||||
不仅限于此，你还可以在 Linux 上获得良好的原生体验，这是 Notion 所没有的。
|
||||
|
||||
### AppFlowy 的特点
|
||||
### AppFlowy 的功能
|
||||
|
||||
![appflowy screenshot 1][4]
|
||||
|
||||
AppFlowy 在功能方面可能并不优越，但它确实提供了几个基本功能。
|
||||
AppFlowy 在功能方面可能并不优越，但它确实提供了基本的功能。
|
||||
|
||||
随着开发的继续，您可以期待更多的功能添加。一些现有的亮点包括：
|
||||
随着开发的继续，你可以期待它会添加更多的功能。一些现有的功能包括：
|
||||
|
||||
* 原生跨平台支持。
|
||||
* 能够自行托管或将其安装在你的计算机上。
|
||||
* 可定制性。
|
||||
* 原生的跨平台支持。
|
||||
* 能够自行托管或将其安装在你的本地计算机上。
|
||||
* 可定制。
|
||||
* 数据隐私（重中之重）。
|
||||
* 单一代码库，便于更好地维护。
|
||||
* 社区驱动的可扩展性。
|
||||
* 简约的用户界面。
|
||||
* 添加待办事项，管理任务。
|
||||
* 高亮文本和基本格式。
|
||||
* 可以添加待办事项、管理任务。
|
||||
* 文本高亮和基本的格式化。
|
||||
* 用于编辑单元格/网格的键盘快捷键。
|
||||
* 深色模式支持。
|
||||
* 支持深色模式。
|
||||
|
||||
#### 在 Linux 上安装 AppFlowy
|
||||
|
||||
由于这仍处于测试阶段，它在默认仓库中不可用，并且没有任何维护的 PPA，也没有任何 Flatpak/Snap 包。
|
||||
由于它仍处于测试阶段，在默认仓库中还不可用，并且没有维护任何 PPA，也没有 Flatpak/Snap 包。
|
||||
|
||||
但是，你可以通过给定的命令轻松安装 AppFlowy（仅在 Ubuntu 20.04 LTS 和 Arch X86_64 上测试）：
|
||||
但是，你可以通过给定的命令轻松安装 AppFlowy（仅在 Ubuntu 20.04 LTS 和 Arch X86_64 上测试过）：
|
||||
|
||||
```
|
||||
wget https://github.com/AppFlowy-IO/AppFlowy/releases/download/0.0.4/AppFlowy-linux-x86.tar.gz
|
||||
@ -87,7 +90,7 @@ tar -xzvf AppFlowy-linux-x86.tar.gz
|
||||
cd AppFlowy
|
||||
```
|
||||
|
||||
要运行 AppFlowy，请使用给定的命令：
|
||||
要运行 AppFlowy，请使用该命令：
|
||||
|
||||
```
|
||||
./app_flowy
|
||||
@ -95,31 +98,31 @@ cd AppFlowy
|
||||
|
||||
要在你的系统菜单中注册 AppFlowy，你必须执行以下附加步骤：
|
||||
|
||||
首先，你必须更改 AppFlowy logo 的默认名称：
|
||||
首先，你必须更改 AppFlowy 徽标的默认名称：
|
||||
|
||||
```
|
||||
mv flowy_logo.svg app_flowy.svg
|
||||
```
|
||||
|
||||
现在，你必须将临时 Linux 桌面文件复制到可用的 Linux 桌面文件中。
|
||||
现在，你必须将 Linux 桌面文件模板复制为正式的 Linux 桌面文件。
|
||||
|
||||
```
|
||||
cp appflowy.desktop.temp app_flowy.desktop
|
||||
```
|
||||
|
||||
是时候对配置文件进行一些更改了。
|
||||
然后对配置文件进行一些更改。
|
||||
|
||||
```
|
||||
sudo nano appflowy.desktop
|
||||
```
|
||||
|
||||
在这里，你必须将 [CHANGE_THIS] 替换为图标和可执行文件的路径。
|
||||
在这里，你必须将 `[CHANGE_THIS]` 替换为图标和可执行文件的对应路径。
|
||||
|
||||
![add location of icon and exec file][5]
|
||||
|
||||
使用 CTRL + O 保存更改并使用 CTRL + X 退出。
|
||||
使用 `CTRL + O` 保存更改并使用 `CTRL + X` 退出。
|
||||
|
||||
最后，移动 desktop 文件，以便你的系统可以读取它。
|
||||
最后，移动桌面文件，以便你的系统可以读取它。
|
||||
|
||||
```
|
||||
mv app_flowy.desktop ~/.local/share/applications/.
|
||||
@ -129,17 +132,17 @@ mv app_flowy.desktop ~/.local/share/applications/.
|
||||
|
||||
![appflowy in system menu][6]
|
||||
|
||||
无论哪种情况，你都可以查看 AppFlowy 的 [官方文档][7] 以从源代码构建它。在其官方网站上探索更多关于它的信息。
|
||||
无论哪种情况，你都可以查看 AppFlowy 的 [官方文档][7] 以从源代码构建它。在其官方网站上了解更多关于它的信息。
|
||||
|
||||
[AppFlowy][8]
|
||||
> **[AppFlowy][8]**
|
||||
|
||||
### 总结
|
||||
|
||||
如果你需要具有原生 Linux 体验的简单的类 Notion 应用，AppFlowy 是一个有趣的选择。
|
||||
|
||||
考虑到它正在积极开发中并且远非 Notion 的完全替代品，你应该预期会出现错误/问题。
|
||||
考虑到它正在积极开发中，并且远非 Notion 的完全替代品，肯定会出现一些错误/问题。
|
||||
|
||||
作为 Notion 的开源替代品？它可以工作！你可以使用它来管理任务、添加笔记和制作待办事项列表。
|
||||
作为 Notion 的开源替代品？它可以的！你可以使用它来管理任务、添加笔记和制作待办事项列表。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
@ -148,7 +151,7 @@ via: https://itsfoss.com/appflowy/
|
||||
作者：[Sagar Sharma][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -0,0 +1,124 @@
|
||||
[#]: subject: "Linus Torvalds Uses Apple MacBook Hardware to Release Linux Kernel 5.19"
|
||||
[#]: via: "https://news.itsfoss.com/linux-kernel-5-19-release/"
|
||||
[#]: author: "Jacob Crume https://news.itsfoss.com/author/jacob/"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: " "
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
Linus Torvalds Uses Apple MacBook Hardware to Release Linux Kernel 5.19
|
||||
======
|
||||
Linux Kernel 5.19 is introducing support for a new CPU architecture, along with improvements for next-gen components from Intel and AMD.
|
||||
|
||||
![linux kernel][1]
|
||||
|
||||
Three months after the [last kernel release][2], Linux Kernel 5.19 is finally here. This exciting release brings plenty of improvements to every aspect of the kernel and opens up opportunities with new hardware.
|
||||
|
||||
The most interesting part is that the Linux creator Linus Torvalds used an Apple MacBook, the Arm version, to announce this release.
|
||||
|
||||
Don’t get your pitchfork out just yet. Torvalds used [Asahi Linux][3], a project dedicated to adding Linux support to Apple’s Arm-based Silicon Macbooks.
|
||||
|
||||
> On a personal note, the most interesting part here is that I did the release (and am writing this) on an arm64 laptop. It’s something I’ve been waiting for for a *loong* time, and it’s finally reality, thanks to the Asahi team. We’ve had arm64 hardware around running Linux for a long time, but none of it has really been usable as a development platform until now.
|
||||
|
||||
That’s interesting. And this is the [third time][4] Torvalds used Apple hardware for Linux development.
|
||||
|
||||
### Linux Kernel 5.19: What’s New?
|
||||
|
||||
As with all previous releases, Linux Kernel 5.19 has a lot of technical changes. However, there are only a few major ones that will have a direct impact on users, so we will focus on those here.
|
||||
|
||||
If you are interested in all the low-level code changes, you can refer to the official changelog.
|
||||
|
||||
#### LoongArch CPU Architecture Support
|
||||
|
||||
Over the past few years, it has been interesting to see Chinese chip manufacturers attempt to catch up to Intel and AMD. One way they have tried to do this is by creating their architectures, which are generally compatible with existing architectures.
|
||||
|
||||
One of the more successful of these companies is **Loongson**. However, due to their new architecture, the software support for these CPUs was pretty limited.
|
||||
|
||||
Starting with this release, these CPUs have initial support (it won’t work for booting) and will likely soon have packages ported to them.
|
||||
|
||||
We should see more progress on this with Linux Kernel 5.20.
|
||||
|
||||
#### 32-bit RISC-V Apps on 64-bit RISC-V
|
||||
|
||||
As has been the case for the recent releases, Linux Kernel 5.19 greatly improves support for the open-source RISC-V architecture. This time, this comes in the form of allowing 32-bit RISC-V apps to run on 64-bit RISC-V systems.
|
||||
|
||||
Very few 32-bit RISC-V CPUs can run Linux, meaning very few Linux packages are designed for them. And those packages already have 64-bit counterparts.
|
||||
|
||||
Even if its usefulness is limited, it is good to see RISC-V being treated as a first-class architecture and getting more improvements to bring it closer to mainstream feasibility.
|
||||
|
||||
#### Improved Arc Alchemist Support
|
||||
|
||||
It’s no surprise that Intel’s initial Arc Alchemist GPU launch is a disaster so far, Linux Kernel 5.19 is the first release where you could assume these GPUs are usable on Linux.
|
||||
|
||||
This release finally brings compute support to the Linux kernel. It is somewhat surprising this code was not merged earlier, but at least the support exists now.
|
||||
|
||||
The other major Arc improvement is significantly better power management. This comes in the form of a small tweak in Linux’s PCIe subsystem that treats the Arc GPUs as unlimited, enabling PCI Express Active State Power Management in far more configurations.
|
||||
|
||||
In essence, this change means that the GPU can now be put into an extremely low power mode when not in use, yielding some significant power savings.
|
||||
|
||||
#### Improved ARM SoC Support
|
||||
|
||||
This release brings support to several new ARM SoCs. This time around, 7 new SoCs have been added to the list, specifically:
|
||||
|
||||
* Renesas RZ/G2UL (R9A07G043)
|
||||
* Renesas RZ/V2M (R9A09G011)
|
||||
* Renesas R-Car V4H (R8A779G0)
|
||||
* Broadcom BCM47622
|
||||
* Corstone1000
|
||||
* Mediatek MT8195 (Kompanio 1200)
|
||||
* NXP i.MXRT1050
|
||||
|
||||
In addition, Apple’s M1 chip also gained some improved support. This comes from a new driver for the on-chip NVMe controller. Now, users wanting to be able of NVMe storage on their Apple Silicon Macs are able to do so, thanks to the contribution by the Asahi Linux project.
|
||||
|
||||
#### Significantly Reduced Boot Times For Azure VMs
|
||||
|
||||
Azure users, you are in for a good improvement. Thanks to a contribution by Microsoft, Azure VMs using multiple GPUs can have as many as 3 minutes shaved off their boot times!
|
||||
|
||||
To achieve this, Microsoft changed their PCI Hyper-V driver to avoid setting “PCI_COMMAND_MEMORY”, which stops the driver sending/receiving heaps of unnecessary data from each GPU, saving around 14 seconds of boot time per GPU.
|
||||
|
||||
### Other Changes
|
||||
|
||||
In addition to the ones I mentioned above, Linux Kernel 5.19 also includes
|
||||
|
||||
* Raspberry Pi Sense Hat joystick driver
|
||||
* Various BTRFS improvements
|
||||
* New Intel IFS driver
|
||||
* Intel Raptor Lake P graphics support.
|
||||
* Alder lake improvements.
|
||||
* Initial support for AMD RDNA3 graphics.
|
||||
* Performance optimizations as reported by [Phoronix][5].
|
||||
|
||||
Overall, these changes make up for a pretty decent release. Although there aren’t any major changes, Linux Kernel 5.19 continues to build on the great work of the past few Linux releases.
|
||||
|
||||
### How to Install Linux Kernel 5.19?
|
||||
|
||||
If you are using Arch Linux or Fedora, you can easily upgrade shortly. But, if you are using other Linux distributions (Pop!_OS can be an exception to some extent), you may not receive an upgrade.
|
||||
|
||||
So, if you are feeling adventurous (and know what you are doing), you can find the newer kernel listed on [Linux Kernel Archives][6]. You can download the [tarball][7] to test it out.
|
||||
|
||||
However, we recommend waiting for your Linux distribution to push an update if you do not want to take any chances. It is best to stick to what’s being offered for your Linux distribution by default.
|
||||
|
||||
[Linux Kernel Archives][8]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://news.itsfoss.com/linux-kernel-5-19-release/
|
||||
|
||||
作者：[Jacob Crume][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://news.itsfoss.com/author/jacob/
|
||||
[b]: https://github.com/lkxed
|
||||
[1]: https://news.itsfoss.com/wp-content/uploads/2022/07/linux-kernel-5-19-released.jpg
|
||||
[2]: https://news.itsfoss.com/linux-kernel-5-18-release/
|
||||
[3]: https://news.itsfoss.com/asahi-linux-alpha/
|
||||
[4]: https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0Xi0OEQ3H1uQgOdFvHgx0w@mail.gmail.com/T/#u
|
||||
[5]: https://www.phoronix.com/news/Linux-5.19-Features
|
||||
[6]: https://www.kernel.org/
|
||||
[7]: https://git.kernel.org/torvalds/t/linux-5.19.tar.gz
|
||||
[8]: https://www.kernel.org/
|
||||
@ -0,0 +1,49 @@
|
||||
[#]: subject: "What Made Fedora Choose To Use CC0 Licensed Code As The Boot"
|
||||
[#]: via: "https://www.opensourceforu.com/2022/08/what-made-fedora-choose-to-use-cc0-licensed-code-as-the-boot/"
|
||||
[#]: author: "Laveesh Kocher https://www.opensourceforu.com/author/laveesh-kocher/"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: " "
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
What Made Fedora Choose To Use CC0 Licensed Code As The Boot
|
||||
======
|
||||
![fedora-1024x614][1]
|
||||
|
||||
Open source is a challenging concept. Many people interpret this to mean that they can use a specific piece of software however they choose and that it is free to download. The actual rights you as a user are granted, however, depend largely on which licence the developers chose to share their code under. Open source software can be expensive, can restrict how you can use it, and in rare circumstances, can even land you in legal trouble.
|
||||
|
||||
The Fedora Project recently decided to reject all code that is licenced under the Creative Commons “Public Domain Dedication” CC0 licence in an effort to avoid precisely this situation. CC0 will soon be removed from the list of permissible code licences for all new submissions, however it will still be permitted for material like artwork and there might even be exceptions made for current packages on a case-by-case basis.
|
||||
|
||||
It wouldn’t ordinarily make the news if Fedora objected to a software licence. In fact, the project rejects a number of licences that are on a fairly extensive list. The unexpected aspect of this situation is that CC0 was originally regarded as a valid licence, and is only now being reclassified as a result of a shift in perspective within the greater free and open source (FOSS) community.
|
||||
|
||||
What exactly is wrong with CC0 that Fedora decided to stop supporting it, and does this indicate you shouldn’t use the licence for your own projects?
|
||||
|
||||
The part of this narrative that may surprise those who are familiar with Creative Commons and its family of licences the most is that the Fedora Project formerly approved CC0 for software in the first place. After all, the goal from the beginning was to develop a range of licences expressly for artistic works. The organization’s mission and licence requirements are stated in the name itself.
|
||||
|
||||
To “overcome legal hurdles to the sharing of information and creativity” by offering a free framework under which people and organisations might share things like music, artwork, or educational material, Creative Commons, the forerunner of the previous Open Content Project, was established in 2001. Software, however, was never a factor. Why might that be? At that time, important software licences like the MIT License and the GNU General Public License had already been around for more than ten years.
|
||||
|
||||
It seems obvious that you should probably believe a company if they go out of their way to warn you that something they have made is unsuitable for a particular use. The Creative Commons FAQ lists a number of compelling arguments against using their licences for software, but one in particular jumps out for users like the Fedora Project: patent rights.
|
||||
|
||||
This may seem contradictory given that the CC0 licence is meant for works in the public domain and that by using it, the creator expressly “waives all of his or her rights to the work globally under copyright law.” However, the issue is that copyright legislation does not apply to patents. In fact, a review of the license’s complete wording reveals that it directly tackles this in a worrying section that reads, “No trademark or patent rights held by Affirmer are waived, abandoned, relinquished, leased or otherwise modified by this document.”
|
||||
|
||||
In other words, even while the author of something that has been licenced under CC0 may be willing to give up the rights to it, they are still free to patent it. What’s even worse is that they still retain the ability to use that patent however they see fit. Theoretically, this means that the creator of a piece of source code that was first made available under CC0 may later assert that anyone who utilised the code violated their patent and could demand royalties.
|
||||
|
||||
It’s very obvious why something like this would worry the Fedora Project. Consider a scenario where CC0-licensed code is incorporated into a system’s core package and then made available to millions of users. Out of nowhere, the original creator appears, alleges patent violation, and wants payment. Could Red Hat’s or Fedora’s attorneys refute such a claim? Maybe. Is it worth it to use CC0 code in order to find out for sure? Zero chance.
|
||||
|
||||
It’s important to note that this is not at anyway a new issue. In fact, back in 2012, the patent clause prevented the Open Source Initiative’s (OSI) License Review Committee from conclusively determining if CC0 genuinely complied with their definition of an open source licence. The Committee was unable to come to an agreement because its members believed that included such terms in a software licence would create a risky precedent. Fedora’s decision to ever accept CC0 in the first place is even more puzzling given its turbulent history.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.opensourceforu.com/2022/08/what-made-fedora-choose-to-use-cc0-licensed-code-as-the-boot/
|
||||
|
||||
作者：[Laveesh Kocher][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.opensourceforu.com/author/laveesh-kocher/
|
||||
[b]: https://github.com/lkxed
|
||||
[1]: https://www.opensourceforu.com/wp-content/uploads/2022/08/fedora-1024x614-1-e1659346500461.jpg
|
||||
@ -0,0 +1,62 @@
|
||||
[#]: subject: "AI, ML and DL: What’s the Difference?"
|
||||
[#]: via: "https://www.opensourceforu.com/2022/08/ai-ml-and-dl-whats-the-difference/"
|
||||
[#]: author: "Bala Kalavala https://www.opensourceforu.com/author/bala-kalavala/"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: " "
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
AI, ML and DL: What’s the Difference?
|
||||
======
|
||||
We often use the terms artificial intelligence, machine learning and deep learning interchangeably, even though we read or hear about them almost each day. This article explains how these technologies evolved and in what ways they differ.
|
||||
|
||||
![AI ML and DL What’s the Difference][1]
|
||||
|
||||
Artificial intelligence (AI), machine learning (ML), and deep learning (DL) are often used interchangeably; however, they are not quite the same things. AI is the broadest concept of all, and gives a machine the ability to imitate human behaviour. ML is the application of AI into a system or machine, which helps it to self-learn and improve continually. Lastly, DL uses complex algorithms and deep neural networks to repetitively train a specific model or pattern.
|
||||
|
||||
Let’s look at the evolution and journey of each term to get a better understanding of what AI, ML and DL actually refer to.
|
||||
|
||||
#### Artificial intelligence
|
||||
|
||||
AI has a come a long way since the last 70-odd years, infiltrating into every aspect of our life, whether we know it, and like it or not. Advancements in machine learning and deep learning over the last decade have created an AI boom across industries and organisations of all sizes. Cloud service providers have added to the momentum by developing open source services that are available for free and by offering new use cases.
|
||||
|
||||
![Figure 1: Overview of AI, ML and DL][2]
|
||||
|
||||
AI is perhaps the most worked upon concept since 1956. By 2015, the wide availability of GPUs made parallel processing faster, powerful and cheaper. Cheaper options led to humongous storage of Big Data (plain text to images, to mapping, etc). This created the need for data analytics, more popularly known as data science, leading to the evolution of machine learning as an approach to achieving artificial intelligence.
|
||||
|
||||
#### Machine learning
|
||||
|
||||
ML is the use of algorithms to process, learn and make sense or predict the pattern of available data. More recently, the low-code and no-code concepts of software development are being used in machine learning as self-learning processes that give specific instructions to accomplish particular tasks. The machine is ‘trained’ by using data and algorithms, giving it the ability to learn how to perform the task and, more importantly, apply the learning to evolve continuously.
|
||||
|
||||
![Figure 2: Evolution of AI, ML and DL][3]
|
||||
|
||||
ML was evolved when the developer community focused on AI, and then developed algorithmic decision-tree learning, logic programming, clustering, parallel processing and reinforcement learning. ML was evolved when the developer community focused on AI, and then developed algorithmic decision-tree learning, logic programming, clustering, parallel processing and reinforcement learning. These were all good steps in the right direction but not enough to solve use cases that were of interest to the world.
|
||||
|
||||
#### Deep learning
|
||||
|
||||
DL is an evolution of neural networks and machine learning, and the brainchild of the AI community. It learns about how the human mind works in specific scenarios, and then gets better at that job than humans! As an example, IBM’s Watson played chess against itself and improved at the game so much to eventually beat the world champion. Google’s AlphaGo also learnt how to play the Go board game by playing it over and over to better itself, and became the champion.
|
||||
|
||||
AI, ML and DL are evolving continuously. It’s the intent of everyone involved with data science to advance these concepts to better our daily lives. The good thing is that the open source community, private enterprises, scientists, and government agencies are all working together for this.
|
||||
|
||||
![Figure 3: Types of AI, ML and DL][4]
|
||||
|
||||
To conclude, while AI helps to create smart intelligent machines, ML helps to build AI-driven applications. DL is a subset of ML; it trains a specific model by leveraging complex algorithms for large volumes of data. As narrow AI is extremely difficult to develop, ML is addressing the opportunities in this space with rigid computing. DL helps to bring AI and ML together, at least for realising general AI.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.opensourceforu.com/2022/08/ai-ml-and-dl-whats-the-difference/
|
||||
|
||||
作者：[Bala Kalavala][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.opensourceforu.com/author/bala-kalavala/
|
||||
[b]: https://github.com/lkxed
|
||||
[1]: https://www.opensourceforu.com/wp-content/uploads/2022/06/AIML-and-DL-Whats-the-Difference.jpg
|
||||
[2]: https://www.opensourceforu.com/wp-content/uploads/2022/06/Figure-1-Overview-of-AI-ML-and-DL.jpg
|
||||
[3]: https://www.opensourceforu.com/wp-content/uploads/2022/06/Figure-2-Evolution-of-AI-ML-and-DL.jpg
|
||||
[4]: https://www.opensourceforu.com/wp-content/uploads/2022/06/Figure-3-Types-of-AI-ML-and-DL.jpg
|
||||
@ -0,0 +1,114 @@
|
||||
[#]: subject: "Padloc: An Intuitive Open-Source Password Manager"
|
||||
[#]: via: "https://itsfoss.com/padloc/"
|
||||
[#]: author: "Ankush Das https://itsfoss.com/author/ankush/"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: " "
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
Padloc: An Intuitive Open-Source Password Manager
|
||||
======
|
||||
Brief: Exploring an open-source password manager with a pleasing user interface, available cross-platform.
|
||||
|
||||
There are plenty of free and premium password managers for individuals and teams.
|
||||
|
||||
However, when it comes to open-source solutions, it is often limited to a couple of good ones like [Seahorse][1], [KeePassXC][2], and [Bitwarden][3].
|
||||
|
||||
If you have read through our list of the [best password managers for Linux][4], you might already know some of them.
|
||||
|
||||
I stumbled upon another interesting open-source password manager that could make it to that list for its user experience, i.e., **Padloc**.
|
||||
|
||||
### Padloc: A Secure Cross-Platform Password Manager App
|
||||
|
||||
![padloc screenshot][5]
|
||||
|
||||
While Padloc is not super popular, it is not just another open-source password manager.
|
||||
|
||||
You get a refreshing user experience with the app and end-to-end encryption to secure passwords. It aims to provide a clean and simple interface to work with.
|
||||
|
||||
![padloc light mode][6]
|
||||
|
||||
Free to start with, but offers paid subscriptions to unlock most features.
|
||||
|
||||
And it supports all the major platforms, including Linux, Windows, macOS, Android, and iOS.
|
||||
|
||||
You also get browser extensions for Mozilla Firefox and Google Chrome with all the available applications. So, you can always choose to access/use it on the web browser as well.
|
||||
|
||||
Interestingly, the project did not see any major updates for almost two years until recently. But, it is an actively maintained open-source project.
|
||||
|
||||
### Features of Padloc
|
||||
|
||||
![padloc active sessions][7]
|
||||
|
||||
Padloc offers a range of free and premium features. As per your requirements, you can choose to upgrade with a paid subscription.
|
||||
|
||||
Some features include:
|
||||
|
||||
* Unlimited vault items
|
||||
* Unlimited devices
|
||||
* Two-factor authentication via email
|
||||
* Add tags
|
||||
* Generate unique passwords
|
||||
* Favicon support to identify vault items
|
||||
* Dark/light mode theme
|
||||
* Active session management
|
||||
* Import/Export functionality (encrypted container/ CSV)
|
||||
* Team support (paid)
|
||||
* Multi-Factor Authentication (paid)
|
||||
* Note-taking (paid)
|
||||
* Document attachments (paid)
|
||||
* Security report (paid)
|
||||
|
||||
Technically, you get all the essential features. But, to make the most out of it, you will need the premium subscription that starts at **$3.49 per month or $34.9 per year**.
|
||||
|
||||
### Install Padloc on Linux
|
||||
|
||||
![padloc app screenshot 1][8]
|
||||
|
||||
Padloc gives you multiple options for Linux. You can download the AppImage, .deb, Snap, or the Flatpak package.
|
||||
|
||||
Furthermore, you can download a non-electron desktop client version, which is nice!
|
||||
|
||||
I tested the AppImage file, and it worked well. You can follow our guide to [use AppIma][9][ge, set up Flatpak][10], or [install deb packages][11] to get started.
|
||||
|
||||
You can check out its [official website][12] or [GitHub page][13] for more information.
|
||||
|
||||
[Padloc][14]
|
||||
|
||||
### A Slightly Expensive Password Manager for a Good User Experience
|
||||
|
||||
I was impressed with its user interface and the overall experience you get with it.
|
||||
|
||||
If you prioritize the user interface, minimalism, and open-source tech, Padloc can be a useful option, whether you decide to use it for free or pay.
|
||||
|
||||
Of course, if you want something value for money (or cheaper), you can always pick something like [Bitwarden][15].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/padloc/
|
||||
|
||||
作者：[Ankush Das][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://itsfoss.com/author/ankush/
|
||||
[b]: https://github.com/lkxed
|
||||
[1]: https://itsfoss.com/seahorse/
|
||||
[2]: https://itsfoss.com/keepassxc/
|
||||
[3]: https://itsfoss.com/bitwarden/
|
||||
[4]: https://itsfoss.com/password-managers-linux/
|
||||
[5]: https://itsfoss.com/wp-content/uploads/2022/08/padloc-screenshot.png
|
||||
[6]: https://itsfoss.com/wp-content/uploads/2022/08/padloc-light-mode.png
|
||||
[7]: https://itsfoss.com/wp-content/uploads/2022/08/padloc-active-sessions.png
|
||||
[8]: https://itsfoss.com/wp-content/uploads/2022/08/padloc-app-screenshot-1.png
|
||||
[9]: https://itsfoss.com/use-appimage-linux/
|
||||
[10]: https://itsfoss.com/flatpak-guide/
|
||||
[11]: https://itsfoss.com/install-deb-files-ubuntu/
|
||||
[12]: https://padloc.app/
|
||||
[13]: https://github.com/padloc/padloc
|
||||
[14]: https://padloc.app/
|
||||
[15]: https://itsfoss.com/bitwarden/
|
||||
@ -1,182 +0,0 @@
|
||||
[#]: subject: "7 key components of observability in Python"
|
||||
[#]: via: "https://opensource.com/article/21/11/observability-python"
|
||||
[#]: author: "Moshe Zadka https://opensource.com/users/moshez"
|
||||
[#]: collector: "lujun9972"
|
||||
[#]: translator: "MCGA"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
|
||||
Python 中可观测性的 7 个关键组件
|
||||
======
|
||||
|
||||
学习为什么 Python 中的可观测行很重要，以及如何在你的软件开发生命周期中实现它。
|
||||
![Searching for code][1]
|
||||
|
||||
你写的应用会执行很多代码，以一种看不到的方式。所以你是怎么知道：
|
||||
|
||||
* 代码是否在运行？
|
||||
* 是不是在正常工作？
|
||||
* 谁在使用它，如何使用？
|
||||
|
||||
|
||||
可观测性是一种可以通过查看数据来告诉你，你的代码在做什么的一种能力。在这篇文章中，主要关注的问题是分布式系统中的服务器代码。并不是说客户端应用代码的可观测性不重要，只是说客户端往往不是用 Python 写的。也不是说可观测性对数据科学不重要，而是在数据科学领域的可观测性工具（大多是 Juptyter 和快速反馈）是不同的。
|
||||
|
||||
### 为什么可观测性很重要
|
||||
|
||||
所以，为什么可观测性重要呢？在软件开发生命周期（SDLC）中，可观测性是一个关键的部分。
|
||||
|
||||
交付一个应用不是结束；这只是一个新周期的开始。在这个周期中，第一个阶段是确认这个新版本运行正常。否则的话，很有可能就需要回滚。哪个功能正常运行？哪些功能有小 bug？你需要知道发生了什么才能知道接下来要怎么做。这些东西有时候会以奇怪的方式不能正常运行。不管是天灾，还是底层基础设施的回滚，或者应用进入了一种奇怪的状态，这些东西可能在任何时间以任何理由停止工作。
|
||||
|
||||
在标准 SDLC 之外，你需要知道一切都在运行中。如果没有，有办法知道是怎么不能运行的，这是非常关键的。
|
||||
|
||||
### 反馈
|
||||
|
||||
可观测性的第一部分是获得反馈。当代码给出它正在做什么的信息时，反馈可以在很多方面提供帮助。在模拟环境或测试环境中，反馈有助于发现问题，更重要的是，以更快的方式对它们进行分类。这可以改善在验证步骤中的工具和交流。
|
||||
|
||||
当进行<ruby>金丝雀部署<rt>canary deployment</rt></ruby>或更改特性标志时，你需要知道是否要继续，还是等更长时间，或者回滚，反馈就显得很重要了。
|
||||
|
||||
### 监控
|
||||
|
||||
有时候你怀疑有些东西不太对。也许是一个依赖服务有问题，或者是社交网站有大量关于你的网站的问题。也许在相关的系统中有复杂的操作，然后你想确保你的系统能完美处理。在这些情况下，你就想把可观测性系统的数据整合到控制面板上。
|
||||
|
||||
当写一个应用的时候，这些控制面板需要是设计标准的一部分。只有当你的应用能把数据共享给这些控制面板，它们才会把这些数据显示出来。
|
||||
|
||||
### 警报
|
||||
|
||||
每次看控制面板超过 15 分钟就像看油漆变干一样。任何人都不应该遭受这种折磨。对于这种任务，我们要有报警系统。报警系统将可观测性数据与预期数据进行对比，当它们不匹配的时候就发出通知。完全深入研究时间管理超出了本文的范围。然而，从两方面来说，可观测应用是<ruby>报警友好的<rt>alert-friendly</rt></ruby>：
|
||||
|
||||
* 它们有足够多，足够好的数据，发出的警报才是高质量的。
|
||||
* 警报有足够的数据，或者接收者可以很容易的得到数据，这样有助于找到源头
|
||||
|
||||
|
||||
高质量警报有三个特点：
|
||||
|
||||
* 较少的错报：如果有警报，那一定是有问题了。
|
||||
* 较少的漏报：如果有问题，那一定有警报触发。
|
||||
* 及时性：警报会迅速发出以减少恢复时间。
|
||||
|
||||
这三个特点是互相有冲突的。你可以通过提高监测的标准来减少错误警报，代价是增加了漏报。你也可以通过降低监测的门槛来减少漏报，代价是增加错报。通过收集更多数据，你也可以同时减少错报和漏报，而代价是降低了及时性。
|
||||
|
||||
同时改善这三个参数就更难了。这就要求高质量的可观测性数据。更高质量的数据可以同时改善这三个特点。
|
||||
|
||||
### 日志
|
||||
|
||||
有的人喜欢嘲笑用打印来调试的方法。但是，在一个大多数软件都不在你本机运行的世界里，你所能做的只有打印调试。日志记录就是打印调试的一种形式。对于它的所有错误，Python 日志库允许标准话的日志记录。更重要的是，它意味着你可以通过这些库去记录日志。
|
||||
|
||||
应用程序要对配置日志如何记录负责。讽刺地是，在应用程序对配置日志负责了多年以后，现在越来越不是这样了。在现代容器<ruby>编排<rt>orchestration</rt><ruby>环境中，现代应用程序记录标准错误和标准输出，并且信任<ruby>编排<rt>orchestration</rt><ruby>系统可以合理的处理日志。
|
||||
|
||||
然而，你不应该依赖库，或者说，其他任何地方。如果你想让操作的人知道发生了什么，_使用日志，而不是打印_
|
||||
|
||||
#### 日志级别
|
||||
|
||||
日志记录的一个最重要功能就是 _日志级别_。不同的日志级别可以让你过滤并找到合适的日志。但是这只能在日志级别保持一致的情况下完成。最后，你应该在整个应用程序中保持日志级别的一致性。
|
||||
|
||||
在应用层面通过合理的配置，只需要这一点帮助，那些选择了不兼容语义的库就可以被修复。通过使用 Python 中最重要的通用风格：使用 `getLogger(__name-_)`。
|
||||
|
||||
大多数合理的库都会遵循这个约定。<ruby>筛选器<rt>Filters</rt></ruby>可以在发出日志对象之前就地修改它们。你可以将筛选器附加到处理程序，这个处理程序会根据名称修改消息，使其具有合适的级别。
|
||||
|
||||
```
|
||||
|
||||
import logging
|
||||
|
||||
LOGGER=logging.getLogger(__name__)
|
||||
|
||||
```
|
||||
|
||||
|
||||
考虑到这一点，你现在必须明确日志级别的语义。这其中有很多选项，但是下面这些是我的最爱：
|
||||
|
||||
* Error：立即发送一个警告。应用程序处于一个需要操作人员引起注意的状态。（这意味着有致命问题和错误）
|
||||
* Warning：我喜欢把这些称作“工作时间警报”。这种情况下，应该有人在一个工作日内关注一下。
|
||||
* Info：这是在正常工作流程中发出的。如果怀疑有问题的时候，这个是用来帮助人们了解应用程序在做什么的。
|
||||
* Debug：默认情况下，这个不应该在生产环境中出现。在模拟环境或开发环境下，可以发出来，也可以不发。如果需要更多的信息，在生产环境也可以特地被打开。
|
||||
|
||||
任何情况下都不要在日志中包含个人信心（PII：Personal Identifiable Information）或密码。无论日志级别是什么，都要这么做，比如级别更改，激活调试级别等等。日志聚合系统很少是 <ruby>PII 安全<rt>PII-safe</rt></ruby>的，特别是随着 PII 管理的进步（HIPAA，GDPR，以及其他的）。
|
||||
|
||||
#### 日志聚合
|
||||
|
||||
现代系统几乎都是分布式的。<ruby>冗余<rt>redundancy</rt><ruby>，<ruby>扩展性<rt>scaling</rt></ruby>，有时是<ruby>管辖权<rt>jurisdictional</rt></ruby>需要更多的水平分布。微服务意味着垂直分布。登录到每个机器去查看日志已经是不现实的了。出于合理的控制原因，允许开发人员登录到机器中会给予他们他多特权，这不是个好主意。
|
||||
|
||||
所有的日志都应该被发到一个聚合模块。有一些商业的方案，你可以配置一个 ELK 栈，或者也可以使用其他的数据库（SQL 或则 no-SQL）。作为一个技术含量很低的解决方案，你可以将日志写入文件，然后将他们发送到对象存储中。有很多解决方案，但是最重要的事情是选择一个并且将所有东西聚合到一起。
|
||||
|
||||
#### 日志查询
|
||||
|
||||
在将所有东西记录到一个地方后，会有很多日志。特定的聚合模块可以定义如何写查询，但是它是通过从存储中搜索还是写 NoSQL 的查询，日志查询以匹配源和详细信息是很有用的。
|
||||
|
||||
### <ruby>度量抓取<rt>Metric Scraping</rt><ruby>
|
||||
|
||||
度量抓取是一个<ruby>服务器拉取<rt>server pull</rt><ruby>模型。度量服务器定时和应用程序连接，并且拉取度量。
|
||||
|
||||
最后，这意味着服务器需要连接并且找到所有相关的应用服务器。
|
||||
|
||||
#### 以 Prometheus 为标准
|
||||
|
||||
如果你的度量聚合模块是 Prometheus，[Prometheus][2] 格式做为一个<ruby>端点<rt>endpoint</rt></ruby>是很有用的。但是，即使聚合模块不是 Prometheus，也是很有用的。几乎所有的系统都包含与 Prometheus 端点兼容的<ruby>垫片<rt>shim</rt></ruby>
|
||||
|
||||
使用客户端 Python 库给你的应用程序加一个 Prometheus 垫片，这将使他能够被大多数的度量聚合器所抓取。当 Prometheus 发现一个服务器，它就期望找到一个度量端点。这经常是应用程序路由的一部分，通常在 `/metrics` 路径下。不管 web 应用的平台是什么，如果你能在一个端点下运行一个定制类型的定制字节流，Prometheus 就可以将它抓取。
|
||||
|
||||
对于大多数流行的框架，总有一个中间件插件或者类似的东西收集度量，像延迟和错误率。通常这还不够。你需要收集定制的应用数据：比如，每个端点的缓存<ruby>命中/缺失<rt>hit/miss</rt></ruby>率，数据库延迟，等等。
|
||||
|
||||
#### 使用计数器
|
||||
|
||||
Prometheus 支持多个数据类型。一个重要且巧妙的类型就是计数器。计数器总是会现有一个警告。
|
||||
|
||||
当应用重置，计数器会归零。计数器中的这些“<ruby>时期<rt>epochs</rt></ruby>”通过将计数器“创建时间”作为元数据发送来管理。Prometheus 知道不去比较两个<ruby>时期<rt>epochs</rt></ruby>的计数器
|
||||
|
||||
#### 使用仪表
|
||||
|
||||
仪表会简单很多：他们测量瞬时值。用它们来测量会上下起伏的数据：比如，所有分配的内存，缓存大小，等等。
|
||||
|
||||
#### 使用枚举
|
||||
|
||||
枚举对于整个应用程序的状态是很有用的，尽管它们可以以更精细的方式被收集。比如，你正使用一个<ruby>功能限制<rt>feature-gating</rt></ruby>框架，一个有多个状态（比如，使用中，关闭，<ruby>屏蔽<rt>shadowing</rt></ruby>）的功能，也许使用枚举会更有用。
|
||||
|
||||
### 分析
|
||||
|
||||
分析不同于度量，因为它们要对应连续的事件。比如，在网络服务器中，一个事件是在请求和所有工作都完成之后的。特别是事件分析在事件完成之前是不能被发送的。
|
||||
|
||||
一个事件包含特定的度量：延迟，对其他服务请求的数量和可能的细节，等等。
|
||||
|
||||
#### 结构化日志
|
||||
|
||||
现在一个可能的选择是将日志结构化。发送事件只发送带有正确格式<ruby>负载<rt>payload</rt></ruby>的日志。这个数据可以从日志聚合器请求，然后解析，并且放入一个合适的系统，这样可以对它进行可视化。
|
||||
|
||||
### 错误追踪
|
||||
|
||||
你可以使用日志去追踪错误，然后你可以用分析方法去追踪错误。但是一个专门的错误系统还是值得的。一个为错误优化的系统可以发送更多的错误，因为错误毕竟还是不多。这样它就可以发送正确的数据，并且用这些数据，它能做更多智能的事情。Python 中的错误追踪系统通常和一般的异常处理关联，然后收集数据，并且把它发到一个专门的错误聚合器。
|
||||
|
||||
#### 使用 Sentry
|
||||
|
||||
很多情况下，自己运行 Sentry 是一个正确的事情。当一个错误发生时，有些东西就出问题了。可靠地删除敏感数据是不可能的，因为一定有会出现敏感数据被发送到不应该的地方。
|
||||
|
||||
通常，这种工作量并不会很大：异常并不常出现。最后，这个系统并不需要很高的质量，也不需要高可靠性的备份。但愿昨天的错误已经修复了，如果没有，你还会发现的！
|
||||
|
||||
### 快速，安全，可重复：三者都要
|
||||
|
||||
可观测的系统可以开发的更快，因为它们可以给你提供反馈。它们运行起来也更安全，因为当出问题的时候，它们也会更早的让你知道。最后，因为有反馈循环，可观测性也有助于围绕它构建可重复的过程。可观测性可以让你了解你的应用程序。而更了解它们，就胜利了一半。
|
||||
|
||||
#### 前期的投入总会有回报
|
||||
|
||||
构建所有的可观测层是一件困难的事情。总会让人感觉是在浪费工作，或者更像是“可以有，但是不急”。
|
||||
|
||||
之后再做这个可以吗？也许吧，但是不应该。正确的构建可观测性可以加速后面所有阶段的开发：测试，监控，甚至是培训新人。在一个和科技行业一样动荡的行业，减少培训新人的工作量绝对是值得的。
|
||||
|
||||
事实上，可观测性很重要，所以尽早把它写出来，然后就可以在整个过程中进行维护。反过来，它也会帮你维护你的软件。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/21/11/observability-python
|
||||
|
||||
作者：[Moshe Zadka][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[Yufei-Yan](https://github.com/Yufei-Yan)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/moshez
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/search_find_code_python_programming.png?itok=ynSL8XRV (Searching for code)
|
||||
[2]: https://opensource.com/article/21/7/run-prometheus-home-container
|
||||
Loading…
Reference in New Issue
Block a user