此系列文章一共分为三部分,分为filebeat部分,logstash部分,es部分。这里会按照每天几百亿条的数据量来考虑,去设计、部署、优化这个日志系统,来最大限度的利用资源,并达到一个最优的性能。本篇主要讲解filebeat这一块

介绍

版本:filebeat-7.12.0

是关于k8s的日志采集,部署方式是采用DaemonSet的方式,采集时按照k8s集群的namespace进行分类,然后根据namespace的名称创建不同的topic到kafka中

k8s日志文件说明

一般情况下,容器中的日志在输出到标准输出(stdout)时,会以*-json.log的命名方式保存在/var/lib/docker/containers目录中,当然如果修改了docker的数据目录,那就是在修改后的数据目录中了,例如:

# tree /data/docker/containers
/data/docker/containers
├── 009227c00e48b051b6f5cb65128fd58412b845e0c6d2bec5904f977ef0ec604d
│   ├── 009227c00e48b051b6f5cb65128fd58412b845e0c6d2bec5904f977ef0ec604d-json.log
│   ├── checkpoints
│   ├── config.v2.json
│   ├── hostconfig.json
│   └── mounts

这里能看到,有这么个文件: /data/docker/containers/container id/*-json.log,然后k8s默认会在/var/log/containers/var/log/pods目录中会生成这些日志文件的软连接,如下所示:

cattle-node-agent-tvhlq_cattle-system_agent-8accba2d42cbc907a412be9ea3a628a90624fb8ef0b9aa2bc6ff10eab21cf702.log
etcd-k8s-master01_kube-system_etcd-248e250c64d89ee6b03e4ca28ba364385a443cc220af2863014b923e7f982800.log

然后,会看到这个目录下存在了此宿主机上的所有容器日志,文件的命名方式为:

[podName]_[nameSpace]_[depoymentName]-[containerId].log

上面这个是deployment的命名方式,其他的会有些不同,例如:DaemonSetStatefulSet等,不过所有的都有一个共同点,就是

*_[nameSpace]_*.log

到这里,知道这个特性,就可以往下来看Filebeat的部署和配置了。

filebeat部署

部署采用的DaemonSet方式进行,这里没有啥可说的,参照官方文档直接部署即可

---
apiVersion: v1
data:
filebeat.yml: |-
filebeat.inputs:
- type: container
enabled: true
paths:
- /var/log/containers/*_bim5d-basic_*log
fields:
log_topic: bim5d-basic
env: dev
- type: container
enabled: true
paths:
- /var/log/containers/*_bim5d-cost_*log
fields:
log_topic: bim5d-cost
env: dev
- type: container
enabled: true
paths:
- /var/log/containers/*_giot-integration-test_*log
fields:
log_topic: giot-integration-test
env: dev
- type: container
enabled: true
paths:
- /var/log/containers/*_infra-integration-test_*log
fields:
log_topic: infra-integration-test
env: dev
- type: container
enabled: true
paths:
- /var/log/containers/*_gss-integration-test_*log
fields:
log_topic: gss-integration-test
env: dev
filebeat.config.modules:
path: ${path.config}/modules.d/*.yml
reload.enabled: false
output.kafka:
hosts: ["10.0.105.74:9092","10.0.105.76:9092","10.0.105.96:9092"]
topic: '%{[fields.log_topic]}'
partition.round_robin:
reachable_only: true
kind: ConfigMap
metadata:
name: filebeat-daemonset-config-test
namespace: default
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: filebeat
namespace: kube-system
labels:
k8s-app: filebeat
spec:
selector:
matchLabels:
k8s-app: filebeat
template:
metadata:
labels:
k8s-app: filebeat
spec:
serviceAccountName: filebeat
terminationGracePeriodSeconds: 30
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
containers:
- name: filebeat
image: docker.elastic.co/beats/filebeat:7.12.0
args: [
"-c", "/etc/filebeat.yml",
"-e",
]
env:
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
securityContext:
runAsUser: 0
# If using Red Hat OpenShift uncomment this:
#privileged: true
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 100Mi
volumeMounts:
- name: config
mountPath: /etc/filebeat.yml
readOnly: true
subPath: filebeat.yml
- name: data
mountPath: /usr/share/filebeat/data
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
- name: varlog
mountPath: /var/log
readOnly: true
volumes:
- name: config
configMap:
defaultMode: 0640
name: filebeat-config
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
- name: varlog
hostPath:
path: /var/log
# data folder stores a registry of read status for all files, so we don't send everything again on a Filebeat pod restart
- name: data
hostPath:
# When filebeat runs as non-root user, this directory needs to be writable by group (g+w).
path: /var/lib/filebeat-data
type: DirectoryOrCreate
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: filebeat
subjects:
- kind: ServiceAccount
name: filebeat
namespace: kube-system
roleRef:
kind: ClusterRole
name: filebeat
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: filebeat
labels:
k8s-app: filebeat
rules:
- apiGroups: [""] # "" indicates the core API group
resources:
- namespaces
- pods
- nodes
verbs:
- get
- watch
- list
- apiGroups: ["apps"]
resources:
- replicasets
verbs: ["get", "list", "watch"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: filebeat
namespace: kube-system
labels:
k8s-app: filebeat

启动的话直接kubectl apply -f启动即可,部署不是本篇的重点,这里不做过多介绍。

官方部署参考:https://raw.githubusercontent.com/elastic/beats/7.12/deploy/kubernetes/filebeat-kubernetes.yaml

filebeat配置简单介绍

这里先简单介绍下filebeat的配置结构

filebeat.inputs:

filebeat.config.modules:

processors:

output.xxxxx:

结构大概是这么个结构,完整的数据流向简单来说就是下面这个图:

前面也说了,我是根据根据命名空间做分类,每一个命名空间就是一个topic,如果要收集多个集群,同样也是使用命名空间做分类,只不过topic的命名就需要加个k8s的集群名,这样方便去区分了,那既然是通过命名空间来获取日志,那么在配置inputs的时候就需要通过写正则将指定命名空间下的日志文件取出,然后读取,例如:

filebeat.inputs:
- type: container
enabled: true
paths:
- /var/log/containers/*_bim5d-basic_*log
fields:
log_topic: bim5d-basic
env: dev

这里我的命名空间为bim5d-basic,然后通过正则*_bim5d-basic_*log来获取带有此命名空间名的日志文件,随后又加了个自定义字段,方便下面创建topic时使用。

这里是写了一个命名空间,如果有多个,就排开写就行了,如下所示:

filebeat.inputs:
- type: container
enabled: true
paths:
- /var/log/containers/*_bim5d-basic_*log
fields:
log_topic: bim5d-basic
env: dev
- type: container
enabled: true
paths:
- /var/log/containers/*_bim5d-cost_*log
fields:
log_topic: bim5d-cost
env: dev
- type: container
enabled: true
paths:
- /var/log/containers/*_giot-integration-test_*log
fields:
log_topic: giot-integration-test
env: dev

这种写法有一个不好的地方就是,如果命名空间比较多,那么整个配置就比较多,维护起来可能是个问题,所以建议将filebeat的配置文件通过版本控制来管理起来

注意: 日志的类型,要设置成container

上面说了通过命名空间创建topic,我这里加了一个自定义的字段log_topic,就是后面的topic的名称,但是这里有很多的命名空间,那在输出的时候,如何动态去创建呢?

output.kafka:
hosts: ["10.0.105.74:9092","10.0.105.76:9092","10.0.105.96:9092"]
topic: '%{[fields.log_topic]}'
partition.round_robin:
reachable_only: true

注意这里的写法:%{[fields.log_topic]}

那么完整的配置如下所示:

filebeat.inputs:
- type: container
enabled: true
paths:
- /var/log/containers/*_bim5d-basic_*log
fields:
log_topic: bim5d-basic
env: dev
- type: container
enabled: true
paths:
- /var/log/containers/*_bim5d-cost_*log
fields:
log_topic: bim5d-cost
env: dev
- type: container
enabled: true
paths:
- /var/log/containers/*_giot-integration-test_*log
fields:
log_topic: giot-integration-test
env: dev
output.kafka:
hosts: ["10.0.105.74:9092","10.0.105.76:9092","10.0.105.96:9092"]
topic: '%{[fields.log_topic]}'
partition.round_robin:
reachable_only: true

如果是不对日志做任何处理,到这里就结束了,但是这样又视乎在查看日志的时候少了点什么? 没错!到这里你仅仅知道日志内容,和该日志来自于哪个命名空间,但是你不知道该日志属于哪个服务,哪个pod,甚至说想查看该服务的镜像地址等,但是这些信息在我们上面的配置方式中是没有的,所以需要进一步的添砖加瓦。

这个时候就用到了一个配置项,叫做: processors, 看下官方的解释

You can define processors in your configuration to process events before they are sent to the configured output

简单来说就是处理日志

下面来重点讲一下这个地方,非常有用和重要

filebeat的processors使用介绍

添加K8s的基本信息

在采集k8s的日志时,如果按照上面那种配置方式,是没有关于pod的一些信息的,例如:

  • Pod Name
  • Pod UID
  • Namespace
  • Labels
  • 等等等等

那么如果想添加这些信息,就要使用processors中的一个工具,叫做: add_kubernetes_metadata, 字面意思就是添加k8s的一些元数据信息,使用方法可以先来看一段示例:

processors:
- add_kubernetes_metadata:
host: ${NODE_NAME}
matchers:
- logs_path:
logs_path: "/var/log/containers/"

host: 指定要对filebeat起作用的节点,防止无法准确检测到它,比如在主机网络模式下运行filebeat

matchers: 匹配器用于构造与索引创建的标识符相匹配的查找键

logs_path: 容器日志的基本路径,如果未指定,则使用Filebeat运行的平台的默认日志路径

加上这个k8s的元数据信息之后,就可以在日志里面看到k8s的信息了,看一下添加k8s信息后的日志格式:

{
"@timestamp": "2021-04-19T07:07:36.065Z",
"@metadata": {
"beat": "filebeat",
"type": "_doc",
"version": "7.11.2"
},
"log": {
"offset": 377708,
"file": {
"path": "/var/log/containers/geip-gateway-test-85545c868b-6nsvc_geip-function-test_geip-gateway-test-server-885412c0a8af6bfa7b3d7a341c3a9cb79a85986965e363e87529b31cb650aec4.log"
}
},
"fields": {
"env": "dev",
"log_topic": "geip-function-test"
},
"host": {
"name": "filebeat-fv484"
},
"agent": {
"id": "7afbca43-3ec1-4cee-b5cb-1de1e955b717",
"name": "filebeat-fv484",
"type": "filebeat",
"version": "7.11.2",
"hostname": "filebeat-fv484",
"ephemeral_id": "8fd29dee-da50-4c88-88d5-ebb6bbf20772"
},
"ecs": {
"version": "1.6.0"
},
"stream": "stdout",
"message": "2021-04-19 15:07:36.065 INFO 23 --- [trap-executor-0] c.n.d.s.r.aws.ConfigClusterResolver : Resolving eureka endpoints via configuration",
"input": {
"type": "container"
},
"container": {
"image": {
"name": "packages.gxxxxxn.com/docxxxxxp/gexxxxxxxst:3.3.1-ent-release-SNAPSHOT.20210402191241_87c9b1f841c"
},
"id": "885412c0a8af6bfa7b3d7a341c3a9cb79a85986965e363e87529b31cb650aec4",
"runtime": "docker"
},
"kubernetes": {
"labels": {
"pod-template-hash": "85545c868b",
"app": "geip-gateway-test"
},
"container": {
"name": "geip-gateway-test-server",
"image": "packages.xxxxxxx.com/dxxxxxp/gxxxxxxxxt:3.3.1-ent-release-SNAPSHOT.20210402191241_87c9b1f841c"
},
"node": {
"uid": "511d9dc1-a84e-4948-b6c8-26d3f1ba2e61",
"labels": {
"kubernetes_io/hostname": "k8s-node-09",
"kubernetes_io/os": "linux",
"beta_kubernetes_io/arch": "amd64",
"beta_kubernetes_io/os": "linux",
"cloudt-global": "true",
"kubernetes_io/arch": "amd64"
},
"hostname": "k8s-node-09",
"name": "k8s-node-09"
},
"namespace_uid": "4fbea846-44b8-4d4a-b03b-56e43cff2754",
"namespace_labels": {
"field_cattle_io/projectId": "p-lgxhz",
"cattle_io/creator": "norman"
},
"pod": {
"name": "gxxxxxxxxst-85545c868b-6nsvc",
"uid": "1e678b63-fb3c-40b5-8aad-892596c5bd4d"
},
"namespace": "geip-function-test",
"replicaset": {
"name": "geip-gateway-test-85545c868b"
}
}
}

可以看到kubernetes这个key的value有关于pod的信息,还有node的一些信息,还有namespace信息等,基本上关于k8s的一些关键信息都包含了,非常的多和全。

但是,问题又来了,这一条日志信息有点太多了,有一半多不是我们想要的信息,所以,我们需要去掉一些对于我们没有用的字段

删除不必要的字段

processors:
- drop_fields:
#删除的多余字段
fields:
- host
- ecs
- log
- agent
- input
- stream
- container
ignore_missing: true

元信息:@metadata是不能删除的

添加日志时间

通过上面的日志信息,可以看到是没有单独的一个关于日志时间的字段的,虽然里面有一个@timestamp,但不是北京时间,而我们要的是日志的时间,message里面倒是有时间,但是怎么能把它取到并单独添加一个字段呢,这个时候就需要用到script了,需要写一个js脚本来替换。

processors:
- script:
lang: javascript
id: format_time
tag: enable
source: >
function process(event) {
var str=event.Get("message");
var time=str.split(" ").slice(0, 2).join(" ");
event.Put("time", time);
}
- timestamp:
field: time
timezone: Asia/Shanghai
layouts:
- '2006-01-02 15:04:05'
- '2006-01-02 15:04:05.999'
test:
- '2019-06-22 16:33:51'

添加完成后,会多一个time的字段,在后面使用的时候,就可以使用这个字段了。

重新拼接k8s源信息

实际上,到这个程度就已经完成了我们的所有需求了,但是添加完k8s的信息之后,多了很多无用的字段,而我们如果想去掉那些没用的字段用drop_fields也可以,例如下面这种写法:

processors:
- drop_fields:
#删除的多余字段
fields:
- kubernetes.pod.uid
- kubernetes.namespace_uid
- kubernetes.namespace_labels
- kubernetes.node.uid
- kubernetes.node.labels
- kubernetes.replicaset
- kubernetes.labels
- kubernetes.node.name
ignore_missing: true

这样写也可以把无用的字段去掉,但是结构层级没有变化,嵌套了很多层,最终结果可能变成这个样子

{
"@timestamp": "2021-04-19T07:07:36.065Z",
"@metadata": {
"beat": "filebeat",
"type": "_doc",
"version": "7.11.2"
},
"fields": {
"env": "dev",
"log_topic": "geip-function-test"
},
"message": "2021-04-19 15:07:36.065 INFO 23 --- [trap-executor-0] c.n.d.s.r.aws.ConfigClusterResolver : Resolving eureka endpoints via configuration",
"kubernetes": {
"container": {
"name": "geip-gateway-test-server",
"image": "packages.xxxxxxx.com/dxxxxxp/gxxxxxxxxt:3.3.1-ent-release-SNAPSHOT.20210402191241_87c9b1f841c"
},
"node": {
"hostname": "k8s-node-09"
},
"pod": {
"name": "gxxxxxxxxst-85545c868b-6nsvc"
},
"namespace": "geip-function-test"
}
}

这样在后面使用es创建template的时候,就会嵌套好多层,查询起来也很不方便,既然这样那我们就优化下这个层级结构,继续script这个插件

processors:
- script:
lang: javascript
id: format_k8s
tag: enable
source: >
function process(event) {
var k8s=event.Get("kubernetes");
var newK8s = {
podName: k8s.pod.name,
nameSpace: k8s.namespace,
imageAddr: k8s.container.name,
hostName: k8s.node.hostname
}
event.Put("k8s", newK8s);
}

这里单独创建了一个字段k8s,字段里包含:podName, nameSpace, imageAddr, hostName等关键信息,最后再把kubernetes这个字段drop掉就可以了。最终结果如下:

{
"@timestamp": "2021-04-19T07:07:36.065Z",
"@metadata": {
"beat": "filebeat",
"type": "_doc",
"version": "7.11.2"
},
"fields": {
"env": "dev",
"log_topic": "geip-function-test"
},
"time": "2021-04-19 15:07:36.065",
"message": "2021-04-19 15:07:36.065 INFO 23 --- [trap-executor-0] c.n.d.s.r.aws.ConfigClusterResolver : Resolving eureka endpoints via configuration",
"k8s": {
"podName": "gxxxxxxxxst-85545c868b-6nsvc",
"nameSpace": "geip-function-test",
"imageAddr": "packages.xxxxxxx.com/dxxxxxp/gxxxxxxxxt:3.3.1-ent-release-SNAPSHOT.20210402191241_87c9b1f841c",
"hostName": "k8s-node-09"
}
}

这样看起来就非常清爽了。

下面贴一些一个完整的示例:

configmap参考

apiVersion: v1
data:
filebeat.yml: |-
filebeat.inputs:
- type: container
enabled: true
paths:
- /var/log/containers/*_bim5d-basic_*log
fields:
namespace: bim5d-basic
k8s: cluster01
env: prod
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}|^[1-9]\d*\.[1-9]\d*\.[1-9]\d*\.[1-9]\d*'
multiline.negate: true
multiline.match: after
multiline.timeout: 10s
- type: container
enabled: true
paths:
- /var/log/containers/*_bim5d-cost_*log
fields:
namespace: bim5d-cost
k8s: cluster01
env: prod
multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}|^[1-9]\d*\.[1-9]\d*\.[1-9]\d*\.[1-9]\d*'
multiline.negate: true
multiline.match: after
multiline.timeout: 10s
filebeat.config.modules:
path: ${path.config}/modules.d/*.yml
reload.enabled: false
processors:
- add_kubernetes_metadata:
#添加k8s描述字段
default_indexers.enabled: true
default_matchers.enabled: true
host: ${NODE_NAME}
matchers:
- logs_path:
logs_path: "/var/log/containers/"
- drop_event.when.regexp:
or:
kubernetes.pod.name: "filebeat.*"
kubernetes.pod.name: "external-dns.*"
kubernetes.pod.name: "coredns.*"
- drop_fields:
#删除的多余字段
fields:
- host
- tags
- ecs
- log
- prospector
- agent
- input
- beat
- offset
- stream
- container
- kubernetes
ignore_missing: true
- timestamp:
field: start_time
timezone: Asia/Shanghai
layouts:
- '2006-01-02 15:04:05'
- '2006-01-02 15:04:05.999'
test:
- '2019-06-22 16:33:51'
output.kafka:
hosts: ["10.0.105.74:9092","10.0.105.76:9092","10.0.105.96:9092"]
topic: '%{[fields.k8s]}-%{[fields.namespace]}'
partition.round_robin:
reachable_only: true
kind: ConfigMap
metadata:
name: filebeat-daemonset-config
namespace: default

总结

个人认为让filebeat在收集日志的第一层做一些处理,能缩短整个过程的处理时间,因为瓶颈大多在es和logstash,所以一些耗时的操作尽量在filebeat这块去处理,如果处理不了在使用logstash,另外一个非常容易忽视的一点就是,对于日志内容的简化,这样能显著降低日志的体积,我做过测试,同样的日志条数,未做简化的体积达到20G,而优化后的体积不到10G,这样的话对于整个es集群来说可以说是非常的友好和作用巨大了。

另外,可以通过版本控制,来管理filebeat的配置文件,这样在维护时也能有个记录,变化管理。


欢迎各位朋友关注我的公众号,来一起学习进步哦

日志收集之filebeat使用介绍的更多相关文章

  1. 快速搭建应用服务日志收集系统(Filebeat + ElasticSearch + kibana)

    快速搭建应用服务日志收集系统(Filebeat + ElasticSearch + kibana) 概要说明 需求场景,系统环境是CentOS,多个应用部署在多台服务器上,平时查看应用日志及排查问题十 ...

  2. 日志分析平台ELK之日志收集器filebeat

    前面我们了解了elk集群中的logstash的用法,使用logstash处理日志挺好的,但是有一个缺陷,就是太慢了:当然logstash慢的原因是它依赖jruby虚拟机,jruby虚拟机就是用java ...

  3. 分布式日志收集系统- Cloudera Flume 介绍

        Flume是Cloudera提供的日志收集系统,具有分布式.高可靠.高可用性等特点,对海量日志采集.聚合和传输, Flume支持在日志系统中定制各类数据发送方, 同时,Flume提供对数据进行 ...

  4. 日志收集之filebeat

    一,软件介绍 Filebeat是一个轻量级日志传输Agent,可以将指定日志转发到Logstash.Elasticsearch.Kafka.Redis等中.Filebeat占用资源少,而且安装配置也比 ...

  5. MySQL日志收集之Filebeat和Logstsh的一键安装配置(ELK架构)

    关于ELK是什么.做什么用,我们不在此讨论.本文重点在如何实现快速方便地安装logstash和filebeat组件,特别是在近千台DB Server的环境下(为了安全保守,公司DB Server 目前 ...

  6. elk 日志收集 filebeat 集群搭建 php业务服务日志 nginx日志 json 7.12版本 ELK 解决方案

    难的不是技术,难的是业务.熟悉业务流程才是最难的. 其实搜索进来的每一个人的需求不一样,希望你能从我的这篇文章里面收获到. 建议还是看官方文档,更全面一些. 一.背景 1,收集nginx  acces ...

  7. 轻松上手Fluentd,结合 Rainbond 插件市场,日志收集更快捷

    以往有篇文章介绍 EFK(Kibana + ElasticSearch + Filebeat)的插件日志收集.Filebeat 插件用于转发和集中日志数据,并将它们转发到 Elasticsearch ...

  8. 【转】Flume日志收集

    from:http://www.cnblogs.com/oubo/archive/2012/05/25/2517751.html Flume日志收集   一.Flume介绍 Flume是一个分布式.可 ...

  9. SpringBoot使用Graylog日志收集

    本文介绍SpringBoot如何使用Graylog日志收集. 1.Graylog介绍 Graylog是一个生产级别的日志收集系统,集成Mongo和Elasticsearch进行日志收集.其中Mongo ...

随机推荐

  1. django学习-20.python3中的特殊方法【__str__】的作用

    目录结构 1.前言 2.[__str__]特殊方法的具体使用 2.1.当使用print打印一个类被实例化后生成的对象的时候,若类里有定义了[__str__]特殊方法,是打印出这样的数据:[__str_ ...

  2. django学习-2.urls.py和view.py的相关知识点

    1.URL函数简单解析 1.1.url() 函数可以接收四个参数,分别是两个必选参数:regex.view,和两个可选参数:kwargs.name. def url(regex, view, kwar ...

  3. requests页面请求返回400:{"errors":{"username":"值必须是非空字符串。"}}

    我的描述:我引入requests包,携带json类型数据请求(POST)一个网站,,访问提示<Response [400]> 解决方案: 1.首先使用postman请求一模一样的数据,发现 ...

  4. Spring的BeanFactoryPostProcessor接口

    接口简介 BeanFactoryPostProcessor 接口是 Spring 初始化 BeanFactory 时对外暴露的扩展点,Spring IoC 容器允许 BeanFactoryPostPr ...

  5. 页面强制重新加载js的办法

    1:线上强制重新加载js的办法 js后缀?v1.0 2:开发环境强制重新加载js的办法?now=Date.now() 3:开发环境强制重新加载js的办法F12进入调试页面选择network下单 dis ...

  6. TERSUS无代码开发(笔记05)-简单实例电脑端页面设计

    案例笔记电脑端页面设计   1.新建项目(请假管理qjgl)   2.开发软件界面介绍(常用的功能按键)      3.目录中显示元件对象      4.对元件对象的操作主要方式是双击(双击哪个元件, ...

  7. vscode的代码片段

    一.快速创建一个vue单文件组件 "Create a new Component": { "prefix": "vue", "bo ...

  8. Django框架admin后台管理和用户端静态文件

    目录 一.admin后台管理 1. 如何使用 2. 路由分发的本质 二.用户上传的静态文件的展示 1. media配置 2. 手动开设media接口 三.图片防盗链 一.admin后台管理 djang ...

  9. token、cookie和session区别以及django中的cookie,csrf

    参考:https://my.oschina.net/xianggao/blog/395675?fromerr=GC9KVenE [前言]登录时需要post的表单信息. 先跳过具体案例,讲解基础知识: ...

  10. DCL之单例模式

    所谓的DCL 就是 Double Check Lock,即双重锁定检查,在了解DCL在单例模式中如何应用之前,我们先了解一下单例模式.单例模式通常分为"饿汉"和"懒汉&q ...