whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[zh] Sync changes that remove logging solutions

Browse Source
This commit is contained in:
Qiming Teng
2021-02-14 20:42:47 +08:00
parent a4e48ec21a
commit 9ee0e9c077
4 changed files with 489 additions and 806 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/tasks/debug-application-cluster/events-stackdriver.md
-156
View File
@@ -1,156 +0,0 @@
---
content_type: concept
title: StackDriver 中的事件
---
<!--
reviewers:
- piosz
- x13n
content_type: concept
title: Events in Stackdriver
-->
<!-- overview -->
<!--
Kubernetes events are objects that provide insight into what is happening
inside a cluster, such as what decisions were made by scheduler or why some
pods were evicted from the node. You can read more about using events
for debugging your application in the [Application Introspection and Debugging
](/docs/tasks/debug-application-cluster/debug-application-introspection/)
section.
-->
Kubernetes 事件是一种对象，它为用户提供了洞察集群内发生的事情的能力，
例如调度程序做出了什么决定，或者为什么某些 Pod 被逐出节点。
你可以在[应用程序自检和调试](/zh/docs/tasks/debug-application-cluster/debug-application-introspection/)
中阅读有关使用事件调试应用程序的更多信息。
<!--
Since events are API objects, they are stored in the apiserver on master. To
avoid filling up master's disk, a retention policy is enforced: events are
removed one hour after the last occurrence. To provide longer history
and aggregation capabilities, a third party solution should be installed
to capture events.
-->
因为事件是 API 对象，所以它们存储在主控节点上的 API 服务器中。
为了避免主节点磁盘空间被填满，将强制执行保留策略：事件在最后一次发生的一小时后将会被删除。
为了提供更长的历史记录和聚合能力，应该安装第三方解决方案来捕获事件。
<!--
This article describes a solution that exports Kubernetes events to
Stackdriver Logging, where they can be processed and analyzed.
-->
本文描述了一个将 Kubernetes 事件导出为 Stackdriver Logging 的解决方案，在这里可以对它们进行处理和分析。
<!--
It is not guaranteed that all events happening in a cluster will be
exported to Stackdriver. One possible scenario when events will not be
exported is when event exporter is not running (e.g. during restart or
upgrade). In most cases it's fine to use events for purposes like setting up
[metrics][sdLogMetrics] and [alerts][sdAlerts], but you should be aware
of the potential inaccuracy.
-->
{{< note >}}
不能保证集群中发生的所有事件都将导出到 Stackdriver。
事件不能导出的一种可能情况是事件导出器没有运行（例如，在重新启动或升级期间）。
在大多数情况下，可以将事件用于设置
[metrics](https://cloud.google.com/logging/docs/view/logs_based_metrics) 和
[alerts](https://cloud.google.com/logging/docs/view/logs_based_metrics#creating_an_alerting_policy)
等目的，但你应该注意其潜在的不准确性。
{{< /note >}}
<!-- body -->
<!--
## Deployment
-->
## 部署 {#deployment}
### Google Kubernetes Engine
<!--
In Google Kubernetes Engine, if cloud logging is enabled, event exporter
is deployed by default to the clusters with master running version 1.7 and
higher. To prevent disturbing your workloads, event exporter does not have
resources set and is in the best effort QOS class, which means that it will
be the first to be killed in the case of resource starvation. If you want
your events to be exported, make sure you have enough resources to facilitate
the event exporter pod. This may vary depending on the workload, but on
average, approximately 100Mb RAM and 100m CPU is needed.
-->
在 Google Kubernetes Engine 中，如果启用了云日志，那么事件导出器默认部署在主节点运行版本为 1.7 及更高版本的集群中。
为了防止干扰你的工作负载，事件导出器没有设置资源，并且处于尽力而为的 QoS 类型中，这意味着它将在资源匮乏的情况下第一个被杀死。
如果要导出事件，请确保有足够的资源给事件导出器 Pod 使用。
这可能会因为工作负载的不同而有所不同，但平均而言，需要大约 100MB 的内存和 100m 的 CPU。
<!--
### Deploying to the Existing Cluster
Deploy event exporter to your cluster using the following command:
-->
### 部署到现有集群
使用下面的命令将事件导出器部署到你的集群：
```shell
kubectl create -f https://k8s.io/examples/debug/event-exporter.yaml
```
<!--
Since event exporter accesses the Kubernetes API, it requires permissions to
do so. The following deployment is configured to work with RBAC
authorization. It sets up a service account and a cluster role binding
to allow event exporter to read events. To make sure that event exporter
pod will not be evicted from the node, you can additionally set up resource
requests. As mentioned earlier, 100Mb RAM and 100m CPU should be enough.
-->
由于事件导出器访问 Kubernetes API，因此它需要权限才能访问。
以下的部署配置为使用 RBAC 授权。
它设置服务帐户和集群角色绑定，以允许事件导出器读取事件。
为了确保事件导出器 Pod 不会从节点中退出，你可以另外设置资源请求。
如前所述，100MB 内存和 100m CPU 应该就足够了。
{{< codenew file="debug/event-exporter.yaml" >}}
<!--
## User Guide
Events are exported to the `GKE Cluster` resource in Stackdriver Logging.
You can find them by selecting an appropriate option from a drop-down menu
of available resources:
-->
## 用户指南 {#user-guide}
事件在 Stackdriver Logging 中被导出到 `GKE Cluster` 资源。
你可以通过从可用资源的下拉菜单中选择适当的选项来找到它们：
<!--
<img src="/images/docs/stackdriver-event-exporter-resource.png" alt="Events location in the Stackdriver Logging interface" width="500">
-->
<img src="/images/docs/stackdriver-event-exporter-resource.png" alt="Stackdriver 日志接口中事件的位置" width="500">
<!--
You can filter based on the event object fields using Stackdriver Logging
[filtering mechanism](https://cloud.google.com/logging/docs/view/advanced_filters).
For example, the following query will show events from the scheduler
about pods from deployment `nginx-deployment`:
-->
你可以使用 Stackdriver Logging 的
[过滤机制](https://cloud.google.com/logging/docs/view/advanced_filters)
基于事件对象字段进行过滤。
例如，下面的查询将显示调度程序中有关 Deployment `nginx-deployment` 中的 Pod 的事件：
```
resource.type="gke_cluster"
jsonPayload.kind="Event"
jsonPayload.source.component="default-scheduler"
jsonPayload.involvedObject.name:"nginx-deployment"
```
{{< figure src="/images/docs/stackdriver-event-exporter-filter.png" alt="在 Stackdriver 接口中过滤的事件" width="500" >}}
content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
-197
View File
@@ -1,197 +0,0 @@
---
content_type: concept
title: 使用 ElasticSearch 和 Kibana 进行日志管理
---
<!--
reviewers:
- piosz
- x13n
content_type: concept
title: Logging Using Elasticsearch and Kibana
-->
<!-- overview -->
<!--
On the Google Compute Engine (GCE) platform, the default logging support targets
[Stackdriver Logging](https://cloud.google.com/logging/), which is described in detail
in the [Logging With Stackdriver Logging](/docs/user-guide/logging/stackdriver).
-->
在 Google Compute Engine (GCE) 平台上，默认的日志管理支持目标是
[Stackdriver Logging](https://cloud.google.com/logging/)，
在[使用 Stackdriver Logging 管理日志](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)
中详细描述了这一点。
<!--
This article describes how to set up a cluster to ingest logs into
[Elasticsearch](https://www.elastic.co/products/elasticsearch) and view
them using [Kibana](https://www.elastic.co/products/kibana), as an alternative to
Stackdriver Logging when running on GCE.
-->
本文介绍了如何设置一个集群，将日志导入
[Elasticsearch](https://www.elastic.co/products/elasticsearch)，并使用
[Kibana](https://www.elastic.co/products/kibana) 查看日志，作为在 GCE 上
运行应用时使用 Stackdriver Logging 管理日志的替代方案。
<!--
You cannot automatically deploy Elasticsearch and Kibana in the Kubernetes cluster hosted on Google Kubernetes Engine. You have to deploy them manually.
-->
{{< note >}}
你不能在 Google Kubernetes Engine 平台运行的 Kubernetes 集群上自动部署
Elasticsearch 和 Kibana。你必须手动部署它们。
{{< /note >}}
<!-- body -->
<!--
To use Elasticsearch and Kibana for cluster logging, you should set the
following environment variable as shown below when creating your cluster with
kube-up.sh:
-->
要使用 Elasticsearch 和 Kibana 处理集群日志，你应该在使用 kube-up.sh
脚本创建集群时设置下面所示的环境变量：
```shell
KUBE_LOGGING_DESTINATION=elasticsearch
```
<!--
You should also ensure that `KUBE_ENABLE_NODE_LOGGING=true` (which is the default for the GCE platform).
-->
你还应该确保设置了 `KUBE_ENABLE_NODE_LOGGING=true` （这是 GCE 平台的默认设置）。
<!--
Now, when you create a cluster, a message will indicate that the Fluentd log
collection daemons that run on each node will target Elasticsearch:
-->
现在，当你创建集群时，将有一条消息将指示每个节点上运行的 fluentd 日志收集守护进程
以 ElasticSearch 为日志输出目标：
```shell
cluster/kube-up.sh
```
```
...
Project: kubernetes-satnam
Zone: us-central1-b
... calling kube-up
Project: kubernetes-satnam
Zone: us-central1-b
+++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel
+++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d)
+++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0)
Looking for already existing resources
Starting master and configuring firewalls
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd].
NAME ZONE SIZE_GB TYPE STATUS
kubernetes-master-pd us-central1-b 20 pd-ssd READY
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip].
+++ Logging using Fluentd to elasticsearch
```
<!--
The per-node Fluentd pods, the Elasticsearch pods, and the Kibana pods should
all be running in the kube-system namespace soon after the cluster comes to
life.
-->
每个节点的 Fluentd Pod、Elasticsearch Pod 和 Kibana Pod 都应该在集群启动后不久运行在
kube-system 名字空间中。
```shell
kubectl get pods --namespace=kube-system
```
```
NAME READY STATUS RESTARTS AGE
elasticsearch-logging-v1-78nog 1/1 Running 0 2h
elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-5oq0 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-6896 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-l1ds 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-lz9j 1/1 Running 0 2h
kibana-logging-v1-bhpo8 1/1 Running 0 2h
kube-dns-v3-7r1l9 3/3 Running 0 2h
monitoring-heapster-v4-yl332 1/1 Running 1 2h
monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h
```
<!--
The `fluentd-elasticsearch` pods gather logs from each node and send them to
the `elasticsearch-logging` pods, which are part of a
[service](/docs/concepts/services-networking/service/) named `elasticsearch-logging`. These
Elasticsearch pods store the logs and expose them via a REST API.
The `kibana-logging` pod provides a web UI for reading the logs stored in
Elasticsearch, and is part of a service named `kibana-logging`.
-->
`fluentd-elasticsearch` Pod 从每个节点收集日志并将其发送到 `elasticsearch-logging` Pod，
该 Pod 是名为 `elasticsearch-logging` 的
[服务](/zh/docs/concepts/services-networking/service/)的一部分。
这些 ElasticSearch pod 存储日志，并通过 REST API 将其公开。
`kibana-logging` pod 提供了一个用于读取 ElasticSearch 中存储的日志的 Web UI，
它是名为 `kibana-logging` 的服务的一部分。
<!--
The Elasticsearch and Kibana services are both in the `kube-system` namespace
and are not directly exposed via a publicly reachable IP address. To reach them,
follow the instructions for [Accessing services running in a cluster](/docs/concepts/cluster-administration/access-cluster/#accessing-services-running-on-the-cluster).
-->
Elasticsearch 和 Kibana 服务都位于 `kube-system` 名字空间中，并且没有通过
可公开访问的 IP 地址直接暴露。要访问它们，请参照
[访问集群中运行的服务](/zh/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster)
的说明进行操作。
<!--
If you try accessing the `elasticsearch-logging` service in your browser, you'll
see a status page that looks something like this:
-->
如果你想在浏览器中访问 `elasticsearch-logging` 服务，你将看到类似下面的状态页面：
![Elasticsearch Status](/images/docs/es-browser.png)
<!--
You can now type Elasticsearch queries directly into the browser, if you'd
like. See [Elasticsearch's documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)
for more details on how to do so.
-->
现在你可以直接在浏览器中输入 Elasticsearch 查询，如果你愿意的话。
请参考 [Elasticsearch 的文档](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)
以了解这样做的更多细节。
<!--
Alternatively, you can view your cluster's logs using Kibana (again using the
[instructions for accessing a service running in the cluster](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster)).
The first time you visit the Kibana URL you will be presented with a page that
asks you to configure your view of the ingested logs. Select the option for
timeseries values and select `@timestamp`. On the following page select the
`Discover` tab and then you should be able to see the ingested logs.
You can set the refresh interval to 5 seconds to have the logs
regularly refreshed.
-->
或者，你可以使用 Kibana 查看集群的日志（再次使用
[访问集群中运行的服务的说明](/zh/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster)）。
第一次访问 Kibana URL 时，将显示一个页面，要求你配置所接收日志的视图。
选择时间序列值的选项，然后选择 `@timestamp`。
在下面的页面中选择 `Discover` 选项卡，然后你应该能够看到所摄取的日志。
你可以将刷新间隔设置为 5 秒，以便定期刷新日志。
<!--
Here is a typical view of ingested logs from the Kibana viewer:
-->
以下是从 Kibana 查看器中摄取日志的典型视图：
![Kibana logs](/images/docs/kibana-logs.png)
## {{% heading "whatsnext" %}}
<!--
Kibana opens up all sorts of powerful options for exploring your logs! For some
ideas on how to dig into it, check out [Kibana's documentation](https://www.elastic.co/guide/en/kibana/current/discover.html).
-->
Kibana 为浏览你的日志提供了各种强大的选项！有关如何深入研究它的一些想法，
请查看 [Kibana 的文档](https://www.elastic.co/guide/en/kibana/current/discover.html)。